feat(stage2): implement S2_10 provisional bundle workflow

Apply the v4-1 strategy with reversible source bundles, bundle-level legal assessment, bounded reassessment and structural repair, and validated claim-record publication.

Preserve the original YAML backup and v4 copy. Add v3/v4 strategies, the simplicity evaluation, v4-1 strategy, v4 analysis, and S2_10 memory notes.

Validation: offline implementation records and current source/schema/artifact checks. Live runtime, legal quality, and downstream readiness remain pending.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/agent_scripts/Analysis_Stage_2_S2_10_v.4.md

@@ -0,0 +1,270 @@
+# Stage 2 S2_10 v4 작업명세서 분석
+
+## Executive Summary
+
+현행 S2_10 v4의 핵심은 **원본 자료를 코드로 잠정 묶은 다음, 묶음별 LLM이 청구권의 동일성·분리·경합과 법률관계·요건·항변·구제수단을 함께 평가하고, 코드가 결과를 검증·조립하는 구조**이다. cluster마다 상세 법률평가를 작성한 뒤 전역 통합 LLM으로 다시 판단하는 구조는 사용하지 않는다. 원본 cluster는 유지하되, 실제 추론 입력인 bundle은 여러 cluster의 자료를 포함하거나 한 cluster의 일부 자료만 포함할 수 있다. bundle 하나에서 여러 청구권 후보가 나올 수 있으므로 bundle을 확정된 단일 청구권으로 이해하면 안 된다.
+
+선언된 실행 DAG는 **2개 stage·3개 task**이다. 최초 묶음의 구성은 고정하고, 실행당 최대 8개 묶음을 병렬 평가한다. 최초 묶음 전체가 검증된 뒤 필요한 영향 범위만 완전 재평가하며, 그 재평가는 연결된 검토 범위당 최대 1회다. 출력 구조·참조 오류에 대해서는 동일 원본 입력을 사용한 구조 보정을 최대 1회 허용한다. 원본과 배치 결과를 보존하면서 활성 평가 범위를 교체하는 방식으로 가역성을 확보한다. 다만 여러 bundle에서 나온 후보를 전역적으로 동일 청구권 하나로 자동 합치는 알고리즘은 없다.
+
+**현재 파일은 runtime 검증을 기다리는 구현 상태다.** 동적 slot preflight와 provider 예산·reasoning 적용 여부의 검증값이 기본 False이므로, upstream과 I/O 검증이 성공하더라도 prepare는 모델 작업을 비우고 `TECHNICAL_INCOMPLETE`를 발행한다. 빈 map의 reducer 실행도 별도 검증이 필요하다. 또한 `AUTHORITY_INPUTS=[]`이므로 공식 근거가 필요한 확정적 판단에는 제약이 있다. 현행 S2_20은 다른 파일·Schema·완료 상태를 요구하여 이 v4 결과를 그대로 소비할 수 없다. 따라서 소스에 구현된 워크플로우, 과거 오프라인 확인 기록, 실제 backend/model 실행, 법률 품질, 후속 단계 연결을 구분해야 한다.
+
+| 분석 기준 | 확인 내용 |
+|---|---|
+| 기준일 | 2026-10-04, Asia/Seoul |
+| 분석 대상 | [agent_scripts/Stage_2_S2_10.yml](Stage_2_S2_10.yml) |
+| 식별자 | `Agent.name=Stage_2_S2_10_v4`, `Agent.version=4.1.0`, `algorithm_version=s2_10_provisional_bundles/4.1.0` |
+| 원본 크기·해시 | 145,115 bytes, 1,414 lines; SHA-256 `e4148f6d5d4c285c4d0e7523b87d9b1f689b12717be681a060e59a8d3a2d04fa` |
+| 버전 사본 | [Stage 2 루트의 Stage_2_S2_10_v.4.yml](../../../Stage_2_S2_10_v.4.yml)과 byte 단위 동일 |
+| 설계 근거 | [S2_10_revision_strategy_v.4-1.md](S2_10_revision_strategy_v.4-1.md); YAML metadata에 해당 전략의 해시가 고정되어 있음 |
+| 확인 범위 | 현재 YAML·inline Python·prompt·출력 Schema의 정적 분석, 현행 S2_00/S2_20 소스 대조 |
+| 실행 증거의 범위 | 이번 분석에서 원격 backend·MCP·LLM을 실행하지 않음. 과거 fixture 검증은 metadata와 프로젝트 MEMORY의 기록으로만 구분하여 인용 |
+
+근거: 현행 YAML `L1–L72`의 metadata, `L776–L867`의 `prepare()`, `L878–L935`의 map 선언, `L1363–L1414`의 `publish()`.
+
+## 전체 작업 DAG와 책임 경계
+
+### 한 번의 Agent 실행에 선언된 DAG
+
+```mermaid
+flowchart TD
+    U["S2_00 v6: status와 4개 불변 산출물"] --> P["S2_10_prepare / code: 검증·잠정 묶음·slot 준비"]
+    P --> G{"입력 및 runtime admission"}
+    G -->|"충족"| I["bundle_plan.items: 최대 8개 descriptor"]
+    I --> M["S2_10 / map LLM: bundle별 완전 평가, 동시성 최대 8"]
+    M --> R["reduce code: 구조·참조·coverage 검증"]
+    R --> B["불변 assessments/batch-NNNN.json"]
+    B --> C["활성 결과 조립: claims/claim_records.json"]
+    C --> S["s2_10_status.json: 마지막 기록"]
+    G -->|"runtime 미확인"| T["prepare에서 모델 items 비움·기술 미완료 상태 기록"]
+    S --> N["NEXT_WAVE_PENDING 또는 완료/기술 미완료"]
+```
+
+위 그림의 admission 분기는 inline 코드의 동작을 나타낸다. YAML에 별도 조건부 stage나 자동 반복 edge가 선언되어 있다는 뜻은 아니다. `S2_10_prepare`의 `prevs=[]`, `nexts=[S2_10]`이며 내부 `task_procedure`는 `IN → prepare task → OUT`이다. `S2_10`은 `prevs=[S2_10_prepare]`, `nexts=[]`로 map/reduce를 실행한다. 두 stage 모두 `skip_confirm=true`다. 코드가 반환한 `ok=False`·종료코드 2 이후 backend가 후속 stage를 어떻게 중단하거나 처리하는지는 실제 실행으로 확인해야 한다.
+
+### 책임 배분
+
+| 구간 | 담당하는 판단·처리 | 다음 구간에 넘기는 경계 |
+|---|---|---|
+| S2_00 | Stage 1 자료를 검증·투영하고 명시 관계에 따른 원본 cluster, scheduling waves, signals, review 원장, profile context를 생성 | cluster는 자료 연결 단위이며 청구권 확정 결과가 아님 |
+| S2_10 prepare 코드 | upstream·해시·Schema 확인, occurrence 목록, 잠정 membership, 입력 크기·배치, 재사용·보정 범위 관리 | 법률상 동일 청구권 여부나 청구 성립을 결정하지 않음 |
+| S2_10 map LLM | 권리자·의무자·법적 지위, 권리 동일성·분리·경합, 요건·반대 사실·항변/재항변·부담·구제, 자료별 처리와 추가 검토 필요성 | 완전 평가 JSON과 원본 refs를 제시; 파일 저장·완료 상태·최종 청구 ID는 작성하지 않음 |
+| S2_10 reducer 코드 | Schema·허용 참조·자료 coverage·후보 endpoint·근거 요구·입력 결속 검증, 배치 저장, 후속 검토 범위와 활성 결과 조립 | 법률판단의 타당성·원문 권위·원고/피고 특정의 실질적 정확성은 자동 인증하지 않음 |
+| 후속 작업 | 청구 선택·계산·rule binding·문안 작성 등 후속 단계가 별도 담당할 작업 | 현행 S2_20과는 계약 연결을 새로 확인해야 함 |
+
+### 여러 실행에 걸친 진행
+
+한 번의 실행은 현재 배치만 처리한다. 미평가 묶음이 남으면 `NEXT_WAVE_PENDING`을 기록하고 **같은 root에 대해 단일 writer가 Agent를 순차 재호출**해야 한다. `max_concurrency=8`은 한 배치 안의 병렬 상한이며, `MAX_BATCH_ITEMS=8`은 별도로 코드가 보장하는 실행당 admission 상한이다. 최초 배치의 앞선 결과를 뒤쪽 최초 묶음의 선행 법률결론으로 주입하지 않는다.
+
+모든 최초 묶음이 `VALIDATED`된 이후에만 `schedule_followups()`가 partition 경계 및 LLM의 `followup_requests`를 처리한다. 겹치는 원본 자료·대상 bundle의 요청을 공동 검토 범위로 모아 `F-00001` 등의 입력을 만든다. 여기서 연결되는 것은 **함께 읽을 범위**다. 자료가 연결되었다는 이유로 청구권 동일성을 전이시키는 법률적 Union-Find는 수행하지 않는다. 재평가가 예정된 기존 scope는 활성 결과에서 제외하고, 새 범위의 검증 결과로 완전히 대체한다. 기존 배치 파일은 유지한다.
+
+근거: 현행 YAML `L75–L112`, `L329–L384`의 `schedule_followups()/current_active()`, `L797–L867`의 continuation·queue, `L878–L901`의 map 설정.
+
+## 실제 실행단위와 prompt 구성
+
+### 자료 단위와 호출 단위
+
+| 단위 | 구현상의 의미 |
+|---|---|
+| 원본 cluster | S2_00이 만든 `CL-001` 등의 연결 자료 단위. S2_10은 구성원·wave coverage를 검증하며 원본 cluster를 변경하지 않음 |
+| material occurrence | 원본 member, signal occurrence, review occurrence. `ref`, `source_ref`, 원래 `cluster_refs` 등을 보존하며 동일 본문이어도 서로 다른 occurrence는 남김 |
+| 잠정 bundle | `B-00001` 등의 읽기 범위. 명시 source anchor·1-hop 관계·원본 cluster 또는 residual에 따라 구성하며 동일 청구권의 확정 병합을 뜻하지 않음 |
+| model packet | 현재 bundle의 occurrence·본문 사전·질문·profile·authority·제한을 갖춘 자기완결적 slot JSON |
+| LLM 실행 instance | `items`의 descriptor 하나에 대응하는 `Task_S2_10_assess_bundle` 1회. 원본 cluster 하나나 청구권 하나에 고정되지 않음 |
+| 청구권 후보 | 한 응답 안의 `option_local_ref`. 한 bundle에서 0개 또는 복수 후보를 생성할 수 있음 |
+| 재검토·보정 instance | 같은 map task와 같은 완전 출력 Schema를 사용. 의미상 재평가와 구조 보정은 각각 별도 제한을 가짐 |
+
+잠정 묶음의 anchor는 `transaction_id/ref`, `contract_id/ref`, `loan_id/ref`, `event_id/ref`, `occurrence_id`, `source_event_candidate_ids`, `bo_id/source_bo_id` 계열의 **정확한 식별값**이다. 코드의 우선순위는 거래·계약·대여 anchor, 없으면 사건 anchor, 그 밖에는 BO anchor다. anchor가 없는 일반 member는 명시 관계의 1-hop 이웃에서 anchor를 받거나 원본 cluster/residual에 남는다. signal·review의 연결이 불명확하면 domain 이름을 근거로 여러 묶음에 본문을 방송하지 않고 residual 묶음과 `unassigned` 기록으로 보존한다.
+
+여러 anchor에 해당하는 자료는 여러 bundle에 들어갈 수 있고, 한 원본 cluster의 자료가 서로 다른 bundle로 나뉠 수 있다. 동일 본문은 각 호출 내부의 `bodies`에 한 번만 저장하고 occurrence가 `body_ref`로 연결한다. **호출 사이에는 필요한 본문이 다시 전달된다.** 이를 전역 token deduplication이나 provider cache 적중으로 해석할 수 없다.
+
+### 세 task의 실제 구성
+
+| task | 실행 방식 | 실제 작업 |
+|---|---|---|
+| `Task_S2_10_prepare_provisional_bundles` | Code Executor `run_code`; inline Python 759 lines | 입력 검증·목록·잠정 묶음·예산·slot/plan·continuation 준비 |
+| `Task_S2_10_assess_bundle` | OpenAI `gpt-6.1-sol`; `llm_endpoint=responses`, `llm_reasoning=xhigh`, `llm_verbosity=medium` | bundle별 법률관계·청구권·요건·항변·구제의 본 추론 |
+| `Task_S2_10_validate_publish_bundles` | Code Executor `run_code`; inline Python 468 lines | map envelope·응답 검증·배치 보존·활성 결과 및 status 발행 |
+
+두 code task는 `network=agent-network`, `timeout=300`이며 `requirements`를 `httpx==0.28.1`과 `jsonschema==4.23.0`의 줄바꿈 block scalar로 선언한다. 워크스페이스의 별도 Python 모듈을 import하는 구조가 아니다. LLM task에는 `use_tools`가 없고 system prompt도 도구·검색·파일 저장을 금지한다. 파일 입력은 모델이 추가로 도구를 호출하는 방식이 아니라 backend의 `preflight=true`, `preflight_files=[{{item.input_path}}]`로 공급하도록 선언되어 있다.
+
+### prompt의 층위와 판단 요구
+
+system 메시지는 역할, 입력 정책, 8단계 알고리즘, 출력 정책, inline JSON Schema로 이루어진다. user 메시지는 `<assignment>{{item_json}}</assignment>`와 slot 파일을 이번 입력으로 사용하라는 짧은 지시다. assignment에 들어가는 것은 `bundle_ref`와 `input_path`의 작은 descriptor이며 자료 본문은 아니다. 실제 본문·근거는 preflight로 전달될 slot에 있다.
+
+| prompt 요소 | 주요 요구 |
+|---|---|
+| `<system_role>` | 대한민국 민사소송 원고 대리 지원을 위한 검토 초안 작성. 최종 법률 승인·소장 작성은 별도 |
+| `<input_policy>` | bundle은 잠정 가설, 원본 refs 유지, 다른 map 결과·미제공 자료를 읽었다고 가정하지 않음. Stage 1 발췌/투영과 원문 전체 확인을 구별 |
+| `<algorithm_to_perform>` | 당사자·지위·승계·standing, 동일성 8기준, 요건·항변/재항변·부담, 구제·경합·중복 회복, review 및 의뢰인 제약, occurrence coverage, 실제 필요한 추가 검토를 함께 판단 |
+| `<output_policy>` | 최초·재검토 모두 완전 평가. 구조 보정에서는 원본 사실과 불확실성 유지. 짧은 근거와 JSON 객체 하나만 출력 |
+| `<output_contract>` | 코드 validator와 동일한 JSON Schema. 평가·후보·관계·patch·자료별 처리·followup·공백·가정을 제한된 필드로 표현 |
+
+동일성 8기준은 ① 권리자·의무자와 법적 지위, ② 구체적 거래·발생 사건, ③ 실체법상 권리의 요건·내용, ④ 급부·대상·법률효과, ⑤ 범위·시간 구간, ⑥ 발생·변경·소멸 자료의 보완 관계, ⑦ 독립·부수·경합 관계, ⑧ 원본 근거·불확실성이다. 모든 후보 쌍의 상세 행렬을 작성하지 않는다. 동일성 판단 `identity_decision`과 청구 성립 판단 `decision`을 분리하며, 같은 당사자·공유 증거·동일 손해만으로 합치지 않는다. 자료 부족만으로 `EXCLUDED`를 선택하지 않는다.
+
+검토 범위를 늘려야 할 때는 원본 `material_refs/bundle_refs`, 질문, 사유, 필요한 `domain_ids`를 요청한다. 이미 읽은 자료에서 여러 권리로 나누는 판단은 현재 응답에서 수행하고 이를 이유로 추가 호출을 요구하지 않는다. 재검토 입력은 원본 자료와 기존 scope의 완전 평가를 `prior_results`로 포함한다. `repair_context`는 구조 오류와 제한된 이전 실패 출력을 제공하되 같은 원본 사실을 유지한다.
+
+정적 prompt 두 개의 UTF-8 본문은 합계 16,363 bytes이며, 코드의 `FIXED_PROMPT_BYTES=18,411`은 여기에 2,048 bytes의 여유를 더한 값과 일치한다. system의 16,010 bytes에는 전체 출력 Schema도 포함된다. 이는 실제 provider가 청구한 token 수가 아니다. 고정 prompt 해시는 메시지 목록을 canonical JSON으로 직렬화한 SHA-256 `c650159eadfe4d3f5526a49a5673070f8b317d0510a71b28e640f703ac2f5ecc`와 일치한다.
+
+근거: 현행 YAML `L588–L739`의 `explicit_anchors()/make_membership()/packet_for()`, `L891–L934`의 task·system/user prompt, 각 code task의 `parameters` 및 inline code.
+
+## In & Out 설명
+
+### 입력의 세 경로
+
+| 입력 경로 | 내용과 확인 |
+|---|---|
+| S2_00 완료 marker | `stage2_runs/from-stage1/s2_00/v6/ingress/ingress_status.json`; `READY/READY_WITH_ISSUES`, 고정 algorithm/schema, 실행 모드·release class, root, `written_last` 확인 |
+| marker에 등록된 4개 파일 | `ingress/stage1_input_manifest.json`, `ingress/intake_report.json`, `review/issue_ledger.base.json`, `context/case_context.json`; 정확한 artifact 집합·byte length·raw SHA-256·공통 header 확인 |
+| 봉인된 원본·배포 및 선택적 authority | manifest가 지정한 Stage 1 사건/배포 root의 자료·signal·Schema를 필요 시 읽고 해시 확인. authority는 명시 `path/raw_sha256` 목록만 허용하며 기본 목록은 비어 있음 |
+
+`case_context.json`의 members, clusters, signals, relationships, candidate_dependencies, scheduling_waves, client_goal, active_profiles 등을 사용한다. upstream waves는 모든 cluster를 정확히 한 번 포함하는지 검사한다. 그러나 S2_10의 새로운 bundle queue는 이 waves를 그대로 추론 실행 순서로 사용하는 구조가 아니다. profile은 canonical JSON의 끝 LF까지 포함한 해시를 검사한다. signal은 봉인된 registry·Schema를 이용해 별도 평가하며 `FAILED`는 제한 자료로 보존하고, `NOT_EVALUATED`는 입력 공백으로 표시한다.
+
+### LLM 입력 packet
+
+| 필드 | LLM에 제공되는 내용 |
+|---|---|
+| `bundle_ref`, `scope` | 원본 cluster/material/anchor refs, 잠정 배정 사유, partial scope, 질문, 아직 읽지 않은 관련 material refs |
+| `materials`, `bodies` | occurrence 목록과 동일 본문 사전. body 사전의 ID는 원본 인용 ref를 대체하지 않음 |
+| `relations` | 현재 자료에 접하는 명시 relationships와 candidate dependencies |
+| `goal` | client_goal의 원본 ref 및 projection; 요구·제약을 보존 |
+| `profiles`, `profile_catalog` | 자료에서 명시적으로 발견한 domain의 질문 일부와 전체 profile의 ID/label 목록. 전체 profile·계산 설정을 매번 전달하지 않음 |
+| `authorities` | domain에 대응하는 proposition과 usable 여부. 실제 usable 판단은 공식 출처·시간적 적용 범위의 검증값이 모두 True인 경우 |
+| `reviews` | 실제 본문이 제공된 selected refs와 global blocker의 ref·제한 안내. 모든 global review 본문을 매번 재전달하지 않음 |
+| `source_gaps`, `evidence_scope` | authority/profile 미확인, Schema 평가 공백, global blocker, partition 경계·외부 관련 자료 등의 한계 |
+| `prior_results`, `repair_context` | 최초에는 빈 값; 영향 범위 재평가와 동일 입력 구조 보정에서만 사용 |
+
+허용 source/authority/review refs, payload·slot 해시, repair count 등 검증 정보는 plan의 `validation`에 있으며 모델의 hash echo에 의존하지 않는다. `work/bundle_plan.json`은 코드 제어·검증용 정보를 포함하고 `items`만 작은 map descriptor 배열이다. map source의 MCP `read_docs`는 plan을 읽으며 `source.mcp.key=[items]`로 배열을 선택한다. 전체 plan이 provider prompt에 포함되지 않고 지정 slot만 정확히 주입되는지는 runtime 확인사항이다.
+
+### LLM 출력
+
+| 최상위 필드 | 의미 |
+|---|---|
+| `bundle_ref` | 이번 응답의 입력 bundle 결속 |
+| `domain_resolutions` | domain별 판단·원본/authority 근거·공백·review refs |
+| `claim_option_candidates` | 권리자·의무자·지위·발생 원인·급부·대상·효과·범위, 동일성 및 성립 판단, 요건·항변·구제·기간·의뢰인 지시, 기여 cluster/material refs |
+| `candidate_relations` | 주위/예비, 누적, 부수, 선결, 양립 불가, 동일 회복 가능, 경합, 선택, 분리 관계. 양 끝은 같은 응답의 local 후보로 제한 |
+| `review_patches` | 원본 review의 상태 변경 제안; 원장 전체를 재출력하거나 직접 수정하지 않음 |
+| `materials_reviewed` | 제공된 모든 occurrence를 `CLAIM_LINKED/NON_RELEVANT/UNRESOLVED`로 누락·중복 없이 설명 |
+| `followup_requests` | 실제 필요한 추가 자료·묶음·domain 및 검토 질문 |
+| `missing_inputs`, `assumptions` | 미확인 자료와 명시적 전제 |
+
+`decision`은 `SUPPORTED/CONDITIONAL/UNRESOLVED/EXCLUDED`, `identity_decision`은 `MERGE/KEEP_SEPARATE/UNRESOLVED`다. 각 후보에는 최소 하나의 요건 평가, 항변 평가, 구제 후보가 필요하다. 요건·항변 평가는 지지/반대 refs, authority, 부담, missing inputs를 포함한다. 숫자·이율·기산일·기간을 계산하여 확정하거나 최종 `case_type/claim_group/renderer/exhibit` ID·소장 문안·파일 저장 위치·완료 상태·usage를 생성하지 않는다.
+
+### 코드 저장 산출물과 상태
+
+출력 root는 `stage2_runs/from-stage1/s2_10/v4`다. 모든 경로는 인증된 localdocs workspace 안의 상대 경로이며 이 저장소의 물리적 Markdown/YAML 디렉터리를 뜻하지 않는다.
+
+| 파일 | 수명과 내용 |
+|---|---|
+| `work/bundle_plan.json` | 변경 가능한 코드 제어 파일. inventory, 초기 membership, unassigned/restricted/input_blocked, followups·before/after changes, 배치 items/validation, 기존 artifact·활성 결과를 포함 |
+| `work/llm_input/slot-01.json` 등 | 현재 배치의 자기완결 입력. 최대 8개이며 다음 순차 실행에서 재사용·덮어쓸 수 있음; reducer가 현재 slot hash를 확인 |
+| `assessments/batch-NNNN.json` | 불변 배치 결과. input packet·validation metadata·검증 상태와 model result를 저장. 실패 시 원본 model output도 보존하며 다음 보정은 새 배치로 추가 |
+| `claims/claim_records.json` | 현재 활성 결과의 청구 기록 초안. 후보·관계·자료 처리·derived membership·review 제안·충돌·잔여 자료·제한을 조립한 갱신 가능한 snapshot |
+| `s2_10_status.json` | 배치·claims 해시, 입력 결속, bundle/material/review coverage, 공백·기술 사유·완료 상태를 마지막에 기록 |
+
+| durable status | 코드에서의 의미 |
+|---|---|
+| `NEXT_WAVE_PENDING` | 예상 scope 중 아직 결과가 없는 범위가 남음. 추가 순차 재호출 필요 |
+| `TECHNICAL_INCOMPLETE` | 강제 runtime 제한, 검증 실패 결과 또는 처리 불가 입력 등이 존재 |
+| `COMPLETED_WITH_ISSUES` | 예정 처리가 끝났으나 공백·제한·불확실성·잔여/미해결 자료·review 충돌/미제안·upstream 이슈 등이 남음 |
+| `COMPLETED` | 예정 처리가 끝나고 코드가 집계하는 이슈가 없음. 법률 승인이나 S2_20 연결 승인을 뜻하지 않음 |
+
+prepare의 `BUNDLE_BATCH_PREPARED`, `SAME_INPUT_BATCH_REUSED`, `REUSED_COMPLETED_OUTPUT`은 stdout 실행 receipt의 값이며 durable status와 구별한다. status-last는 배치와 claims를 읽어 확인한 후 marker를 기록하는 **논리적 commit**이다. 원격 파일 transaction·lock·CAS는 구현하지 않는다. 예외를 잡는 `receipt_main()`은 기술 미완료 receipt를 출력하지만 모든 예외 경로에서 새로운 durable status를 기록하는 것은 아니다. 소비자는 stdout과 저장 marker를 구분해야 한다.
+
+근거: 현행 YAML `L459–L586`의 입력 검증, `L694–L739`의 packet, `L386–L457`의 결과·status 조립, `L1294–L1414`의 validator·reducer, `L928–L934`의 출력 계약.
+
+## 작업용 고정 자산
+
+| 자산·설정 | 고정 방식 및 용도 |
+|---|---|
+| 현행 Agent YAML | 두 code task와 map prompt·Schema를 자체 포함. 별도 workspace Python 파일 실행에 의존하지 않음 |
+| algorithm·model·prompt·출력 Schema | `ALGORITHM`, `MODEL_CONFIG`, `PROMPT_SHA256`, `OUTPUT_SCHEMA`; contract를 input fingerprint에 포함해 다른 판단 설정의 기존 결과와 혼용을 차단 |
+| upstream root·버전 | `UPSTREAM_ROOT`와 `/s2_00/v6 → /s2_10/v4` 변환, upstream의 고정 algorithm/schema 및 dev 실행 조건 |
+| Stage 1 source/deployment manifest | 논리 source ID, path, byte length, raw hash를 통한 원본 봉인. 배포 Schema는 필요한 local `$ref` alias를 등록하며 외부 URL을 가져오지 않음 |
+| signal registry·Schemas | `signals/signal_registry.v2.json` 및 registry가 지정한 개별/공통 Schema. Draft 2020-12와 봉인된 배포 파일을 사용 |
+| profile | S2_00 context의 `active_profiles`와 profile별 canonical hash. 질문 구조의 자산이며 공식 법률·판례 authority로 취급하지 않음 |
+| authority pack | `AUTHORITY_INPUTS`의 명시 path/raw hash 목록. proposition의 text/domain_ids와 공식 출처·시간 범위 검증값 사용. 현재는 `[]` |
+| source review 원장 | S2_00 `review/issue_ledger.base.json`의 path/raw hash를 보존. sparse patch는 변경 제안이며 원본 state는 자동으로 해소되지 않음 |
+| MCP·dependency | localdocs `http://mcp-localdocs:8012/mcp`, Code Executor `https://code-executor.mcp.eroomai.com/mcp`, protocol `2025-03-26`, 고정 httpx/jsonschema 버전 |
+
+`Localdocs` helper는 backend가 치환한 `__user_hash__`, `__workspace_hash__`를 64자리 hash로 확인하고 MCP initialize와 initialized notification을 전송한다. code I/O는 `read_binary_doc/write_binary_file`의 base64 원본 bytes와 read-back을 사용한다. map source/preflight의 `read_docs` 경로와 code의 binary I/O는 다른 경로다.
+
+| 크기·횟수 guard | 현재 값과 해석 |
+|---|---|
+| `MAX_FILE_BYTES` | 32 MiB; 개별 binary 입력/출력 파일 guard |
+| `MAX_INPUT_BYTES` | 65,536 bytes; canonical packet과 고정 prompt 여유 합계의 입력 guard |
+| `FIXED_PROMPT_BYTES` | 18,411 bytes; 현재 두 prompt 본문 합계 + 2,048 bytes 여유 |
+| `MAX_OUTPUT_BYTES` | 131,072 bytes; 응답 UTF-8 크기 guard. 실제 API의 출력 token parameter와 같지 않음 |
+| `MAX_REPAIR_OUTPUT_BYTES` | 16,384 bytes; repair input에 넣을 이전 실패 출력 상한. 초과 시 이전 본문 대신 오류 정보로 보정 |
+| 배치 | 최대 8 items, 입력 합계 guard `8 × 65,536 = 524,288` bytes, map concurrency 최대 8 |
+| map envelope | strict base64 decode 후 16 MiB 이하 |
+| reasoning·context reserve | reasoning 32,768 tokens, configured context budget 262,144 tokens; 출력 reserve에는 131,072의 보수적 값을 사용 |
+| 의미상 재검토·구조 보정 | 영향 범위 완전 재평가 최대 1회, 동일 base input의 구조 보정 최대 1회 |
+
+`input_fits()`는 UTF-8 byte guard를 보수적인 입력 reserve로 사용하여 출력·reasoning reserve와 함께 확인한다. 실제 tokenizer·provider 한도를 측정한 결과는 아니다. 큰 묶음은 occurrence 경계에서만 partition하며 본문을 자르지 않는다. 하나의 occurrence만으로도 한도를 넘으면 `INDIVISIBLE_INPUT_EXCEEDS_ADMISSION`을 기록한다. partition된 묶음의 전체 경계를 다시 읽는 F-input도 한도를 넘을 수 있으며, 그 경우 `FULL_BOUNDARY_REVIEW_EXCEEDS_INPUT_BUDGET`이 남는다.
+
+근거: 현행 YAML `L113–L140`, `L225–L280`, `L503–L571`, `L741–L771`, `L797–L861`. 작성 관례 비교에 사용한 [Agent Script YAML 가이드](../../../../../SKILL.md)의 preflight·LLM·치환 규칙도 참고했다.
+
+## Upstream/Downstream 설명
+
+### Upstream: S2_00 v6의 직접 산출물
+
+현행 [Stage_2_S2_00.yml](Stage_2_S2_00.yml)은 Stage 1 사건·배포 root에서 자료를 읽고 하나의 Code Executor task로 ingress와 case context를 만든다. `compile_case_context()`가 명시 관계를 Union-Find로 연결하여 원본 cluster를 구성하고 candidate dependency의 SCC/위상 관계로 scheduling waves를 생성한다. S2_10은 이 cluster를 검증·소비하며 청구권으로 다시 정의하지 않는다.
+
+S2_10의 stage `prevs`는 Agent 내부 prepare stage만 가리킨다. 다른 Agent인 S2_00의 `{{prev.*}}` 결과를 직접 치환하지 않고 workspace 파일의 status/artifact 계약을 읽는다. request/attempt ID도 생성하지 않는다. Stage 1 roots는 upstream marker가 지정한 값으로 따라가지만, S2_00 출력 root는 현재 inline 상수로 고정되어 있다. S2_00이 사건별 다른 출력 root에 실행되었다면 S2_10의 현재 상수와 맞는지 별도 확인이 필요하다.
+
+| upstream 조건 | S2_10 요구 |
+|---|---|
+| algorithm/schema | `s2_00_direct_ingress/6.0.0`, `stage2_s2_00_direct.v4` |
+| 실행 admission | `WORKSPACE_EXECUTION_TEST`, `DEV_FIXTURE_RELEASE` |
+| 준비 상태 | `READY` 또는 `READY_WITH_ISSUES`; 후자는 S2_10 완료 시에도 이슈 조건에 반영 |
+| 산출물 | marker + 정확히 4개 등록 artifact; 공통 header와 raw hash/byte length 일치 |
+| 관계·자료 보존 | 모든 cluster/member의 coverage, signal source, review refs, cluster bundle 내용 일치 |
+
+### Downstream: 현행 S2_20과 직접 호환되지 않음
+
+현행 [Stage_2_S2_20.yml](Stage_2_S2_20.yml)은 release-bound request를 읽는 단일 deterministic Code Executor 작업이다. 기존 canonical DomainVerdict를 유지하여 option portfolio, exact case/rule binding, 계산·요건사실 pack, frozen ReliefPlan을 만드는 구성을 선언한다. 그런데 다음 요구는 S2_10 v4가 발행하는 계약과 다르다.
+
+| 항목 | S2_10 v4 생산 | 현행 S2_20 요구 |
+|---|---|---|
+| status 위치 | `s2_10/v4/s2_10_status.json` | request root 아래 `map_s2_10/s2_10_publish_status.json` |
+| 완료 barrier | `COMPLETED/COMPLETED_WITH_ISSUES`, `written_last` | `COMPLETE`, `route=TO_S2_20`, `status_written_last`와 추가 release/run 결속 |
+| 판단 파일 | bundle별 `assessments/batch-NNNN.json`, 활성 `claims/claim_records.json` | cluster별 `map_s2_10/domain_verdicts/{cluster_id}.json` 및 item/issue/assumption/usage 파일 |
+| context | S2_00 v6의 통합 `case_context.json`, 원본 `CL-###` refs | cluster_plan, cluster_slices, party/object context, bundle cohorts 등 별도 frozen context |
+| Schema·식별 | `stage2_s2_10_* .v4` 계열의 bundle/claim 구조, fingerprint | `schemas/s2_10.schema.json`의 canonical verdict·global status, run/release/producer digest |
+
+이는 source 대조로 확인한 계약 차이다. 파일을 복사하거나 status 이름만 바꾸어 연결할 수 있다는 근거는 없다. S2_20이 요구하는 producer/release binding, cluster 중심 coverage와 v4의 다대다 자료·청구 범위 사이의 의미 보존도 확인해야 한다. v4 metadata 역시 후속 호환성을 주장하지 않는다. 본 분석에서는 S2_20이나 배포 manifest를 개정하지 않았다.
+
+근거: S2_00 `L2738–L2853`의 cluster/context 생성; S2_10 `L459–L476`, `L181–L184`의 upstream 계약; S2_20 `L2576–L2627`의 barrier/verdict 계약 및 `L2770–L2790`의 fixed paths.
+
+## 구현과 계약 사이 확인사항 및 잔여 한계
+
+### 소스에서 확인되는 구현과 추가 확인이 필요한 범위
+
+| 사항 | 구현·계약의 실제 관계 | 잔여 확인사항 또는 한계 |
+|---|---|---|
+| 기본 runtime 차단 | prepare·reducer 양쪽에 slot/provider 검증값이 False. prepare는 준비 slot이 있더라도 items를 비우고 기술 미완료를 발행 | 실제 동적 preflight·context 치환·모델 budget·실패 stage 중단을 확인해야 실행 가능. 상수 True 변경만으로 검증을 대신할 수 없음 |
+| 빈 map·완료 재사용 | 같은 완료 snapshot은 원본 결과와 claims artifact를 확인하여 모델 items를 0개로 재사용. reducer의 빈 map 경로에는 별도 검증 flag 필요 | backend가 빈 배열에서도 reducer를 호출하는지, prepare receipt/status와 일치하는지 미확인 |
+| model reasoning | YAML은 OpenAI Responses와 `xhigh`를 선언하지만 [가이드](../../../../../SKILL.md)는 `llm_reasoning`이 Google native SDK 경로에서만 작동한다고 설명 | 실제 OpenAI 호출 parameter와 provider receipt로 적용 여부를 확인해야 함. 선언만으로 xhigh 적용·reasoning token reserve의 적정성을 확정할 수 없음 |
+| 당사자·목적물 기반 묶음 | 입력 자료·goal·후보에는 당사자·목적물 refs가 존재하나 선행 anchor 함수는 거래/사건/BO 계열에 한정 | `object_and_party_refs`를 독립 인덱스로 소비하거나 일반 party/object ref로 직접 묶는 구현은 없음. 당사자·법적 지위 동일성은 본 LLM의 실질 판단에 의존 |
+| authority 부재 | `AUTHORITY_INPUTS=[]`; validator는 SUPPORTED/EXCLUDED에 usable authority와 실제 사실 근거, MERGE/KEEP_SEPARATE에 authority·identity 근거를 요구 | runtime을 열더라도 근거 없는 확정 판단은 검증을 통과하지 못함. 비어 있지 않은 후보는 조건부/미해결 판단과 공백을 남겨야 하며 법률 동일성도 확정할 수 없음 |
+| 전역 청구권 중복 | bundle별 동일성을 판단하고 reducer는 활성 후보를 나열. `record_ref=bundle_ref/option_local_ref`이며 전역 legal dedup key는 없음 | 같은 권리가 여러 bundle에서 독립 후보로 남을 수 있음. cross-scope followup이 요청·수행되지 않은 경우 전역 중복 제거를 보장하지 않음 |
+| 분할·재연결의 가역성 | 원본 자료 불변, 복수 membership, residual/restricted 보존, before/after 목록, 불변 배치 및 영향 scope의 완전 대체 | 자유로운 ATTACH/DETACH 연산 API나 무제한 재계획은 없음. LLM은 후보·기여 refs를 나누고 필요한 외부 자료를 요청하며 코드가 한정된 재검토 범위를 구성 |
+| 대형 범위·공유 자료 | 동일 본문은 호출 내부에서만 dedup. 큰 자료는 occurrence 단위 분할 후 경계 검토 요청 | 불가분 자료·합쳐도 큰 F-input은 처리 한계를 남김. prior_results·repair·반복 slot 전송의 추가 비용도 있음 |
+| global blockers | 모든 blocking review의 ref/제한을 각 packet에 남기고 본문 없는 review의 patch를 금지. global blocker가 있으면 공백 flag 유지 | 본문을 실제 읽은 범위에도 글로벌 미확인 flag가 남을 수 있으며 해당 flag는 SUPPORTED 후보를 차단. resolved patch만으로 전역 제한을 자동 해제하는 로직은 없음 |
+| reducer 검증의 깊이 | Schema, 참조 허용, candidate/material 범위, occurrence coverage, 근거 존재, 같은 응답 endpoint 등을 확인 | 사실과 법률의 적합성·부담 배분·금액의 실질적 정확성은 검증하지 않음. 후보의 `material_refs`와 `materials_reviewed` 사이 법률적 처리의 완전한 상호 일치도 별도 의미 검증이 아님 |
+| profile/domain 범위 | 자료의 정확한 domain ID 힌트에서 질문을 선택하고 전체 ID/label catalog를 제공. followup으로 catalog 내 domain을 추가 가능 | domain 이름만으로 상세 평가를 선행하지 않음. validator의 domain 허용 목록은 전체 profile catalog여서 선택 profile의 질문 전달 여부와는 다름; 본문·질문 부족 시 미해결 유지 필요 |
+| review·완료 의미 | 원장은 보존하고 sparse 제안을 조립; 서로 다른 proposed_state의 충돌·미제안을 이슈로 집계 | 미제안 review의 기존 상태를 자동 추정하지 않음. 같은 proposed_state의 서로 다른 이유·근거까지 모두 충돌 검사하는 것은 아니며, COMPLETED도 법률·사람의 승인 상태가 아님 |
+| 저장·재시도 | 해시 결속·read-back·불변 배치·status-last와 단일 writer 가정. 중단 batch는 같은 slot로 재사용 | 원격 CAS/lock·파일 단위 transaction 없음. status 기록 전 중단 또는 동일 root 병행 실행의 복구를 완전히 인증하지 않음. 가정이 깨진 상태를 자동 성공으로 표시하면 안 됨 |
+| usage·토큰 효율 | status/entry에 `usage=None`과 미측정 사유를 기록. 선행 상세 cluster/연결 LLM을 제거하고 packet 중복을 줄이는 구조 | 실제 입력·출력·reasoning token, cache, latency, 재검토·repair 합계와 법률 정확도의 비교 실측은 없음 |
+| 후속 계약 | S2_20의 fixed paths·canonical Schema·완료 barrier와 현행 v4 계약이 다름 | downstream adaptation·release 결속·의미 보존 검증이 필요하며 현재 자동 handoff를 주장할 수 없음 |
+
+위 한계 중 authority, 원본 자료 또는 법률 동일성에 관한 공백은 구조 보정으로 해소할 수 없다. 구조 보정은 같은 base payload를 대상으로 1회만 허용하며 실패 기록을 지우지 않는다. F-scope의 추가 `followup_requests`도 두 번째 의미상 재평가로 실행하지 않고 `ONE_FULL_REASSESSMENT_ALREADY_USED` 제한과 질문을 최종 기록에 보존한다. 정확성과 비용을 위해 반복 횟수를 제한하되, 제한 이후 남은 문제를 완료된 법률판단으로 바꾸지 않는 구성이다.
+
+### 검증 증거의 구분
+
+YAML metadata와 [프로젝트 MEMORY](../../../MEMORY.md)에 기록된 **이전 구현 검증**은 종합 campaign 1회·35항목, 최초 33 통과, fixture 기대값 2건 수정, 증분 코드 보완과 관련 7회 국소 확인이다. 이를 이번 분석에서 새로 실행한 검증으로 취급하지 않는다. metadata의 `remaining_findings=0`도 그 오프라인 campaign 범위의 결과이며 runtime·법률 품질·downstream의 잔여 한계가 없다는 뜻이 아니다.
+
+**이번 분석에서 확인한 사항**은 현재 파일 해시·v4 사본 동일성, 2개 stage/3개 task와 map/reduce 구조, 두 inline Python의 구문 컴파일, prepare/reducer/system prompt의 출력 Schema 일치, 고정 prompt 해시·byte reserve, upstream/downstream의 source-level 계약 차이다. 이 확인은 원격 실행이나 법률 원문 검증을 수반하지 않는다. 원본 YAML과 S2_00/S2_20·버전 사본은 보존하고, 본 분석서 및 지정 MEMORY 요약만 작성했다.
+
+근거: 현행 YAML `L31–L72`의 admission/verification metadata, `L694–L867`의 packet·예산·prepare, `L1210–L1414`의 활성 결과·validator·publish; 가이드 `L305–L307`의 reasoning/preflight 설명; 현행 S2_20 barrier/fixed paths.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/agent_scripts/S2_10_revision_strategy_eval_v.4.md

