docs: record S2_00 IO analysis and request preparation plans

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/MEMORY.md

@@ -16,6 +16,21 @@
 - 하위 에이전트(subagents)를 사용하여 핵심 테마와 교훈을 식별하고 MEMORY.md에 섹션으로 저장하라.
 - 향후 세션 시작 시 MEMORY.md의 이전 섹션을 참조하라.
 
+
+## 2026-09-30 — S2_00 IO 분석·request 준비 계획 및 구현 경계 정정
+
+한 줄 요약: S2_00 입출력 문서와 request 준비 계획·단순화 v1을 작성하고 원본 YAML을 보존했으며, request 생성 코드 구현과 backend 운영 연결 검증을 분리해야 한다는 판단으로 정정했다.
+
+- `Stage_2_00_IO_info.md`: 배포 YAML·분석서·release를 대조하여 DAG, 단계별 파일명·형식·경로, Stage 1 고정 입력 16개·배포 의존 55개·Stage 2 직접 의존 49개, 정상 11+E/diagnostic 5개 출력 및 임시/최종 저장을 문서화했다. 사건별 root·signal 목록·digest·cluster ID는 실제 값이 아닌 결정 규칙으로 구분했다.
+- `../../plans/s2-00-request-preparation.md` 및 `_v1.md`: 두-task request 준비 계획을 작성하고, v1은 동일 불변 외부 인자에서 request를 재구성하여 대조하는 방식으로 별도 준비 receipt 전달·중복 검증을 줄였다. 구현 범위는 v1의 Objective 이하이며, 기존 6필드·canonical JSON·검증·localdocs write/read-back·후행 실패 차단·동시 실행 통제·관련 hash 일관성을 유지한다.
+- `Default_Agent/Stage_2_Clean/agent_scripts/Stage_2_S2_00_outdated_9_09.yml`에 기존 배포본을 byte-identical로 보존했다(SHA-256 `94c2744d71d222cfb5cc1b2a0d33a6cda20079439823de431eef378a2fa5c943`). 기존 builder `--check`는 `PARITY_PASS`, mismatches=[]였으며 변경 전 기준선만 검증했다. 활성 YAML·authoring/runtime/binding은 변경하지 않았고 request writer 및 신규 YAML 구현·live 실행은 미완료다.
+- Stage 1 Default_Agent 자산, v.8 YAML 4개 및 분석 보고서 4개를 확인했다. task 의존·동적 확장·workspace 치환에 관한 단서는 있으나 S2_00 외부 인자 공급·success-only·workspace 직렬화의 backend 구현 전체를 입증하지는 않는다.
+- **정정·후속 원칙:** backend 정보 미확인을 이유로 생성 코드 구현까지 중단한 것은 과도했다. 기존 Stage 2 방식과 일관된 생성·검증·저장 함수를 네 외부 인자를 받도록 구현하고 offline 시험하는 데 backend 전체 구현·명세는 필요하지 않다. 실제 인자 주입·실패 차단·동시 실행의 운영 연결은 필요한 backend 정보만 확보하여 별도로 완성·검증한다. 미지원 템플릿·환경변수·잠금 기능을 임의로 가정하거나 offline 성공을 live-ready로 표현하지 않는다.
+
+## 2026-09-17 — Stage 2 외부 규칙 문서·Weaviate 절차에 관한 의견 평가
+
+외부 문서 접근과 임베딩 검색 위임이 가능하다는 가정 아래 현행 배포 YAML 5종·분석서·관련 자산 및 Stage 1 인계 자료를 대조하여 `Evaluaton_on_hogyus_opinion.md`를 작성하였다. C25/C26의 사건종류·규칙 선택과 Markdown 원문 적재·해시 검증, C27~C29의 Weaviate `search_hybrid` 호출·요건사실 팩 구성은 존재하므로 “절차 부재”라는 평가는 정정하되, 승인된 규칙·검색 범위의 미충족, 규칙·청크 본문의 S2_30 전달 공백, 고정된 요건별 gap 자료, V12 필드와 S2_30→40 해시 대상 불일치는 접근 가능성만으로 해결되지 않음을 구분하였다. 외부 공용 자산의 부재를 추정하지 않았으며, 절차·출처 참조의 존재와 실제 내용 활용·요건 충족·실행 및 법률 검증을 분리하는 것이 핵심 교훈이다. 핵심 경로 독립 검토와 문서 링크·해시 확인을 수행하고 해시 전사 오류 1건을 수정하였으며, 실행 자산 변경·live LLM/MCP/Weaviate·E2E·법률검수·기존 회귀시험 재실행은 수행하지 않았다.
+
 ## 2026-09-09 — Stage 2 배포 YAML 5종 전문 분석과 단계 간 계약 차이 기록
 
 한 줄 요약: 배포 YAML 00/10/20/30/40 총 16,100행을 독립 병렬 분담해 전문 분석하고 각 분석서에 정확히 2회 검증·증분수정을 수행했으며, “구현/봉인/과거 offline PASS”와 “현재 의미 인계·live 실행·법률 승인”을 구별해야 한다는 교훈을 확인했다.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Stage_2_00_IO_info.md

