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 실행·법률적 적정성 검증을 뜻하지 않는다.

Case_02_Comparison_Research/plans/s2-00-request-preparation.md

@@ -0,0 +1,262 @@
+# S2_00 request 생성·검증·저장 선행 task 신설 계획
+
+## Objective
+
+`Stage_2_S2_00.yml`의 맨 앞에 `Task_S2_00_prepare_request`를 신설하여 외부 실행 인자를 검증하고 `stage2_control/s2_00_request.json`을 저장·read-back한 뒤, 성공한 동일 실행만 기존 `Task_S2_00_deterministic_ingress`로 진행하도록 한다. workspace 단위 동시 실행 통제, 두 task 간 request identity 결속, 빌드·배포·hash 계약 갱신을 하나의 변경으로 다룬다.
+
+작성일: 2026-09-30. 상태: **구현 전 계획**. 이 문서 작성 과정에서는 실행 YAML·runtime·배포 자산을 변경하지 않았다.
+
+## Deliverables
+
+| 산출물 | 내용 |
+|---|---|
+| 외부 실행 인자·host 계약 | 인자 전달 방식, workspace 권한·경로 결속, 직렬화, task 실패 차단, receipt 전달 |
+| 2-task authoring 및 배포 YAML | prepare → ingress 순서와 success-only 실행 |
+| prepare 구현 및 runtime mirror | 입력 검증, request 생성, write/read-back, 준비 receipt |
+| ingress 보강 | host가 전달한 준비 receipt의 request hash·실행 identity와 실제 입력 대조 |
+| workflow/schema/binding/builder 갱신 | task별 쓰기 권한, 2-task 추출·검증·receipt·mirror 계약 |
+| 회귀·통합 검증 증거 | mock, 동시 실행, 실제 backend를 구분한 결과 |
+| 분석·IO 문서 개정 | 새로운 선행 단계, 외부 인자 및 실패·잠금 수명 반영 |
+
+## Scope and Non-Scope
+
+- 범위: request 준비와 기존 ingress를 연결하는 구조 및 이를 배포 가능한 상태로 검증하는 데 필요한 계약 변경.
+- 유지: request 파일의 기존 6필드, 고정 경로, 기존 C00/C05/C10/C15의 업무 책임, 정상/diagnostic 산출물 집합.
+- 제외: Stage 1 사건 데이터 수정, S2_10 이후 업무 로직 변경, 기존 DEV release의 자동 production 승격, 기존 보존·projection 결함의 일괄 수정.
+- 계획 작성이 구현 또는 live 배포 승인을 뜻하지 않는다. 실행 제한 해제는 request 생성 구현과 별개의 작업이다.
+
+## Known Inputs
+
+`M = Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/`, `R = M/Default_Agent/Stage_2_Clean/`, `W = localdocs가 결속한 논리 workspace root`.
+
+| 확인한 현 상태 | 근거 |
+|---|---|
+| 현재 IN → ingress → OUT, 단일 task | `R/agent_scripts/Stage_2_S2_00.yml`: 17–43, 6230–6248 |
+| request는 읽기 입력이며 6필드 폐쇄형 검증 | 같은 YAML: 5548–5591, 5757 이후 |
+| 입력 closure를 두 번 읽고 bytes 비교 후 temp hydration | 같은 YAML: 5825–5893 |
+| 빌더가 정확히 1 task·1 run_code·고정 DAG를 강제 | `R/offline_build/build_s2_00_inline_projection.py`: 283–378 |
+| authoring 정본은 `M/Stage_2_S2_00_v.2.yml`; 배포 YAML과 mirror는 파생본 | 같은 builder: 30–38, 680–755 |
+| 단일 code pointer와 code hash·mirror를 receipt에 기록 | 같은 builder: 680–755 |
+| 현재 S2_00 쓰기 root는 `stage2_runs/by-binding/<run_binding_digest>/` | `R/deployment/stage2_code_executor_binding.yml`: 47–66 |
+| localdocs 계약상 허용 도구는 read_binary_doc/write_binary_file | 같은 binding: 47–66. CAS·분산 잠금 기능이 있다는 근거는 없음 |
+| 외부 인자 주입 및 성공 receipt의 task 간 전달에 필요한 backend 구체 API | 현재 확인 범위에서 미확정. 구현 1단계에서 확인해야 함 |
+
+사용자 지정 기존 분석 자료: [Stage_2_00_Analysis_v1.md](../YAML_Prompts/2.%20Stage_2/Stage_2_00_Analysis_v1.md), [Stage_2_00_IO_info.md](../YAML_Prompts/2.%20Stage_2/Stage_2_00_IO_info.md).
+
+## Material Assumptions
+
+1. request는 LLM이 추론하거나 폴더를 scan해서 만드는 값이 아니다. host가 확정한 네 값과 코드상 두 상수로 생성한다.
+2. task 프로세스·임시 디렉터리·메모리는 서로 공유된다고 가정하지 않는다. backend가 인증된 실행 context와 선행 receipt를 후행 task에 전달해야 한다.
+3. `wait_until`은 실행 순서를 기술하지만, 실패한 선행 task의 후속 실행까지 자동 차단한다는 보장은 별도로 검증한다.
+4. 파일 읽기→없으면 lock 파일 쓰기는 원자적 잠금이 아니다. read-back·hash 비교도 상호 배제를 대신하지 않는다.
+5. 권고 기본안은 **host가 같은 user/workspace의 전체 S2_00 실행을 직렬화**하는 것이다. 최소 요구 구간인 request 저장 전부터 hydration 완료까지보다 길게 잠금을 유지하여, 초기 구현에서 중간 해제 프로토콜을 추가하지 않는다.
+
+## Questions That Could Change the Outcome
+
+구현 착수 시 아래를 backend 문서·코드·시험으로 먼저 확인한다. 답을 추측해 YAML 문법이나 도구 기능을 만들지 않는다.
+
+| 확인 사항 | 결정 기준·미지원 시 처리 |
+|---|---|
+| 외부 structured 인자 전달 방식 | 실제 지원하는 executor 입력 채널 사용. 고정된 템플릿 문법·미지원 run_code parameter를 임의 추가하지 않음 |
+| 선행 stdout receipt를 후행 입력으로 전달하는 방식 | backend가 실행 identity에 결속해 전달해야 함. 동일 고정 파일에 별도 receipt를 쓴다는 방식만으로 신뢰 경계를 대신하지 않음 |
+| task 성공 판정 | transport 성공뿐 아니라 exit code·receipt schema·ok·실행 ID 일치 확인 가능해야 함 |
+| workspace 직렬화와 취소·worker 종료 보장 | 여러 backend worker에 걸친 전역 보장 필요. 한 프로세스의 mutex만 있으면 불충분 |
+| 저장 권한 강제 | prepare에 정확한 request 경로만 쓰기 허용; ingress 결과 쓰기 권한과 분리 가능한지 확인 |
+
+미지원 항목이 있으면 해당 backend 기능을 선행 구현 대상으로 기록한다. 로컬/mock 작업은 계속할 수 있으나 backend 증거 없이 live-ready로 표시하지 않는다.
+
+## Workstreams and Dependencies
+
+### 1. 기준선 및 변경 영향 확정
+
+- 관련 authoring·배포 YAML, runtime mirror, workflow, schema, binding, builder·tests의 hash와 Git 변경 상태를 기록한다. 기존 사용자 변경은 보존한다.
+- 문자열뿐 아니라 task ID·code pointer·code hash를 참조하는 소비자를 찾아 변경 목록을 닫는다.
+- 기존 검사 결과를 기준선으로 기록하여 이번 변경의 회귀와 기존 실패를 구분한다.
+- 위 backend 확인 사항을 검증하고 실제 인자·receipt 주입 방식 및 잠금 구현 위치를 확정한다.
+
+완료 기준: 정확한 변경 파일 목록, backend 연동 계약, 기존 실패 목록이 기록되어야 한다.
+
+### 2. 외부 인자 및 request 계약 확정
+
+request 출력은 다음 6필드로 고정한다.
+
+| 필드 | 공급자·형식 | 검증 |
+|---|---|---|
+| `schema_version` | prepare 코드 상수 | `stage2_s2_00_execution_request.v1` |
+| `workflow_id` | prepare 코드 상수 | `S2_00` |
+| `request_id` | host 문자열 | `[A-Za-z0-9][A-Za-z0-9._-]{0,127}` |
+| `attempt_id` | host 문자열 | 위와 동일. 재시도 정책에 따라 새 시도 식별자 부여 |
+| `stage1_run_root_ref` | host 문자열 | W 아래 승인된 Stage 1 사건 root에 결속한 canonical 상대경로 |
+| `stage1_deployment_root_ref` | host 문자열 | W 아래 승인된 Stage 1 배포 root에 결속한 canonical 상대경로 |
+
+- 누락·추가 필드, 빈 값, 잘못된 타입, absolute path, `..`, 역슬래시, NUL, 비정규 NFC 경로 등을 거절한다. 기존 `_inline_relative_path`와 검증 의미를 맞춘다.
+- 문법적으로 올바른 경로라는 사실과 해당 실행이 접근할 권한이 있다는 사실을 구별한다. host가 승인한 user/workspace 및 Stage 1 완료 실행과 두 root를 결속한다.
+- request 값은 다른 업무 run에서 남은 파일, 작업 디렉터리 추측, LLM 판단으로 채우지 않는다.
+- user/workspace·host execution ID·lock ownership·준비 receipt는 별도의 실행 envelope에 담는다. 기존 request JSON에 7번째 필드를 추가하지 않는다.
+- structured 전달을 우선한다. 코드 템플릿에 전달해야 하는 환경이라면 검증된 직렬화·안전한 encoding을 사용하고, 입력 문자열을 Python source에 직접 삽입하지 않는다.
+
+완료 기준: 허용·거절 예제와 인자 전달 계약이 양쪽 task 및 backend 검증에서 일치한다.
+
+### 3. host 직렬화 및 실패 수명 구현
+
+잠금 key는 인증된 `(user, workspace, S2_00 request 고정 경로)`로 정한다. 서로 다른 request_id라도 동일 workspace의 고정 파일을 공유하면 같은 key를 사용한다.
+
+```text
+host admission → workspace 실행 소유권 획득
+  → prepare 시작 → request 저장/read-back
+  → 성공 receipt를 동일 실행 ingress에 전달
+  → ingress request 1차/2차 읽기 → temp hydration
+  → core 실행·원격 출력 발행 → 종료/취소 정리
+  → 두 task와 미완료 I/O의 종료 확인 → 소유권 해제
+```
+
+- 기본안은 전체 S2_00 종료까지 직렬화한다. 따라서 최소 보호 구간인 hydration 완료까지는 확실히 포함된다.
+- prepare에서 획득한 프로세스 로컬 lock을 task 종료 때 해제하는 구조는 금지한다. 소유권은 host 실행 전체에 귀속된다.
+- 모든 request writer와 재시도 경로가 같은 통제에 참여해야 한다. 통제 밖 writer는 권한으로 차단한다.
+- timeout·취소·host 재시작 시 오래된 worker와 진행 중 쓰기가 끝났는지 확인한 후 다음 실행을 허용한다. TTL 만료만으로 새 소유자를 실행하지 않는다.
+- lease 방식이 불가피하다면 stale owner의 쓰기/읽기를 실제로 거절하는 fencing 또는 동등한 host 보장을 구현한다. JSON에 token만 넣는 것은 fencing이 아니다.
+- 이후 성능 최적화로 hydration 직후 해제하려면 authenticated hydration-complete 신호, 이후 request 재읽기 없음, 원본 Stage 1 run의 불변성 등을 별도 입증한다. 초기 버전에는 적용하지 않는다.
+
+완료 기준: 두 host worker의 경쟁·지연·취소 시험에서도 request 교차 소비가 없어야 한다.
+
+### 4. 선행 task 구현
+
+신규 task ID: `Task_S2_00_prepare_request`.
+
+1. 인증된 host envelope, 실행 소유권, 네 외부 인자를 검증한다.
+2. 고정 두 상수를 추가하여 6필드 request 객체를 만든다.
+3. strict JSON/schema 및 경로·ID 검증을 수행한다. schema 자산을 읽는 경우 release/module manifest의 hash 결속된 정확한 closure를 사용한다.
+4. 기존 canonical JSON 규칙(UTF-8, 정렬 key, 고정 구분자, NaN 금지, 종료 newline)으로 직렬화하고 raw SHA-256을 계산한다.
+5. 소유권을 유지한 상태에서 `W/stage2_control/s2_00_request.json`에 binary write를 수행한다. 현재 계약에 없는 원격 rename·원자적 파일 교체 기능을 가정하지 않는다.
+6. 같은 경로를 binary read-back하여 bytes가 동일한지 확인하고, 다시 parse/schema 검증한다.
+7. 성공일 때만 stdout 준비 receipt를 반환한다. 권고 schema는 신규 `stage2_s2_00_prepare_request_receipt.v1`이며 `ok`, request path/hash/byte length, request_id/attempt_id, host execution binding을 포함한다. 이것은 **신규 설계**이며 기존 파일이라고 표현하지 않는다.
+8. 오류·write 응답 유실·read-back 불일치·close 실패 등은 성공 receipt로 취급하지 않는다. ingress는 실행하지 않는다. 부분 파일이 남아 있어도 성공한 것으로 간주하지 않는다.
+
+동일 시도 재실행은 같은 bytes 및 host identity가 확인되면 재사용 가능하다. 새 시도/다른 request로 교체할 때에는 이전 실행 종료 및 새 소유권이 먼저 확인되어야 한다. 성공 후 무조건 request를 삭제하는 정리 코드는 두지 않는다.
+
+완료 기준: 실제 저장 bytes와 receipt hash가 일치하고, 모든 실패 경로가 후행 실행을 차단한다.
+
+### 5. ingress 결속 및 DAG 변경
+
+```text
+IN
+ → Task_S2_00_prepare_request
+ → [host: exit=0 + 유효한 ok:true receipt + 동일 실행 binding 확인]
+ → Task_S2_00_deterministic_ingress
+ → OUT
+```
+
+- YAML `task_procedure`에 prepare의 `wait_until: [IN]`, ingress의 `wait_until: [Task_S2_00_prepare_request]`를 설정하고 nexts를 대응시킨다. stage prevs/nexts는 기존 독립 stage 구조를 유지한다.
+- host의 success-only 조건은 YAML edge와 별도로 계약 및 시험에 포함한다. 실패한 prepare가 '완료'되었다는 이유로 ingress를 시작하지 않는다.
+- ingress는 host가 제공한 준비 receipt가 없거나 잘못되면 시작을 거절한다. 최초 request bytes와 expected hash, request_id/attempt_id를 대조한다.
+- 기존 두 read-pass의 동등성 검사를 유지한다. 두 번째 request bytes도 준비 receipt hash와 일치해야 한다. 동일하게 바뀐 다른 request를 두 번 읽어 통과하는 상황까지 차단한다.
+- 신뢰할 수 없는 stale receipt·다른 workspace receipt·다른 attempt의 receipt를 거절한다.
+- 기존 C00–C15, output barrier·route 계약은 유지한다. wrapper 실패와 core diagnostic 분기를 혼동하지 않는다.
+
+완료 기준: prepare와 ingress가 같은 request를 사용했다는 검증 가능한 연결이 생긴다.
+
+### 6. authoring·빌드·배포 계약 갱신
+
+| 파일·영역 | 작업 |
+|---|---|
+| `M/Stage_2_S2_00_v.2.yml` | authoring 정본에서 2-task 구조·설명·version·inline source 갱신 |
+| `R/agent_scripts/Stage_2_S2_00.yml` | 수정한 builder로 배포본 생성. 배포본만 수작업 수정하지 않음 |
+| `R/offline_build/build_s2_00_inline_projection.py/.txt` | '정확히 1개' 검증을 **정확히 두 개의 지정 task와 지정 순서**로 변경; 추가 임의 task는 거절 |
+| 같은 builder의 code 검사 | 공통 보안·endpoint·import 검사는 유지; ingress 전용 token과 prepare 전용 token을 분리 |
+| `R/runtime/s2_00_ingress.py/.txt` | ingress task code의 파생 mirror로 유지 |
+| 신규 `R/runtime/s2_00_prepare_request.py/.txt` | prepare code의 파생 mirror 제안. 두 task를 결합한 실행 파일로 만들지 않음 |
+| `R/manifest/s2_00_inline_code_receipt.json` | task별 code pointer·hash·mirror, 전체 task semantics hash로 확장; schema version/소비자 동시 갱신 |
+| `R/workflows/S2_00_stage1_ingress_normalize_and_bundle_compile.yml` | 선행 단계, 외부 인자, receipt·success gate·직렬화 계약 반영 |
+| `R/deployment/stage2_code_executor_binding.yml` | task별 executor 및 권한: prepare는 request 고정 경로, ingress는 기존 결과 root. schema/release 읽기 경로도 task별 명시 |
+| `R/schemas/ingress.schema.json` | 기존 6필드 execution_request 유지, 신규 prepare/envelope receipt 검증 정의 |
+| `R/schemas/deployment.schema.json` 및 관련 schema | 두 task·task별 code binding·receipt 계약과 실제 소비자 호환성 반영 |
+| `R/manifest/module_manifest.json`, `stage2_release.json`, release validator | 변경 자산의 등록·hash와 추가된 계약 검증 반영 |
+| `M/Stage_2_00_Analysis_v1.md`, `Stage_2_00_IO_info.md` | 구현 완료 후 실제 구조·IO·검증 상태로 개정 |
+
+`task index=0`에 ingress가 있다고 가정하는 코드를 모두 확인한다. task_name으로 추출하고 receipt에는 실제 YAML pointer도 남긴다. version 값은 관련 schema와 소비자 호환성을 확인해 함께 올린다.
+
+### 7. hash 재결속 및 패키지 확정
+
+- 변경 자산 → module/release → inline release pin → authoring projection/mirror/receipt → executor binding/detached admission의 실제 참조 그래프를 먼저 만든다.
+- 현재 builder는 projection 이후 binding 재결속을 전제로 한다. 기존 detached 설계를 유지하고, parent release에 자신을 포함한 code hash를 되먹이는 순환 의존을 새로 만들지 않는다.
+- 참조 그래프의 위상 순서대로 재생성한다. 순환이 발견되면 hash를 반복 덮어쓰는 대신 detached boundary를 설계·검증한다.
+- 현재 `expected_release_sha256`, task별 code hash, Agent raw hash, workflow/schema/module hash와 receipt pointer를 함께 대조한다.
+- 재생성 뒤 빌더 `--check`, release validator, mirror parity를 실행한다. 두 번째 빌드에서 bytes 차이가 없어야 한다.
+- 테스트용 release와 실제 배포 release를 분리한다. DEV guard를 삭제하거나 production 표기를 붙여 검사를 통과시키지 않는다.
+
+완료 기준: 참조된 변경 자산의 hash가 모두 일치하고, 반복 빌드가 추가 변경을 만들지 않는다.
+
+## Source and Tool Plan
+
+로컬 authoring·builder·runtime·tests를 우선 읽는다. backend 관련 문서·코드는 필요한 범위에서 확인하고 지원 여부를 증거로 남긴다. 신규 의존성 설치나 서비스 호출은 이 계획 작성에 포함하지 않는다. 구현 시 기존 도구·검증 runner를 확인해 사용하고, 라이브 시험은 별도 격리 workspace와 비실사건 fixture로 수행한다.
+
+## Validation Plan
+
+| 시험 | 통과 기준 |
+|---|---|
+| 유효한 인자 | request 정확히 6필드, canonical bytes/hash/read-back 일치 |
+| 누락·추가·타입·ID·경로 오류 | 저장 전 거절, ingress 호출 0회 |
+| 권한 밖 경로·다른 workspace | host 결속 검증 실패, 업무 입력 읽기 불가 |
+| 저장 실패·응답 유실·read-back mismatch | 성공 receipt 없음, ingress 호출 0회 |
+| 선행 task exit 0이나 ok:false/깨진 receipt | host가 후행 task를 실행하지 않음 |
+| 준비 후 request 변조 | 첫 읽기 expected hash 검증 또는 두 pass 비교에서 거절 |
+| 두 pass 모두 동일한 타 요청으로 교체 | 준비 receipt hash/identity 검증에서 거절 |
+| 같은 workspace 두 요청·두 worker | 단일 소유자만 진입, 다른 요청 bytes를 소비하지 않음 |
+| 다른 workspace 병렬 실행 | 불필요한 전역 직렬화 없이 독립 진행 |
+| cancel·timeout·host crash·오래된 worker 재개 | 이전 쓰기 가능성이 사라지기 전 새 owner 쓰기 금지; stale owner 차단 |
+| 동일 시도 retry / 새 attempt | 정의한 재사용/교체 정책 준수, 기존 output idempotency 계약 유지 |
+| task shape / builder | 지정 두 task와 순서만 허용; task 누락·추가·우회 edge 거절 |
+| 두 code mirror·receipt pointer·hash | authoring에서 추출한 bytes와 정확히 일치 |
+| 기존 core 정상·diagnostic 회귀 | fixture 기준 11+E/5 출력 및 barrier 계약 보존 |
+| 실제 backend 통합 | 인자 주입·receipt 전달·failure gate·workspace 격리를 실제 환경에서 확인 |
+
+mock 통과는 실제 host 잠금·권한 강제 증거가 아니다. `STATIC_PASS`, `OFFLINE_TEST_PASS`, `BACKEND_INTEGRATION_PASS`, `LIVE_ADMISSION_PENDING`을 구분해 보고한다. 현재 DEV release로 정상 core 성공을 주장하지 않는다.
+
+## Approval Boundaries
+
+현재 요청은 작업 계획 작성이다. 이 단계에서는 계획 문서만 생성한다. 이후 구현 요청 시 범위 내 로컬 수정·시험을 수행하고, 실제 서비스 배포·외부 쓰기·live activation은 그때의 승인 범위를 확인한다. backend 기능 미지원은 기술적 미완료 조건으로 기록하며 이를 단순 승인 문제로 대체하지 않는다.
+
+## Progress
+
+- [x] 현재 단일 task·request read·builder 제약 확인
+- [x] 현재 write root와 localdocs 도구 계약 확인
+- [x] 작업 순서·의존성·동시 실행·검증 계획 작성
+- [ ] backend 전달·직렬화 기능 확인 및 연동 방식 확정
+- [ ] schema·prepare·ingress·DAG 구현
+- [ ] builder·binding·hash 재결속
+- [ ] offline·동시 실행·backend 통합 검증
+- [ ] 분석·IO 문서 갱신 및 배포 적격성 판정
+
+## Decision Log
+
+| 날짜 | 결정 | 근거 | 결과 |
+|---|---|---|---|
+| 2026-09-30 | request의 기존 6필드 유지 | 현재 strict validator와 사용자 요구 | 실행 보조 정보는 host envelope로 분리 |
+| 2026-09-30 | 첫 버전은 전체 S2_00 host 직렬화 | 두 독립 task 사이 lock 수명 및 고정 request 경로 | hydration 완료 전 해제 위험과 중간 callback 의존 감소 |
+| 2026-09-30 | 준비 receipt hash를 ingress에 전달 | 두 read-pass 비교만으로 다른 요청 교체를 모두 검출할 수 없음 | 소비할 request를 선행 실행에 결속 |
+| 2026-09-30 | authoring부터 재생성 | builder가 정본 및 mirror parity를 관리 | 배포 YAML 단독 변경 방지 |
+
+## Evidence Ledger
+
+| 명제 | 확인 근거 | 상태 |
+|---|---|---|
+| 기존 builder는 두 task를 거절한다 | extract_run_code_task의 EXACTLY_ONE_TASK_REQUIRED·EXACTLY_ONE_RUN_CODE_REQUIRED | 확인 |
+| 현재 request 저장은 쓰기 허용 root 밖이다 | S2_00 binding의 write_root_rule | 계약에서 확인; live 강제 여부는 미확인 |
+| localdocs 원자적 lock/CAS 지원 | 현재 allowlist에 read/write만 있음 | 지원 근거 없음, 사용 가능하다고 가정하지 않음 |
+| 선행 task를 현재 backend가 어떻게 인자 결속하는가 | 구체 backend 구현을 아직 확인하지 않음 | 미확정 |
+| request writer의 생성 필요 | 현재 소비 코드 및 이전 폴더 전체 검색 결과 | 현 패키지에 실사용 writer 없음 |
+
+## Risks and Failure Modes
+
+- YAML만 바꾸면 builder·code pointer·권한·hash 계약에서 실패한다.
+- `wait_until`만 추가하면 prepare 실패 후 ingress가 진행될 수 있다.
+- 고정 request 파일에 write/read-back만 구현하면 동시 요청이 서로 덮어쓸 수 있다.
+- lock TTL 이후 오래된 writer가 살아 있으면 새 요청을 오염시킬 수 있다.
+- 기존 release 제한을 이번 변경의 실패로 혼동하거나, 이를 제거해 정상 실행을 과장할 수 있다.
+- 다른 request가 같은 run binding으로 귀결될 때 기존 status bytes 일치 요건은 여전히 적용된다. 기존 출력 충돌을 자동 덮어쓰기로 해소하지 않는다.
+
+롤백은 두 task 실행을 먼저 정지하고 진행 중 I/O 종료를 확인한 뒤, authoring·배포본·mirror·schema·binding·receipt를 검증된 동일 버전 묶음으로 복원한다. 이전 버전도 외부 request 공급 없이는 실행되지 않으므로 롤백 자체를 서비스 정상화로 보지 않는다. 사건 입력·이미 발행된 결과는 일괄 삭제하지 않는다.
+
+## Results and Residual Uncertainty
+
+계획은 작성 완료하였고, 구현은 미착수다. 가장 중요한 미확정 항목은 backend의 structured 인자/receipt 전달과 workspace 단위 직렬화·worker 종료 통제이다. 이 기능이 확인되거나 구현되어야 안전한 2-task 실행이 완성된다. 완료 판정은 request 생성 성공뿐 아니라 **동일 요청의 후행 소비, 실패 시 차단, 동시 실행 안전성, 빌드·hash 일치**를 모두 통과하는 것으로 한다. 실제 backend 시험 전에는 live-ready로 판정하지 않는다.