@@ -0,0 +1,126 @@
+# S2_10 개정 전략 v.4 평가 — 단순한 해법 우선
+
+작성일: 2026-10-04  
+평가 대상: [S2_10_revision_strategy_v.4.md](S2_10_revision_strategy_v.4.md)  
+개정 산출물: [S2_10_revision_strategy_v.4-1.md](S2_10_revision_strategy_v.4-1.md)  
+상태: 문서와 현행 YAML에 근거한 설계 평가. 구현·실행·법률 정확도·실제 토큰 비교 전.
+
+## 1. 평가 결론
+
+**v.4의 ‘원본 참조로 잠정 묶음 구성 → 묶음별 본 법률 추론 → 코드 검증·조립’은 유지하고, 최초 구현에 요구하는 계약·상태·보정 장치를 줄이는 것이 적절하다.** 관련 자료를 먼저 읽을 범위로 묶는 설계는 사용자 목표에 직접 대응한다. 원본 불변, 복수 묶음 참여, 미배정 보존, 분할·재연결, 청구권 동일성과 성립 판단의 구별도 필수 요구다. 이 부분을 단순화의 대상으로 삼지 않는다.
+
+반면 v.4는 선택적 선행 LLM, 네 가지 묶음 변경 operation, plan revision·부모 digest, supersedes와 assessment delta, 여러 입력 표현 및 새 pending 상태까지 함께 제안한다. 각각의 용도는 설명돼 있지만, 첫 구현에서 동시에 필요한지는 입증되지 않았다. 가장 작은 성공 경로를 먼저 구현하고 예외는 제한된 재검토와 명시적 미해결로 처리하는 v.4-1을 권고한다. 이는 설계 판단이며 성능 우월성에 대한 실측 결론이 아니다.
+
+## 2. 평가 범위와 기준
+
+‘단순한 해법 우선’을 다음 기준으로 적용한다.
+
+1. **목표와 직접 연결되는 책임만 기본 경로에 둔다.** 자료 묶음 준비와 본 추론을 분리하되, 선행 상세 법률평가와 상시 전역 재통합을 추가하지 않는다.
+2. **독립 계약과 상태를 줄인다.** 같은 결과 형식으로 최초 평가와 제한된 재검토를 처리하고, 코드가 복원·적용해야 하는 별도 delta 언어를 피한다.
+3. **원본 보존과 수정 가능성을 작은 자료구조로 충족한다.** 원본 참조 목록, 파생 membership, 변경 전후 범위와 사유로 가역성을 설명할 수 있어야 한다.
+4. **관측된 비용에만 추가 최적화를 붙인다.** 입력 안의 정확한 본문 중복부터 제거하고, 별칭·별도 wire Schema·광범위 재사용은 효과가 확인될 때 도입한다.
+5. **법률 내용과 실패의 가시성을 유지한다.** 반대 자료·항변·부담·권리 경합·미배정 자료와 authority 제한을 줄여 복잡도를 낮추지 않는다.
+6. **전체 비용으로 판단한다.** 최초 호출뿐 아니라 재검토·구조 보정·자료 재전달까지 계산한다. 문서 길이와 파일 수의 감소는 실제 모델 토큰 절감과 구별한다.
+
+판단 근거의 우선순위는 사용자 요구, v.4의 실제 명세, [현행 S2_10 YAML](Stage_2_S2_10.yml), 이전 전략의 참고 내용 순이다. 새로운 법률 명제나 모델 성능 수치를 제시하지 않으므로 외부 법률 조사·성능 실험은 이번 평가에 포함하지 않는다.
+
+분석 기준 SHA-256:
+
+- v.4: `9b6ff5f34b45080af0f20167266a292a13abf11bc6109e570647b3749c4c02f9`
+- 현행 YAML: `3d8616c2e2a1c3a5f405ba9806718b9ac519843ddc02c80ff4d51a67c42e8c50`
+
+## 3. 관찰·평가·개정의 대응
+
+아래 ‘관찰’은 원문에서 확인한 사실이고, ‘평가’와 ‘개정’은 이번 보고서의 판단·제안이다. R1–R8은 v.4-1의 변경 근거로 사용한다.
+
+| ID | 원문에서 확인한 관찰 | 단순성 관점의 평가 | v.4-1 개정 |
+|---|---|---|---|
+| R1 | v.4 §1·§3·§7은 잠정 묶음 뒤 본 추론에서 동일성·분리·경합과 요건·항변·구제를 함께 판단한다. | 목표와 책임의 대응이 명확하다. 원본 cluster 평가를 모두 수행한 뒤 다시 합치는 단계는 필요하지 않다. | 세 task의 기본 경로와 8개 동일성 기준을 유지한다. |
+| R2 | §4.4는 기본 0회이지만 모호한 entity/ref 연결에 선택적 선행 LLM을 허용한다. | 초기부터 보조 prompt·Schema·예산·검증 경로를 추가한다. 자료가 모호하면 본 추론에서 확인하는 경로가 이미 있다. | 선행 LLM을 기본 구현에서 제외한다. 불명 연결은 독립·잔여 묶음과 본 추론의 확인 대상으로 보존한다. |
+| R3 | §5·§8.2는 ATTACH/DETACH/SPLIT/RELINK, plan revision·부모 digest와 supersedes를 정의한다. | 가역성은 필요하지만 실행 중 동적 재계획과 법률 결과 계승까지 한꺼번에 구현하면 변경 영향 관리가 커진다. | 한 평가 회차의 계획을 고정하고 membership의 변경 전후 refs·사유만 기록한다. 영향받은 결과는 재사용에서 제외하고 제한된 재검토로 갱신한다. |
+| R4 | §8.2는 최초의 완전 평가와 후속 assessment_deltas·supersedes_refs를 조건부 Schema로 구분한다. | delta 적용·계승 범위·충돌 검증에 추가 계약이 필요하다. 보정 범위가 작고 횟수가 제한되면 같은 형식의 완전 결과가 더 단순하다. | 최초·재검토에 같은 출력 Schema를 사용한다. 영향 범위의 대체 결과와 코드의 활성 결과 목록으로 조립한다. |
+| R5 | §6·§8·§10.3·§11은 본문 사전, 인용 별칭, wire/정본 역변환, control/index/plan, slot과 직접 전달 선택지를 계승한다. | 요청 내부의 정확한 중복 제거는 직접적이다. 여러 표현·파일·전달 경로를 동시에 유지할 필요는 확인되지 않았다. | 원본 refs와 필요한 본문을 유지하고 호출 내부 본문 사전만 기본으로 둔다. 계획·검증 정보를 한 코드용 파일에 모으고 descriptor+자기완결 slot 한 경로를 먼저 검증한다. 별칭·delta·대체 전달은 후속 조건으로 둔다. |
+| R6 | §11은 BUNDLE_ANALYSIS_PENDING과 BOUNDARY_REVIEW_PENDING을 새로 제안한다. 현행 YAML은 NEXT_WAVE_PENDING·TECHNICAL_INCOMPLETE·COMPLETED_WITH_ISSUES·COMPLETED를 사용한다. | 처리 중인 작업의 종류는 pending 목록과 사유로 표현할 수 있다. 새 상태마다 caller·복구·후속 소비 계약이 늘어난다. | 현행 상태 집합을 재사용하고 의미와 coverage를 새 묶음 작업에 맞게 고친다. 자동 호환을 주장하지 않는다. |
+| R7 | §9·§10.1은 경계·자료 보강·구조 repair와 여러 operation을 동일 map task로 처리한다. | 동일 task 재사용은 유용하다. 여러 의미 operation과 조건부 출력은 축소할 수 있다. | 최초 평가 뒤 실재하는 미해결 질문을 모아 영향 범위당 재검토 최대 1회로 통합한다. 구조 보정은 동일 입력의 실패 출력에 최대 1회이며 별도 법률 작업으로 확대하지 않는다. |
+| R8 | §12·§13은 폭넓은 사례·세 방식 비교·다수 구현 단계를 제안한다. | 중요한 검증을 포함하지만 전체 비교 실험과 고급 복구를 모두 최초 도입 조건으로 삼으면 출발 범위가 커진다. | 원본 coverage·권리 구별·가역성·입출력 예산·실패 상태를 대표 사례로 먼저 확인한다. 실제 전체 토큰과 품질을 확인한 뒤 최적화를 확장한다. |
+
+현행 YAML의 `validate_result(value, meta, cluster_ref)`는 단일 cluster와 후보 endpoint를 전제로 한다. 상태 이름·평가 필드의 재사용은 가능하지만, 묶음의 복수 원본 범위와 결과 검증은 개정해야 한다. 표면적인 명칭 변경만으로 호환성을 확보했다는 결론은 내리지 않는다.
+
+## 4. 유지해야 할 내용
+
+단순화한 전략에서도 다음 요구는 그대로 유지한다.
+
+- 당사자·거래·발생 사건·목적물의 **실제 원본 참조**로 묶는다. 이름·같은 profile·공유 증거만으로 동일 청구권을 확정하지 않는다.
+- 하나의 cluster가 여러 묶음에 참여할 수 있고, 묶음 하나에서 여러 독립·경합 청구권이 나올 수 있다.
+- 연결 불명·미배정·schema 제한 자료를 원본 inventory에 남긴다. 실제로 읽지 않은 자료를 검토 완료로 표시하지 않는다.
+- 분할·재연결은 파생 참조 목록을 바꾸는 방식으로 가능해야 한다. 이미 평가한 근거 범위가 달라지면 그 평가를 자동 계승하지 않는다.
+- 본 추론은 지지·반대 사실, 요건·항변/재항변·부담·구제·기간, usable authority와 의뢰인 제한을 함께 검토한다.
+- 공유 본문은 한 요청 안에서 중복 제거하되 서로 다른 요청의 입력 비용은 합산한다. 필요한 반대 자료를 비용 절감 때문에 숨기지 않는다.
+- reducer는 참조·범위·구조·coverage를 검사하고 명시적 판단을 조립한다. 법률상 동일성을 코드의 전이 연결로 새로 확정하지 않는다.
+
+## 5. 권고하는 최소 workflow
+
+```text
+code prepare
+  원본 검증 → 명시적 refs의 잠정 묶음 → 미배정 목록·입력 예산 확인
+LLM map
+  묶음별 권리 식별·동일성/분리/경합·요건/항변/구제의 본 평가
+code reducer
+  구조·참조·coverage 검증 → 평가 보존·청구 기록 조립
+  실제 미해결 질문이 있을 때만 영향 범위의 재검토 1회
+  → 최종 상태와 남은 한계 기록
+```
+
+정상 경로에서 묶음당 본 추론은 한 번이다. 최초 묶음 계획은 그 회차에서 고정한다. 본 추론의 분할·재연결 제안은 코드가 유효한 refs와 coverage를 확인한 뒤 다음 회차의 파생 목록에 반영한다. 이미 읽은 자료에서 청구를 나누는 것만으로 재호출하지 않는다.
+
+재검토 결과는 해당 범위의 완전한 대체 평가다. 이전 결과는 보존하고 최종 활성 결과 목록에서 영향 범위를 교체한다. 이를 위해 별도의 LLM delta 적용기·일반화된 묶음 연산 API·실행 중 plan 변경 엔진을 만들지 않는다. 재검토 예산 안에 필요한 자료를 담지 못하면 미해결을 기록한다.
+
+## 6. 반대 근거와 후속 도입 조건
+
+v.4의 상세 장치가 유리할 수 있는 조건도 있다. 큰 사건에서 같은 자료가 여러 번 재배정되고 이미 평가한 결과가 계속 바뀐다면, delta·supersedes·세밀한 revision 관리가 재출력과 재추론을 줄일 수 있다. 원본 refs가 긴 경우 별칭이 입력을 줄일 수 있고, 여러 관련 묶음을 공동 처리하면 공유 본문의 요청 간 반복을 줄일 수 있다. 이러한 장치를 영구 배제하는 것은 권고하지 않는다.
+
+다만 현재 문서에는 이 추가 복잡도의 필요성을 입증하는 실제 운영 측정이 없다. 먼저 단일 출력 Schema와 한정된 재검토를 구현하고, 대체 평가의 출력량 또는 자료 반복이 비용의 주된 원인으로 확인될 때 해당 장치를 개별적으로 도입한다. 완전 대체 평가가 delta보다 출력 토큰을 더 쓰는 경우도 있으므로 v.4-1의 토큰 우월성을 미리 확정하지 않는다.
+
+정확도는 source coverage와 법률 판단을 유지한다는 조건에서 평가해야 한다. 원본에 거래·사건 식별자가 부족하면 단독 묶음이 많아져 추론 횟수가 줄지 않을 수 있다. 이를 숨기기 위해 선행 법률평가를 부활시키거나 느슨한 연결을 확정 병합으로 바꾸지 않는다.
+
+## 7. v.4-1의 수용 기준
+
+| 확인할 사항 | 수용 조건 |
+|---|---|
+| 본 추론의 순서 | 선행 상세 cluster 평가·선행 LLM·상시 전역 통합 LLM이 기본 경로에 없다. |
+| 원본 및 배정 | 원본 불변, 복수 membership, 미배정·이용 제한 목록으로 모든 occurrence의 행선지를 설명한다. |
+| 가역성 | 분할·재연결 전후 refs·근거가 남고 영향받은 법률 결과의 자동 재사용을 막는다. |
+| 법률 내용 | 8개 동일성 기준, 독립/경합 권리, 반대 자료·항변·부담·구제·authority 제한을 유지한다. |
+| 입력·출력 | 호출 내부 본문 중복을 줄이고 원본 refs를 사용한다. 최초와 재검토가 같은 출력 계약이다. |
+| 조건부 처리 | 영향 범위 재검토 1회, 실패 출력의 구조 보정 1회, 예산 초과·잔여 질문의 명시적 처리로 자동 반복을 막는다. |
+| 상태·발행 | 현행 상태 집합을 재사용하고 pending 사유·잔여 범위·read-back·status-last를 명시한다. |
+| 비용·품질 | 실제 요청 전체 비용과 대표 사건의 권리·항변·근거 누락을 함께 확인한다. 구조 검증을 법률 품질로 표현하지 않는다. |
+
+## 8. 작업 계획·결정 기록
+
+이 절은 이번 문서 작업의 실행계획이다. 사용자 지정 평가서 안에 계획을 포함하여 별도 계획 파일을 추가하지 않는다.
+
+- **목표·산출물:** v.4의 단순성 평가서, 평가에 따른 v.4-1 전략서, 지정 Stage 2 MEMORY의 작업 요약.
+- **범위:** v.4와 현행 YAML을 읽고 전략 문서만 작성한다. 기존 전략·YAML·backend·사건 자료를 변경하거나 실행하지 않는다.
+- **입력·가정:** 사용자 요구와 실제 로컬 문서를 사용한다. 실측 성능은 미확인이고 이번 평가에서 새로운 법률 결론을 내리지 않는다.
+- **질문·승인 경계:** 지정 출력 파일은 작성 전 존재하지 않았음을 확인했다. 추가 사용자 선택을 필요로 하는 미결 사항은 없으며 외부 발행·구현은 범위 밖이다.
+- **작업 순서:** 원문 관찰과 근거 정리 → R1–R8 평가 → v.4-1 작성 → 정적 검증·원본 보존 확인 → MEMORY 삽입.
+- **검증 계획:** 정확한 제목·파일명·UTF-8·fence·표·로컬 링크, R1–R8 반영, 필수 법률 내용·가역성·출력/보정 계약의 정합성, 원본 hash와 MEMORY 삽입 외 본문 보존을 확인한다.
+
+진행 상태:
+
+- [x] 평가 대상과 출력 경로·기존 파일 보존 범위를 확인했다.
+- [x] v.4의 관찰·평가·R1–R8 개정 방안을 작성했다.
+- [x] v.4-1 작성·정적 검증·MEMORY 기록을 마쳤다.
+
+| 결정 | 근거 | 결과 |
+|---|---|---|
+| 핵심 추론 순서와 법률 내용 유지 | 사용자 요구 및 v.4 §1·§7 | 정확도에 필요한 범위를 단순화의 대상으로 삼지 않는다. |
+| 고정 회차·완전 대체 결과 채택 | R3·R4·R7 | 최초 계약 수를 줄이고 미해결은 제한된 재검토로 처리한다. |
+| 원본 refs·한 전달 경로·현행 상태 우선 | R5·R6 | 별칭 복원과 새 상태 전파를 최초 도입 조건에서 뺀다. |
+
+## 9. 검증 결과와 한계
+
+정적 확인 36개 항목을 통과했다. 두 문서의 제목·UTF-8/LF·절 순서·fence·표·로컬 링크 7개, R1–R8 대응·8개 동일성 기준·가역성·단일 출력/보정 계약·상태·비용 한계를 확인했다. 원본 참조 4종의 명시 문구를 보완한 뒤 해당 항목을 다시 확인했다. 기존 v.2/v.3/v.4·S2_00/S2_10 YAML은 보존하며, 작업 요약은 지정 MEMORY의 `How to Write MEMORY.md` 바로 아래에 삽입한다.
+
+평가의 근거는 확인한 로컬 명세다. 실제 provider/backend 실행, 새 packet의 수용, S2_20 handoff, 법률 품질과 전체 토큰 개선은 이 작업에서 검증하지 않는다. 문서 확인은 제안의 내부 정합성 검증이며 구현·법률 승인이나 성능 측정을 대신하지 않는다.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/agent_scripts/S2_10_revision_strategy_v.3.md