@@ -0,0 +1,332 @@
+# Stage_2_S2_00.yml 단계별 Input / Output 파일 정보
+
+## 1. 범위·기준 및 경로 표기
+
+작성 기준일: 2026-09-30. 사용자 지정 [Stage_2_00_Analysis_v1.md](Stage_2_00_Analysis_v1.md)의 DAG·IO·자산 분석을 기준으로, [배포 YAML](Default_Agent/Stage_2_Clean/agent_scripts/Stage_2_S2_00.yml)과 해당 YAML이 참조하는 release/module manifest를 대조하였다. main 폴더 바로 아래의 동명 YAML은 분석 대상이 아니다. `Y:행번호`는 배포 YAML의 행번호이다.
+
+이 문서는 **파일 계약에 대한 정적 분석**이다. 사건 run이나 MCP 실행을 수행하여 파일 생성 성공을 확인한 문서가 아니다. 현재 release는 `DEV_FIXTURE_RELEASE / DRAFT_NOT_EXECUTABLE`이며 core의 DEV guard가 실제 run을 거절한다. 아래 출력은 해당 실행 경로가 정상적으로 완료되는 경우의 코드상 산출물이다.
+
+| 기호 | 정확한 위치·결정 방식 |
+|---|---|
+| `M/` | `prompt_updates_sequential/Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/` — 이 문서 저장 폴더 |
+| `R/` | `M/Default_Agent/Stage_2_Clean/` — 로컬 배포 패키지 |
+| `W/` | localdocs가 user/workspace session에 결속하는 논리 workspace root. 로컬 Dropbox 절대경로와 동일하다고 가정하지 않음 |
+| `A/` | `W/Default_Agent/Stage_2_Clean/` — 실행 시 Stage 2 자산 source root. 로컬 대응 위치는 `R/` |
+| `U/` | `W/<s2_00_request.json의 stage1_run_root_ref>/` — Stage 1 사건 입력 root |
+| `D/` | `W/<s2_00_request.json의 stage1_deployment_root_ref>/` — Stage 1 고정 배포 source root |
+| `O/` | `W/stage2_runs/by-binding/<run_binding_digest>/` — 최종 파일 저장 root |
+| `T/` | Code Executor의 `TemporaryDirectory(prefix="liti-s2-00-")`로 생성한 임시 root |
+
+`U/`, `D/`, `T/`, `<run_binding_digest>`, `<cluster_id>`의 실제 값은 실행 입력·환경·내용에 따라 결정된다. 분석 자료만으로 실제 사건 폴더명이나 digest를 확정할 수 없으므로, 임의 값 대신 정확한 결정식을 기재한다. 각 표의 **folder + file name**을 이어 붙이면 전체 경로가 된다. 대소문자와 점·밑줄은 원문대로 유지하였다.
+
+근거: 분석서 §0.1·§2·§6, Y:194–227, 4544–4612, 5548–5591, 5957–5959, 6032–6059.
+
+분석 YAML SHA-256: `94c2744d71d222cfb5cc1b2a0d33a6cda20079439823de431eef378a2fa5c943`. 분석서에 기록된 YAML hash와 일치한다. 분석서 SHA-256: `905abf5d93d67b7ab7f9f55e0197e320a69c2d909859dcba145e173a13b65253`.
+
+## 2. 작업 DAG structure
+
+```mermaid
+flowchart TD
+    IN[Agent IN] --> TASK[Task_S2_00_deterministic_ingress: 단일 code-executor.run_code]
+    TASK --> H0[MCP 세션 초기화 · request/release 읽기]
+    H0 --> H1[exact input closure 2회 읽기 · hash/bytes 대조 · 임시 파일 hydration]
+    H1 --> C00[C00: source/schema/producer/identity/seal · signal ALL 검증]
+    C00 --> C05[C05: review 정규화 · 보존검사]
+    C05 --> B[run binding · artifact header]
+    B --> C10[C10: case/evidence/object/party/slot context]
+    C10 --> C15A[C15: membership · cluster · SCC · scheduling wave]
+    C15A --> C15B[C15: slice · bundle/cohort · invariant]
+    C15B --> ROUTE[executable/residual 분할 · route · manifest/intake/issue/status 조립]
+    ROUTE --> N[정상: 공통 4 + context 7 + slice E]
+    ROUTE --> D[diagnostic: 공통 4 + technical diagnostic 1]
+    N --> L[원본 snapshot 재검사 결과 반영 · output schema 검사 · 임시 tree 저장/rename]
+    D --> L
+    L --> V[exact artifact set/hash 재검사]
+    V --> P[원격 non-status write/read-back · ingress_status 마지막 write/read-back]
+    P --> OUT[stdout JSON receipt · Agent OUT]
+    OUT --> EXT[외부 orchestrator: barrier 검증]
+    EXT --> S10[S2_10 또는 S2_10_WITH_ISSUES]
+    EXT --> S40[S2_40_STATUS_ONLY]
+```
+
+원본 snapshot 재검사는 실제 코드에서 route 결정 직후, manifest/intake/status 최종 조립 이전에 수행된다(Y:5114–5117). 도식의 저장 노드는 그 재검사 결과를 전제로 한다.
+
+Agent의 실제 task edge는 `IN → Task_S2_00_deterministic_ingress → OUT` 하나다. C00·C05·C10·C15는 단일 Python 호출 내부의 논리 단계이다. **C00–C15 사이에는 중간 JSON 파일을 저장하고 다음 단계가 다시 읽는 구조가 없다.** 메모리 객체를 전달하고 마지막에 선택된 출력 집합을 일괄 저장한다. S2_10/S2_40 호출은 YAML 외부 orchestrator의 작업이다.
+
+예외가 발생하면 `ok:false / FAILED_NO_BARRIER` receipt 및 exit 2로 빠질 수 있다. 이는 diagnostic 5파일이 자동 생성된다는 뜻도, 이미 저장한 원격 파일이 없다는 보장도 아니다.
+
+근거: 분석서 §1·§4·§6, Y:4801–5243, 5896–6103, 6230–6248.
+
+## 3. 전체 입력 파일 목록
+
+### 3.1 제어·자산 메타데이터 및 출력 검증 schema
+
+| ID | 정확한 file name | file format | source folder | 사용 단계 |
+|---|---|---|---|---|
+| CTRL-1 | `s2_00_request.json` | JSON, UTF-8 | `W/stage2_control/` | H0/H1: 6개 request 필드와 source root 결정 |
+| CTRL-2 | `stage2_release.json` | JSON | `A/manifest/` | H0/H1 및 C00–C15: raw hash pin·입력 및 bundle 계약 |
+| META-1 | `module_manifest.json` | JSON | `A/manifest/` | H1: 아래 schema 3개 선택·hash 검증 |
+| SCHEMA-1 | `ingress.schema.json` | JSON Schema (`.json`) | `A/schemas/` | hydration, manifest/intake/status/diagnostic 출력 검증 |
+| SCHEMA-2 | `context.schema.json` | JSON Schema (`.json`) | `A/schemas/` | hydration, header 및 context/slice/bundle 검증 |
+| SCHEMA-3 | `review_status.schema.json` | JSON Schema (`.json`) | `A/schemas/` | hydration, issue ledger 검증 |
+
+request는 정확히 `schema_version`, `workflow_id`, `request_id`, `attempt_id`, `stage1_run_root_ref`, `stage1_deployment_root_ref`의 6필드이다. 임의 output root를 받지 않는다. YAML 실행 정의 자체는 `R/agent_scripts/Stage_2_S2_00.yml`(YAML)이며 backend가 그 안의 Python code를 실행한다. 별도 `.py` 파일을 사건 입력으로 읽는 방식이 아니다.
+
+근거: Y:194–208, 637–682, 5548–5591, 5721–5753.
+
+### 3.2 Stage 1 사건 고정 입력 16개
+
+아래 모두 strict UTF-8 JSON이다. H1에서 전부 필수 읽기 및 임시 복제하고 C00에서 계약 검증한다. 단계별 의미 사용은 §5에 정리한다. source folder는 원격 `U/` 기준이며 core가 읽는 대응 폴더는 `T/stage1_run/`이다.
+
+| ID | logical input ID | 정확한 file name | file format | source folder |
+|---|---|---|---|---|
+| I01 | `evidence_indexed` | `evidence_indexed.json` | JSON | `U/` |
+| I02 | `evidence_event_candidates` | `evidence_event_candidates.json` | JSON | `U/` |
+| I03 | `client_goal` | `client_goal.json` | JSON | `U/` |
+| I04 | `domain_screening` | `domain_screening.json` | JSON | `U/routing/` |
+| I05 | `domain_activation_manifest` | `domain_activation_manifest.json` | JSON | `U/routing/` |
+| I06 | `b1_evidence_indexed_gate` | `B1_evidence_indexed_gate.json` | JSON | `U/quality_gates/` |
+| I07 | `b2_event_candidates_gate` | `B2_event_candidates_gate.json` | JSON | `U/quality_gates/` |
+| I08 | `stage1_part1_soft_gate_handoff` | `stage1_part1_soft_gate_handoff.json` | JSON | `U/quality_gates/` |
+| I09 | `bo` | `BO.json` | JSON | `U/` |
+| I10 | `signal_manifest` | `signal_manifest.json` | JSON | `U/signals/` |
+| I11 | `stage1_part2_review_handoff` | `stage1_part2_review_handoff.json` | JSON | `U/quality_gates/` |
+| I12 | `legal_effect_structures` | `legal_effect_structures.json` | JSON | `U/` |
+| I13 | `stage1_part3_review_handoff` | `stage1_part3_review_handoff.json` | JSON | `U/quality_gates/` |
+| I14 | `fact_ledger_base` | `Fact_Ledger_base.json` | JSON | `U/` |
+| I15 | `fact_ledger_writer_report` | `fact_ledger_writer_report.json` | JSON | `U/stage1_tmp/fact_ledger/` |
+| I16 | `stage1_part4_review_handoff` | `stage1_part4_review_handoff.json` | JSON | `U/quality_gates/` |
+
+### 3.3 manifest 전개 입력·조건부 입력
+
+| 입력 | 정확한 file name / path 결정 규칙 | file format | source folder | 현재 확정 범위 |
+|---|---|---|---|---|
+| signal payload family | `basename(signal_manifest.files[i].path)` | JSON | `U/signals/<dirname(files[i].path)>/`(dirname이 비어 있으면 `U/signals/`) | `U/signals/signal_manifest.json`의 모든 `files[]`를 전개. 전체 파일명 확정에는 실제 사건 manifest 필요 |
+| SG-01 activation | `domain_activation_manifest.json` | JSON | `U/signals/` | 위 family 내부에서 core가 명시적으로 찾는 파일. `U/routing/`의 동명 파일과 별개 |
+| contract manifest | `basename(release.dependency_locks.stage1.contract_manifest_ref.path)` | JSON | `D/<dirname(path)>/` | 현 release는 path=null. 현재 고정 입력에는 추가하지 않음 |
+| completion seal | `basename(release.dependency_locks.stage1.completion_seal_ref.path)` | JSON | `U/<dirname(path)>/` | 현 release는 ref 없음. 현재 고정 입력에는 추가하지 않음 |
+
+signal의 정확한 전체 경로는 `U/signals/<files[i].path>`. `files[i].path` 자체에 `signals/` prefix를 포함하면 금지된다. canonical/domain_signal은 의미 처리, compatibility_view는 무결성 검증 대상이다. 디렉터리 scan이나 추측한 고정 파일 목록으로 대체하지 않는다.
+
+근거: 분석서 §2.1, Y:1420–1591, 4895–4914, 5635–5720, 6162–6183.
+
+### 3.4 Stage 1 고정 배포 입력 55개
+
+source-of-truth: [stage2_release.json](Default_Agent/Stage_2_Clean/manifest/stage2_release.json)의 `/dependency_locks/stage1/concrete_paths`. H1에서 **전부** raw hash를 검증하고 `T/stage1_deployment/`의 같은 상대경로로 복제한다. C00 검증과 C10 slot 구성에서 사용한다. schema 파일도 직렬화 형식은 JSON이다. 근거: 분석서 §3.2, Y:4164–4242, 5670–5698.
+
+| 번호 | 정확한 file name | file format | source folder |
+|---|---|---|---|
+| D01 | `runtime_manifest.json` | JSON | `D/` |
+| D02 | `_registry_index.json` | JSON | `D/domains/` |
+| D03 | `signal_registry.v2.json` | JSON | `D/signals/` |
+| D04 | `domain_config.json` | JSON | `D/domains/E-00/` |
+| D05 | `domain_config.json` | JSON | `D/domains/E-01/` |
+| D06 | `domain_config.json` | JSON | `D/domains/E-02/` |
+| D07 | `domain_config.json` | JSON | `D/domains/E-03/` |
+| D08 | `domain_config.json` | JSON | `D/domains/E-04/` |
+| D09 | `domain_config.json` | JSON | `D/domains/E-05/` |
+| D10 | `domain_config.json` | JSON | `D/domains/E-06/` |
+| D11 | `domain_config.json` | JSON | `D/domains/E-07/` |
+| D12 | `domain_config.json` | JSON | `D/domains/E-08/` |
+| D13 | `domain_config.json` | JSON | `D/domains/E-09/` |
+| D14 | `domain_config.json` | JSON | `D/domains/E-10/` |
+| D15 | `domain_config.json` | JSON | `D/domains/E-11/` |
+| D16 | `domain_config.json` | JSON | `D/domains/E-12/` |
+| D17 | `domain_config.json` | JSON | `D/domains/E-13/` |
+| D18 | `domain_config.json` | JSON | `D/domains/E-14/` |
+| D19 | `domain_config.json` | JSON | `D/domains/E-15/` |
+| D20 | `domain_config.json` | JSON | `D/domains/E-16/` |
+| D21 | `domain_config.json` | JSON | `D/domains/E-17/` |
+| D22 | `domain_config.json` | JSON | `D/domains/E-18/` |
+| D23 | `domain_config.json` | JSON | `D/domains/E-19/` |
+| D24 | `domain_config.json` | JSON | `D/domains/E-20/` |
+| D25 | `domain_config.json` | JSON | `D/domains/E-21/` |
+| D26 | `domain_config.json` | JSON | `D/domains/EC-00/` |
+| D27 | `domain_config.json` | JSON | `D/domains/X1/` |
+| D28 | `domain_config.json` | JSON | `D/domains/X2/` |
+| D29 | `domain_config.json` | JSON | `D/domains/X3/` |
+| D30 | `client_goal_domain_profiles.schema.json` | JSON Schema | `D/platform/schemas/` |
+| D31 | `domain_fanout_plan.schema.json` | JSON Schema | `D/platform/schemas/` |
+| D32 | `domain_seed_output.schema.v3.json` | JSON Schema | `D/platform/schemas/` |
+| D33 | `domain_slice.schema.v2.json` | JSON Schema | `D/platform/schemas/` |
+| D34 | `fact_exception_pack.schema.json` | JSON Schema | `D/platform/schemas/` |
+| D35 | `fact_ledger_base.schema.json` | JSON Schema | `D/platform/schemas/` |
+| D36 | `fact_ledger_candidate_bundle.schema.json` | JSON Schema | `D/platform/schemas/` |
+| D37 | `legal_effect_structures.schema.json` | JSON Schema | `D/platform/schemas/` |
+| D38 | `structure_seed_bundle.schema.json` | JSON Schema | `D/platform/schemas/` |
+| D39 | `evidence_slot_status.schema.json` | JSON Schema | `D/signals/_common/` |
+| D40 | `signal_item.schema.json` | JSON Schema | `D/signals/_common/` |
+| D41 | `domain_activation_manifest.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D42 | `procedural_posture_relief_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D43 | `party_capacity_standing_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D44 | `governing_law_version_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D45 | `legal_relation_lifecycle_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D46 | `timeline_notice_condition_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D47 | `asset_right_state_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D48 | `liability_causation_damage_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D49 | `defense_exception_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D50 | `evidence_proof_conflict_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D51 | `calculation_requirements.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D52 | `remedy_enforcement_signals.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D53 | `legal_effect_routes.schema.json` | JSON Schema | `D/signals/schemas/` |
+| D54 | `domain_signal_envelope.schema.v2.json` | JSON Schema | `D/signals/schemas/` |
+| D55 | `signal_manifest.schema.json` | JSON Schema | `D/signals/schemas/` |
+
+### 3.5 Stage 2 직접 의존 입력 49개
+
+source-of-truth: release `/dependency_locks/stage2_direct`. H1이 아래 **49개 전부를 읽고** `T/stage2_asset/`의 같은 상대경로에 복제한다. C15가 S2_10 Agent/binding의 opaque hash와 release가 선택한 context를 결속한다. 읽은 모든 profile을 후속 LLM에 제공한다는 뜻은 아니다. 현 release의 `/bundle/selected_context_refs`는 빈 배열이다. 근거: 분석서 §3.3, Y:3283–3475, 5741–5753.
+
+| 번호 | 정확한 file name | file format | source folder |
+|---|---|---|---|
+| A01 | `Stage_2_S2_10.yml` | YAML | `A/agent_scripts/` |
+| A02 | `stage2_s2_10_llm_binding.yml` | YAML | `A/deployment/` |
+| A03 | `authority_registry.yml` | YAML | `A/registry/authority/` |
+| A04 | `authority_release.json` | JSON | `A/manifest/` |
+| A05 | `EC-00_contract_general.yml` | YAML | `A/registry/substantive/` |
+| A06 | `E-01_juristic_act_validity.yml` | YAML | `A/registry/substantive/` |
+| A07 | `E-02_contract_money_claim.yml` | YAML | `A/registry/substantive/` |
+| A08 | `E-03_parties_liability_succession.yml` | YAML | `A/registry/substantive/` |
+| A09 | `E-04_unjust_enrichment.yml` | YAML | `A/registry/substantive/` |
+| A10 | `E-05_tort_general.yml` | YAML | `A/registry/substantive/` |
+| A11 | `E-06_professional_liability.yml` | YAML | `A/registry/substantive/` |
+| A12 | `E-07_construction_defect.yml` | YAML | `A/registry/substantive/` |
+| A13 | `E-08_lease_deposit.yml` | YAML | `A/registry/substantive/` |
+| A14 | `E-09_registry_transfer_claims.yml` | YAML | `A/registry/substantive/` |
+| A15 | `E-10_secured_registry.yml` | YAML | `A/registry/substantive/` |
+| A16 | `E-11_possession_vindication.yml` | YAML | `A/registry/substantive/` |
+| A17 | `E-12_co_ownership_boundary.yml` | YAML | `A/registry/substantive/` |
+| A18 | `E-13_creditor_preservation.yml` | YAML | `A/registry/substantive/` |
+| A19 | `E-14_execution_linked_claims.yml` | YAML | `A/registry/substantive/` |
+| A20 | `E-15_succession_family_property.yml` | YAML | `A/registry/substantive/` |
+| A21 | `E-16_negotiable_instruments.yml` | YAML | `A/registry/substantive/` |
+| A22 | `E-17_labor_wage_claims.yml` | YAML | `A/registry/substantive/` |
+| A23 | `E-18_org_resolution_status.yml` | YAML | `A/registry/substantive/` |
+| A24 | `E-19_insurance_claims.yml` | YAML | `A/registry/substantive/` |
+| A25 | `E-20_ip_claims.yml` | YAML | `A/registry/substantive/` |
+| A26 | `E-21_media_personality_rights.yml` | YAML | `A/registry/substantive/` |
+| A27 | `E-00_residual_unrouted.yml` | YAML | `A/profiles/crosscut/` |
+| A28 | `X1_notice_lifecycle.yml` | YAML | `A/profiles/crosscut/` |
+| A29 | `X2_asset_identity_lineage.yml` | YAML | `A/profiles/crosscut/` |
+| A30 | `X3_procedure_standing_relief.yml` | YAML | `A/profiles/crosscut/` |
+| A31 | `X4_response_admission_defense.yml` | YAML | `A/profiles/crosscut/` |
+| A32 | `SL-AUTO_motor_vehicle.yml` | YAML | `A/profiles/special_law/` |
+| A33 | `SL-INDUSTRIAL_ACCIDENT.yml` | YAML | `A/profiles/special_law/` |
+| A34 | `SL-PRODUCT_LIABILITY.yml` | YAML | `A/profiles/special_law/` |
+| A35 | `SL-RESIDENTIAL_LEASE.yml` | YAML | `A/profiles/special_law/` |
+| A36 | `SL-COMMERCIAL_LEASE.yml` | YAML | `A/profiles/special_law/` |
+| A37 | `SL-LABOR.yml` | YAML | `A/profiles/special_law/` |
+| A38 | `SL-STATE_LIABILITY.yml` | YAML | `A/profiles/special_law/` |
+| A39 | `SL-IP-PATENT.yml` | YAML | `A/profiles/special_law/` |
+| A40 | `SL-IP-COPYRIGHT.yml` | YAML | `A/profiles/special_law/` |
+| A41 | `SL-IP-OTHER.yml` | YAML | `A/profiles/special_law/` |
+| A42 | `SL-MEDIA.yml` | YAML | `A/profiles/special_law/` |
+| A43 | `SL-TRANSPORT_MARITIME.yml` | YAML | `A/profiles/special_law/` |
+| A44 | `SL-CONSUMER_CONTRACT.yml` | YAML | `A/profiles/special_law/` |
+| A45 | `ACTIO-MORTGAGE.yml` | YAML | `A/profiles/overlays/` |
+| A46 | `ACTIO-MORTGAGE-CREATION.yml` | YAML | `A/profiles/overlays/` |
+| A47 | `ACTIO-ENCUMBERED-TRANSFER.yml` | YAML | `A/profiles/overlays/` |
+| A48 | `ACTIO-PRESERVED-CLAIM-BUNDLE.yml` | YAML | `A/profiles/overlays/` |
+| A49 | `ACTIO-DEFENSE-MAP.yml` | YAML | `A/profiles/overlays/` |
+
+## 4. 최종 출력 파일 목록
+
+모든 출력 형식은 **canonical UTF-8 JSON**이다. 표의 `O/`는 최종 원격 저장 root이며, 같은 상대경로가 먼저 `T/core_output/` 아래에 저장된다. `E`는 cohort 검증 이후의 **최종 executable cluster 수**이다. 정상 branch(`TO_S2_10`, `TO_S2_10_WITH_ISSUES`)는 11+E개, diagnostic branch(`TO_S2_40_STATUS_ONLY`)는 정확히 5개다.
+
+| ID | 정확한 file name | file format | 최종 저장 folder | branch | 생성 책임·내용 |
+|---|---|---|---|---|---|
+| O01 | `stage1_input_manifest.json` | JSON | `O/ingress/` | 공통 | C00 검사 결과·source snapshot·hydration receipt를 마지막에 조립 |
+| O02 | `intake_report.json` | JSON | `O/ingress/` | 공통 | C00/C05 결과·source count·compact review/conservation report |
+| O03 | `issue_ledger.base.json` | JSON | `O/review/` | 공통 | 누적 technical issue와 UNMAPPED review를 조립 |
+| O04 | `ingress_status.json` | JSON | `O/ingress/` | 공통·마지막 write | route·run binding·exact artifact hash 목록·barrier |
+| O05 | `case_context.json` | JSON | `O/context/` | 정상 | C10: fact/BO/LES/evidence/event/signal 등의 참조 context |
+| O06 | `evidence_inventory.json` | JSON | `O/context/` | 정상 | C10: evidence-event-fact 연결·provenance |
+| O07 | `object_registry.json` | JSON | `O/context/` | 정상 | C10: BO object occurrence·ID·label·lineage |
+| O08 | `party_and_title_context.json` | JSON | `O/context/` | 정상 | C10: party occurrence와 title/role 등 context |
+| O09 | `slot_crosswalk.json` | JSON | `O/context/` | 정상 | C10: domain config의 slot skeleton |
+| O10 | `cluster_plan.json` | JSON | `O/context/` | 정상 | C15: cluster·SCC·wave·executable/residual |
+| O11 | `bundle_plan.json` | JSON | `O/context/` | 정상 | C15: selected context·cohort·slice·S2_10 binding |
+| O12 | `<cluster_id>.json` | JSON | `O/context/cluster_slices/` | 정상·E개 | C15: 최종 executable cluster별 immutable slice |
+| O13 | `technical_diagnostic.json` | JSON | `O/ingress/` | diagnostic만 | route 조립: reason·source ref·context_published=false |
+
+O12의 실제 basename은 코드가 계산한 `cluster_id`에 `.json`을 붙인 값이다. residual/non-executable cluster의 slice는 최종 출력 집합에 포함하지 않는다. diagnostic branch에는 O05–O12가 없다.
+
+근거: 분석서 §2.2, Y:5180–5243.
+
+## 5. DAG 각 단계별 Input / Output 연결
+
+아래 ID는 §3·§4의 정확한 이름·형식·폴더 행을 참조한다. C00 이후의 '입력'은 원칙적으로 hydration된 파일을 파싱한 메모리 객체이다. '출력 Oxx'는 그 단계에서 준비하는 데이터의 **최종 파일 대응**이며 해당 단계 즉시 저장을 뜻하지 않는다.
+
+| 단계·작업명 | Input file / 전달 객체 | Output file / 전달 객체와 저장 위치 | 근거 Y |
+|---|---|---|---|
+| Agent IN·단일 executor 호출 | `R/agent_scripts/Stage_2_S2_00.yml`(YAML); user/workspace hash 및 인증·실행환경은 파일이 아닌 외부 주입 값 | Python 실행 시작. 별도 업무 출력 파일 없음 | 1–43, 6230–6248 |
+| H0 MCP 초기화·제어 확정 | CTRL-1, CTRL-2 | request/release 메모리 객체. 별도 request 복사 파일 없음 | 5548–5591, 5757–5824 |
+| H1 exact closure 2회 읽기·hydration | CTRL-1/2, META-1, SCHEMA-1–3, I01–I16, signal family, D01–D55, A01–A49; 조건이 충족되면 contract/completion | §6.1에 명시한 임시 파일 복제. `hydration_stability_receipt`는 메모리 객체, 이후 O01에 포함 | 5602–5893 |
+| C00 source/schema/producer/identity | I01–I16, release, D01–D55 및 조건부 contract/completion | source contract rows·snapshots·issues. 이후 O01/O02/O03/O04로 조립, 이 단계 저장 없음 | 1084–1392, 4801–4888 |
+| C00 signal ALL·activation | I10 `signal_manifest.json`, manifest payload 전부, I05 routing activation, `D/signals/signal_registry.v2.json`, 사건 documents | signal occurrence·semantic/integrity rows·activation 비교 결과. 별도 signal output 파일 없음 | 1420–1726, 4881–4923 |
+| C00 cross-artifact seal | 사건 documents/snapshots, 특히 I04/I06/I07/I08 등의 P1 guard와 `D/domains/_registry_index.json`, P2–P4 및 ledger/report | seal 검사 결과·issues. 이후 O01/O02/O03에 반영 | 1740–1782, 4924–4931 |
+| C05 review 정규화 | I08/I11/I13/I16(4개 review handoff), CTRL-2의 review mapping | normalized review occurrence·issues; 독립 `normalized_reviews.json`은 없음. compact receipt→O02, UNMAPPED issue→O03 | 1897–2065, 4932–4934 |
+| C05 보존검사 | I01–I16 파싱 documents와 snapshots, signal ALL 결과, normalized reviews | conservation checks·issues. compact checks→O02, issue→O03 | 2068–2436, 4935–4941 |
+| run binding·artifact header | source/signal/deployment snapshots, release, request/context 값, SCHEMA-2 | binding/header 메모리 객체. O04 내 run_binding_receipt 및 context header 등에 포함 | 4942–4971 |
+| C10 case context | 사건 documents(주요 I05/I09/I12/I14 및 evidence/event/source refs), signal ALL, binding/header/issues | O05용 `case_context` 객체 → 최종 `O/context/case_context.json` | 2523–2630, 4988–4994 |
+| C10 evidence inventory | I01 `evidence_indexed.json`, I02 `evidence_event_candidates.json` 등 documents·header | O06용 객체 → 최종 `O/context/evidence_inventory.json` | 2633–2685, 4995–4999 |
+| C10 object registry | I09 `BO.json`, header | O07용 객체 → 최종 `O/context/object_registry.json` | 2701–2731, 5000–5004 |
+| C10 party/title context | I09 `BO.json`, header | O08용 객체 → 최종 `O/context/party_and_title_context.json` | 2734–2779, 5005–5009 |
+| C10 slot crosswalk | 사건 documents, D/ 아래 domain config 26개(E-00–E-21, EC-00, X1–X3), header | O09용 객체 → 최종 `O/context/slot_crosswalk.json`; 현재 fact/evidence 배열은 빈 skeleton | 2782–2831, 4972–4977, 5010–5015 |
+| C15 membership·cluster·SCC·wave | I09 BO, I14 ledger, I12 LES, I01 evidence, I02 event의 명시 member/relation | O10용 `cluster_plan` 객체. 최종 executable/wave는 cohort 검사 후 갱신 | 2834–3129, 4339–4527, 5016–5017 |
+| C15 bounded slice | cluster_plan 및 C10 context 객체, EVENT/LES 원문 row, signal/review/domain-config projection source map | O12용 slice 객체들. 최종 executable만 `O/context/cluster_slices/<cluster_id>.json` | 3132–3269, 5018–5054 |
+| C15 bundle/cohort·invariant | cluster_plan·slice 객체, CTRL-2 bundle 계약, `A/agent_scripts/Stage_2_S2_10.yml`, `A/deployment/stage2_s2_10_llm_binding.yml`, release-selected context refs(현재 없음) | O11용 bundle_plan, O10 executable/residual/wave 갱신. 입력 Agent/binding은 hash 결속 대상 | 3283–3906, 5055–5113 |
+| route·snapshot 재검사·최종 조립 | source rows, C00/C05 검사·review·issue, C10/C15 객체, 원본 임시 snapshot | 정상 O01–O11+O12 E개 또는 diagnostic O01–O04+O13를 메모리 artifact map으로 확정 | 5114–5243 |
+| output schema 검사·로컬 tree 발행 | 선택된 artifact map, `T/stage2_asset/schemas/`의 SCHEMA-1–3 | 모든 선택 파일을 `T/.staging/core_output.<attempt_id>/`에 저장/fsync, status 마지막 저장, `T/core_output/`로 rename | 4015–4108, 5235–5242 |
+| exact artifact set/hash 재검사 | `T/core_output/ingress/ingress_status.json` 및 해당 tree의 전체 파일 | 파일 bytes map. 새로운 별도 출력 파일 없음 | 5896–5931 |
+| 원격 status-last 발행 | 검증된 local 파일 bytes; 기존 `O/ingress/ingress_status.json`이 있으면 기존 O 전체 파일도 읽어 대조 | 선택된 동일 파일 집합을 O에 저장/read-back; O04 마지막. 기존 집합과 bytes 동일하면 재사용 | 5934–6008 |
+| 단일 receipt·Agent OUT | core 결과·logical publication receipt 또는 예외 | stdout JSON 객체 1개. 고정 파일명·저장 폴더 없음 | 6018–6103 |
+| 외부 downstream dispatch | O04 barrier 및 O10/O11/O12 등 | S2_10 동적 item 또는 S2_40 status-only 호출. S2_00이 추가 파일을 쓰지 않음 | 분석서 §1·§2.2·§5 |
+
+C15 표의 projection source map에 signal/review/profile이 준비된다는 것과 실제 slice에 모두 포함된다는 것은 다르다. 현 구현의 member 생성은 BO/FACT/LES/EVIDENCE/EVENT 중심이며, 이 문서는 전체 내용의 무손실 인계를 보증하지 않는다(분석서 §8).
+
+## 6. 임시 저장·최종 저장·파일이 아닌 출력의 구별
+
+### 6.1 hydration 파일의 source → 임시 output
+
+| 원격 Input | 임시 Output 경로 | file name / format |
+|---|---|---|
+| `U/<상대경로>`: I01–I16 및 signal family, 조건부 completion | `T/stage1_run/<동일 상대경로>` | 원본 basename 및 JSON bytes 그대로 |
+| `D/<상대경로>`: D01–D55, 조건부 contract manifest | `T/stage1_deployment/<동일 상대경로>` | 원본 basename 및 JSON bytes 그대로 |
+| `A/<상대경로>`: release/module manifest·schema 3개·direct 49개 | `T/stage2_asset/<동일 상대경로>` | 원본 basename 및 JSON/YAML bytes 그대로 |
+| `W/stage2_control/s2_00_request.json` | 임시 파일로 저장하지 않음 | 메모리 request 및 두 read-pass 비교에 사용 |
+
+두 read-pass는 임시 복제 전에 같은 원격 경로의 bytes를 비교한다. 임시 폴더는 `TemporaryDirectory` 수명 내에서만 사용한다. 여기의 input 복제는 최종 업무 output 개수(11+E 또는 5)에 포함하지 않는다. 근거: Y:5602–5753, 5825–5893.
+
+### 6.2 최종 저장 순서
+
+1. 선택된 모든 output에 schema 검사를 수행한다.
+2. `T/.staging/core_output.<attempt_id>/<출력 상대경로>`에 non-status를 저장/fsync하고 `ingress/ingress_status.json`을 마지막에 저장한다.
+3. staging tree를 `T/core_output/`으로 rename한다.
+4. exact file set와 raw hash를 다시 검사한다.
+5. 기존 원격 barrier가 있으면 binding·status 및 전체 파일 bytes 일치를 검사한다. 일치하면 `IDEMPOTENT_SUCCESS`이다.
+6. 기존 barrier가 없으면 `O/<출력 상대경로>`에 non-status 파일별 write/read-back을 마친 뒤 `O/ingress/ingress_status.json`을 마지막에 write/read-back한다.
+
+로컬 rename과 원격 `STATUS_LAST_LOGICAL_COMMIT`은 서로 다른 저장 보장이다. 저장 후 read-back 또는 close 실패가 발생하면 실패 receipt와 일부 원격 파일이 함께 남을 수 있다. 근거: Y:4015–4108, 5896–6103.
+
+### 6.3 별도 파일로 오인하면 안 되는 값
+
+| 이름 | 실제 형태·위치 |
+|---|---|
+| `hydration_stability_receipt` | 메모리 객체 및 O01 내부 객체 |
+| `run_binding_receipt` | O04 등의 내부 객체 |
+| `context_materialization_receipt` | bundle 관련 내부 객체 |
+| `output_barrier` | O04 내부 객체 |
+| `logical_publish_receipt` | stdout inner receipt 내부 객체 |
+| `stage2_s2_00_inner_receipt.v1` | stdout 객체의 schema_version; basename이 아님 |
+| `selected_legal_context_json`, `cluster_case_payload_json` | 외부 orchestrator가 만드는 S2_10 item의 문자열 필드 |
+
+S2_00은 `control/run_status.json`이나 최종 청구취지·청구원인 문안을 생성하지 않는다. 또한 YAML 안에 보존된 별도 `main(argv)` CLI의 `project_root/stage2_runs/<run_id>` 경로를 현재 inline MCP 실행의 O 경로와 혼동하면 안 된다. 실제 `__main__`은 `run_inline_mcp()`를 호출한다(Y:6190–6232).
+
+## 7. 식별 결과와 검증 범위
+
+- 16개 Stage 1 고정 사건 입력, 55개 Stage 1 배포 입력, 49개 Stage 2 직접 의존 입력의 이름·형식·source folder를 현재 release와 대조하였다.
+- 제어 request/release, module manifest 및 출력 검증 schema 3개를 별도로 식별하였다.
+- 정상·diagnostic 분기의 출력 목록과 개수, 임시 staging/core_output 및 최종 O 경로를 YAML의 artifact map·publication 코드와 대조하였다.
+- signal family의 모든 basename, 조건부 입력의 실제 경로, U/D의 실제 사건 경로, output digest 및 cluster별 basename은 실제 request/manifest/run이 없으므로 값 자체는 미확정이다. 코드가 정한 결정 규칙을 명시하였다.
+- `runtime/s2_00_ingress.py`, `.txt` mirror, workflow YAML, offline build/test 파일은 실행·검증 자산이지만 이 inline task가 별도 업무 입력으로 import/실행하는 파일이 아니다. `deployment.schema.json`, prompt cache policy, P00/P10 Markdown 등도 위 실제 hydration 집합에 포함하지 않았다(분석서 §3.1·§3.3).
+- 원본 YAML·분석서·release 및 실행 자산은 수정하지 않았다. 문서의 경로·집합 대조는 정적 검증이며, MCP 실행 성공·후속 Agent 실행·법률적 적정성 검증을 뜻하지 않는다.