---
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 \
  <build-base-basis> \
  <large-indivisible-context> <loop-risk-count> \
  <review-rework-count> <evidence-integrity-failure> \
  <build-scope> <build-state> <build-blast> <build-evidence> <build-verification> \
  official-review \
  <review-scope> <review-state> <review-blast> <review-evidence> <review-verification>
```

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를 직접 수정하지 않는다.
