--- name: finalize-task-routing description: PLAN/CODE_REVIEW 작성 직전 완성된 build packet을 한 번 평가해 local-first lane, G, canonical filename을 확정한다. 최초 plan과 WARN/FAIL follow-up에서 capability gap, indivisible context, 복합 loop-risk, review rework, evidence integrity에 따른 cloud 경계를 적용할 때 사용한다. --- # Finalize Task Routing ## 목표 완성된 in-memory PLAN 하나를 한 번 평가해 build/review route를 확정한다. routing 전용 문서나 증거 탐색을 만들지 않는다. Build의 기본값은 local이며 아래 표의 cloud 조건에 일치할 때만 승격한다. 공식 review는 항상 cloud의 Codex `gpt-5.6-sol` xhigh다. 이 스킬은 task 파일을 수정하지 않는다. ## 입력 - `evaluation_mode`: `first-pass | isolated-reassessment` - `targets.build`: 구현 에이전트가 읽을 PLAN과 PLAN 작성에 이미 사용한 scope, source/test/contract, 불변조건, 검증 근거 - `targets.review`: review scope, 영향 경로, 검증 계획과 근거 - target별 closure와 근거: `scope_closed`, `context_closed`, `verification_closed`, `evidence_trusted`, `ownership_closed`, `decision_closed` - target별 G 점수: `scope_coupling`, `state_concurrency`, `blast_irreversibility`, `evidence_diagnosis`, `verification_complexity` - build 신호: `large_indivisible_context`, `matched_loop_risk_signatures`, `review_rework_count`, `evidence_integrity_failure` - closure가 false이고 cloud가 해소할 수 있을 때만 `capability_gap`: `observed`, `evidence`, `cloud_resolution` 이전 lane/G, 점수, route 사유, filename을 입력하지 않는다. `review_rework_count`와 `evidence_integrity_failure`만 route-free 운영 이력으로 전달한다. ## 판정 순서 아래 순서를 지키고 종료 조건을 만나면 즉시 멈춘다. ### 1. Snapshot 고정 PLAN body, split, verification, evidence, ownership, decision이 완성된 뒤 실행한다. - PLAN 자체를 build packet으로 사용한다. 별도 packet 요약을 만들지 않는다. - 이미 읽은 사실만 사용한다. routing 때문에 source/test/log를 다시 읽지 않는다. - split된 packet만 평가한다. parent/sibling의 파일·상태·risk를 합산하지 않는다. - `isolated-reassessment`에서는 이전 route 정보를 제거한다. 제거할 수 없으면 `blocked: isolated-routing-unavailable`로 종료한다. ### 2. Closure gate 각 target의 closure를 독립적으로 판정한다. - `scope_closed`: 정확성 조건과 영향 경로가 확정됨 - `context_closed`: PLAN과 pointer가 구현에 필요한 사실을 제공함 - `verification_closed`: 결정적 성공 판정 방법이 있음 - `evidence_trusted`: 실제 경로를 실행하는 재현 가능한 근거가 있음 - `ownership_closed`: 공유 상태와 외부 소유권이 명확함 - `decision_closed`: 사용자·외부 의미 판단 없이 완료 가능함 첫 번째로 일치하는 규칙을 적용한다. | 조건 | 결과 | |------|------| | 어느 target이든 closure 하나라도 `unknown` | `needs_evidence`; 부족한 evidence를 구체적으로 기록하고 종료 | | 어느 target이든 closure 하나라도 `false`이고 구체적인 `cloud_resolution`이 없음 | `blocked`; 해제 조건을 기록하고 종료 | | build closure가 `false`이고 `observed`, `evidence`, `cloud_resolution`이 모두 있음 | build base basis를 `capability-gap`으로 설정 | | review closure만 `false`이고 cloud가 해소함 | review gap만 기록; build basis에는 영향 없음 | | build closure가 모두 `true` | G를 계산해 build base basis 결정 | `needs_evidence`는 확인된 모든 missing evidence를 한 번에 나열한다. 입력이 달라진 뒤에만 재평가하고 같은 evidence로 반복하지 않는다. ### 3. G 계산 각 target의 다섯 값을 `0`~`2`로 채점하고 `grade=max(1, 합계)`로 계산한다. - `scope_coupling`: 국소 / 여러 연결 지점 / 다중 모듈·계약 - `state_concurrency`: 무상태 / 상태 전이 / 공유 상태·순서·동시성 - `blast_irreversibility`: 내부 가역 / 다중 호출자·지속 상태 / 외부 계약·비가역 - `evidence_diagnosis`: 직접 증거 / 복수 증거 조합 / 충돌·불신 증거 진단 - `verification_complexity`: 단일 명령 / 복수 단계·통합 / 외부·상호작용·장시간 capability gap이 없으면 G01~G08은 `local-fit`, G09~G10은 `grade-boundary`다. ### 4. Build 신호 계산 `large_indivisible_context=true`는 다음 세 조건을 모두 만족할 때만 사용한다. 1. 안전한 split을 끝냈다. 2. 하나의 correctness/transaction 판단이 여러 독립 source of truth를 동시에 요구한다. 3. 명시적 국소 규칙과 결정적 verification oracle로 축약할 수 없다. 파일이 많다는 이유만으로 true로 두지 않는다. 아래 signature를 이미 읽은 PLAN/source/test/contract에서 한 번만 확인한다. 양성 조건이 보인 이름만 기록하고, match하지 않은 signature의 부재를 증명하지 않는다. 필요한 범위가 불명확하면 risk를 `unknown`으로 만들지 말고 closure에서 처리한다. - `temporal_state`: 상태 3개 이상과 partial/retry/cancel/recovery/stale/duplicate 경로 - `concurrent_consistency`: actor 2개 이상과 atomic snapshot/lock order/exactly-once/race-free 제약 - `boundary_contract`: component 3개 이상 또는 consumer 2개 이상과 validation/immutability/compatibility 제약 - `structured_interpretation`: parser/lexer/protocol assembly/multi-source merge와 nesting/quoting/precedence/deduplication 위험 - `variant_product`: 독립 variant 축 2개 이상과 조합 검증 중복 없는 이름 수를 `loop_risk_count=0..5`로 사용한다. - `risk_boundary = large_indivisible_context || loop_risk_count >= 4` - `recovery_boundary = review_rework_count >= 2 || evidence_integrity_failure` `review_rework_count`는 같은 task path의 archived `WARN|FAIL` 수에 현재 non-PASS verdict를 더한 값이다. 첫 non-PASS follow-up은 1, 두 번째는 2다. ### 5. Build route 확정 첫 번째로 일치하는 규칙을 적용한다. | 조건 | `route_basis` | lane | |------|---------------|------| | base basis가 `capability-gap` | `capability-gap` | cloud | | base basis가 `grade-boundary` | `grade-boundary` | cloud | | base basis가 `local-fit`이고 `recovery_boundary` | `recovery-boundary` | cloud | | base basis가 `local-fit`이고 `risk_boundary` | `risk-boundary` | cloud | | 그 외 | `local-fit` | local | risk/recovery는 local-fit build의 승격 조건이다. 이미 cloud인 capability/grade basis를 덮어쓰지 않는다. grade는 lane 변경과 무관하게 보존한다. review는 `official-review`, cloud, 실제 G를 사용한다. ### 6. Finalizer 실행 `status=routed`일 때만 아래 명령을 정확히 한 번 실행한다. ```bash agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-policy.sh pair \ \ \ \ \ official-review \ ``` finalizer 출력만 사용한다. lane, grade, boundary, filename을 수작업으로 만들지 않는다. ## 출력 계약 항상 `status`, `evaluation_mode`, `missing_evidence`, `blocked_reason`을 반환한다. `status=routed`이면 다음 필드를 모두 반환한다. - 공통: `finalizer=finalize-task-policy.sh`, `finalizer_mode=pair` - target별: `closures`, `closure_basis`, `capability_gap`, `grade_scores`, `route_basis`, `lane`, `grade`, `filename` - build 전용: `base_route_basis`, `large_indivisible_context`, `matched_loop_risk_signatures`, `loop_risk_count`, `review_rework_count`, `evidence_integrity_failure`, `risk_boundary_matched`, `recovery_boundary_matched` - review 전용: `route_basis=official-review`, `adapter=codex`, `model=gpt-5.6-sol`, `reasoning_effort=xhigh` ## 완료 확인 - 기존 PLAN 분석만 사용했고 routing-only 탐색을 하지 않았는가 - split packet마다 독립 평가했는가 - G01~G08 cloud route가 선택된 `route_basis` 하나와 일치하는 근거를 갖는가 - G09~G10은 risk/recovery 신호가 있어도 `grade-boundary`를 유지하는가 - finalizer 출력과 active filename이 일치하는가 ## 금지 - unmatched signature의 부재를 찾기 위해 추가 탐색하지 않는다. - 이전 lane/G나 finding 개수를 승격 근거로 쓰지 않는다. - cloud가 해소할 수 없는 문제를 cloud route로 바꾸지 않는다. - PLAN, CODE_REVIEW, archive, complete.log를 직접 수정하지 않는다.