iop/agent-ops/skills/common/finalize-task-routing/SKILL.md

name	description
finalize-task-routing	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 lane을 사용하되 agent와 model은 런타임 실행 카탈로그가 결정한다. 이 스킬은 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이 없으면 G01G08은 local-fit, G09G10은 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일 때만 아래 명령을 정확히 한 번 실행한다.

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, catalog_route
• 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, catalog_route=review/cloud/GNN. 구체적인 agent와 model은 이 출력에 포함하지 않는다.

완료 확인

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