Case_02_Comparison_Research/plans/s2-00-request-preparation_v1.md

@@ -0,0 +1,206 @@
+# S2_00 request 준비 계획 v1 — 필수 조건을 유지한 단순화
+
+작성일: 2026-09-30. 상태: **분석·계획 작성 완료 / 구현 미착수**.
+원본: [s2-00-request-preparation.md](s2-00-request-preparation.md). 원본은 보존한다.
+
+## 1. Occam's Razor 분석
+
+**기존 계획은 안전성에 필요한 항목과 선택적인 구현을 함께 필수화하여, 가장 단순한 계획이라고 보기는 어렵다.** 같은 요구를 충족하면서 새 프로토콜·검증 중복·변경 범위를 줄일 수 있다. 다만 backend 기능이 미확정이므로 '절대적으로 가장 효율적'이라고 단정하지 않고, 확인된 코드와 사용자 제약 아래의 권고안을 제시한다. 여기서 효율성은 우선 구현·검증·유지보수 비용이며, 실행시간 개선 수치는 측정하지 않았다.
+
+### 1.1 제약을 지키는 단순화와 구조 변경의 구분
+
+| 대안 | 장점·비용 | 판단 |
+|---|---|---|
+| 원본의 독립 2-task + 준비 receipt 전달 | 별도 receipt schema·실행 envelope·후행 전달·task별 검증 필요 | 요청 identity 확인은 타당하지만 구체 수단을 줄일 수 있음 |
+| **2-task + 동일한 불변 host 인자 공급** | 두 task가 같은 값으로 request를 재구성; 별도 준비 receipt 전달 불필요. 2-task 빌드 변경은 여전히 필요 | **v1 채택**: 기존 '선행 task 신설' 요구 유지 |
+| 기존 단일 task 맨 앞의 준비 함수 | task 간 전달·실패 gate·2-task builder 변경을 제거할 수 있어 구조적으로 더 단순 | 독립 선행 task 요구를 완화하는 대안. v1에 몰래 적용하지 않음 |
+| 외부 host에서 request 생성 | YAML 구조 변경이 작음 | 'YAML 맨 앞의 선행 task' 요구와 다르므로 기본안 제외 |
+
+v1은 요청 목적을 바꾸지 않고 독립 선행 task를 유지한다. 단일 task 내부 함수 방식은 추가 구조를 가장 크게 줄이지만, 기존에 명시한 두-task 조건과 구별해야 한다.
+
+### 1.2 줄일 수 있는 항목과 유지할 항목
+
+| 원본 계획 | v1 결정 | 이유·적용 조건 |
+|---|---|---|
+| 신규 prepare receipt schema와 host→ingress receipt 전달 | **제거**. host가 확정한 동일 네 인자를 두 task에 제공하고 ingress가 expected bytes를 재구성 | 별도 파생 자료를 전달하지 않아도 요청 일치 검증 가능. host 인자는 실행 중 불변이어야 함 |
+| 새로운 execution envelope·lock token을 task마다 검증 | **별도 형식 신설 안 함**. 기존 인증된 실행 context와 host 직렬화 사용 | 기존 기능의 실제 지원 여부부터 확인. 없는 기능을 있다고 가정하지 않음 |
+| 검증한 bytes를 write/read-back한 뒤 동일 bytes를 다시 parse/schema 검사 | **반복 검사 제거** | 처음 검증한 canonical bytes와 read-back bytes의 완전 일치가 확인되면 같은 내용을 다시 검증할 필요 없음 |
+| 선행 단계에서 schema/release closure 별도 hydration | **기본안에서 제외** | 이미 존재하는 폐쇄형 request validator와 schema의 일치를 offline test로 확인. ingress의 기존 release 검증은 유지 |
+| 신규 분산 lock·lease·fencing 체계 가능성까지 초기 구현에 포함 | **기존 host 직렬화 재사용 우선**, 별도 체계는 실제 미지원일 때만 재설계 | 잠금 안전성은 필수이나 새 잠금 서비스를 만드는 것이 필수는 아님 |
+| 동일 attempt 재사용 최적화 | **초기 제외**. 소유권 획득 후 전체 준비 작업 재실행 | 작은 JSON의 재쓰기보다 별도 재사용 분기의 관리 비용이 클 수 있음. 기존 결과 idempotency는 유지 |
+| schema·manifest 전체 개정 | **실제 구조·hash 참조가 바뀌는 항목만 갱신** | 파일을 더 적게 수정하려고 필요한 hash/권한 갱신을 생략하지 않음 |
+| 정확히 2 task·순서 및 두 code hash 검증 | **유지** | 현 builder가 1 task를 강제하므로 피할 수 없는 변경 |
+| 저장 실패 시 차단·request 2회 읽기·host 직렬화 | **유지** | 요구된 실행 안전성. bytes 비교는 상호 배제를 대신하지 않음 |
+
+특히 runtime의 `write_binary_verified()`에는 이미 write 후 read-back bytes 비교가 있다. 같은 일을 하는 새 IO 계층을 만들 필요가 없다. `_inline_validate_request()`도 이미 정확히 6필드·ID·경로 검증을 수행한다. 근거는 아래 Evidence Ledger에 기록한다.
+
+## Objective
+
+`IN → Task_S2_00_prepare_request → Task_S2_00_deterministic_ingress → OUT`을 구현하되, 새 준비 receipt 전달 프로토콜 없이 동일한 외부 인자와 기존 검증·IO 기능으로 request 생성 및 소비를 연결한다.
+
+## Deliverables
+
+- 기존 authoring을 정본으로 하는 2-task YAML·파생 배포본 및 필요한 code mirror/빌드 receipt 변경.
+- 최소 준비 함수, ingress의 expected request bytes 대조, 외부 인자·직렬화·success-only 계약.
+- 실제 변경된 binding·schema·manifest/hash, 관련 시험 및 분석·IO 문서 개정.
+
+## Scope and Non-Scope
+
+request의 6필드·고정 경로와 기존 ingress의 C00–C15·출력 계약을 유지한다. 신규 receipt 파일·범용 workflow framework·독립 lock 서비스·release 전체 재설계는 기본 범위에 넣지 않는다. 기존 DEV release 제한과 core 결함 수정은 별개다. 이 문서는 구현 계획이며 실행 자산을 변경하지 않는다.
+
+## Known Inputs
+
+`M = Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/`, `R = M/Default_Agent/Stage_2_Clean/`, `W = 인증된 localdocs workspace`.
+
+현재 authoring은 `M/Stage_2_S2_00_v.2.yml`, 배포본은 `R/agent_scripts/Stage_2_S2_00.yml`이다. 빌더는 1 task·1 code pointer를 전제로 하고, S2_00 binding은 결과 root만 쓰기 허용한다. request writer를 추가하려면 이 두 계약 변경은 불가피하다. backend의 실제 인자 전달·직렬화 구현은 **UNVERIFIED**다.
+
+## Material Assumptions
+
+- host가 권한을 확인한 네 인자를 실행 시작 때 확정하고 두 task에 동일하게 공급할 수 있어야 한다. YAML 문법·환경변수 이름·run_code parameter를 임의로 발명하지 않는다.
+- 같은 `(user, workspace)`의 S2_00 실행은 host가 전역 직렬화한다. 단일 worker의 로컬 mutex만으로 다중 worker 안전성을 주장하지 않는다.
+- task 간 메모리 공유는 가정하지 않는다. request bytes는 각 task가 동일한 규칙으로 재구성한다.
+- 동일한 bytes의 request가 남아 있다는 사실만으로 prepare 성공을 대신하지 않는다. 현재 host 실행에서 prepare 성공 판정이 먼저 있어야 한다.
+
+## Questions That Could Change the Outcome
+
+구현 전에 **세 가지**만 먼저 확인한다: ① 동일 불변 인자를 두 task에 공급하는 실제 방식, ② exit code와 task 결과에 따른 success-only 후행 실행, ③ 취소·worker 장애·진행 중 I/O까지 포함한 workspace 직렬화. 세 조건이 지원되면 아래 최소안을 진행한다. 미지원이면 필요한 backend 보강을 명시하며, receipt나 lock 파일을 추가하는 것으로 문제가 해결되었다고 간주하지 않는다. 기존 지원만으로 가능하다는 현재의 실증 근거는 없다.
+
+## Workstreams and Dependencies
+
+### 1단계 — 외부 입력과 host 경계 확정
+
+외부에서 공급하는 값은 다음 네 문자열이다.
+
+| 필드 | 검증 |
+|---|---|
+| `request_id` | `[A-Za-z0-9][A-Za-z0-9._-]{0,127}` |
+| `attempt_id` | 위와 동일; host 재시도 정책으로 결정 |
+| `stage1_run_root_ref` | W 아래 승인된 Stage 1 사건 root의 NFC canonical 상대경로 |
+| `stage1_deployment_root_ref` | W 아래 승인된 Stage 1 배포 root의 NFC canonical 상대경로 |
+
+준비 task가 `schema_version=stage2_s2_00_execution_request.v1`, `workflow_id=S2_00`을 추가하여 정확히 6필드를 만든다. 누락·추가 외부 키와 잘못된 타입을 거절한다. 기존 path validator로 absolute path·`..`·역슬래시·NUL·비정규 경로를 거절하고, 접근 권한과 Stage 1 run 선택은 host가 결속한다. shell/Python source에 원문 인자를 직접 삽입하지 않는다.
+
+host는 준비 task 시작 전 실행 소유권을 획득하여 **S2_00 전체 종료 및 미완료 I/O 종료까지** 유지한다. 이는 hydration 완료까지의 최소 보호 요구를 충족한다. 중간 해제 callback은 추가하지 않는다. 모든 writer·retry가 같은 통제에 참여해야 하며, 종료 여부가 불명확한 경우 다음 실행을 보류한다. TTL 만료만으로 takeover하지 않는다. host에 이 보장이 없으면 live-ready로 판정하지 않는다.
+
+### 2단계 — 최소 준비 함수와 ingress 비교 구현
+
+아래는 의미를 설명하는 pseudocode이며 현재 실행 가능한 API가 아니다.
+
+```python
+# 양쪽 task에 host가 동일하게 공급한 네 값
+expected = build_request(immutable_host_args)  # 두 상수 추가, 정확한 외부 키 확인
+expected_raw = canonical_json_bytes(expected)
+_inline_validate_request(expected_raw)
+
+# prepare task: 인증된 localdocs 세션 및 host 실행 소유권 아래 수행
+localdocs.write_binary_verified(INLINE_REQUEST_PATH, expected_raw)
+# 세션 종료까지 성공한 후 task 성공을 반환한다.
+
+# ingress task: 현재 실행의 host_args로 expected_raw를 독립 재구성
+actual_raw = localdocs.read_binary(INLINE_REQUEST_PATH)  # 기존 첫 읽기에 통합
+if actual_raw != expected_raw:
+    raise IngressError("RUN_REQUEST_INPUT_MISMATCH", "request differs from host input")
+# 이후 기존 strict validation 및 2회 읽기/hydration을 계속한다.
+```
+
+- `build_request`는 네 값에 두 상수를 추가하는 작은 함수로 제한한다. 별도의 범용 serializer나 validator framework를 만들지 않는다.
+- prepare는 기존 validator·canonical serializer·MCP IO helper의 동작을 재사용한다. 두 독립 inline payload에 필요한 helper는 authoring/build 시 포함한다. 외부 `.py` runtime import나 ingress 전체 실행 코드를 복제해 실행하는 방식은 피한다. 중복 포함된 helper의 일치는 좁은 parity 검사로 확인하며 새 공통 모듈 배포 체계까지 만들지 않는다.
+- `write_binary_verified`가 bytes 일치를 확인하므로 추가 read-back/parse를 중복 수행하지 않는다. task 성공 결과에는 backend가 요구하는 최소 `ok`/error만 사용하며 새 버전 receipt schema·추가 파일은 만들지 않는다.
+- ingress의 expected bytes 검사는 기존 첫 request 읽기에 결합한다. 이미 첫 읽기가 expected와 같고 두 번째가 첫 번째와 같은지 검사하므로 두 번째에서 동일한 expected hash를 다시 계산할 필요는 없다.
+- 이 대조는 request ID만이 아니라 여섯 필드 전체를 확인한다. 서로 다른 요청으로 두 pass 모두 교체되더라도 거절한다. 다만 상호 배제는 여전히 host 책임이다.
+- 실패 시 준비 작업 전체를 다시 실행한다. 남아 있는 파일을 신뢰해 ingress만 우회 실행하지 않는다. 정리 목적으로 request를 무조건 삭제하지 않는다.
+
+### 3단계 — 두 task의 실행 순서와 실패 차단
+
+```text
+host: 동일 workspace 실행 소유권 확보, 네 인자 확정
+  → IN
+  → prepare: 검증 → 저장/read-back → 세션 종료 → 성공
+  → host: 현재 실행의 prepare 성공일 때만 ingress 시작
+  → ingress: expected bytes 일치 → 기존 2회 읽기/hydration → 기존 core/발행
+  → OUT 또는 실패 정리
+  → host: task와 미완료 I/O 종료 확인 후 소유권 해제
+```
+
+YAML의 nexts/wait_until은 위 순서를 정확히 기술한다. transport 응답 성공만으로 업무 성공을 판정하지 않는다. exit code 및 backend가 해석하는 task 결과에서 실패·잘못된 결과·timeout이면 ingress를 호출하지 않는다. 후행에 준비 receipt를 전달할 필요는 없지만, host의 task 성공 판정 자체는 생략할 수 없다. 직접 ingress 호출은 host admission으로 차단한다.
+
+### 4단계 — 실제 영향 범위만 빌드·배포 갱신
+
+| 항목 | 최소 변경 |
+|---|---|
+| `M/Stage_2_S2_00_v.2.yml` | prepare task와 지정 DAG, ingress expected bytes 검사 추가 |
+| `R/offline_build/build_s2_00_inline_projection.py/.txt` | 정확히 두 task를 ID로 추출·검증. 0번 task가 ingress라는 가정 제거. 공통 코드 검사와 task별 필수 검사 분리 |
+| `R/agent_scripts/Stage_2_S2_00.yml`, runtime mirror, `R/manifest/s2_00_inline_code_receipt.json` | 기존 파생 절차로 재생성. 두 code pointer/hash를 결속. 별도 runtime 준비 receipt와 혼동하지 않음 |
+| prepare code mirror | 기존 mirror 정책을 유지하는 데 필요한 `runtime/s2_00_prepare_request.py/.txt`만 파생 생성. 새로운 독립 서비스는 아님 |
+| workflow 및 executor binding | 외부 네 인자, success-only, 직렬화 책임과 prepare의 정확한 request 쓰기 경로 추가. ingress의 결과 root 쓰기 범위 유지 |
+| 관련 schema | 2-task binding/빌드 receipt 표현이 바뀌어 기존 schema와 충돌하는 부분만 수정. 기존 execution_request의 6필드 schema는 유지 |
+| module/release·code pin·Agent/workflow hash | 실제 변경 자산 및 이를 참조하는 hash만 재결속. 순환 결속을 새로 만들지 않고 기존 detached 절차 유지 |
+| 기존 분석서·IO 문서 | 구현 완료 후 실제 두-task 구조, 인자 및 request 저장 시점을 반영 |
+
+스키마를 안 바꾼다는 이유로 필요한 code hash를 누락하거나, 단순화를 이유로 기존 검증기를 무력화하지 않는다. 두 task 구성이 요구되는 한 builder·mirror·권한·hash 비용은 남는다. 별도의 준비 receipt schema와 전달 소비자만 제거하는 것이다. 빌드 재실행 시 동일 bytes인지 확인한다.
+
+### 5단계 — 필요한 시험과 완료 판정
+
+아래 Validation Plan을 실행하여 기준선에 있던 실패와 이번 변경의 회귀를 구분한다. host 지원 여부가 불확실하면 offline 구현·시험과 실제 운영 적격성을 별도로 보고한다. DEV guard를 해제해서 성공 결과를 만들지 않는다.
+
+## Source and Tool Plan
+
+원본 계획, 현재 authoring/runtime/builder/binding을 우선 근거로 삼는다. 외부 제품 권고나 일반론이 아닌 로컬 코드의 중복·의존성을 분석한다. 구현 시 backend 코드·문서로 세 선행 조건을 확인하고 기존 테스트 runner 및 빌드 `--check`를 사용한다. 실제 backend 통합 시험은 격리된 fixture 환경에서 수행한다.
+
+## Validation Plan
+
+| 시험 묶음 | 통과 기준 |
+|---|---|
+| 정상·잘못된 외부 입력 | 정상은 정확한 6필드 canonical bytes; 누락/추가/ID/path/type 오류는 저장 전 거절. 기존 request schema와 validator 수용 범위 일치 |
+| 저장·read-back·종료 실패 | 후행 ingress 호출 0회. `ok:false`·비정상 exit·잘못된 성공 결과도 차단 |
+| request 교체·잘못된 host 입력 결속 | 첫 읽기의 전체 bytes 대조 및 기존 두 pass 비교로 거절. stale request·다른 attempt·다른 roots 포함 |
+| 경쟁·취소·재시도 | 같은 workspace의 두 worker는 직렬 실행; 이전 writer/I/O가 남은 동안 다음 실행 금지. 다른 workspace는 독립 실행 |
+| 2-task 빌드·회귀 | 지정 두 task/순서만 허용, code/mirror/receipt/hash 일치, 반복 빌드 동일. 기존 정상 11+E/diagnostic 5파일 fixture 계약 유지 |
+| backend 통합 | 동일 불변 인자 공급, success-only 실행, 전역 직렬화·권한 강제가 실제 작동 |
+
+별도 준비 receipt, TTL/fencing 프로토콜, 재사용 최적화를 만들지 않으므로 이들의 전용 시험도 만들지 않는다. 단, worker 장애 이후 교차 쓰기가 없다는 기능 시험은 필수로 남는다. 신규 기능의 fixture 회귀와 실제 MCP/backend 실행 증거를 구분한다.
+
+## Approval Boundaries
+
+이번 요청 범위는 분석과 v1 계획 파일 작성이다. 원본 계획과 실행 자산을 보존한다. 이 문서 작성만으로 구현·배포·live 검증을 수행한 것으로 표현하지 않는다.
+
+## Progress
+
+- [x] 원본 계획과 현재 validator·IO·builder·binding 대조
+- [x] 제약 유지안과 제약 완화 대안 구별
+- [x] 중복 프로토콜·검증·최적화 제거 및 v1 작성
+- [ ] backend 세 조건 확인
+- [ ] 준비 task·ingress·빌드/배포 계약 구현
+- [ ] 회귀·경쟁·backend 통합 검증 및 문서 갱신
+
+## Decision Log
+
+| 결정 | 근거·효과 |
+|---|---|
+| 독립 선행 task 유지 | 앞선 사용자 요구를 바꾸지 않음. 절대 최소 구조와 제약 내 최소안을 구분 |
+| 동일 host 인자로 expected bytes 재구성 | 별도 준비 receipt·schema·전달을 제거하면서 전체 request 일치 검증 유지 |
+| 기존 verified write/validator 재사용 | 현재 존재하는 동작을 새 계층으로 중복 구현하지 않음 |
+| 전체 실행 직렬화 유지 | 중간 해제 신호보다 구현이 단순함. 동일 workspace 처리량 최적화는 이번 목표에서 제외 |
+| 조건부 backend 확인 | 미확정 host 기능을 기정사실로 삼는 것이 가장 큰 숨은 복잡성이므로 먼저 검증 |
+
+## Evidence Ledger
+
+행번호는 2026-09-30 확인본 기준이다. runtime mirror를 구현 대조 자료로 사용했으며 authoring의 정본 지위를 바꾸지 않는다.
+
+| 분석 명제 | 현재 확인 근거 | 판정 |
+|---|---|---|
+| 중복 없는 writer/validator 재사용 가능 | `R/runtime/s2_00_ingress.py`의 `write_binary_verified`(5492행), `_inline_validate_request`(5505행) | write/read-back 및 6필드 검증 존재 확인 |
+| ingress 첫 읽기에 expected 대조 추가 가능 | 같은 runtime `_inline_hydrate`(5712행 이후) | 기존 첫 읽기 및 검증 순서 확인; 변경은 제안 |
+| 2-task 빌드 변경은 생략 불가 | `R/offline_build/build_s2_00_inline_projection.py`: 326–378 | 단일 task·DAG 제약 확인 |
+| 준비 receipt 제거의 전제 | 두 task가 동일한 인증된 불변 host 입력을 받는다는 새 계약 | 설계 제안; backend 실제 지원 UNVERIFIED |
+| request 쓰기 권한 추가 필요 | `R/deployment/stage2_code_executor_binding.yml`: 47–66 | 기존 write root는 결과 폴더 |
+
+## Risks and Failure Modes
+
+직렬화가 실제로 보장되지 않으면 receipt를 제거하든 유지하든 고정 request 경로의 안전한 실행은 완성되지 않는다. task별 입력이 서로 다르거나 조작될 수 있다면 expected bytes 방식의 전제가 무너진다. 이 경우 host 입력 결속을 먼저 수정해야 한다. 인증된 인자·권한·잠금은 JSON을 단순하게 만드는 것과 별개의 필수 조건이다.
+
+실패한 변경의 롤백은 진행 중 실행과 I/O 종료 후 검증된 기존 authoring·배포본·mirror·binding/hash 묶음으로 복원한다. 사건 자료·발행 결과는 삭제하지 않는다. 기존 버전도 request 외부 공급이 필요하므로 롤백이 자동 정상화를 뜻하지 않는다.
+
+## Results and Residual Uncertainty
+
+**기존 계획은 단순화할 수 있다.** v1은 두-task 요구를 유지하면서 신규 준비 receipt/전달 schema·독립 실행 envelope 설계·중복 read-back 검증·불필요한 사전 closure 읽기·재사용 최적화를 기본 범위에서 제거했다. 필수 인자 검증·저장 확인·후행 차단·동일 요청 소비·동시 실행 통제·hash 일치는 유지했다. 이는 코드 근거에 따른 설계 평가이며 성능 벤치마크 결과가 아니다. backend 세 조건의 실제 지원과 구현 완료 여부는 미확정·미착수다.