@@ -0,0 +1,331 @@
+# S2_10 작업명세서 개정 전략 v.3
+
+작성일: 2026-10-04  
+대상: 같은 폴더의 `Stage_2_S2_10.yml`  
+개정 원본: `S2_10_revision_strategy_v.2.md` — 원본 보존  
+상태: **청구권 통합 식별을 포함한 개정 전략 — YAML/Python 구현·workspace 실행·법률판단 품질·실제 토큰 검증 전**
+
+## 1. 목표와 채택할 구성
+
+v.2의 cluster별 법률판단과 무손실 입력 단축을 유지하고, **사건의 모든 cluster 판단이 구조·참조 검증을 마친 뒤 청구권 통합 식별 단계를 추가한다.** 첫 단계에서는 자료 연결 단위별 후보와 쟁점을 발견하고, 통합 단계에서는 분산된 사실·증거·항변을 종합하여 동일 청구권의 중복 후보를 통합하고 기존 후보의 누락·충돌을 재검토한다. 소장 또는 준비서면 작성에 사용할 청구별 검토 기록을 만드는 것이 목적이며, 최종 서면 문안·수치 계산·법률 승인까지 수행하지 않는다.
+
+통합의 직접 단위는 **원본 cluster 전체가 아니라 그 안의 청구 후보와 자료 참조**다. 하나의 cluster가 여러 청구권에 기여할 수 있고, 후보가 없는 cluster에도 계약·변제·시효 등에 관한 중요한 자료가 있을 수 있다. 따라서 cluster ID와 원본 연결 구조는 불변으로 두고, 그 위에 후보 및 자료와 청구 기록 사이의 다대다 대응을 만든다. 같은 원고·피고라는 이유로 모든 청구를 하나로 합치거나 원본 cluster를 다시 작성하지 않는다.
+
+기본안은 **비 LLM 인덱싱·검토 묶음 준비 → 필요한 묶음만 LLM 통합 판단 → 비 LLM 검증·청구 기록 조립**이다. 기존 결과의 재사용, 호출 안의 본문 공유, 짧은 인용 별칭, 변경 항목 중심 출력으로 개별 입력과 전체 추론의 중복을 줄인다. 통합 판단이 필요한 경우의 추가 비용은 인정하되, 전체 사건을 한 번 더 요약하거나 모든 후보 쌍을 LLM으로 비교하는 구조는 채택하지 않는다. v.2보다 사건 전체의 실제 추론 토큰이 감소했다고 선험적으로 주장하지 않는다.
+
+## 2. 근거, 산출물과 작업 범위
+
+| 근거 | 적용 범위와 확인 상태 |
+|---|---|
+| [v.2 전략서](S2_10_revision_strategy_v.2.md) | 무손실 compact packet, 참조 별칭, Schema 공통화, prepare 인덱스, 최대 8개 배치, 검증용 control 분리의 선행 설계. 구현된 기능으로 간주하지 않는다. |
+| [현행 S2_10 YAML](Stage_2_S2_10.yml) | 실제 `prepare`, cluster map prompt·출력 Schema, `validate_result`, `coverage_status`, `publish`를 직접 확인했다. |
+| 사용자 제공 맥락·8개 기준 | 당사자·발생 원인·실체법상 권리·급부·범위의 동일성과 보완 자료, 독립 청구, 근거·불확실성 처리의 설계 요구다. |
+| [YAML 작성 가이드](../../../../../SKILL.md) 및 [Stage 2 사본](../../../SKILL.md) | 두 파일은 이번 확인에서 byte-identical이었다. MapReduce·preflight·결과 수집의 문서화된 계약을 사용하고 미확인 Stage 조건문·반복 실행은 가정하지 않는다. |
+| [Code Executor 노트북](../../../test_code_executor.ipynb) | MCP 초기화·notification, `run_code` 인자와 stdout 처리의 참고 자료다. 노트북은 실행하지 않았다. |
+| [Stage 2 MEMORY](../../../MEMORY.md) | 기존 전략·실행 기록을 구분하고 이번 문서 작업만 압축 기록한다. |
+
+분석 기준 SHA-256:
+
+- 현행 S2_10 YAML: `3d8616c2e2a1c3a5f405ba9806718b9ac519843ddc02c80ff4d51a67c42e8c50`
+- v.2 전략서: `7cbd50a49b07470496a2234b795c639a04dd8f0e2447cc4d4867709124dfd978`
+
+이번 산출물은 **이 v.3 전략서와 지정 MEMORY 기록**이다. 기존 v.2·S2_00/S2_10 YAML·원본 사건·배포 자산·backend·S2_20 이후의 파일은 개정하지 않는다. 이 문서 안의 task명·새 필드·파일명·상태는 향후 구현 제안이다. 실제 S2_20 소비 계약과 backend 연결 확인은 후속 구현의 조건이며 이번에 실행하거나 변경하지 않는다. 별도 실행계획 파일을 추가하지 않고 이 문서에 구현 순서·검증·결정 기록을 포함한다.
+
+## 3. 현행 작업의 책임과 통합 단계의 최적 위치
+
+현행 `Task_S2_10_prepare_wave`는 S2_00의 cluster·wave를 소비하고 `payload_json`·`repair_json`을 준비한다. `Task_S2_10_resolve_cluster`는 한 cluster의 법률관계·청구권·구제 후보를 판단한다. `Task_S2_10_validate_publish_wave`는 JSON Schema·허용 참조·authority·blocking review·coverage 등을 검사하고 wave와 status를 저장한다. 이 reducer는 청구권 동일성을 법률적으로 재판단하지 않는다.
+
+cluster 밖의 맥락은 명시적 관계·후보 의존 정보, 관계가 연결된 이전 wave의 검증된 후보 요약, 같은 SCC의 이웃 원본 자료로 제한된다. 선행 후보 요약은 후보 참조·판단·법률효과만 제공하며, 같은 wave의 다른 cluster 후보를 생성하여 참조할 수 없다. 동일 당사자 조합의 전체 자료를 종합하여 청구권을 식별하는 절차가 현행 코드에 있다고 해석하지 않는다.
+
+**통합 단계의 시작점은 마지막 논리적 wave의 cluster 결과가 검증·저장된 이후, S2_10의 사건 전체 최종 완료 표시 이전**이다. 부분 물리 배치나 개별 wave reducer 안에서 곧바로 통합하면 뒤에 도착할 자료 때문에 동일성을 반복 판단하거나 성급하게 확정할 수 있다. S2_20 이전에 배치해야 후속 단계가 분절된 후보를 다시 모으는 부담을 줄일 수 있다.
+
+```text
+S2_00 불변 입력
+  → 기존 prepare + cluster별 LLM + 비 LLM 검증·wave 저장
+      [모든 논리적 wave·cluster의 구조 검증 완료]
+  → 청구권 통합 준비: 후보·원본 자료 인덱싱, 검토 묶음과 잔여 자료 구성
+  → 필요한 묶음의 LLM 통합 식별
+  → 통합 검증·기존 결과와 delta 조립·청구 기록 및 전체 status 저장
+  → 검증된 새 handoff 계약에 따른 후속 소비
+```
+
+여기서 ‘검증 완료’는 법률상 `SUPPORTED`만을 뜻하지 않는다. `CONDITIONAL`, `UNRESOLVED`, `EXCLUDED`, 후보 배열이 빈 정상 결과도 포함한다. 구조·참조 오류나 누락 cluster가 남으면 통합 확정 발행을 시작하지 않는다. 법률 미해결은 통합의 검토 대상이고 기술 실패는 먼저 보정할 대상이다.
+
+## 4. 하나의 청구권으로 통합할 판단 기준
+
+아래 기준은 이름이나 문자열을 비교하는 자동 병합 규칙이 아니라 **청구권 동일성을 판단할 질문과 근거 요구**다. 같은 청구권의 자료를 모으는 것과 그 청구권이 성립한다고 판단하는 것을 분리한다.
+
+| 기준 | 통합 단계의 판단 내용 | 유지하거나 보류해야 하는 경우 |
+|---|---|---|
+| 1. 권리자·의무자 및 법적 지위의 동일성 | 실제 권리 귀속·의무 부담 주체, 본인/대리인·법인/대표자, 승계 경로와 현재 행사 주체를 확인한다. | 이름만 같거나 당사자 지위·승계가 불명확하면 동일성을 유보한다. 원고 표시와 실체적 권리자를 기계적으로 동일시하지 않는다. |
+| 2. 구체적 거래·사건의 동일성 | 같은 계약·대여·사고·침해행위에 관한 자료인지, 별개 발생 원인인지 확인한다. | 같은 당사자의 독립된 거래·발생 사건은 별개로 유지한다. 계약 ID가 다르더라도 변경·승계 관계일 수 있어 그 차이만으로 독립성을 확정하지 않는다. |
+| 3. 실체법상 청구권의 동일성 | 동일 권리의 요건·내용을 설명하는 후보인지 확인한다. 조문 이름·domain 일치만으로 판단하지 않는다. | 같은 손해의 계약책임·불법행위책임 등 경합하는 권리는 별도로 유지하고 관계를 기록한다. |
+| 4. 급부·대상·법률효과의 동일성 | 누구에게 어떤 급부를 요구하는지와 목적물·등기·법률관계·법률효과를 비교한다. | 같은 부동산의 인도·이전등기·손해배상 등 서로 다른 요구를 하나의 권리로 합치지 않는다. |
+| 5. 청구 범위·시간 구간의 대응 | 전체/일부, 금액 산정 차이, 기간·회차와 독립 채권 여부를 구별한다. | 단순 총액·기간 중첩은 동일성 근거가 아니다. 같은 권리에 속하는 범위 구분도 삭제하지 않는다. |
+| 6. 발생·변경·소멸 자료의 보완 관계 | 계약·송금·변제·상계·시효 자료를 같은 권리의 요건·항변·재항변으로 연결한다. | 반대 자료와 모순을 보존한다. 상계의 자동채권 등 별도 권리의 존재도 구별한다. |
+| 7. 독립 청구·부수·경합 관계 보존 | 원금/이자·지연손해금, 주채무/보증, 주위·예비·선택·누적 관계와 회복 범위의 영향을 구별한다. | 공동 검토·동일 손해·중복 회복 제한은 곧 청구권 동일성이 아니다. 별개 권리와 연결 관계를 함께 저장한다. |
+| 8. 근거 추적·불확실성 처리 | 원본 refs로 동일성 판단을 설명하고 자료·authority·review 공백을 표시한다. | shared evidence·같은 이름·같은 profile만으로 확정하지 않는다. 동일성 불명확은 병합 보류이며 청구 배제가 아니다. |
+
+사용자가 제시한 [대법원 2008. 6. 26. 선고 2007다43436 판결](https://law.go.kr/LSW/precInfoP.do?precSeq=64896)은 같은 채권자·채무자라도 별개의 발생시기·원인을 가진 손해배상채권을 각각 특정해야 한다는 구별과 관련된다. [대법원 1983. 3. 22. 선고 82다카1533 전원합의체 판결](https://www.law.go.kr/LSW/precInfoP.do?evtNo=82%EB%8B%A4%EC%B9%B41533)은 해당 해상운송 사안의 계약상·불법행위상 손해배상청구권 경합에 관한 근거다. 이를 모든 청구 유형의 동일성에 관한 단일 공식으로 확장하지 않는다. 개별 청구 유형의 소송물·청구 범위는 제공 authority와 사건 자료에 따라 검토한다.
+
+통합 결과에는 `MERGE`, `KEEP_SEPARATE`, `UNRESOLVED`의 **동일성 판단**과 기존 `SUPPORTED/CONDITIONAL/UNRESOLVED/EXCLUDED`의 **청구 성립 판단**을 따로 둔다. 같은 청구의 자료라는 판단이 가능해도 성립 여부는 조건부일 수 있으며, 청구가 배제되는 후보도 그 검토 이력을 삭제하지 않는다.
+
+## 5. 수행 방안의 비교와 선택
+
+| 방안 | 이점 | 비용·누락 위험 | 선택 |
+|---|---|---|---|
+| 전체 사건·모든 cluster를 한 LLM에 재전달 | 전역 맥락을 한 번에 볼 수 있다. | 기존 추론·자료를 전량 반복하고 큰 입력·출력·재시도 부담이 생긴다. | 기본안 제외 |
+| 원고·피고 조합마다 자료 전량을 재판단 | 당사자별 검토를 구성하기 쉽다. | 독립 거래가 많으면 입력이 커지고 조합 밖의 보증·공동채무 관계를 놓칠 수 있다. | 후보 탐색의 상위 묶음으로만 사용 |
+| 모든 후보 쌍을 별도 LLM 비교 | 비교 결과를 개별 추적하기 쉽다. | 후보 n개에 최대 n(n−1)/2개의 비교가 생기고 설명·증거를 반복한다. 연쇄 병합의 정합성도 별도 판단해야 한다. | 제외 |
+| 기존 후보·자료 인덱스에서 관련 묶음을 준비하고 필요한 법률판단만 추가 | 원본을 보존하면서 후보·공유 본문을 재사용하고 누락·충돌에 집중한다. | 자료 연결·잔여 자료 coverage와 큰 묶음의 처리가 필요하다. | **채택** |
+
+채택안은 **통합 기록을 모든 후보에 대해 만들되, 새로운 LLM 추론은 공동 검토가 필요한 묶음에 집중**한다. 기존 단일 후보를 코드로 재사용하는 것은 첫 단계의 법률판단을 상속하는 처리이며, reducer가 그 판단을 다시 법률적으로 인증한다는 의미가 아니다.
+
+## 6. 비 LLM 통합 준비와 당사자 확인
+
+### 6.1 기존 결과로부터 만들 인덱스
+
+통합 prepare 한 프로세스에서 모든 검증된 wave를 한 번 읽어 다음 자료를 만든다.
+
+- 후보 endpoint `(cluster_ref, option_local_ref)`별 전체 결과와 원본 근거 참조.
+- 권리자·의무자 refs, 원본에 명시된 party ID·동일인/승계 관계와 그 근거.
+- 계약·발생 사건·목적물·급부·법률효과·시간 범위의 명시적 원본 참조.
+- 요건·항변/재항변·구제·기간·의뢰인 지시·review와 source_gaps.
+- 후보 간 관계와 아직 후보 endpoint가 없어 남긴 관계·missing_inputs.
+- 후보가 없는 cluster의 원본 자료, 미선택·unbound signal/review의 보존 위치와 연결 상태.
+
+기존 후보 Schema에는 독립된 거래 ID·기간 구간·당사자 정규화표가 항상 제공되는 것은 아니다. 필요한 anchor는 `basis_refs`, 당사자·객체 refs와 실제 제공된 원본 필드에서 얻고, 자유 서술의 의미를 Python이 확정했다고 표시하지 않는다. 확보되지 않은 anchor는 `unknown`으로 남긴다. 새로운 요약 LLM이나 별도의 당사자 식별 LLM을 선행 추가하지 않는다.
+
+명시적 동일인 ID나 검증 가능한 원본 연결이 있으면 코드가 표기·참조를 대응시킬 수 있다. 이름 유사도·법률영역 일치는 탐색 힌트로만 쓰며 최종 동일인 판정으로 쓰지 않는다. 권리 귀속·대표·승계의 법률판단이 남아 있으면 동일 통합 호출 안에서 먼저 검토하도록 한다. 당사자가 미확인이라는 이유로 후보나 자료를 검토 묶음에서 탈락시키지 않는다.
+
+### 6.2 검토 묶음은 잠정 관련 집합이다
+
+먼저 확인된 당사자 조합을 탐색 범위로 삼고, 구체적 거래·발생 사건·목적물·권리 내용 및 명시적 관계를 이용해 **관련성이 있는 후보와 자료의 잠정 묶음**을 만든다. 이 묶음은 청구권 동일성의 결론이 아니다. 모호한 후보는 여러 묶음과의 관련 가능성을 보존하고, 공통 사실 자료도 여러 청구의 근거가 될 수 있다.
+
+명확한 자료 참조, 후보 관계, missing_inputs가 지시한 연결을 우선 사용한다. 같은 domain의 모든 자료를 각 묶음에 방송하지 않는다. 반대로 party·거래 anchor가 없거나 기존 후보에 참조되지 않았다는 이유로 자료를 버리지 않는다. 연결할 수 없는 자료는 잔여 자료 목록에 남기고, 짧은 원본 투영·자료 종류·가능한 연결·미확인 이유를 제공하여 연결 검토 대상으로 배정한다. 짧은 투영은 원본 값의 명시적 선택으로 만들고 자유 서술에서 법률적 중요성을 추측해 축약하지 않는다.
+
+잠정 묶음을 분할할 때는 명시적으로 독립된 검토 범위만 분리한다. 서로 다른 contract ID나 후보 문장의 차이만으로 법률적 독립성이 증명되었다고 처리하지 않는다. 당사자 조합을 넘어서는 보증·공동채무·승계·중복 회복·선결 관계는 별도 연결로 유지하고 필요한 후보·자료만 함께 제공한다.
+
+### 6.3 코드 재사용과 LLM 호출의 구분
+
+| 상황 | 처리 |
+|---|---|
+| 단일 후보이며 당사자·발생 원인·범위가 명확하고 관련 자료·미해결 연결·새 충돌이 없는 경우 | 기존 결과를 참조하여 단일 청구 기록을 조립한다. 새 법률판단 없이 동일성 통합 LLM은 생략한다. |
+| 완전히 같은 후보 endpoint가 여러 탐색 묶음에 반복 등장 | 참조 표현 중복을 코드로 제거한다. 서로 다른 endpoint의 동일성은 이 이유만으로 확정하지 않는다. |
+| 여러 cluster 후보의 동일성, 흩어진 요건·항변, 서로 다른 당사자 표시, 상충 판단 또는 잔여 자료 연결이 필요한 경우 | 하나의 자기완결적 묶음에서 통합 LLM으로 판단한다. |
+| 후보가 없지만 관련 사실을 모으면 권리 후보가 생길 수 있는 경우 | 기존 원본 자료와 빈 후보 결과를 함께 제공해 새 후보를 식별할 수 있게 한다. |
+| 당사자·거래·authority가 부족하여 결론이 어려운 경우 | 관련성 검토와 부족 자료를 기록하고 동일성 또는 성립 판단을 유보한다. |
+
+단일 후보 재사용에는 **사건 전체 후보·잔여 자료를 검토한 인덱스와 그 한계**가 있어야 한다. unbound 자료의 관련성 미평가가 남아 있으면 이를 물려받고 ‘완전한 검토 완료’로 표시하지 않는다. 모든 `EXCLUDED`·미제기 지시·빈 후보 결과를 재사용 또는 검토 대상으로 명시하여 조용히 삭제하지 않는다.
+
+## 7. 통합 LLM 입력과 출력의 최소 계약
+
+### 7.1 자기완결적 통합 packet
+
+| 입력 영역 | 전달 내용 |
+|---|---|
+| `candidates` | 기존 후보 endpoint와 당사자·발생 원인 anchor·급부·대상·법률효과·범위, 요건/항변 등의 기존 판단 참조. 동일 입력 안의 사전에 모든 필요한 값이 존재해야 한다. |
+| `materials` | 동일성·분산 요건·반대 자료·항변·자료 공백 판단에 필요한 원본 투영과 필드 refs. 다른 cluster의 중요한 자료도 포함한다. |
+| `assessment_catalog` | 재사용할 요건·항변/재항변·구제·기간·review 평가를 한 번씩 저장한 사전. 후보별로 같은 평가 본문을 반복하지 않는다. |
+| `questions` | 8개 동일성 기준에 따른 미확인·충돌 질문과 기존 missing_inputs. 통합 대상 목록이 법률 결론이 아님을 명시한다. |
+| `relations` | 내부 후보 관계와 필요한 외부 후보의 최소 내용·근거. 같은 입력에 없는 외부 자료를 본 것처럼 판단하지 않는다. |
+| `goal`, `profiles`, `authorities`, `limitations` | 실제 관련된 의뢰인 제약·검토 질문·사용 가능한 authority·source_gaps·evidence/dependency 범위. authority 원문은 해당 호출에 필요한 명제를 보존한다. |
+| `residual_materials` | 배정된 미연결 자료의 실제 값과 참조, 미배정 자료의 수·이유·확정 판단 제한. count만으로 관련 자료를 검토한 것으로 간주하지 않는다. |
+
+기존 후보 판단을 사실이나 공식 authority로 취급하지 않는다. 동일성을 좌우하는 당사자·거래·목적물·급부·범위는 첫 호출에 포함한다. 새로운 청구 성립 판단이나 기존 요건 변경에 필요한 사실·반대 자료도 전달해야 한다. 저장 파일에 ref가 있다는 것만으로 모델이 해당 본문을 읽었다고 간주하지 않는다.
+
+긴 원본 ref는 호출별 짧은 별칭으로 바꾸고 reducer control에서 되돌린다. 서로 다른 occurrence에는 서로 다른 별칭을 주고, 동일 본문만 `bodies` 사전으로 공유한다. 원본에서 기존에 다른 의미를 가진 fact/party ID·증거번호·날짜·금액을 덮어쓰지 않는다. `shared_context`가 파일을 한 번 읽어도 각 모델 요청에 다시 들어가는 본문은 요청별 입력 토큰으로 계산한다.
+
+### 7.2 한 호출에서 수행할 순서
+
+1. 권리자·의무자·법적 지위와 동일성의 미확인 범위를 검토한다.
+2. 기존 후보·원본 자료를 8개 기준에 따라 비교하여 동일 청구권의 구성, 별개 권리, 판단 유보를 제안한다.
+3. 분산 자료를 함께 보았을 때 새로 드러난 요건·항변/재항변·청구 후보와 기존 판단의 모순을 검토한다.
+4. 요건·반대 자료·부담·구제·기간·의뢰인 제약·review의 **변경 또는 추가가 필요한 부분**을 판단한다.
+5. 독립·부수·경합·주위/예비·중복 회복 관계와 미해결 연결을 남긴다.
+
+동일성 판정과 통합 후 성립 검토를 별도 LLM task로 쪼개지 않는다. 같은 사실을 다시 전송하고 동일성 이유를 반복하는 비용을 줄이기 위해 관련 묶음의 한 task 안에서 수행한다. 외부 검색·파일 저장·자율 tool 호출은 허용하지 않는다.
+
+### 7.3 sparse 출력과 비 LLM 조립
+
+통합 LLM의 출력은 `identity_decisions`, `claim_compositions`, `assessment_deltas`, `new_claim_candidates`, `relation_deltas`, `review_patches`, `needs_materials`, `missing_inputs`, `assumptions`의 JSON 객체 하나로 설계한다. `claim_compositions`에는 통합 또는 분리할 기존 endpoint, 사용·재사용할 평가 참조, 관련 원본 자료 참조와 이유를 둔다. 새 후보에는 기존과 동등한 법률 검토 필드를 요구한다. `needs_materials`는 고정 snapshot의 허용 자료 참조와 요청 이유이며 불필요하면 빈 배열로 둔다.
+
+동일성 판단에도 8개 기준별 결론·지지/반대 원본 refs·authority·미확인 사항을 기록한다. 법률적 동일성을 확정하는 `MERGE/KEEP_SEPARATE`에는 사용 가능한 authority와 사실 근거를 요구하고, 부족하면 잠정 구성과 `UNRESOLVED`를 남긴다. 동일 endpoint의 표현 중복을 제거하는 코드 처리는 이런 법률판단과 구별한다.
+
+변경 없는 기존 평가 본문을 전부 재출력하지 않는다. **재사용 여부는 입력에 실제 포함된 평가를 모델이 명시적으로 선택**하도록 하고, 통합으로 새 자료·반대 근거가 추가된 요건은 delta로 수정한다. 병합 전의 서로 다른 판단을 코드가 임의로 하나 골라 채택하거나, 관련 범위가 달라진 평가를 자동으로 승계하지 않는다. 변경 없는 출력의 생략이 허용되는 필드와 계승 규칙은 wire Schema·compiler 버전에 명시한다.
+
+새 청구 기록의 임시 참조는 현재 snapshot 안의 검토용 식별값이다. 기존 `(cluster_ref, option_local_ref)`와 자료 refs를 항상 보존하며 최종 사건유형·claim_group·renderer·exhibit ID를 만들지 않는다. 한 후보의 부분 범위를 나누는 경우 근거와 범위 설명을 남겨 단순 중복 membership 오류와 구별한다.
+
+## 8. 개별 입력과 전체 추론 토큰을 줄이는 원칙
+
+**기존 cluster 판단:** v.2의 원래 논리적 payload를 보존한다. `cluster_ref`와 `members`, `signals`, `reviews`, `goal`, `profiles`, `profile_catalog`, `authorities`, `relations`, `predecessor_candidates`, `scc_neighbour_members`, `source_gaps`, `unbound_domain_material_counts`, `evidence_scope`, `dependency_scope` 및 repair 자료를 pack/unpack으로 검증한다. 호출 내부의 완전히 같은 본문만 공유하며 원본 occurrence·순서·상태·차단 정보를 유지한다.
+
+**통합 판단:** 기존 법률판단을 재사용하되 동일성·새 사실·반대 자료·누락·모순에 필요한 범위만 추가 추론한다. 후보별 요건·항변을 모든 경우 다시 작성하게 하지 않는다. 단일 후보 재사용, 관련 묶음 단위 호출, 중복 본문과 평가의 사전화, 임시 별칭, sparse delta를 함께 적용한다. 같은 모델·추론 설정을 우선 유지하고 reasoning 설정을 낮추는 것을 기본 절감 수단으로 삼지 않는다.
+
+정확히 같은 자료를 짧게 표현하는 것과 자료를 선별하는 것을 구분한다. 통합 packet의 선택은 항목별 원본 refs·목적·선택/보류 사유를 control에 남긴다. 동일성 검토에는 필요 없는 대형 평가 본문을 재출력하지 않을 수 있으나, 그 평가를 새 성립 판단의 근거로 사용할 때는 필요한 본문·반대 자료를 실제 입력에 제공한다. 사실·법률 내용의 중요성이 불명확하면 삭제 대신 보류 또는 명시적 추가 자료 요구로 처리한다.
+
+### 8.1 추가 자료가 꼭 필요한 경우
+
+LLM은 고정 snapshot 안의 `needs_materials` 참조와 미해결 질문을 반환할 수 있다. prepare가 허용된 원본만 결정적으로 보강하고, **해당 미해결 질문에 한해 한 번의 보강 판단**을 허용하는 방안을 채택한다. 모델이 자료를 직접 읽거나 새로운 검색을 수행하는 구조가 아니다. 처음부터 필요한 핵심 자료를 빼고 모든 묶음에 두 호출을 강제하는 방법도 아니다.
+
+자료 보강은 법률상 새 입력을 추가하는 호출이므로 기존 구조 보정과 별도로 기록하고 총 입력·추론 예산에 포함한다. 보강 packet은 같은 upstream snapshot에 묶되 새 packet digest를 가진다. 구조 보정은 이 보강 packet까지 포함한 정확히 같은 입력에서 오류만 고치는 것으로 최대 한 번이며, 기존 cluster의 단일 구조 보정 규칙을 확장하지 않는다. 보강 후에도 부족하면 `UNRESOLVED`를 보존하고 자동 반복하지 않는다.
+
+### 8.2 큰 통합 묶음
+
+호출 예산은 system·Schema·packet·repair의 전체 입력, 출력 예약, 추론 예산, 동시 TPM와 MCP envelope를 함께 고려한다. byte 제한을 모델 토큰 한도로 해석하지 않는다. 먼저 본문·평가 사전과 별칭을 적용하고, 명시적으로 독립된 권리 범위가 있으면 그 범위로 분리한다. 관련 묶음이 여러 청구를 포함할 수 있으므로 ‘하나의 당사자 조합당 한 호출’을 강제하지 않는다.
+
+법률적으로 연결된 묶음을 임의의 8-cluster 단위로 잘라 각각 병합 확정하지 않는다. 독립 분할이 불가능하면 후보·관계별 하위 검토 후 **공유 자료·모순·경계 후보를 포함한 최종 조정 호출**이 필요한 제한적 대안을 비교한다. 그 조정 호출까지 예산에 넣고, A–B·B–C 판단만으로 A–C의 충돌을 무시한 전이 병합을 금지한다. 의미와 참조를 충분히 전달할 수 없으면 크기·자료 부족을 명시해 미완료 또는 법률 미해결로 남긴다.
+
+### 8.3 총 토큰 비교
+
+```text
+v3 사건 전체 모델 토큰
+  = cluster 판단의 입력 + 출력 + 실제 reasoning
+  + 필요한 통합 판단의 입력 + 출력 + 실제 reasoning
+  + 자료 보강 + 구조 보정 + 큰 묶음의 최종 조정 비용
+```
+
+최적화 목적은 **필수 통합 품질과 자료 coverage를 충족하는 설계들 사이에서** 이 합계와 개별 호출의 최대 입력을 최소화하는 것이다. 통합 기능이 없는 현행 또는 v.2와 비교하여 항상 총량이 줄어든다는 의미가 아니다. 할인·prompt cache·저장 바이트 감소도 실제 입력·reasoning 토큰 감소와 따로 보고한다.
+
+v.2의 Schema 공통화 실험은 7,668→5,443바이트라는 이전 문서의 로컬 표현 측정으로만 인용한다. 이번에 재실험하거나 모델 토큰 절감을 측정하지 않았다. 새 통합 Schema도 재사용 `$defs`로 표현하되 필수 필드·enum·참조 제한을 삭제하지 않는다. 작은 입력이 사전 마커 때문에 더 커지면 일반 표현을 사용한다.
+
+## 9. v.2 입력·저장 최적화의 계승
+
+원래 payload의 Python 복원·검증, 자기완결적 compact model packet, 허용 인용 필드에서만 alias 복원, 정본 Schema 검증은 계속 유지한다. prompt Schema 축약과 출력의 sparse patch는 법률 검토 항목을 축소하는 수단이 아니다. 프로세스별 인덱스 재사용을 우선하고 영속 cache·journal·추가 요약 LLM은 기본안에 추가하지 않는다.
+
+`wave_input.json`에서 다음 10개 최상위 값은 v.2처럼 파생하거나 고정 입력에서 얻는다. 모든 값을 control에 그대로 복제하지 않는다.
+
+| 제거 필드 | 대체 근거 |
+|---|---|
+| `algorithm_version` | 코드 상수와 `input_binding.contract.algorithm` |
+| `upstream_root`, `output_root` | 고정 upstream 및 새 출력 계약; 작은 receipt 경로 |
+| `input_fingerprint` | canonical input binding의 digest |
+| `expected_clusters` | 원래 waves의 평탄화·중복 검사 |
+| `prior_artifacts`, `previous_wave_sha256` | 해시로 고정한 기존 status와 해당 artifact; 최초 부재 확인 |
+| `execution_mode`, `source_policy_release_class`, `upstream_status` | 고정한 upstream ingress status |
+
+control에는 기존 `validation`, `input_binding`, waves·wave ordinal·현재 batch 선택·이전 status hash·base_summary·source_issues·재사용 여부와 compiler/alias 결속을 보존한다. 통합용 control도 전체 후보/자료 목록, 묶음 배정, 원본/결과/packet hash, 허용 refs·authority·review·성공 결과 불변성·잔여 자료를 가진다. 이 정보는 LLM map source에 방송하지 않는다.
+
+전달 경로는 v.2의 **작은 map 인덱스 + 최대 8개 compact slot**을 우선 검증한다. 통합 slot도 한 호출에 필요한 본문 사전을 모두 포함한다. dynamic `preflight_files`가 map에서 동작하고 whitelist 및 중복 삽입 방지가 실제 확인되어야 한다. LLM의 자율 도구 호출은 여전히 금지한다. 작은 직접 `item_json` 전달은 native `read_docs` 응답·입력 반송·최대 모델 출력·base64 envelope를 포함한 admission과 속도 비교를 통과할 때만 채택한다. 두 경로를 무조건 동시에 배포하지 않는다.
+
+prepare의 common index, source·schema 검사 cache는 한 프로세스 안에서 재사용한다. Code Executor 호출 사이 메모리 공유나 캐시된 원본의 무조건적 불변성을 가정하지 않는다. 필요 최초 read-back·발행 직전 변경 확인을 유지하고 대형 자료를 stdout·`map_results`로 중복 반송하지 않는다.
+
+## 10. 작업 연결, 배치와 이어 실행
+
+### 10.1 제안하는 책임 분리
+
+| 제안 task/역할 | 실행 주체와 책임 |
+|---|---|
+| 기존 `Task_S2_10_prepare_wave` / `Task_S2_10_resolve_cluster` / `Task_S2_10_validate_publish_wave` | cluster phase의 선택·추론·검증·wave 발행. 통합 전까지 첫 단계 결과는 가설·검토 기록으로 유지한다. |
+| `Task_S2_10_prepare_claim_integration` | 비 LLM. 전체 cluster coverage gate, party/거래/후보/자료 인덱스, 재사용 대상, 잔여 자료, 이번 배치의 통합 packet·control 준비. |
+| `Task_S2_10_integrate_claims` | LLM. 한 잠정 묶음의 동일성·보완 자료·새 후보·변경 평가와 관계를 판단한다. |
+| `Task_S2_10_validate_publish_claims` | 비 LLM. 참조·동일성 구성·자료 coverage·delta·review 충돌 검증, 기존 판단과 조립, 통합 batch 저장·최종 청구 기록 발행. |
+
+통합 prepare와 통합 MapReduce를 기존 wave 저장 뒤의 고정 작업으로 연결하는 구성이 기본안이다. **실행 단계 도달과 사건 전체 완료 gate를 구분**해야 한다. 현행 Stage DAG가 수행됐다는 사실만으로 모든 wave가 끝났다고 간주하지 않는다. gate는 원본의 expected cluster 집합과 모든 저장 artifact를 직접 대조한다.
+
+호출자는 전체 status에 따라 한 writer로 같은 Agent를 재호출한다. 진입 prepare가 이번 호출의 phase를 고정한다. cluster phase가 끝나면 다음 호출은 integration phase를 선택하고 기존 cluster LLM을 재호출하지 않는다. 한 호출에서 새 모델 작업은 한 phase의 최대 8개로 제한하여, 마지막 cluster 배치와 첫 통합 배치를 한꺼번에 실행해 16개 호출이 생기지 않게 한다. 한 실행의 항목 수≤8과 map 동시성≤8은 각각 별도로 적용한다.
+
+구현 시 phase gate가 비활성 phase의 모델 호출을 확실히 막는지 확인해야 한다. 비활성 phase의 prepare/reducer는 명시적 no-op receipt만 반환하고 wave·성공 결과·전체 status를 덮어쓰지 않는다. 문서화된 task-procedure 조건 분기 또는 검증된 빈 map 동작을 사용하며, 가이드에 없는 Stage `when`, 자동 Stage loop, 동적 prompt loader를 가정하지 않는다. 고정 Stage를 빈 source로 통과시키는 경로는 empty-map reducer·실패 전파·동일 실행 receipt 결속이 live 검증되어야 한다. 미지원이면 문서화된 분기 실행 계약을 먼저 정하고 phase routing을 구현 완료로 표시하지 않는다.
+
+### 10.2 논리적 wave와 통합 배치의 구별
+
+cluster phase는 S2_00의 논리적 wave·SCC를 유지한다. 물리 배치만 최대 8개로 나누고 같은 wave의 앞 배치 verdict를 뒤 배치의 선행 후보로 넣지 않는다. 통합 phase는 모든 wave가 끝난 이후이므로 **이번 통합 snapshot 안의 모든 검증된 cluster 후보**를 읽을 수 있다. 서로 병렬인 통합 묶음의 미완료 출력은 참조하지 않는다.
+
+통합 묶음 간 관계는 원래 후보 endpoint로 표현하고, 최종 reducer가 endpoint→청구 기록 대응을 복원한다. 한 묶음에서 여러 청구권을 식별할 수 있다. 나눠 실행한 묶음 사이에 병합 여부가 미확인으로 남으면 필요한 경계 후보만 조정 호출에 제공하며 전체 사건을 다시 판단하지 않는다. 경계 검토 없이 관계를 자동 청구권 병합으로 승격하지 않는다.
+
+배치에는 같은 phase의 미처리·허용 보강·구조 보정 항목만 선택한다. 입력 크기·출력 예약·동시 예산·측정된 처리시간으로 개수를 줄일 수 있다. 8개 동시성이 전체 입력 개수나 출력 한도의 보증은 아니다. 동일 입력의 검증된 성공 결과는 재사용하며 완료 snapshot 전체 재사용의 모델 호출 수는 0이다.
+
+## 11. 통합 출력, 검증과 완료 상태
+
+### 11.1 제안하는 최소 파일 구성
+
+새 출력 root는 계약 버전으로 구분하여 현행 `s2_10/v1` 결과를 덮어쓰지 않는다. request/attempt ID는 새로 만들지 않고 기존 snapshot·자료 refs와 hash binding을 재사용한다.
+
+| 파일 | 역할 |
+|---|---|
+| `waves/wave-NNNN.json` | 기존 cluster phase 결과. 통합 결과로 원본 후보를 수정하지 않는다. |
+| `work/claim_integration_control.json` | 통합 snapshot·결과 hash·전체 배정/잔여 자료·alias와 검증 기준. reducer 전용이며 모델 입력과 분리한다. |
+| `work/claim_integration_index.json` 및 최대 8개 통합 slot | 현재 배치 descriptor와 자기완결적 compact packet. 검증된 직접 경로를 택하면 slot은 생략한다. |
+| `integration/batch-NNNN.json` | 검증된 통합 composition·sparse delta·보강/보정 이력. 성공 항목 재사용과 조립의 근거다. |
+| `claims/claim_records.json` | 모든 통합 배치가 끝난 뒤 조립한 청구 기록·관계·잔여 자료·검토 제한. 최종 법률 승인 전의 draft다. |
+| `s2_10_status.json` | cluster와 integration phase별 coverage·기술 상태·법률 공백·최종 artifact 결속. 항상 마지막 저장. |
+
+청구 기록은 권리자·의무자·지위, 발생 원인·급부·대상·법률효과·범위, 기여한 cluster/후보/원본 refs, 요건·항변/재항변·부담·구제·기간·의뢰인 지시·review·공백을 포함한다. 공통 평가·자료 본문은 파일 안의 사전에 한 번 저장할 수 있으나 소비자가 결정적으로 복원할 수 있어야 한다. downstream에 파일 path만 넘기고 알아서 원래 평가를 찾게 하지 않는다.
+
+### 11.2 reducer의 검증 범위
+
+- wire JSON을 검사한 뒤 alias를 허용 필드에서 복원하고 정본 Schema·허용 원본 refs·authority·review·후보 endpoint를 검증한다.
+- 모든 기존 후보가 청구 composition·별개 보존·동일성 미해결 중 하나에 명시적으로 대응되는지 확인한다. 부분 범위 분리·다대다 자료 공유는 명시적 근거로 구별한다.
+- `MERGE` 구성 안의 당사자·원인·권리·급부·범위 설명과 명시적 `KEEP_SEPARATE` 제약이 충돌하면 거부하거나 법률 재검토 대상으로 남긴다. 문자열 일치만으로 법률적 동일성을 인증하지 않는다.
+- 빈 후보 cluster 및 미연결 signal/review는 검토·재사용·근거 있는 관련 없음·미확인 중 어떤 처리가 됐는지 추적한다. 미확인 잔여 자료를 없어졌다고 간주하지 않는다.
+- 변경 없는 평가의 명시적 계승, 새/변경 요건의 근거·반대 자료·부담·missing_inputs, blocking review와 source_gaps의 확정 판단 제한을 검사한다.
+- 새 후보의 refs는 이번 packet에서 실제 제공된 자료에 한정한다. 다른 통합 묶음의 출력·읽지 않은 authority를 발명할 수 없다.
+- 동일 snapshot·source/cluster-result/control/packet hash, 성공 결과 불변, 원본 원장 불변, read-back·status-last를 유지한다. single writer를 원격 CAS 또는 원자적 잠금의 구현 증거로 삼지 않는다.
+
+기존 `validate_result`의 allowed_refs와 predecessor endpoint는 cluster별 범위다. 통합 결과에 그대로 적용하면 타 cluster의 유효 근거를 잘못 거부할 수 있으므로, **통합 packet에 실제 포함된 자료와 모든 참여 후보를 기준으로 별도 validation scope**를 만든다. 기존 cluster 검증은 변경된 scope로 느슨하게 만들지 않는다. `SUPPORTED/EXCLUDED`의 usable authority 요구와 `CONDITIONAL/UNRESOLVED`의 missing_inputs 요구도 새 검증에 유지한다.
+
+모든 wave의 후보가 제공되어 기존 SCC verdict 부족 등의 제한을 실제 해소한 경우에는 근거와 해소 범위를 통합 기록에 명시한다. 원본 source_gaps는 삭제하지 않고 최종 평가의 제한과 구별한다. schema 미평가·원문/authority 부족·미배정 자료처럼 통합만으로 해결되지 않는 공백은 계승한다.
+
+### 11.3 상태의 의미
+
+새 status는 `cluster_phase`와 `integration_phase`를 분리한다. cluster 완료만으로 S2_10 전체 `COMPLETED`를 발행하지 않는다.
+
+| 상태 제안 | 의미 |
+|---|---|
+| `NEXT_WAVE_PENDING` | cluster phase의 미처리 wave/배치가 남았다. |
+| `INTEGRATION_PENDING` | cluster coverage는 완료됐으나 통합 준비·판단·필요 조정이 남았다. |
+| `TECHNICAL_INCOMPLETE` | 해당 phase의 구조/참조/입출력 실패가 있어 허용된 보정 또는 운영 조치가 필요하다. |
+| `COMPLETED_WITH_ISSUES` | 모든 배정 작업과 최종 조립이 기술적으로 끝났으나 동일성·법률·당사자·잔여 자료·review 공백이 남았다. 완전한 청구권 식별이나 법률 승인이라는 뜻이 아니다. |
+| `COMPLETED` | 두 phase와 최종 artifact 검증이 끝났고 정의된 미해결 사항이 없다. 여전히 검토 가능한 법률 초안이다. |
+
+원본 전체가 빈 경우에는 근거 있는 empty-input 결과와 잔여 자료 coverage를 기록하며 모델을 부르지 않는다. 후보 배열이 비었다는 이유만으로 empty input으로 처리하지 않는다. 기존 완료 결과와 새 통합 계약의 완료 의미가 다르므로 알고리즘·Schema·prompt·compiler·출력 root를 함께 버전 관리한다. S2_20의 실제 소비 코드·Schema가 새 결과를 허용하는지는 구현 때 별도로 확인해야 하며, 기존 handoff와 자동 호환된다고 선언하지 않는다.
+
+## 12. 구현 순서와 검증 계획
+
+1. **입력·계약 고정:** 현재 YAML과 S2_00 snapshot, 모델·prompt·authority·Schema·원본 refs를 기록한다. 두 phase, 통합 wire·조립 Schema·검토용 참조·새 status와 root를 정의한다.
+2. **v.2 저비용 최적화:** prepare 인덱스, 10개 필드 파생·control 분리, Schema 공통화, compact packet·alias 복원을 구현한다. 원래 선택 집합·의미·최종 refs의 동등성을 확인한다.
+3. **통합 prepare:** 기존 후보 필드·원본 refs에서 party/거래/자료 인덱스를 만들고 잠정 묶음·단일 후보 재사용·잔여 자료 배정과 coverage를 구현한다. 문서에 없는 party registry가 있다고 가정하지 않는다.
+4. **통합 LLM와 조립:** 동일성·새 후보·평가 delta·관계·review 계약을 구현하고 input에 포함된 값만 재사용하도록 한다. 자료 보강과 구조 보정의 서로 다른 예산·digest를 연결한다.
+5. **실행 연결:** 전체 cluster gate, phase별 최대 8개 admission, 재호출·완료 재사용·slot/control 결속·실패 전파·중단 후 복구·최종 status를 검증한다.
+6. **법률 품질·전체 비용 비교:** 같은 사건으로 무통합 baseline, 전량 재판단, 채택안을 비교하여 청구 누락·잘못된 병합/분리·당사자 오류와 개별/전체 토큰·지연을 확인한다.
+
+### 12.1 의미 있는 검증 사례
+
+| 사례 | 확인할 결과 |
+|---|---|
+| 같은 대여의 계약·송금·변제·시효 자료가 여러 cluster에 분산 | 동일 권리의 자료를 종합하고 반대 자료·잔액/기간 미확인을 보존한다. |
+| 같은 당사자의 서로 다른 대여 또는 독립 손해 | 총액·이름·domain이 같아도 별개 권리와 범위를 유지한다. |
+| 같은 손해의 계약책임·불법행위책임 | 권리를 별도로 유지하고 경합·회복 범위 관계를 기록한다. |
+| 원금/이자·지연손해금, 주채무/보증, 승계 전후 자료 | 서로 다른 권리·급부·주체와 연결/승계 이력을 보존한다. |
+| 당사자 이름만 같음, 대표자·법인 혼동, 지위 미확인 | 자동 동일인·동일 청구 판정을 하지 않고 확인 사항을 남긴다. |
+| 후보가 없는 cluster에 중요한 반대 자료 또는 새 청구의 요건 존재 | 해당 자료를 통합 검토에 포함하고 새 후보 또는 기존 판단 수정이 가능하다. |
+| 같은 후보에 대한 상충 요건 판단·blocking review·authority 없음 | 코드로 한 판단을 골라 확정하지 않고 조건부·미해결을 유지한다. |
+| A–B 병합·B–C 병합 후보와 A–C 분리 근거 | 단순 Union-Find로 하나의 청구권을 확정하지 않는다. |
+| 여러 권리를 포함한 한 cluster와 여러 청구에 공통인 증거 | 원본 cluster 불변과 후보/자료의 다대다 대응을 유지한다. |
+| 0·1·8·9개, 8개 초과 SCC, 큰 party 묶음, 한 packet 크기 초과 | phase당 배치·개별/전체 예산과 의미 보존·미완료 처리를 확인한다. |
+| 자료 보강·구조 보정·stale control·출력 누락·status 전 중단 | 입력 변경과 보정을 구별하고 성공 결과 불변·복구·hash 결속을 확인한다. |
+| 같은 완료 snapshot 재호출 | 원본·결과 확인 후 모델 호출 0회이며 통합 작업을 누락하지 않는다. |
+
+### 12.2 측정과 채택 조건
+
+입력 토큰은 system·Schema·실제 packet·보강/repair를 포함해 호출별 최대값과 사건 전체 합계를 측정한다. 실제 output·reasoning 토큰, cache/billing, phase별 호출 수·보강/보정 수, prepare·MCP·map·reducer·전체 지연도 함께 기록한다. 현재 현행 entry의 `usage`는 null이며 문서화된 map 결과만으로 usage를 확보했다고 볼 수 없다. 사용량 경로를 확인하지 못하면 reasoning 토큰은 미측정으로 보고하고 모델에게 토큰 계산을 시키지 않는다.
+
+구조 검증과 pack/unpack 동등성은 법률 품질의 증거를 대신하지 않는다. 청구권 동일성·당사자/지위·신규 후보 발견·요건/항변·불리한 사실·중복 회복·원본 인용·잔여 자료 coverage를 사건별 검토 기준과 대조한다. **중요한 검토 누락이나 잘못된 병합이 없는 범위에서** 총 모델 비용과 개별 입력을 줄이는 구성을 채택한다. compact 표현의 해석 부담·추론 토큰·보정이 늘면 일반 표현 또는 더 넓은 자료 제공으로 되돌린다.
+
+## 13. 주요 결정과 잔여 한계
+
+| 결정 | 근거와 효과 | 잔여 조건 |
+|---|---|---|
+| 모든 cluster wave 완료 후, S2_10 최종 완료 전 통합 | 늦게 오는 자료에 따른 반복 병합과 후속 서면 단계의 재집계 부담을 줄인다. | phase gate와 재호출 상태의 실제 backend 결속 필요 |
+| cluster 불변, 후보·자료→청구 기록의 다대다 대응 | 복수 권리·공유 증거·빈 후보 자료를 보존한다. | 범위 분리와 후보 coverage Schema 필요 |
+| 당사자 조합은 탐색 범위, 동일성은 8개 기준으로 판단 | 독립 거래·권리 경합·조합 밖의 관계를 구별한다. | source 기반 anchor가 부족하면 미해결 유지 |
+| 통합과 변경 요건 검토를 한 LLM task로 수행 | 같은 자료 재전송과 동일성 설명의 반복을 줄인다. | 큰 관련 묶음은 예산 내 분할/조정 또는 미완료 처리 |
+| 기존 평가 재사용 + 명시적 sparse delta | 모든 후보를 다시 추론·출력하는 비용을 줄인다. | 새로운 범위·반대 자료가 있으면 자동 계승 금지 |
+| 잔여 자료·빈 후보·EXCLUDED도 coverage에 포함 | 첫 단계 후보만 모아 생기는 누락을 방지한다. | 미배정 자료의 관련성 공백은 최종 기록에 유지 |
+| 고정 snapshot의 제한된 보강만 허용 | 무한 tool loop 없이 실제 자료 부족을 보완한다. | 추가 호출·입력 변경을 구조 보정과 따로 계산 |
+
+v.2의 ‘여러 cluster 공동 판단을 기본안에서 제외’, ‘추가 LLM 판단 없이 cluster 수만큼 호출’이라는 경계는 **통합 phase에 대해서 개정**한다. 기존 cluster phase의 한 cluster당 한 task는 유지하고, 이후 관련 후보·자료를 공동 검토하는 필요한 통합 task만 추가한다. v.2의 전량 재요약·불필요한 요약 LLM 제외 원칙은 유지한다.
+
+이번 작업에서는 v.2·현행 S2_10·가이드·노트북 인자를 대조하여 위 전략을 작성했다. 입력 compiler·통합 prepare·LLM task·reducer·status·새 handoff는 구현하지 않았고, 실제 token·reasoning·속도·법률판단 품질은 미검증이다. S2_00의 원본 연결 그래프와 후속 서면 작성·계산·법률 승인 책임은 그대로 두며, 실제 구현은 지정 가이드·노트북에 맞춰 수행한다. requirements는 줄바꿈 문자열로 전달하고 별도 pip task·cluster별 Code Executor 복원 task·비밀정보의 사건 prompt 삽입을 추가하지 않는다.
+
+**작성·확인 내역:** v.3 전략서를 작성했고 13개 상위 절·8개 통합 기준·로컬 링크 6개·UTF-8/fence·입력/출력/상태의 내부 정합성과 v.2·현행 YAML·가이드의 원본 hash를 정적으로 확인했다. 작업 요약은 지정 MEMORY의 `How to Write MEMORY.md` 바로 아래에 삽입하며, 기존 MEMORY 본문은 보존한다. 전략의 저장·정적 확인과 향후 구현·live 검증·법률 승인을 구별한다.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/agent_scripts/S2_10_revision_strategy_v.4-1.md

@@ -0,0 +1,247 @@
+# S2_10 작업명세서 개정 전략 v.4-1
+
+작성일: 2026-10-04  
+대상: 같은 폴더의 `Stage_2_S2_10.yml`  
+개정 근거: [v.4 평가서](S2_10_revision_strategy_eval_v.4.md)의 R1–R8  
+개정 원본: [v.4 전략서](S2_10_revision_strategy_v.4.md) — 원본 보존  
+상태: 단순한 해법 우선의 구현 전략. YAML/Python 구현·workspace 실행·법률 품질·실제 토큰 검증 전.
+
+## 1. 채택할 구조와 개정 범위
+
+S2_10은 **코드로 원본 검증·잠정 묶음 준비 → 묶음별 본 LLM 추론 → 코드로 결과 검증·청구 기록 조립**의 세 task를 기본 경로로 삼는다. 본 추론에서 청구권의 동일성·분리·경합과 법률관계·요건·항변/재항변·구제수단을 함께 판단한다. 선행 cluster 상세 법률평가, 선행 자료 연결 LLM, 상시 전역 재통합 LLM은 기본 구현에 두지 않는다.
+
+잠정 묶음은 **함께 읽을 자료의 범위**다. 같은 청구권이라는 확정 결론이 아니며, 한 묶음에서 여러 독립·경합 권리가 나올 수 있다. 원본 cluster와 자료는 불변이고, 한 cluster의 복수 묶음 참여·미배정 자료 보존·분할·재연결은 필수다. 이를 참조 목록과 작은 변경 기록으로 구현한다.
+
+v.4의 의미 판단과 자료 보존 요구는 유지하면서 선행 보조 LLM, 실행 중 동적 재계획, 일반화된 ATTACH/DETACH/SPLIT/RELINK API, assessment delta·supersedes 출력 계약, 필수 인용 별칭·별도 wire Schema, 새 pending 상태는 최초 구현에서 제외한다. 실측 효과가 필요한 장치는 §10의 조건에 따라 나중에 개별 도입한다.
+
+이번 작업의 산출물은 평가서·이 전략서·지정 MEMORY 요약이다. [현행 YAML](Stage_2_S2_10.yml), v.2/v.3/v.4, S2_00, backend와 사건 자료는 변경하지 않는다. 아래 task·필드·파일은 향후 개정 제안이며 실제 지원이나 실행 완료를 뜻하지 않는다. 법률 작업의 적합성은 사용자 맥락을 설계 전제로 삼고 새로운 법률 조사·판례 결론을 추가하지 않는다.
+
+## 2. 평가서와 변경의 대응
+
+| 근거 | v.4-1의 결정 |
+|---|---|
+| R1 — 본 추론 순서 | 잠정 묶음 뒤 한 번의 본 평가를 유지하고 8개 동일성 기준을 적용한다. |
+| R2 — 선행 보조 LLM | 최초 구현에서 제거한다. 모호한 자료는 단독·잔여 묶음 또는 본 추론의 확인 대상으로 남긴다. |
+| R3 — 가역성 | 원본 refs·다대다 membership·회차별 고정 계획·변경 전후 범위로 표현한다. 실행 중인 계획은 바꾸지 않는다. |
+| R4 — 보정 결과 | 최초와 재검토에 동일한 출력 Schema를 사용한다. 영향 범위의 완전 대체 평가를 저장한다. |
+| R5 — 전달·표현 | 원본 refs와 호출 내부 본문 사전을 기본으로 한다. 계획·검증 정보를 한 코드용 파일에 모으고 한 전달 경로부터 검증한다. |
+| R6 — 상태 | 현행 상태 집합을 재사용하고 묶음·재검토의 남은 범위는 pending 목록과 사유로 표시한다. |
+| R7 — 추가 추론 | 최초 평가 뒤 실제 미해결 질문에 대해서만 영향 범위당 재검토 1회를 허용한다. 구조 보정은 같은 입력에서 최대 1회다. |
+| R8 — 도입·검증 | 대표 사례와 실제 전체 비용을 먼저 확인하고 고급 최적화는 효과가 확인된 경우에 도입한다. |
+
+```text
+S2_00 원본 snapshot
+  → prepare(code): 검증·잠정 묶음·미배정·이번 입력 준비
+  → assess(LLM map): 동일성/분리/경합 + 요건/항변/구제
+  → publish(code reducer): 검증·결과 보존·청구 기록 조립
+       남은 최초 묶음 → 다음 배치
+       실제 미해결 질문 → 영향 범위 재검토 최대 1회
+       끝난 범위·잔여 한계 → status-last 발행
+```
+
+## 3. 원본 참조로 잠정 묶음 만들기
+
+### 3.1 사용할 입력과 묶음 규칙
+
+현행 prepare가 소비하는 `context/case_context.json`의 cluster/member/signal/relationship/dependency, client goal, active profiles 및 base review 원장을 검증하여 사용한다. 당사자·구체적 거래·발생 사건·목적물의 **실제 원본 참조**를 사용하며, 실제 존재하는 `member_ref`, `source_ref`, `stage1_id`, `field_refs`, 원본 projection과 명시적 연결을 이용한다. 제공되지 않은 party registry·거래 ID·법적 지위를 새로 확보했다고 가정하지 않는다.
+
+1. **원본 inventory를 한 번 만든다.** cluster·member·signal·review와 인용 가능한 필드 refs, 원본 값·검증 제한을 코드에서 인덱싱한다. 임의로 자유 서술을 세분하거나 요약하는 단계를 추가하지 않는다.
+2. **같은 구체적 거래·발생 사건의 명시적 refs를 우선한다.** 그 연결에 참여하는 당사자·목적물 자료와 원본에서 관련성이 명시된 보완·반대 자료를 함께 읽을 범위로 모은다. 이 범위는 법률상 동일 청구권을 뜻하지 않는다.
+3. **당사자·목적물 refs는 관련성 확인에 사용한다.** 같은 이름·같은 당사자 조합·같은 부동산·같은 profile만으로 모든 자료를 합치지 않는다. 대리·대표·승계·보증 등 법적 지위는 본 추론에서 확인한다.
+4. **한 cluster의 여러 원본 anchor를 허용한다.** 각각의 member/signal/review refs를 필요한 묶음에 배정하여 cluster의 복수 참여를 표현한다. 안전하게 나눌 수 없는 본문은 보존하고 연결 불명을 남긴다.
+5. **연결 부족을 보존한다.** 명시적 anchor가 없으면 원본 cluster의 자료를 단독 검토 범위로 유지하거나 잔여 묶음에 넣는다. 부족한 ID를 채우기 위해 선행 상세 법률평가를 하지 않는다.
+
+서로 관련된 자료가 같은 사건·거래 refs를 공유하고 한 호출의 예산에 들어가면 처음부터 하나의 읽기 범위로 구성한다. 별도의 하위 묶음·owner·공동 packet 계층을 필수로 만들지 않는다. 공통 자료라는 이유만으로 관련 없는 거래를 무리하게 함께 넣지 않는다.
+
+S2_00 wave/SCC와 `candidate_dependencies`는 원본 관계·의존 가능성의 정보로 보존한다. 옛 cluster verdict를 기다리는 순서를 새 묶음에 강제하지 않는다. 필요한 연결 자료를 함께 제공하거나 확인 질문으로 남기고, 코드가 법률상 선결 관계를 확정하지 않는다.
+
+### 3.2 최소 자료구조와 미배정 보존
+
+코드용 계획은 다음 목록을 갖는다.
+
+```text
+source_inventory: 원본 occurrence refs와 검증 상태·제한
+bundles: bundle_ref, anchor_refs, cluster_refs, material_refs, 배정 이유·근거
+unassigned: 원본 refs, 가능한 연결, 미배정 사유
+restricted: 원본 refs, schema/원문/이용 제한
+changes: 변경 전후 bundle/material refs, 이유·근거, 영향받은 평가 범위
+active_results: 최종 조립에 사용할 검증 결과 refs
+```
+
+membership은 `bundle_ref → material_refs` 목록이다. 같은 material ref가 여러 목록에 있어도 허용하며, 해당 cluster의 참여는 원본 대응으로 설명한다. 별도 권리 ID나 동일성 점수를 선행 생성하지 않는다.
+
+원본 occurrence마다 묶음 배정·미배정·이용 제한 중 하나 이상의 행선지가 있어야 한다. 미배정 목록의 존재는 법률 검토 완료를 뜻하지 않는다. 이용 가능한 잔여 자료는 실제 본문을 담은 독립 검토 입력으로 평가할 수 있어야 한다. 예산·자료 공백 때문에 평가하지 못하면 잔여 범위와 사유를 남긴다. count나 파일 경로만 전달한 자료를 읽었다고 표시하지 않는다.
+
+## 4. 가역성은 고정 회차와 참조 목록으로 구현한다
+
+최초 본 추론 회차에서는 묶음 membership을 고정한다. 여러 배치로 나누더라도 실행 중인 입력·계획은 수정하지 않는다. 본 추론이 제안한 연결 추가·제외·분할·재연결은 reducer가 실제 refs와 coverage를 확인한 뒤 다음 재검토 범위에 반영한다.
+
+수정은 파생 목록의 변경 전후 bundle/material refs와 사유·근거를 기록하는 것으로 충분하다. 원본을 지우거나 cluster를 재작성하지 않는다. 제외한 membership의 자료는 다른 묶음·미배정·이용 제한 목록 중 행선지를 갖는다. 분할 시 공통 자료의 복수 참여를 허용하고, 재연결 시 관련 자료를 함께 읽을 범위와 법률적 동일성 판단을 구별한다.
+
+한 본 추론에서 이미 제공된 자료로 여러 권리를 식별한 경우, 청구 기록을 나누는 것만으로 재호출하지 않는다. 필요 자료가 빠졌거나 서로 다른 결과 사이의 동일성·모순이 실제로 남은 경우에만 재검토한다. 최초 묶음의 단순 제목 변경도 재추론 사유로 삼지 않는다.
+
+이미 평가한 범위가 바뀌면 해당 결과를 최종 조립의 자동 재사용 대상에서 제외한다. 이전 batch는 보존하고, 필요한 원본과 관련 이전 평가를 실제 입력에 담아 영향 범위의 완전 대체 결과를 만든다. 코드의 `active_results`가 이전·새 결과의 조립 범위를 관리한다. 교체하지 못한 범위는 유효한 새 평가가 있는 것으로 취급하지 않고 미해결 또는 기술 미완료로 남긴다.
+
+이 구조는 실행 중 동적 계획 변경, 부모 digest 체인, 모델의 supersedes 선언이나 delta 적용기를 요구하지 않는다. 각 batch의 원본 snapshot·입력 범위·hash·결과 대응은 유지하여 오래된 slot이나 영향받은 결과를 잘못 재사용하지 않게 한다.
+
+## 5. 묶음별 본 LLM 추론과 단일 결과 계약
+
+### 5.1 법률 판단의 범위
+
+모델은 원본 관측과 추론을 구분하여 실제 권리자·의무자·법적 지위·승계·standing, 법률관계·청구권·구제수단을 검토한다. 잠정 묶음의 제목이나 예상 청구 유형이 다른 권리의 탐색을 막지 않게 한다. 짧은 profile catalog와 필요한 실제 질문 구조를 제공하고, 추가 영역의 자료·authority가 필요하면 공백으로 남긴다.
+
+| 청구권 동일성 기준 | 본 추론에서 유지할 판단 |
+|---|---|
+| 1. 권리자·의무자와 법적 지위 | 실제 권리 귀속·책임 주체·대표/대리·승계를 구별한다. |
+| 2. 구체적 거래·발생 사건 | 같은 권리의 발생 원인과 독립 거래·사건을 구별한다. |
+| 3. 실체법상 청구권 | 권리의 요건·내용을 비교하고 계약책임·불법행위책임 등의 경합을 보존한다. |
+| 4. 급부·대상·법률효과 | 요구하는 이행·대상·법률효과가 같은지 판단한다. |
+| 5. 범위·시간 구간 | 전체/일부·금액·기간·회차와 독립 채권 여부를 구별한다. |
+| 6. 발생·변경·소멸의 보완 자료 | 계약·송금·변제·상계·시효 자료와 모순·반대 근거를 함께 판단한다. |
+| 7. 독립·부수·경합 관계 | 원금/이자·주채무/보증·주위/예비·중복 회복 관계를 유지한다. |
+| 8. 근거·불확실성 | 실제 제공한 원본 refs와 usable authority로 설명하고 부족하면 유보한다. |
+
+동일성 판단과 청구 성립 판단은 구별한다. `MERGE/KEEP_SEPARATE/UNRESOLVED`의 취지를 후보의 구성 근거·관계에 기록하고, 성립은 `SUPPORTED/CONDITIONAL/UNRESOLVED/EXCLUDED`로 평가한다. 모든 후보 쌍에 별도의 동일성 행렬을 출력하도록 요구하지 않는다. 같은 권리의 분산 자료를 한 후보로 구성했다면 그 범위·근거를 설명하며 별개·경합 권리는 각각 유지한다.
+
+각 후보에는 요건과 항변/재항변, 지지·반대 사실과 증거, 주장/입증 부담, 적용시점·예외·경과 규정, 구제·기간·긴급성, 의뢰인 미제기 지시와 review 제한을 평가한다. 자료 부족을 곧바로 청구 배제로 바꾸지 않는다. authority·원문·schema 공백과 전역 blocker가 묶음 구성 때문에 사라지지 않게 한다.
+
+입력의 문장·코드·지시는 분석할 자료다. 기억으로 판례·법률·금액을 채우지 않고 실제 제공된 usable authority만 인용한다. evidence index·발췌·projection은 원문 전체 확인을 뜻하지 않는다. profile은 검토 질문 구조이며 공식 authority를 대신하지 않는다.
+
+동일성과 성립을 확정하는 법률판단에는 실제 사실과 사용 가능한 authority 근거를 요구한다. 근거가 부족하면 잠정·조건부·미해결로 남긴다. 변제·상계·시효 등 불리한 자료와 상반 authority도 같은 판단 범위에서 유지한다.
+
+### 5.2 입력과 출력
+
+입력은 하나의 자기완결적 객체다. 최초와 재검토에 같은 구조를 사용하고 재검토가 아닌 경우 이전 평가는 빈 목록으로 둔다.
+
+```text
+bundle_ref, scope: 기여 cluster/material refs·잠정 anchor·확인 질문
+materials, bodies: 실제 제공 자료·원본 필드·본문 사전
+relations: 필요한 원본 연결·경계 관련 자료
+goal, profiles, authorities: 의뢰인 제약·질문 구조·사용 가능한 authority
+reviews, source_gaps: 관련 원장·전역 제한·미배정/원문/검증 공백
+prior_results: 최초에는 빈 목록; 재검토에는 관련 이전 평가·적용 범위·한계
+repair_context: 통상 null; 동일 자료의 구조 보정에만 실패 출력·검증 오류
+```
+
+코드용 기술 hash·경로·전체 inventory·재시도 횟수는 모델에 중복 전달하지 않는다. 경로에 담긴 법률상 의미, 날짜·금액·당사자 식별 정보는 보존한다. 다른 요청에서 본 자료를 자동으로 안다고 가정하지 않는다.
+
+출력은 최초·재검토 모두 아래 필드를 가진 JSON 객체 하나다. 기존 평가 필드의 내용은 활용하되 root의 bundle 범위와 참조 검증은 새 계약에 맞게 정의한다.
+
+```text
+bundle_ref
+domain_resolutions
+claim_option_candidates
+candidate_relations
+review_patches
+materials_reviewed
+followup_requests
+missing_inputs
+assumptions
+```
+
+`claim_option_candidates`는 후보 local ref, 권리자·의무자·법적 지위·발생 원인·급부·대상·범위, 동일성 구성 근거, 요건·항변/재항변·부담·구제·기간·원본/authority refs와 제한을 갖는 **완전 평가**다. 최초와 재검토 모두 같은 필수 항목을 쓴다. 최종 case_type/claim_group/renderer/exhibit ID, 소장 문안·확정 계산·완료 상태·hash echo·usage는 모델 출력에 요구하지 않는다.
+
+`candidate_relations`는 이 응답 안의 후보를 연결한다. 아직 나오지 않은 다른 map 결과의 후보 ID를 발명하지 않는다. 다른 묶음과 연결할 필요는 `followup_requests`에 실제 원본 refs·관련 bundle refs·질문·사유로 남긴다. 필요하면 재검토에 관련 범위를 함께 담아 같은 응답 안에서 권리 관계를 판단한다.
+
+`materials_reviewed`는 실제 제공된 occurrence별 검토 범위·청구 연결·비관련 판단·미해결을 추적한다. 같은 처리는 refs 목록으로 묶을 수 있지만 원본별 대응을 복원할 수 있어야 한다. 후보의 인용에 없다는 이유만으로 자료를 자동 비관련 처리하지 않는다. 구조적 coverage 검사는 모델이 의미를 정확히 읽었다는 보증과 구별한다.
+
+`review_patches`는 실제 평가한 변경 제안만 반환한다. 원문·원장 전체 재출력과 별도의 grouping operation·assessment delta·supersedes 필드는 두지 않는다. 대체 평가의 적용 범위와 과거 결과 보존은 코드가 관리한다.
+
+## 6. 공유 자료와 전달 경로의 최소화
+
+prepare에서 자료·관계·review 인덱스를 한 번 만들고 필요한 필드만 선택한다. 같은 요청에 들어가는 **완전히 같은 본문**은 `bodies` 사전에 한 번 담되 서로 다른 occurrence의 원본 ref·자료 종류·blocking 상태는 유지한다. 유사 문장을 하나로 축약하지 않는다. 모델이 사전과 참조를 함께 볼 수 있게 하며 인용 ref 자체를 짧은 별칭으로 치환하지 않는다.
+
+명시적으로 관련된 자료는 §3에 따라 가능한 한 한 읽기 범위에 모아 공유 본문 반복을 줄인다. 서로 다른 묶음에서 필요한 자료는 재전달하고 그 비용을 계산한다. 다른 요청의 사전·shared_context·cache가 자료를 무료로 공유한다고 가정하지 않는다. 공통 자료의 중요성이 불명확하면 유지하거나 보강 필요를 명시한다.
+
+변제·상계·시효·반대 사실·blocking review를 토큰 절감 때문에 누락하지 않는다. 전역 blocker는 원장에 보존하고 영향 범위에 제한과 필요한 근거를 전달한다. 범위가 불명확하면 잠재 영향 판단을 유보하며 미전달·미평가 review를 코드가 자동 해결하지 않는다.
+
+**작은 map descriptor + 최대 8개 자기완결적 slot**을 우선 검증할 전달 경로로 삼는다. 계획·검증 데이터 전체를 모델 prompt에 넣지 않는다. [YAML 가이드](../../../SKILL.md)의 preflight/map/result 계약과 실제 backend의 slot 전달·화이트리스트·응답 크기·중복 삽입을 구현 때 확인한다. 이 경로가 검증되지 않으면 기술 미완료로 보고하고 여러 전달기를 동시에 구현하지 않는다.
+
+최초에는 원본 refs와 단일 논리/출력 Schema를 사용한다. 별도 wire/정본 Schema·인용 별칭 복원·별도 bundle control/index 파일·packet별 복원 task를 필수로 만들지 않는다. 문서화된 map 결과 envelope와 base64 팽창·item 반송까지 실제 admission에 포함한다. 별도 pip task·임의 Python hook·모델의 파일 검색/저장 기능은 추가하지 않는다. 현행 모델 설정을 우선 유지하되 provider의 실제 적용은 구현 검증 대상으로 둔다.
+
+## 7. 제한된 재검토와 큰 입력
+
+최초 묶음을 처리한 뒤, 다른 묶음의 동일 권리 가능성·상충 판단·새 반대 자료·잘못된 배정·필요 자료 누락이 실제로 남으면 관련 질문과 영향 범위를 모은다. 같은 문제를 여러 묶음의 독립 요청으로 반복하지 않고 가능한 범위를 함께 검토한다. 일반적인 전역 통합 LLM은 호출하지 않는다.
+
+영향 범위당 **법률 재검토는 최대 1회**다. 같은 pinned snapshot에서 필요한 원본·관련 이전 평가·사실 전제·한계를 실제로 제공하고, 영향 범위의 완전 대체 평가를 받는다. 실패 출력의 **구조·참조 보정은 동일 입력에서 최대 1회** 허용한다. 변경된 자료를 기존 출력 repair로 처리하지 않는다. 추가 질문이 남으면 미해결로 기록하고 자동 반복하지 않는다.
+
+큰 묶음은 먼저 정확한 본문 중복을 제거하고 필요한 범위로 제한한다. 그래도 입력·출력 예약·실제 추론 예산·동시 처리·I/O envelope의 한도를 넘으면 원본 거래/사건 연결에 따라 잠정 분할하고 공통 자료·경계 질문을 유지한다. ‘8개 cluster마다 확정 청구’처럼 처리량을 법률적 독립성으로 바꾸지 않는다.
+
+경계 범위를 함께 읽지 못했으면 권리 동일성·모순의 완전한 해결을 선언하지 않는다. A–B와 B–C의 연결만으로 A–C의 반대 근거를 무시하여 청구를 전이 병합하지 않는다. 예산 안에 필요한 자료를 담을 수 없는 범위는 기술 실패 또는 명시적 미해결로 남기고, 내용을 잘라 성공 처리하지 않는다.
+
+## 8. task·파일·상태와 발행
+
+### 8.1 세 task와 배치
+
+| 제안 task | 책임 |
+|---|---|
+| `Task_S2_10_prepare_provisional_bundles` | code. upstream 검증·원본 인덱스·잠정 목록·입력 예산·이번 slot 준비. |
+| `Task_S2_10_assess_bundle` | LLM map. 한 묶음의 완전 평가와 실제 미해결 질문 반환. |
+| `Task_S2_10_validate_publish_bundles` | code reducer. 구조·참조·coverage 검사, 불변 batch 저장, 활성 결과·청구 기록·status 조립. |
+
+prepare Stage → 본 추론 MapReduce Stage를 사용하고 자동 Stage loop를 가정하지 않는다. 한 Agent 호출의 packet 수≤8과 map 동시성≤8을 각각 유지하며 개별 입력 예산을 먼저 검사한다. caller는 남은 최초 묶음 또는 제한된 재검토 목록에 따라 같은 Agent를 한 writer로 순차 재호출한다. 성공 batch는 원본·범위·입력 binding이 같고 영향받지 않았을 때 재사용한다.
+
+진정한 빈 입력이나 같은 완료 snapshot의 재호출은 code 처리로 모델 호출 0을 목표로 한다. 모델 작업이 0개일 때의 reducer 실행·Stage 실패 전파·receipt 결속은 backend 검증 대상이다. 원본 자료가 있는데 빈 묶음 배열을 성공으로 바꾸지 않는다. 입력이 변했거나 pending·잔여 제한이 남았으면 그 상태를 그대로 표시한다.
+
+### 8.2 필요한 파일만 둔다
+
+| 제안 파일 | 내용 |
+|---|---|
+| `work/bundle_plan.json` | 원본 inventory·membership·미배정/제한·변경 기록·현재 descriptor·코드용 허용 refs/hash·재검토/repair 횟수·활성 결과 목록. 모델에 통째로 전달하지 않는다. |
+| 최대 8개 `work/llm_input/slot-*.json` | 해당 요청에 필요한 자기완결적 입력. 이전 배치가 끝나고 binding을 확인한 뒤 다음 배치로 교체한다. |
+| `assessments/batch-NNNN.json` | 원본 snapshot·입력 범위/hash·검증 결과·실패 정보. 저장된 평가 내용은 불변으로 보존한다. |
+| `claims/claim_records.json` | 활성 결과로 조립한 청구 draft·관계·원본 refs·review·잔여 범위·한계. |
+| `s2_10_status.json` | 처리·실패·pending·미해결 coverage와 결과 hash를 묶는 마지막 marker. |
+
+새 출력 root를 사용하여 현행 결과를 덮어쓰지 않는다. 별도 request/attempt ID는 추가하지 않는다. 원본 snapshot·알고리즘/prompt/Schema 버전과 입력 hash로 결과를 결속한다. 계획 변경 기록과 batch의 입력 scope로 과거 배정·평가 범위를 추적할 수 있게 한다. 원격 잠금·CAS·범용 실행 복구 시스템을 추가했다고 표현하지 않는다.
+
+### 8.3 기존 상태 집합을 재사용한다
+
+| 상태 | 새 작업에서의 의미 |
+|---|---|
+| `NEXT_WAVE_PENDING` | 최초 묶음 또는 허용된 재검토가 남았다. pending refs와 사유를 별도 필드로 기록한다. |
+| `TECHNICAL_INCOMPLETE` | 읽기/쓰기·입력 크기·Schema·참조·binding·응답 누락 등에 실패했다. |
+| `COMPLETED_WITH_ISSUES` | 정의된 처리와 최종 조립은 기술적으로 끝났지만 법률·동일성·자료·review 공백이 남았다. |
+| `COMPLETED` | 정의된 처리·자료 coverage·발행 검증이 끝났고 기록된 미해결 사항이 없다. 검토 가능한 draft다. |
+
+상태 이름 재사용은 기존 validation·S2_20 handoff의 자동 호환을 뜻하지 않는다. 실제 소비 필드와 새 bundle scope를 확인해야 한다. 남아 있는 모델 작업은 pending이고, 더 진행하지 못하는 자료 공백·법률 질문은 issues로 표현하여 사건 전체 청구 탐색의 완전성과 구별한다.
+
+최종 파일을 저장한 뒤 read-back·hash·coverage를 확인하고 status를 마지막에 발행한다. 모델은 완료 상태를 결정하지 않는다. 원본 원장의 review를 수정하지 않고 검증된 변경 제안과 미해결을 최종 기록에 반영한다.
+
+## 9. 처음 구현할 때의 검증과 순서
+
+| 대표 사례 | 확인할 핵심 |
+|---|---|
+| 같은 대여의 계약·송금·변제·시효 자료가 분산 | 선행 상세 평가 없이 본 추론에서 종합하고 반대 자료·항변을 유지한다. |
+| 같은 당사자의 별개 거래·같은 목적물의 다른 권리 | 잠정 묶음과 동일 청구권을 구별한다. |
+| 계약/불법행위·원금/이자·주채무/보증 | 독립·경합·부수 관계와 회복 범위를 보존한다. |
+| 한 cluster의 복수 참여·미배정 반대 자료·승계/당사자 불명 | 원본 전체 행선지·단독/잔여 검토·유보와 복수 membership을 확인한다. |
+| 분할·재연결 후 기존 평가의 근거 범위 변경 | 변경 전후 refs·이전 결과 보존·자동 재사용 차단·완전 대체 결과의 적용 범위를 확인한다. |
+| global blocker·authority/원문/schema 공백 | 배정·본문 선택 때문에 제한이 사라지지 않는다. |
+| 0·1·8·9 묶음, 큰 입력, stale slot, 결과 누락·잘못된 refs | 배치·예산·구조 repair 한도·기술 실패·read-back/status-last를 확인한다. |
+| 같은 자료의 반복 전달·같은 완료 snapshot 재호출 | 요청별 전체 비용을 합산하고 동일 완료본 재호출의 모델 호출 0을 확인한다. |
+
+코드 검증은 원본/hash/Schema, 전체 occurrence 행선지, 입력에 실제 포함된 refs, 후보·관계 endpoint, review 제한, 변경 전후 scope, 활성 결과의 coverage를 대상으로 한다. 문자열·Schema 검사는 법률적 판단의 정답을 보증하지 않는다. 후보 인용과 자료 검토를 구별하고 동일 권리의 조립은 명시적 판단에 근거해야 한다.
+
+구현 순서는 다음 네 단계로 제한한다.
+
+1. **입력·계약 고정:** 현행 원본과 새 root를 pin하고 bundle refs·단일 입력/출력 Schema·현행 상태 의미를 정한다. `cluster_ref` 중심 validation을 bundle의 복수 원본 범위에 맞게 바꾼다.
+2. **기본 세 task:** 비 LLM 묶음 prepare, slot 전달, 본 prompt, 참조·coverage reducer를 연결한다. 대표 사례의 자료 누락과 잘못된 권리 병합/분리를 확인한다.
+3. **제한된 예외:** 잔여 검토·분할/재연결 변경 기록·재검토 1회·구조 repair 1회·활성 결과 조립을 연결한다. 실제 영향 범위만 처리한다.
+4. **실제 비용·품질 확인:** 같은 사건·authority·모델 설정에서 최초·재검토·repair 전체 입력/출력·확인 가능한 reasoning·지연과 법률 누락을 비교한다. 기본 경로가 통과한 뒤 추가 최적화를 선택한다.
+
+현행 결과의 usage 기록은 실제 reasoning 측정 경로를 보장하지 않는다. provider/backend의 확인된 usage가 없으면 reasoning은 미측정으로 둔다. byte·파일 수·cache 할인·MCP I/O 감소를 실제 모델 토큰 감소로 보고하지 않는다. 토큰 비교에는 공유 본문의 요청 간 반복도 포함한다.
+
+## 10. 후속 도입 조건과 완료 경계
+
+| 후속 장치 | 도입을 검토할 조건 |
+|---|---|
+| 인용 별칭·별도 wire/정본 Schema | 원본 refs가 실제 비용의 주된 부분이고 역복원·오인용 검사 후 전체 비용이 줄어든다. |
+| assessment delta·supersedes | 제한된 완전 대체 결과의 재출력/재추론 비용이 크고 계승·충돌 검증까지 포함해 이점이 확인된다. |
+| 여러 묶음의 공동 처리 | 관련 자료의 요청 간 반복이 크며 개별 입력·정확도·구제 구별을 유지할 수 있다. 최초에는 별도 하위 계층을 만들지 않는다. |
+| 선행 연결 보조 LLM | 단독/잔여 묶음 처리보다 작은 연결 확인이 총 비용과 오류를 줄인다는 사례가 확인된다. 모든 cluster 상세 법률평가는 허용하지 않는다. |
+| 세밀한 revision·자동 재계획·추가 상태 | 고정 회차·참조 변경 기록으로 실제 운영 문제를 해결할 수 없다는 근거가 생긴다. |
+
+이 장치들은 최초 구현의 완료 조건이 아니다. 현재의 복잡도를 미래의 모든 경우에 맞춰 미리 확장하지 않고, 확인된 문제에 필요한 장치만 추가한다. 완전 대체 평가가 delta보다 출력이 길거나 원본 anchor가 부족해 단독 묶음이 많아질 수 있으므로 v.4-1의 실제 토큰·정확도 우월성은 측정 전 확정하지 않는다.
+
+이번 작업은 평가서와 v.4-1 전략서 작성 및 지정 MEMORY 기록까지다. 두 문서의 구조·로컬 링크 7개·R1–R8 대응·8개 동일성 기준·가역성·법률 내용·입출력/보정 계약과 원본 보존을 포함한 정적 확인 36개 항목을 통과했다. YAML/Python 구현, provider/backend workspace 실행, 실제 토큰·속도·법률 품질, S2_20 소비 호환 검증은 미실시다.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/agent_scripts/S2_10_revision_strategy_v.4.md

@@ -0,0 +1,346 @@
+# S2_10 작업명세서 개정 전략 v.4
+
+작성일: 2026-10-04  
+대상: 같은 폴더의 `Stage_2_S2_10.yml`  
+개정 원본: `S2_10_revision_strategy_v.3.md` — 원본 보존  
+상태: **가역적 잠정 묶음 선행 전략 — YAML/Python 구현·workspace 실행·법률 품질·실제 토큰 검증 전**
+
+## 1. 목표와 핵심 변경
+
+S2_10을 **원본 cluster·자료의 검증 → 원본 참조에 따른 관련 자료의 잠정 묶음 준비 → 묶음별 본 LLM 추론 → 결과 검증·필요한 경계 보정·청구 기록 조립**으로 재작성한다. 본 추론에서 청구권의 동일성·분리·경합, 법률관계·요건·항변/재항변·구제수단을 함께 판단한다. v.3의 ‘모든 cluster에 대한 상세 법률평가 후 다시 청구권 통합 평가’라는 두 번의 본 추론 구조는 채택하지 않는다.
+
+선행 묶음은 같은 권리가 있다는 결론이 아니라 **함께 읽을 관련 자료의 범위에 관한 잠정 가설**이다. 한 묶음에서 여러 청구권이 발견될 수 있고, 서로 다른 묶음에서 발견된 후보가 같은 권리일 수도 있다. 원본 cluster를 삭제·재작성하지 않고, 한 cluster의 복수 묶음 참여, 미배정 자료의 보존, 묶음의 분할·재연결을 허용한다. ‘한 cluster→한 묶음→한 청구권’이라는 일대일 대응을 강제하지 않는다.
+
+선행 묶음은 원본에 명시된 당사자·구체적 거래·발생 사건·목적물 refs를 이용한 **비 LLM 인덱싱을 기본값**으로 한다. 부족한 연결을 확인하려고 모든 cluster의 요건·항변·구제수단을 미리 추론하지 않는다. 공유 자료는 호출 안에서 실제 본문을 한 번씩만 전달하고, 호출 사이의 반복은 관련 묶음의 공동 처리·필요 범위 선택·검증된 결과 재사용으로 억제한다. 토큰 절감은 설계 목표이며 현재 측정 결과가 아니다.
+
+## 2. 근거와 이번 작업의 범위
+
+| 근거 | 이 전략에서의 용도 |
+|---|---|
+| 사용자 제공 맥락·3개 기준·제약조건 | 잠정 묶음 선행, 원본 refs를 이용한 저비용 구성, 본 추론의 통합 수행, 가역성·복수 참여·미배정 보존·반복 억제가 채택 조건이다. |
+| [v.3 전략서](S2_10_revision_strategy_v.3.md) | 8개 청구권 동일성 기준, 다대다 자료 대응, 원장·근거·미해결 보존, 토큰·완료 상태의 구분을 계승한다. 본 추론의 순서는 변경한다. |
+| [v.2 전략서](S2_10_revision_strategy_v.2.md) | compact packet·본문 사전·인용 별칭·Schema 공통화·control 분리·최대 8개 admission의 표현·실행 최적화를 계승한다. |
+| [현행 S2_10 YAML](Stage_2_S2_10.yml) | upstream 검증·자료 선택·cluster map prompt·결과 Schema·validation·발행 계약을 직접 확인했다. 현행 구현과 새 제안을 구분한다. |
+| [YAML 작성 가이드](../../../../../SKILL.md) 및 [Stage 2 사본](../../../SKILL.md) | 두 파일의 동일성을 확인했다. MapReduce, `item_json`, preflight, `map_results_b64` 등 문서화된 계약을 따른다. |
+| [Code Executor 노트북](../../../test_code_executor.ipynb) | 향후 `run_code` 인자·MCP 초기화·stdout 실행 계약의 기준이다. 이번에 실행하지 않는다. |
+| [Stage 2 MEMORY](../../../MEMORY.md) | 이번 문서 개정 내역만 지정 위치에 압축 기록한다. |
+
+분석 기준 SHA-256:
+
+- v.3 전략서: `0c8402b308e2bd7ed10587065fa78f879871654a53b0313df83636047f638744`
+- 현행 S2_10 YAML: `3d8616c2e2a1c3a5f405ba9806718b9ac519843ddc02c80ff4d51a67c42e8c50`
+
+이번 산출물은 **이 v.4 전략서와 지정 MEMORY 요약**이다. v.2/v.3·현행 S2_00/S2_10 YAML·원본 사건·배포 자산·backend·다른 Stage는 수정하지 않는다. 아래 task·Schema·파일·상태는 향후 구현 제안이며 현재 지원·실행 완료를 뜻하지 않는다. 별도 실행계획 파일을 만들지 않고 구현 순서·검증·결정 기록을 이 문서에 포함한다.
+
+대한민국 민사서면에 필요한 청구·쟁점별 자료 구성을 더 효율적으로 만들 수 있다는 사용자 맥락을 설계 전제로 삼는다. 이 순서가 실제 모델에서 정확도와 총 토큰 모두 우월하다는 실증 결론으로 취급하지 않는다. 이번 작업에서 새 법률 조사나 성능 실험은 수행하지 않는다.
+
+## 3. v.3에서 유지·변경할 책임
+
+| 항목 | v.4 결정 |
+|---|---|
+| 모든 cluster의 상세 법률평가 | 선행 작업에서 제거한다. 기존 `Task_S2_10_resolve_cluster`를 그대로 실행한 뒤 새 작업을 덧붙이는 방식으로 구현하지 않는다. |
+| 전체 cluster 법률 결과 완료 후 통합 시작 | 원본 cluster·member·signal·review의 검증 및 배정 상태 확인 후 본 추론을 시작한다. 상세 cluster verdict를 준비 조건으로 요구하지 않는다. |
+| 기존 후보·평가에서 anchor 추출 | S2_00 원본 투영·명시적 ID·필드 refs·관계에서 추출한다. 아직 존재하지 않는 청구 후보를 요구하지 않는다. |
+| 묶음별 법률판단 | 권리 식별·동일성·분리·경합과 요건·항변·구제를 한 본 추론 task에서 수행한다. |
+| 원본 cluster와 원장 | 불변으로 보존하고 잠정 membership과 청구 기록을 별도 파생한다. |
+| 상세 법률 평가 재사용 | 새 본 추론의 검증된 결과에 한정하여 필요한 경계·자료 보강에서 재사용한다. 옛 cluster 결과를 v.4의 필수 선행 입력으로 만들지 않는다. |
+| 동일성·성립 판단, sparse review | 서로 구별하고 원본 근거·반대 자료·부담·미확인 정보를 유지한다. |
+
+```text
+S2_00 불변 결과
+  → 비 LLM prepare: 입력 검증·원본 자료 인덱스·잠정 묶음·미배정 목록
+  → 최대 8개 packet의 묶음별 본 LLM 추론
+      [동일성·분리·경합 + 요건·항변/재항변·구제수단]
+  → 비 LLM reducer: 구조·참조·배정·결과 coverage 검사 및 배치 저장
+  → 남은 packet 또는 필요한 경계/자료 보강만 제한적으로 이어 처리
+  → 청구 기록·관계·잔여 자료·한계를 조립하고 status-last 발행
+```
+
+정상 경로에서 상세 법률평가는 **관련 packet당 한 번**이다. 마지막에 전체 사건을 한 번 더 추론하는 통합 LLM을 상시 배치하지 않는다. 실제로 묶음 경계를 넘는 미해결 문제가 발견됐을 때만 해당 질문·후보·근거를 추가 판단한다.
+
+## 4. 선행 잠정 묶음의 비 LLM 구성
+
+### 4.1 실제 원본에서 얻을 자료
+
+현행 S2_10이 읽는 `context/case_context.json`의 `clusters`, `members`, `signals`, `relationships`, `candidate_dependencies`, `client_goal`, `active_profiles`와 base review 원장을 소비한다. member의 `member_ref`, `source_ref`, `stage1_id`, `field_refs`, `projection` 및 실제 제공된 원본 필드를 참조한다. `client_goal`의 당사자·capacity/target matrix·standing watchpoints 등 기존 투영도 관측 자료로 사용한다.
+
+원본에 없는 전역 party registry·거래 ID·발생 사건 ID·정규화된 법적 지위를 이미 확보했다고 가정하지 않는다. 값이 없으면 `unknown`을 남기고 유사 이름·관계 추정은 잠정 연결로만 표현한다. 권리 귀속·대표·승계와 소송상 지위의 법률판단은 본 추론에서 수행한다.
+
+| anchor | 저비용 구성에 사용할 원본 근거 | 구성상의 한계 |
+|---|---|---|
+| 당사자 | 명시적 party ID·원본 필드 ref·동일인 연결·client goal의 지정 당사자 | 같은 이름·같은 회사라는 서술만으로 동일인·동일 책임 주체를 확정하지 않는다. |
+| 구체적 거래 | 계약·대여·송금 등의 원본 ID 또는 같은 자료를 가리키는 명시적 ref | 다른 계약 표기는 변경·승계 관계일 수 있다. ID 차이만으로 법률적 독립성을 확정하지 않는다. |
+| 발생 사건 | event·BO·fact 등에 기록된 명시적 연결과 관련 occurrence | 비슷한 문장·가까운 날짜를 동일 발생 사건의 증명으로 쓰지 않는다. |
+| 목적물 | 특정 물건·부동산·등기·금전 거래의 원본 필드와 객체 ID | 같은 목적물에 서로 다른 권리가 존재할 수 있다. |
+| 보완·상대 자료 | 변제·상계·시효·권리 변경·반대 자료를 연결하는 명시적 관계 | 해당 자료가 청구 성립 또는 배제를 뜻한다고 선행 판단하지 않는다. |
+
+원본 schema·hash·공식 authority의 usable 상태·profile canonical digest와 상대 `$ref` 결속은 유지한다. profile은 질문 구조이며 authority가 아니다. domain 일치는 관련성 탐색의 보조 정보이지 자료 전량 방송 또는 권리 병합 근거가 아니다.
+
+사용 가능한 다른 법률영역을 탐색할 수 있도록 짧은 `profile_catalog`를 유지하고, 선택한 영역의 실제 검토 질문을 제공한다. 선행 anchor가 특정 domain에 연결됐다는 이유로 다른 청구 유형의 검토를 금지하지 않는다. 새로운 질문 구조나 authority가 필요한 경우에는 해당 부족을 본 추론에서 표시한다.
+
+### 4.2 탐색 범위와 묶음 준비
+
+당사자 조합은 탐색 범위로 사용하고 거래·발생 사건·목적물의 명시적 연결을 우선하여 함께 읽을 자료를 모은다. 같은 당사자나 같은 목적물만으로 모든 cluster를 하나의 거대 연결 성분으로 확정하지 않는다. 명시적 증거/사건 연결이 있으면 당사자 표시가 달라도 잠정 관련성을 유지하여 승계·보증·공동채무 등의 검토를 가능하게 한다.
+
+자료 단위는 원본 member/signal/review 및 실제 인용 가능한 필드 occurrence다. 묶음에는 기여한 cluster refs와 선택 자료 refs를 별도로 기록한다. 하나의 cluster가 여러 쟁점과 권리를 포함하면 필요한 자료 부분을 여러 묶음에 배정할 수 있다. 자유 서술을 안전하게 나눌 수 없으면 해당 본문을 보존하고 모호성을 표시한다. 이름·숫자·문장의 유사성으로 내용을 임의 삭제하지 않는다.
+
+구성 과정에는 `(원본 ref, 묶음 ref, 배정 이유, 연결 근거 ref, 잠정/명시 상태)`를 기록한다. 이는 의미를 확정한 claim ID가 아니라 내부 검토용 참조다. 명시적 연결, 불확실한 관련 가능성, 자료를 특정할 수 없는 공백을 구별한다. 점수나 정렬값을 사용해도 법률적 신뢰도 또는 동일성 확률로 표현하지 않는다.
+
+### 4.3 미배정·연결 불명 자료
+
+원본 자료 전체에 대해 `assigned`, `unassigned`, `quarantined` 등의 배정 상태와 이유를 남긴다. `unassigned`에는 원본 ref·자료 종류·확인 가능한 anchor·미배정 사유·가능한 연결을 보존한다. quarantine는 schema 실패 등 이용 제한이며 원본 삭제가 아니다. 어느 profile에도 연결되지 않은 signal/review도 같은 정책을 적용한다.
+
+연결 후보가 있는 미배정 자료는 관련 packet의 본 추론에서 포함·배제·재연결을 검토한다. 연결 자체가 불명확하면 실제 원본 투영을 담은 잔여 자료 packet으로 검토할 수 있다. count나 파일 path만 제공하고 그 본문을 검토했다고 표시하지 않는다. 토큰 예산 때문에 아직 판단하지 못한 잔여 자료는 미해결로 남기고 사건 전체의 청구 탐색이 완전하다고 선언하지 않는다.
+
+### 4.4 선행 LLM의 허용 범위
+
+**기본 선행 LLM 호출 수는 0**이다. 명시적 자료만으로 묶음 구성이 부족하고 작은 확인이 실제 비용을 줄이는 경우에 한하여 원본의 entity/ref 또는 연결 후보를 확인하는 제한적 보조 호출을 검토할 수 있다. 입력은 해당 모호 구간에만 한정하고, 출력은 refs·연결 제안·사유·불명확 사항으로 제한한다.
+
+이 보조 호출에서는 청구권의 성립·동일성 확정, 요건·항변·구제수단의 상세 평가, 전체 cluster의 법률 요약을 출력하지 않는다. 대부분의 cluster를 이 호출로 먼저 평가해야 하는 설계라면 v.4의 비용 목표를 위반하므로 채택하지 않는다. 보조 제안은 본 추론의 전제로 고정하지 않고 원본 검증·가역적 membership의 잠정 값으로만 사용한다. 보조 호출 비용도 총 토큰에 포함한다.
+
+## 5. 가역성, 복수 묶음 참여와 분할·재연결
+
+가역성은 ‘다시 실행하면 된다’는 선언이 아니라 **원본 불변 + membership의 파생·수정 이력 + 영향받은 판단의 명시적 갱신**으로 구현한다.
+
+| 제안 operation | 수행과 보존 요구 |
+|---|---|
+| `ATTACH` | 원본 자료를 하나 이상의 잠정 묶음에 추가한다. 연결 근거·이유를 남기고 원본 occurrence를 바꾸지 않는다. |
+| `DETACH` | 특정 membership을 제거하되 원본을 보존한다. 다른 묶음 배정 또는 미배정 목록으로 이동한 행선지를 기록한다. |
+| `SPLIT` | 한 잠정 묶음을 여러 검토 범위로 나눈다. 공통 자료의 복수 참여·경계 연결을 유지하고 자료 coverage를 대조한다. |
+| `RELINK` | 서로 다른 묶음의 관련 자료를 연결하거나 공동 packet으로 이동한다. 관련 자료 묶음의 조정과 법률상 같은 권리라는 결론을 구별한다. |
+
+원본 cluster 자체와 member/source/review ID는 그대로 둔다. 작업 계획은 revision·부모 digest·변경 operation의 작은 이력을 갖고, 각 packet은 사용한 plan revision과 자료 hash에 묶인다. 별도 사건 request/attempt ID를 만들지 않는다. pending packet은 새 계획으로 교체할 수 있지만 실행 중 packet을 덮어쓰지 않는다.
+
+이미 검증된 결과가 새 자료나 재연결의 영향을 받으면 원본 batch 결과를 수정하지 않고 **해당 질문·후보·근거에 대한 보정 결과와 supersedes 관계**를 저장하여 최종 청구 기록을 조립한다. 관련 범위가 바뀐 이전 법률평가를 코드가 자동 승계하지 않는다. 영향받지 않은 성공 packet은 재사용한다. 원래 grouping plan과 membership은 추적할 수 있어야 한다.
+
+본 추론에서 한 packet을 여러 권리로 분리했더라도 필요한 자료를 이미 검토했다면 단순 분할 때문에 다시 LLM을 호출하지 않는다. 반대로 배정 오류로 필요한 자료가 없었으면 영향 구간만 추가 판단한다. 모든 그룹 재편성을 상세 법률평가의 재실행으로 연결하지 않는다.
+
+## 6. 공유 자료의 반복 전달 억제
+
+### 6.1 호출 안의 중복과 호출 사이의 중복
+
+저장용 material catalog에는 원본 ref별 occurrence·상태와 완전히 같은 본문을 구별해 보존한다. LLM packet에는 필요한 본문만 담고 동일 본문은 `bodies` 사전에 한 번씩 저장한다. 서로 다른 evidence/review occurrence의 ref·partition·blocking 상태는 별도로 남긴다. 유사 문장은 본문 공유 대상으로 삼지 않는다.
+
+같은 자료가 여러 잠정 묶음에 중요하고 관련 권리 사이의 관계를 함께 검토할 필요가 있으면, 입력 예산 내에서 **여러 하위 묶음을 하나의 본 추론 packet으로 공동 처리**한다. 본문을 한 번 전달하면서 각각의 권리·당사자·범위를 구별하게 한다. 이는 전송·검토 단위의 공동 처리이며 청구권 확정 병합이 아니다. 관련 없는 큰 묶음들을 고정 prompt 절감만을 위해 한 호출에 넣지 않는다.
+
+서로 다른 모델 요청은 같은 catalog를 자동으로 공유하지 않는다. `shared_context`, 파일 사전, prompt cache가 존재해도 실제 전달 본문은 요청별 입력으로 계산한다. 독립 packet에서 같은 본문이 필요하면 재전달 비용을 인정한다. 자료를 읽지 않은 모델에 ref만 주고 이전 호출의 전체 내용을 안다고 가정하지 않는다.
+
+### 6.2 선택과 결과 재사용의 범위
+
+공통 material은 저장 위치·검토 책임을 한 곳에서 관리할 수 있지만, 책임 묶음 지정만으로 다른 묶음에서 필요한 사실을 생략할 수는 없다. 후속 packet이 기존 검증 평가를 재사용하려면 관련 평가·적용 범위·사실 전제·원본 refs·한계를 실제 입력에 제공한다. 당사자·범위·반대 자료가 바뀌면 적용 판단을 다시 요구한다.
+
+자료 선택은 원본 필드와 명시적 관계에 기반하고 선택/보류 사유를 control에 남긴다. 청구를 부정할 수 있는 변제·상계·시효·반대 자료나 blocking review를 ‘후보에 아직 쓰이지 않았다’는 이유로 제외하지 않는다. 공유 자료 중 법률적으로 필요한 정보의 중요성을 확신할 수 없으면 유지하거나 명시적 보강 대상으로 남긴다.
+
+전역 blocking review는 원본 원장에 보존하고 전역 제한 상태를 모든 영향받는 판단에 반영한다. 본문은 범위 판단이 필요한 packet 또는 관련 본 추론에서 평가하고, 개별 packet에는 필요한 근거·제한을 전달한다. 범위가 미확인인 blocker는 모든 잠재 영향 범위의 확정 판단을 막는다. review 본문을 방송하지 않았다는 이유로 해결·비관련 처리하지 않으며, 평가하지 않은 review를 reducer가 자동 해결하지 않는다.
+
+### 6.3 전달량을 비교할 지표
+
+`공유 본문 반복량 = 각 모델 요청에 실제 들어간 같은 원본 본문의 토큰 합계 − 해당 본문을 한 번씩 보냈을 때의 토큰 합계`로 중복 전달을 측정한다. 여기에는 최초 본 추론뿐 아니라 보조 묶음 확인·경계 보정·자료 보강·구조 repair도 포함한다. 법률 품질을 보존하는 조건에서 불필요한 반복량을 줄이며, 필수 자료 재전달까지 오류로 취급하지 않는다.
+
+## 7. 묶음별 본 LLM 추론의 범위
+
+한 packet에서 다음 작업을 함께 수행한다.
+
+1. 원본 관측·추론·당사자 표시를 구별하고 실제 권리자·의무자·법적 지위·승계·standing의 확인 범위를 검토한다.
+2. 거래·발생 사건·목적물 자료를 종합하여 가능한 법률관계와 청구권을 식별한다. 잠정 묶음의 제목이나 예상 권리가 탐색 범위를 고정하지 않게 한다.
+3. 아래 8개 기준으로 동일 권리의 자료·중복 후보를 구성하고 별개·경합 권리를 분리한다.
+4. 각 권리 후보의 요건·지지/반대 사실·증거·주장/입증 부담, 항변·재항변, 불리한 자료와 누락 정보를 평가한다.
+5. 제공 authority의 적용시점·예외·경과 규정·상반 근거·미확인 범위를 검토하고 이행·확인·형성 등 구제 후보를 판단한다.
+6. 주위/예비·선택·누적·부수·선결·양립 불가·중복 회복 관계와 기간·긴급성 쟁점을 검토한다.
+7. 의뢰인 제약·미제기 지시, review 상태 변경 제안, 자료의 다른 묶음 연결·분할·보강 요구를 기록한다.
+
+| 청구권 동일성 기준 | 본 추론에서 확인할 내용 |
+|---|---|
+| 1. 권리자·의무자와 법적 지위 | 실제 권리 귀속·책임 주체·승계 경로를 확인한다. 이름·대표자 표기만으로 동일성을 확정하지 않는다. |
+| 2. 구체적 거래·발생 사건 | 같은 권리의 발생 원인인지, 독립된 거래·사건인지 구별한다. |
+| 3. 실체법상 청구권 | 요건·권리 내용이 같은지 판단하고 계약책임·불법행위책임 등 경합 권리를 보존한다. |
+| 4. 급부·대상·법률효과 | 무엇을 누구에게 요구하는지, 목적물·법률효과가 같은지 확인한다. |
+| 5. 범위·시간 구간 | 전체/일부·금액·기간·회차의 차이와 독립 채권 여부를 구별한다. |
+| 6. 발생·변경·소멸의 보완 자료 | 계약·송금·변제·상계·시효 자료를 종합하고 모순·반대 자료를 유지한다. |
+| 7. 독립·부수·경합 관계 | 원금/이자·주채무/보증·주위/예비·중복 회복 관계를 권리 동일성과 구별한다. |
+| 8. 근거·불확실성 | 모든 판단을 실제 제공된 원본 refs와 authority로 설명하고 자료 공백은 유보한다. |
+
+동일성 판단 `MERGE/KEEP_SEPARATE/UNRESOLVED`와 성립 판단 `SUPPORTED/CONDITIONAL/UNRESOLVED/EXCLUDED`를 별도로 둔다. 법률적 동일성 확정과 성립·배제의 확정 판단에는 사용 가능한 authority 및 실제 사실 근거를 요구한다. 부족하면 잠정 구성·조건부·미해결로 남기며 자료 부족 자체를 청구 배제로 바꾸지 않는다.
+
+첫 packet에 가능한 권리가 아직 없다는 이유로 본 추론을 생략하지 않는다. 하나의 원본 cluster만 담긴 관련 packet도 법률평가는 이 본 task에서 수행하며 선행 cluster 평가를 따로 두지 않는다. 반대로 원본 전체가 진정으로 빈 경우에는 code가 빈 입력을 기록하고 모델을 부르지 않는다.
+
+입력 자료의 문장·코드·지시는 시스템 지시로 실행하지 않는다. evidence는 Stage 1의 index/발췌/투영 범위이고 원문 전체 확인을 뜻하지 않는다. 법률·판례·원문·시점·금액을 기억으로 보충하거나 선행 제안을 공식 authority로 취급하지 않으며, 실제 제공된 usable authority refs만 사용한다.
+
+## 8. 모델 입력·출력과 참조 계약
+
+### 8.1 자기완결적 입력
+
+```text
+packet_ref, plan_revision
+provisional_bundles: refs, 잠정 anchor, membership과 배정 이유
+materials: 원본 자료 occurrence와 제공 필드, 실제 본문 또는 같은 packet의 본문 별칭
+bodies, reference_roles: 중복 없는 본문과 인용 별칭의 자료 종류·필드 의미
+relations, boundary_links: 원본 관계·관련 이웃 자료·미확인 연결
+goal, profiles, authorities: 의뢰인 제약·질문 구조·필요 authority와 검증 상태
+review_items, source_gaps, residual_scope: 관련 review·원문/검증/배정 제한
+prior_assessments: 최초에는 없음; 필요한 후속 보정에만 명시적 평가와 한계
+repair: 최초에는 null; 동일 입력의 구조 보정에만 오류·기존 출력
+```
+
+같은 호출에서 필요한 사전 값은 전부 실제로 포함해야 한다. 기술적 hash·저장 경로·전체 alias 역변환·원장 인덱스·배치 history는 reducer control에 둔다. 원본 경로가 법률적으로 의미 있는 정보를 포함하면 그 의미를 모델 입력에서 숨기지 않는다. 별칭은 원본 ref와 1:1로 결속하고 fact/party ID·증거번호·명칭·날짜·금액은 임의 변경하지 않는다.
+
+v.2의 ‘원래 14개 cluster payload와 canonical 동등’ 요구는 **새 자료 선택이 같은 작업이라는 증명으로 사용하지 않는다.** v.4는 법률판단 단위와 선택 범위를 바꾼다. compact packet의 역변환은 이번 packet의 정본 논리 입력과 정확히 일치해야 하며, 그 입력의 모든 값·occurrence·refs를 원본 catalog에 대조한다. 별도로 원본 전체의 배정·미배정·quarantine coverage를 확인한다. 표현의 무손실 검증과 선택의 법률적 적절성을 분리한다.
+
+### 8.2 출력 제안
+
+본 task는 `packet_ref`, `domain_resolutions`, `claim_candidates`, `identity_decisions`, `candidate_relations`, `grouping_proposals`, `material_dispositions`, `review_patches`, `needs_materials`, `missing_inputs`, `assumptions`를 가진 JSON 객체 하나를 반환한다. 후속 보정용 `assessment_deltas`, `supersedes_refs`도 계약에 명시하고 최초에는 빈 배열로 둔다. 최초 본 추론에는 새 후보의 완전한 평가를 요구하며, 후속 operation에서는 입력에 제공된 검증 결과의 명시적 계승과 필요한 delta만 허용하는 조건부 Schema를 정의한다. 실제 wire·정본 Schema는 구현 시 버전 고정한다.
+
+청구 후보에는 기여한 cluster/material refs, 권리자·의무자·법적 지위·발생 원인·급부·대상·법률효과·범위, 근거/authority, 요건·항변/재항변·부담·구제·기간·의뢰인 지시·review·공백을 요구한다. 최초 본 추론에서는 기존 cluster의 상세 평가를 상속할 수 없으므로 필요한 법률평가를 작성한다. 후속 경계/보강 판단만 검증된 평가를 명시적으로 재사용하고 변경 항목을 delta로 출력한다.
+
+`grouping_proposals`는 ATTACH/DETACH/SPLIT/RELINK의 대상 refs·자료 범위·근거·이유를 담는다. 자료 묶음 조정 제안은 법률적 병합 결정과 다르며 reducer가 참조·coverage를 확인한 뒤 새 plan revision에 반영한다. 제안 자체가 다른 packet의 사실 또는 완료 상태가 되지 않는다.
+
+`material_dispositions`에는 검토·청구 연결·비관련 제안·미해결·다른 묶음 연결을 추적한다. 동일하게 처리된 자료 집합은 명시적 refs의 그룹으로 출력할 수 있으나 coverage를 원본 occurrence별로 복원해야 한다. 설명·원문·원장 전체를 재출력하지 않고, review는 실제 평가 또는 변경 제안만 sparse patch로 반환한다. 미제기 지시는 실제 근거와 함께 보존하고 배제 판단과 구별한다.
+
+현재 응답의 후보 local ref는 packet 안에서만 유일한 검토용 참조다. 입력에 있는 검증된 이전 후보만 외부 endpoint로 참조할 수 있고 같은 배치의 미완료 후보를 발명하지 않는다. 연결할 후보가 아직 없으면 boundary 요구를 남기고 reducer가 저장된 대응을 조립한다. 최종 case_type/claim_group/renderer/exhibit ID·소장 문안·확정 수치·완료 상태·hash echo·usage는 모델 출력에 넣지 않는다.
+
+## 9. 경계 보정·자료 보강과 큰 묶음
+
+### 9.1 추가 본 추론은 조건부다
+
+별개 packet에서 같은 권리일 가능성, 상충 판단, 새 반대 자료, 잘못된 배정 또는 필요한 원본 누락이 확인된 경우에만 경계/보강 판단을 준비한다. 영향받은 후보·질문·원본 근거·관련 이전 평가를 한 번에 전달하고, 전체 사건이나 전체 cluster를 다시 평가하지 않는다. 단순 membership 정리와 출력 조립은 코드로 수행한다.
+
+한 영향 묶음에 대한 의미 보정·자료 보강은 기본적으로 **한 번**으로 제한한다. 같은 snapshot의 허용 자료만 보강하고 새 plan/packet digest를 기록한다. 실패한 구조·참조 출력의 보정은 별도로 같은 입력에서 최대 한 번 허용한다. 의미가 바뀐 입력을 기존 구조 repair로 위장하지 않는다. 제한 후에도 연결·권리·사실이 미확인이라면 unresolved와 잔여 범위를 남기고 자동 반복하지 않는다.
+
+한 번의 경계 보정으로 자료가 충분하지 않거나 크기 예산을 넘으면 해당 범위의 미완료·미해결을 보고한다. A–B와 B–C 판단만으로 A–C의 반대 근거를 무시한 전이 병합을 하지 않는다. 최종 조립의 동일성 주장은 명시적으로 검토한 근거·범위 안에 한정한다.
+
+### 9.2 큰 묶음의 분할
+
+system·Schema·packet·repair의 개별 입력, 출력 예약·추론 예산, 배치의 동시 TPM·MCP 응답·base64 결과 envelope를 admission한다. 먼저 본문 사전·짧은 인용 refs·관련 하위 묶음 공동 처리를 적용하고, 예산을 넘으면 자료의 연결과 경계를 표시하여 가역적으로 분할한다.
+
+분할은 법률적 독립성의 확정이 아니다. 각 부분에 검토 범위, 필요한 공통 자료, 경계 ref와 미확인 질문을 제공한다. 부분별 결과가 모든 권리를 완전히 식별했다고 표시하지 않으며, 연결된 범위의 동일성·모순은 경계 판단으로 보완한다. 필요한 경계 정보를 전달할 수 없는 경우 input을 잘라 성공 처리하지 않는다.
+
+자료·반대 근거를 충분히 제공할 수 없는 큰 묶음에 대해 ‘8개 cluster씩’ 잘라 확정 청구를 만드는 규칙은 두지 않는다. packet 수·cluster 수·청구권 수는 다르며 개별 입력 예산이 우선한다. 이 구조의 추가 호출과 공유 본문 반복까지 총 비용에 포함한다.
+
+## 10. 기존 실행 구조의 변경과 효율 유지
+
+### 10.1 제안 task 연결
+
+| 제안 task | 책임 |
+|---|---|
+| `Task_S2_10_prepare_provisional_bundles` | code. upstream·원본 참조 검증, source index·잠정 plan·미배정 목록, 이번 최대 8개 packet과 control 준비. |
+| `Task_S2_10_assess_bundle` | LLM map. 하나의 packet에서 권리 식별·동일성/분리/경합·요건/항변/구제와 배정 수정 제안을 함께 판단. |
+| `Task_S2_10_validate_publish_bundles` | code reducer. 응답 복원·Schema·scope·coverage·source gap·review 검증, batch 결과·계획 변경 요청·이어 처리 status 발행. |
+
+prepare Stage → 본 추론 MapReduce Stage의 단순 구조를 기본안으로 삼는다. 최초·다음 배치·필요 경계/보강·구조 repair 모두 prepare가 명시적인 `operation`과 packet 입력으로 구별하고, 같은 법률 map task의 입력 계약 안에서 처리한다. 자동 Stage loop나 v.3의 cluster phase→integration phase를 그대로 유지하지 않는다.
+
+진정한 빈 입력·완료본 재사용 등 모델 packet이 0개인 경로는 prepare/reducer의 명시적 code 처리로 끝낸다. 빈 map의 reducer 실행, Stage 실패 전파, 같은 실행의 receipt·control hash 결속은 실제 backend에서 검증해야 한다. 미확인 skip/Stage 조건문을 가정하거나 빈 map 때문에 성공 status가 임의 발행되게 하지 않는다.
+
+한 Agent 호출의 모델 packet 수≤8과 map 동시성≤8을 각각 적용한다. packet 안에 관련 하위 묶음이 여럿 있어도 입력/출력 예산을 통과해야 한다. 선택·배치 순서는 결과를 바꾸는 법률 근거가 아니며, 동시 실행의 아직 없는 verdict를 참조하지 않는다. 같은 binding의 성공 batch는 재사용하고 caller가 status에 따라 한 writer로 순차 재호출한다. 완료본 재사용에는 모델 호출 0을 유지한다.
+
+### 10.2 S2_00 waves·SCC의 취급
+
+S2_00의 cluster와 scheduling wave/SCC는 **원본 연결·의존 후보에 관한 검증·provenance 자료로 보존**한다. 이를 선행 cluster 법률 verdict를 기다리는 실행 순서로 그대로 이식하지 않는다. 새 작업 단위가 여러 cluster의 자료를 담을 수 있으므로 원래 wave와 새 packet을 일대일로 맞추지 않는다.
+
+원본 `candidate_dependencies`의 방향은 법률적 선결 관계로 확정된 것이 아니다. 실제 판단에 필요한 관련 자료는 함께 제공하거나 경계 질문으로 남긴다. 사용 가능한 선행 확정 결과가 없는 SCC 자료를 상호 기다리게 하지 않는다. 새로운 packet 작업 의존성은 이미 저장된 결과의 필요 여부와 원본 연결로 정의하며, 결정되지 않은 법률관계를 코드가 확정해 순환 대기를 만들지 않는다.
+
+`predecessor_candidates`와 `SCC_INTERNAL_VERDICTS_UNAVAILABLE`를 옛 cluster phase의 의미 그대로 필수 입력·차단으로 복제하지 않는다. 대신 실제 제공 자료·관련 이웃 범위·미해결 경계와 authority/schema/원문 공백을 기록한다. S2_00의 원본 정보는 삭제하지 않으며 제한을 해소했다고 주장하려면 새 입력과 검토 근거가 있어야 한다.
+
+### 10.3 저장·전달 최적화
+
+v.2/v.3의 준비 인덱스 재사용·본문 사전·별칭·Schema `$defs`·검증 control 분리를 유지한다. 기술적 algorithm/root/fingerprint/기대 집합/원래 artifact/실행 모드·upstream 상태 등 파생 값은 코드·고정 status에서 얻고 LLM 입력에 중복 넣지 않는다. 단, 최종 검증·coverage에 필요한 기준은 control에서 복원 가능해야 한다.
+
+기본 전달 경로는 작은 map descriptor와 최대 8개 자기완결적 compact slot이다. 문서화된 dynamic `preflight_files`의 map 동작·whitelist·중복 삽입 방지를 live 확인하고, 모델의 임의 tool 호출·검색·파일 저장은 금지한다. 작은 `item_json` 직접 전달은 실제 native `read_docs` 전체 응답과 item 반송·최대 출력·base64 팽창이 예산 안에 있고 더 효율적인 경우에만 채택한다. `shared_context`에 임의 Python 복원 hook이 있다고 가정하지 않는다.
+
+prepare 한 프로세스에서 source·signal/schema·party/거래·review·관계 index를 한 번 구성하고 필요한 자료만 packet으로 만든다. 별도 pip task·packet별 Code Executor 복원 task·전체 자료 stdout 반송은 추가하지 않는다. requirements는 줄바꿈 문자열로 전달하고 notebook의 MCP 초기화·notification·workspace 격리 계약을 유지한다. 모델·추론 설정을 우선 유지하되 현행 provider adapter의 실제 설정 적용은 구현 검증 대상으로 둔다.
+
+## 11. 출력 파일과 상태의 제안
+
+새 알고리즘·prompt·packet compiler·wire/정본 Schema·status·출력 root를 함께 버전 관리한다. 현행 `s2_10/v1` 또는 v.3의 결과를 덮어쓰지 않는다. 기존 request/attempt ID를 추가 생성하는 설계는 넣지 않는다.
+
+| 제안 파일 | 역할 |
+|---|---|
+| `work/bundle_plan.json` | source catalog의 참조, 잠정 membership·미배정·경계·plan revision과 변경 이력. 상세 cluster 법률평가를 담지 않는다. |
+| `work/bundle_control.json` | input binding·원본/plan/packet/batch hash·전체 배정 집합·허용 refs/authority/review·alias 복원·재호출 예산. reducer 전용. |
+| `work/bundle_index.json`, 최대 8개 `work/llm_input/slot-*.json` | 현재 descriptor와 실제 compact model packet. 검증된 직접 전달을 택하면 slot 생략. |
+| `assessments/batch-NNNN.json` | 본 추론·조건부 경계/보강·repair의 검증된 결과와 참조·제한·supersedes. 성공 내용은 불변. |
+| `claims/claim_records.json` | 권리별 당사자·발생 원인·급부·범위·요건/항변/구제·근거와 관계, 원본 기여 자료·잔여 범위의 최종 draft 기록. |
+| `s2_10_status.json` | 배정·본 추론·경계·잔여 자료·원장 coverage와 artifact hash를 결속하는 마지막 marker. |
+
+원본 자료와 공통 평가를 사전화할 때 모든 후속 소비자가 결정적으로 복원할 수 있게 한다. 새 claim record ref는 snapshot 안의 검토용 값이며 최종 claim_group ID가 아니다. 최종 청구 기록에는 원본 cluster/material refs와 판단 이력을 보존한다. 기존 S2_20 Schema·소비 코드가 이 handoff를 지원하는지는 구현 때 별도로 확인해야 한다.
+
+| 상태 제안 | 의미 |
+|---|---|
+| `BUNDLE_ANALYSIS_PENDING` | 준비된 본 추론 packet이 남았다. 아직 법률 후보가 없어도 정상 pending이다. |
+| `BOUNDARY_REVIEW_PENDING` | 명시적 경계/자료 보강 또는 재배정으로 영향받은 질문의 검토가 남았다. |
+| `TECHNICAL_INCOMPLETE` | 구조·참조·원본 결속·읽기/쓰기·크기 등에 실패하여 허용 보정 또는 운영 조치가 필요하다. |
+| `COMPLETED_WITH_ISSUES` | 배정 작업과 최종 조립은 기술적으로 끝났으나 법률·당사자·동일성·잔여 자료·review 공백이 남았다. 청구권 탐색의 완전성·법률 승인을 뜻하지 않는다. |
+| `COMPLETED` | 정의된 본 추론·필요 경계 검토·원본 coverage·artifact 검증이 끝났고 기록된 미해결 사항이 없다. 검토 가능한 draft 상태다. |
+
+잠정 묶음을 만든 것, packet을 처리한 것, 원본 자료 전체의 법률적 관련성을 검토한 것을 각각 구별한다. 최초에 자료가 있는데 빈 bundle 배열이 생기면 코드가 이를 empty input 성공으로 처리할 수 없다. 미배정 목록·처리 범위·정상 미해결 또는 기술 미완료로 명시해야 한다.
+
+## 12. 검증 기준과 실패 처리
+
+### 12.1 자료·결과·계획 검증
+
+- 원본 cluster/member/signal/review refs·hash·schema 검증과 전체 inventory를 유지한다. 모든 자료 occurrence가 membership, 미배정 또는 이용 제한에 명시적으로 대응하는지 검사한다. 중복 membership은 허용하지만 자료의 소실은 허용하지 않는다.
+- packet의 정확한 논리 입력과 pack/unpack·alias 복원 동등성을 확인한다. 허용 field pointer·자료 종류·authority usable·검증 범위·본문 마커 충돌을 검사한다.
+- ATTACH/DETACH/SPLIT/RELINK의 범위·근거·revision 및 plan 변경 전후 coverage를 대조한다. 변경으로 영향을 받는 성공 결과와 영향받지 않은 결과를 구별한다.
+- 후보 refs는 이번 입력 또는 명시적으로 제공된 검증 평가에 한정한다. 다른 packet이나 아직 실행되지 않은 동시 결과의 endpoint를 발명할 수 없다.
+- 동일성과 성립의 확정 근거, 요건/항변의 지지·반대·부담·공백, blocking review와 schema/원문/authority 제한, 의뢰인 미제기 지시를 검사한다. 문자열 검사만으로 법률 품질을 인증하지 않는다.
+- 하나의 청구 기록으로 조립할 범위에는 명시적 구성 판단이 있어야 한다. 중복 후보의 exact representation 제거와 법률적 청구권 병합을 구별하고 전이 병합의 충돌을 차단한다.
+- sparse review·assessment delta는 제안과 계승 범위를 구별한다. 원본 원장을 수정하거나 모델이 평가하지 않은 review를 자동 완료 처리하지 않는다.
+- packet·plan·control·원본·기존 성공 결과의 binding과 read-back·status-last를 확인한다. 같은 root의 single writer를 원격 잠금/CAS 구현으로 표현하지 않는다.
+
+현행 `validate_result`는 단일 `cluster_ref`와 기존 후보 endpoint 범위를 전제로 한다. v.4에서는 packet과 복수 cluster/material scope, 자료 disposition·grouping proposal·경계 결과에 맞는 별도 Schema·validation이 필요하다. 이름만 `bundle`로 바꾸고 old cluster validation을 그대로 통과시키는 방식은 채택하지 않는다.
+
+### 12.2 법률·가역성·토큰을 함께 검증할 사례
+
+| 사례 | 요구 결과 |
+|---|---|
+| 같은 대여의 계약·송금·변제·시효가 여러 cluster에 분산 | 선행 상세 평가 없이 묶음 본 추론에서 종합하고 반대 자료·미확인을 보존한다. |
+| 같은 당사자의 별개 대여, 같은 물건의 서로 다른 권리 | 같은 탐색 범위에 있어도 별개 청구권으로 분리한다. |
+| 계약책임/불법행위책임, 원금/이자, 주채무/보증 | 독립·경합·부수 관계와 회복 범위를 유지한다. |
+| 한 cluster에 여러 거래·권리, 여러 묶음에 중요한 공통 증거 | 복수 membership·필요 범위 전달·원본 불변을 확인한다. |
+| party/거래 ID 없음, 유사 이름, 법인/대표자·승계 혼동 | 원본 근거 없이 미리 동일인·동일권리를 확정하지 않는다. |
+| 미배정 자료에서 새 청구 또는 결정적 반대 근거 발견 | 본 추론에 포함·재연결·새 후보/평가 수정이 가능해야 한다. |
+| 선행 prepare·선택적 연결 확인의 출력 검사 | cluster별 상세 요건·항변·구제 평가가 만들어지지 않고, 보조 LLM이 대부분의 cluster를 미리 평가하는 경로가 없는지 확인한다. |
+| 큰 묶음 분할 후 경계 충돌, A–B/B–C/A–C 불일치 | 분할의 잠정성·원본 coverage·한정된 경계 판단·병합 보류를 확인한다. |
+| 본 추론 후 DETACH/RELINK로 성공 결과의 근거 범위가 변경 | 영향 구간만 supersedes 보정하고 기존 artifact와 비영향 결과를 보존한다. |
+| global blocker·schema 실패·authority 없음 | 본문 미전달이나 묶음 변경으로 제한이 사라지지 않는다. |
+| 0·1·8·9 packet, 큰 packet, stale plan/slot/control, 출력 누락·중단 | admission·단일 구조 보정·자료 보강 구분·복구·status-last를 확인한다. |
+| 여러 packet에 같은 본문이 반복 | 실제 요청별 중복량을 측정하고 사전 저장만으로 토큰이 줄었다고 보고하지 않는다. |
+| 동일 완료 snapshot 재호출 | 변경 검증 후 모델 호출 0이며 pending 경계/잔여 범위를 누락하지 않는다. |
+
+## 13. 토큰·정확도 비교와 구현 순서
+
+같은 원본 사건과 authority·모델·추론 설정에서 v.3의 ‘cluster 상세 평가 후 통합’, 원본 전량 공동 평가, v.4의 ‘잠정 묶음 후 본 추론’을 비교한다. 확정 병합을 선행하여 실패한 설계와 비교해 v.4의 우월성을 과장하지 않는다.
+
+```text
+v4 총 모델 토큰
+  = 선택적 묶음 확인의 입력·출력·실제 reasoning
+  + 묶음별 본 추론의 입력·출력·실제 reasoning
+  + 필요한 경계/자료 보강·구조 repair의 전체 비용
+```
+
+호출 수가 줄어도 개별 packet이 커지거나 추론·보정이 늘 수 있으므로 개별 입력 최대값·사건 전체 토큰·공유 본문 반복량·처리시간을 함께 측정한다. 현재 현행 결과 entry의 usage는 null이다. provider/backend에서 확인된 usage 경로가 없으면 reasoning은 미측정으로 남기며 모델에게 토큰 계산을 시키지 않는다. byte 감소·cache 할인·MCP I/O 감소를 실제 추론 토큰 감소와 구별한다.
+
+정확도는 당사자/권리 귀속, 잘못된 병합·분리, 청구 누락, 요건·항변/재항변·반대 자료·구제·기간·원본 인용·잔여 자료 coverage로 평가한다. 선행 grouping의 오류 회복률과 재배정 후 영향 평가도 포함한다. 구조 검증이나 canonical 동등성만으로 법률 품질을 보증하지 않는다. 필요한 법률 품질을 충족하는 구성 중 전체 토큰과 개별 입력이 적은 방식을 채택한다.
+
+구현 순서:
+
+1. **정본 입력·새 계약 고정:** 현행 YAML과 S2_00 snapshot, authority/Schema·모델 설정을 pin하고 bundle/packet/claim record·revision·새 상태와 출력 root를 정의한다.
+2. **비 LLM 잠정 prepare:** source index·anchor·membership·미배정·quarantine·분할/재연결 이력을 구현한다. cluster 상세 법률평가를 호출하지 않는지 확인한다.
+3. **표현·admission:** 정본 packet→본문 사전/alias compact→역복원·control binding, 최대 8개 batch·실제 envelope·preflight 또는 직접 전달을 검증한다.
+4. **본 prompt·Schema·reducer:** 묶음의 동일성/분리/경합·요건/항변/구제, grouping proposal·자료 disposition·sparse review와 신규 scope 검증을 연결한다.
+5. **조건부 이어 처리:** 미처리·영향받은 경계/보강·구조 repair·성공 결과 재사용·supersedes·최종 조립과 status를 연결한다. 자동 무한 반복을 넣지 않는다.
+6. **실제 품질·총 비용 비교:** 가역성·공유 자료·누락·병합 오류와 실제 토큰/지연을 확인한 범위에서만 채택 효과를 보고한다.
+
+## 14. 결정 기록과 완료 경계
+
+| 결정 | 이유 | 되돌림 또는 미해결 조건 |
+|---|---|---|
+| 원본 참조의 잠정 묶음을 선행하고 상세 법률평가는 본 task에 집중 | cluster 상세 평가와 후속 통합의 중복을 줄인다. | 관련 자료를 안정적으로 모으지 못하면 미배정·보강·unresolved를 보존한다. |
+| 복수 참여·분할·재연결·원본 불변 | 묶음 오류를 회복하고 복수 청구·공유 증거를 놓치지 않는다. | 영향받은 결과는 별도 근거로 갱신하고 자동 상속하지 않는다. |
+| 공유 본문과 관련 하위 묶음의 공동 처리 | 같은 자료와 고정 prompt를 불필요하게 반복하는 비용을 줄인다. | 큰 입력·무관한 사실 혼합·추론 증가 시 packet 분리 또는 일반 표현으로 되돌린다. |
+| 최초에는 상세 법률평가 전체, 후속에는 한정 delta | 본 추론의 법률 내용은 유지하면서 보정의 재출력·재추론만 줄인다. | 새 자료로 범위가 바뀌면 적용 여부를 다시 판단한다. |
+| 원본 waves/SCC는 provenance·관계 후보로 보존 | 없는 cluster verdict를 기다리는 구조를 제거한다. | 실제 법률 의존성은 본 판단/경계 질문으로 검토한다. |
+| 전역 재통합 LLM은 기본 경로에서 제거 | 비용 절감이 순서 변경에서 실제로 나오게 한다. | 실재하는 경계 충돌에만 제한적 추가 판단을 수행한다. |
+
+v.3의 전체 cluster 법률 결과 gate·두 phase·기존 평가 자동 재사용 경로는 새 책임에 맞게 대체한다. v.2/v.3의 원본·근거·review·미해결 보존, compact 표현, metadata 분리, 최대 8개 admission, 완료본 재사용, read-back·status-last는 계승한다. v.4가 기존 YAML·후속 handoff와 자동 호환된다고 주장하지 않는다.
+
+이번 작업은 v.4 전략서와 지정 MEMORY 요약 작성이다. 실제 compiler·prepare·LLM prompt/Schema·reducer·revision·새 상태는 구현하지 않았으며 workspace 실행·실제 토큰/속도·법률 품질·S2_20 소비 호환 검증은 미실시다. 문서의 14개 절·8개 동일성 기준·로컬 링크 7개·UTF-8/fence·표 구조·기준과 제약의 반영·계약 정합성과 v.3·현행 YAML·가이드의 원본 hash를 정적으로 확인했다. 작업 요약은 지정 MEMORY의 `How to Write MEMORY.md` 바로 아래에 삽입하고 기존 본문을 보존한다.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/MEMORY.md

@@ -4,6 +4,42 @@
 
 ## How to Write MEMORY.md
 
+### 2026-10-04 — 현행 S2_10 v4 작업명세서 분석
+
+한 줄 요약: `agent_scripts/Analysis_Stage_2_S2_10_v.4.md`에 현행 S2_10 v4(Agent 4.1.0)의 요청된 7개 목차 분석을 작성했다. 실제 실행단위는 확정 청구권이나 원본 cluster가 아니라 가역적 잠정 bundle이며, reducer의 결과 조립을 전역 청구권 중복 제거와 구별해야 한다.
+
+- 2개 stage·3개 task, 최대 8개 배치, 고정 최초 회차·영향 범위 완전 재평가/구조 보정 각 1회, 실제 prompt·packet·출력·고정 자산과 책임 경계를 정리했다. runtime 검증값 False·authority 빈 목록·global blocker·대형 범위·단일 writer/usage 한계, S2_20의 파일·Schema·COMPLETE/TO_S2_20 barrier 차이를 명시했다.
+- 문서 및 source 대조 12개 확인과 로컬 링크 8건을 통과했다. 두 inline Python 구문·3개 출력 Schema·prompt hash/byte reserve·v4 사본 동일성을 확인했고 YAML·S2_00/S2_20·기존 MEMORY 본문을 보존했다. 원격 backend/MCP/LLM 실행·실제 토큰/법률 품질·downstream 연결 검증은 수행하지 않았다.
+
+### 2026-10-04 — S2_10 v4-1 전략 구현 및 YAML v4 저장
+
+한 줄 요약: `agent_scripts/Stage_2_S2_10.yml`을 v4-1 전략의 비 LLM 잠정 묶음→묶음 본 LLM→코드 검증·발행으로 개정했다. 원본은 `Stage_2_S2_10_10_04_11pm.yml`, 개정본의 동일 사본은 Stage 2 루트 `Stage_2_S2_10_v.4.yml`에 저장했다.
+
+- 원본 참조·복수 membership·미배정/제한 자료·고정 최초 회차·본문 사전·최대 8개 배치, 동일 출력 Schema·영향 범위 완전 재평가 1회·동일 입력 구조 보정 1회·불변 batch·활성 결과 교체·기존 상태·read-back/status-last를 구현했다. 선행 cluster/연결 LLM과 delta/supersedes 작업은 없다. 8개 동일성 기준·반대 사실·항변/부담/구제·authority/의뢰인/review 제한을 유지한다.
+- 종합 검증은 sub-agent 없이 1회(35항목) 수행했다. 최초 33항목 통과 후 검증 fixture의 MCP key/slot 선택 2건을 수정했고, 잔여 재검토 질문의 최종 보존과 입력/출력/reasoning 예산 admission을 증분 보완하여 관련 7개 국소 확인을 통과했다. 실제 inline 코드의 합성 in-memory 검증이며 원격 backend·모델·법률 정확도·실제 토큰·S2_20 호환 검증은 미실시다.
+- YAML 버전 4.1.0, 개정본 SHA-256 `e4148f6d5d4c285c4d0e7523b87d9b1f689b12717be681a060e59a8d3a2d04fa`; 원본 백업은 기존 hash `3d8616c2e2a1c3a5f405ba9806718b9ac519843ddc02c80ff4d51a67c42e8c50`와 동일하다. 동적 slot/빈 map/provider 예산·추론 설정 검증값은 기본 False이며 미확인 runtime에서 모델 작업·완료 발행을 막는다. 전략서·가이드·노트북·S2_00·기존 MEMORY 본문은 보존한다.
+
+### 2026-10-04 — S2_10 v4 단순성 평가 및 v4-1 전략
+
+한 줄 요약: `agent_scripts/S2_10_revision_strategy_eval_v.4.md`에서 v4의 핵심 추론 순서는 유지하고 초기 계약·상태·보정 장치를 줄이는 R1–R8을 평가했으며, 이를 반영한 `S2_10_revision_strategy_v.4-1.md`을 작성했다.
+
+- 원본 refs 기반 비 LLM 잠정 묶음→본 LLM→코드 검증의 세 task, 8개 동일성 기준·복수 참여·미배정·분할/재연결을 유지했다. 고정 회차·참조 변경 기록·단일 출력 Schema·영향 범위 완전 대체 평가·기존 상태를 기본으로 하고, 선행 보조 LLM·delta/supersedes·별칭·동적 재계획 등은 실측 후 도입 조건으로 옮겼다. 재검토/구조 보정은 각각 최대 1회이며 공유 본문 재전달도 총 비용에 포함한다.
+- 두 문서의 정적 확인 36개 항목·로컬 링크 7개를 통과했다. v2/v3/v4·현행 S2_00/S2_10 YAML과 기존 MEMORY 본문은 보존했다. 평가서·개정 전략서·본 요약만 작성했으며 구현·workspace 실행·실제 토큰/법률 품질·후속 handoff 검증은 미실시다.
+
+### 2026-10-04 — S2_10 전략 v4: 가역적 잠정 묶음 후 본 추론
+
+한 줄 요약: `agent_scripts/S2_10_revision_strategy_v.4.md`에 원본 당사자·거래·발생 사건·목적물 refs로 관련 자료를 먼저 잠정 배정하고, 묶음별 본 추론에서 청구권 동일성·분리·경합과 요건·항변·구제를 함께 판단하는 전략을 작성했다. 선행 cluster 상세 평가와 상시 전역 재통합을 제거하는 설계다.
+
+- 원본 불변·복수 membership·미배정/quarantine 보존·ATTACH/DETACH/SPLIT/RELINK 이력과 영향 구간의 supersedes 보정으로 가역성을 정의했다. 선행 LLM은 기본 0회이며 선택적 연결 확인도 상세 법률평가를 금지한다. 호출 내부 본문 사전·관련 하위 묶음 공동 처리·필요 범위 재사용으로 공유 자료 반복을 줄이되 요청 사이 재전달 비용은 실제 합계에 포함한다.
+- 14개 절·8개 동일성 기준·로컬 링크 7개·UTF-8/fence·표/계약 정합성을 확인했고 v2/v3·현행 YAML·가이드와 기존 MEMORY 본문은 보존했다. 전략서와 본 요약만 작성했으며 YAML/Python 구현·workspace 실행·실제 토큰/속도·법률 품질·후속 handoff 호환 검증은 미실시다.
+
+### 2026-10-04 — S2_10 전략 v3: cluster 판단 후 청구권 통합 식별
+
+한 줄 요약: `agent_scripts/S2_10_revision_strategy_v.3.md`에 모든 cluster wave 검증 후·S2_10 최종 완료 전 청구권 통합 식별을 추가하는 전략을 작성했다. 원본 cluster는 보존하고 후보·자료를 청구 기록에 다대다로 연결하며 동일성과 성립 판단을 분리한다.
+
+- 8개 동일성 기준, 당사자·거래 anchor의 근거 확인, 비 LLM 인덱싱→필요 묶음 LLM→검증·조립을 설계했다. 빈 후보·EXCLUDED·미연결 자료·반대 근거도 coverage에 포함하고, 기존 평가 재사용·본문/인용 단축·sparse delta·phase별 최대 8개·제한된 자료 보강으로 중복 추론을 줄인다. cluster 완료만으로 전체 완료를 표시하지 않는다.
+- v2·현행 YAML·가이드는 보존했고 문서 구조·로컬 링크 6개·UTF-8/fence·계약 정합성을 정적으로 확인했다. 전략서와 본 요약만 작성했으며 YAML/Python 구현·workspace 실행·실제 토큰/속도·법률 품질 및 새 handoff 호환 검증은 수행하지 않았다.
+
 ### 2026-10-04 — S2_10 전략 v2: 실제 모델 입력·반복 처리 단축
 
 한 줄 요약: `agent_scripts/S2_10_revision_strategy_v.2.md`에 cluster 내부 본문 공유·임시 인용 별칭·Schema 공통화·prepare 인덱싱·예산 기반 최대 8개 배치를 제안했다. 저장 중복 제거와 실제 모델 토큰 개선은 별도로 검증한다.
@@ -34,6 +70,35 @@
 - 하위 에이전트(subagents)를 사용하여 핵심 테마와 교훈을 식별하고 MEMORY.md에 섹션으로 저장하라.
 - 향후 세션 시작 시 MEMORY.md의 이전 섹션을 참조하라.
 
+## 2026-10-03 — 현행 S2_10 v2 분석: 호출 모델과 저장 결속 대조
+
+한 줄 요약: `agent_scripts/Analysis_Stage_2_S2_10_v.2.md`에 요청한 7개 목차로 실제 준비→LLM map→발행 DAG, 직접 파일 인계·선택 자산·sparse review·wave 재실행·상태/책임 경계를 분석했다. 반복 요청 시 현재 소스 hash와 모델 결속을 재확인하여 기존 분석의 판정을 갱신해야 한다.
+
+- 재확인한 현행 task와 두 inline `MODEL_CONFIG`는 모두 `gpt-6.1-sol`로 일치하며, 기존 불일치 판정을 해소 상태로 갱신했다. `Stage_2_S2_10_v.2.yml` 복제본도 byte-identical이다. 분석 기준 SHA-256은 `3184651ff272117ca2b5989854b4b1e08687a636b0849f9fde9ab6f8d1500cfa`이며 과거 오프라인 32건의 검증 hash와 구별한다. 모델 설정은 자동 동기화되지 않으므로 향후에도 세 곳을 함께 확인한다.
+- authority 기본 공백·선택 schema 범위·참조/법률 의미 검증의 차이·BLOCKED 파일 미발행·usage 미제공·단일 writer/복구·후속 통합 한계는 유지했다. 현행 YAML 파싱·두 Python 3.11 문법·prompt hash/schema 정합성 및 문서 구조/링크를 확인했다. 분석서와 본 기존 요약만 갱신하고 YAML·복제본·자산 변경 및 workspace 실행은 하지 않았다.
+
+## 2026-10-02 — S2_10 YAML v2: 직접 handoff·법률 map·최소 wave 발행
+
+한 줄 요약: 전략 v2·Case_02 SKILL·Code Executor notebook에 따라 S2_10을 비 LLM 준비 Stage → cluster별 LLM map → 비 LLM reducer로 개정했다. 같은 실행의 Stage 결과와 `map_results_b64`를 사용해 입력·응답·저장의 실제 생산자를 연결하고, 전체 review/hash echo를 모델에 반복시키지 않는다.
+
+- S2_00 v6의 5개 완료 결과·hash·header를 검증하고, 기존 cluster/member/signal/review 참조로 최소 payload를 구성한다. 관련 없는 domain 자료는 전량 방송하지 않고 원장과 미검토 제한에 남기며, 공식 authority 미제공도 보존한다. 선택 신호 schema의 상대 `$ref`를 검증된 로컬 자산에 결속했고, upstream canonical digest의 trailing LF 규칙을 맞췄다. sparse review 평가 제안, wave 결과 1개+전체 status, read-back·status-last·동일 완료본 재사용을 구현했다.
+- 캡처 입력의 46개 cluster·review 1,128·signal 475 보존, 정상/실패 발행·변조 거부·참조/schema 검사·MCP JSON/SSE·빈 입력·복수 wave·SCC·실패 cluster 1회 보정·재사용의 오프라인 32개 시험 및 YAML/DAG·Python 3.11 문법 검증을 통과했다. 다음 wave와 보정은 동일 Agent 재실행으로 이어가며 자동 Stage loop는 만들지 않았다. 실제 backend Stage 변수·모델 응답·실행 및 법률판단 품질·토큰 비용은 미검증이다.
+- 기존 원본은 `agent_scripts/Stage_2_S2_10_10_02_11pm.yml`로 byte-identical 보존하고 현행 YAML을 overwrite했다. 새 복제본은 본 폴더 `Stage_2_S2_10_v.2.yml`이며 현행본과 동일하다. S2_00·전략서·분석서·SKILL·notebook·다른 단계/자산은 변경하지 않았고 workspace 실행·배포·commit/push도 하지 않았다.
+
+## 2026-10-02 — S2_10 재작성 전략 v2: 반복 검증·전달·저장 축소
+
+한 줄 요약: v1을 보존하고 `agent_scripts/stage_2_s2_10_revision_strategy_v2.md`에 비용 증가 요소의 식별표와 최소 실행 계약을 작성했다. 필수 법률판단·무결성·원장 보존을 유지하면서 같은 정보를 다시 검사·출력·저장하는 부분을 줄이는 것이 핵심이다.
+
+- 입력 1회 검증·참조표 재사용, 소비 신호 파일의 hash별 검사, 코드 metadata와 LLM payload 분리, review sparse patch, wave 결과 1개+전체 status를 기본안으로 제안했다. 재호출·checkpoint·SCC 등은 실제 필요 조건으로 제한하고 기본 출력 namespace의 경로 해석도 바로잡았다.
+- schema 미평가·authority 부족·반대 자료·미해결/UNMAPPED 보존은 유지한다. 파일·문서 축소와 실제 토큰 절감을 구별하며 성능 수치는 측정하지 않았다. 전략 v2·본 요약만 저장하고 v1·YAML·분석서·자산은 보존했다.
+
+## 2026-10-02 — S2_00 v6 직접 소비를 위한 S2_10 재작성 전략 v1
+
+한 줄 요약: `agent_scripts/stage_2_s2_10_revision_strategy_v1.md`에 기존 S2_10의 cluster·wave 법률판단 목적을 유지하고 S2_00 v6의 저장 결과를 직접 소비하는 전략을 작성했다. 구형 dispatch·slice·외부 adapter가 현재 존재한다고 가정하지 않고 입력 준비·검증·저장의 실행 주체를 명시해야 한다.
+
+- 현행 upstream 5개 파일·hash·provenance와 구형 목적·DAG를 대조하고, 당시 캡처 결과 4개의 status hash·byte length를 재검증했다. 새 request/run ID 없이 cluster ref·원본 pointer를 재사용하는 입력 선택, 병렬 판단, wave 진행, 최소 저장·후속 인계 계약을 제안했다.
+- 신호 schema 검사 공백, 미해결 review·UNMAPPED 신호의 전역 보존, 공식 authority 미제공, 의존 방향·SCC, backend map 응답 수집·재호출·동일 root 직렬화를 향후 구현 검증 항목으로 분리했다. 전략서·MEMORY만 저장하며 YAML·자산 변경, workspace 재실행, commit/push는 수행하지 않았다.
+
 ## 2026-10-02 — S2_00 v6 현행 코드·입출력·책임 경계 분석서
 
 한 줄 요약: `agent_scripts/Analysis_Stage_2_S2_00_v.1.md`에 요청한 7개 목차로 현행 v6을 분석했다. 작업 DAG·자산·상태·검증 범위는 전략의 선언보다 실제 호출 경로를 기준으로 판독해야 한다.