feat(stage2): use direct Stage 1 handoff in S2_00 v3

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/agent_scripts/stage_2_s2_00_revision_strategy_v1.md

@@ -0,0 +1,260 @@
+# Stage_2_S2_00.yml 개정 전략 v1
+
+작성일: 2026-10-02. 상태: **개정 전략 작성 완료 / YAML·실행 자산 개정 및 live 실행 미수행**.
+
+## 1. 권고안과 개정 범위
+
+**Stage 1의 사건 run root와 배포 root를 S2_00 호출에 직접 전달하고, 유일한 `Task_S2_00_deterministic_ingress`가 입력 검증·hydration·C00–C15·결과 발행을 한 번에 수행하도록 개정한다.** `Task_S2_00_prepare_request`, 고정 `stage2_control/s2_00_request.json` 생성·저장·재읽기, 호출자의 `request_id`·`attempt_id` 부여를 실행 경로에서 제거한다. Stage 1 결과물의 파일명·상대경로·원본 bytes는 그대로 사용한다.
+
+사용자 지시 중 “사건·배포 경로 전달 및 `request_id`·`attempt_id` 부여 방식 폐기”는 **이를 별도의 request 준비 절차로 구성하는 방식을 폐기**한다는 의미로 적용한다. 경로 자체는 직접 인계에 필요한 값이다. ID는 호출자의 필수 입력에서 제거하고, 기존 출력 schema와 downstream 호환에 필요한 내부 값만 S2_00이 처리한다. 출력의 ID 필드까지 전면 삭제하는 것은 본 최소 변경안에 포함하지 않는다.
+
+개정의 성공 기준은 단일 task 실행 자체가 아니라, Stage 1 원본을 읽어 검증한 뒤 기존 정상 또는 진단 산출물과 마지막 status barrier를 정확히 발행하는 것이다. 기존 구현의 의미 인계 공백 때문에 정상 실행이 성립하지 않는 경우에는 해당 Stage 2 adapter·projection만 보완한다.
+
+본 문서는 전략서다. 아래 함수 signature, 입력 객체, ID 결정 규칙과 변경 순서는 **개정 제안**이며 현재 구현이나 backend 지원 사실을 뜻하지 않는다. 이번 작성 작업의 산출물은 본 문서와 지정된 Stage 2 `MEMORY.md` 요약뿐이다.
+
+## 2. 기준 자료와 실제 확인 결과
+
+판단 순서는 현행 배포 YAML → 현행 release·배포/빌드 계약 → 현행 분석서 → 과거 YAML·분석서다. IO 표의 역사적 행번호를 현행 YAML의 행번호로 사용하지 않는다.
+
+| 자료 | 확인 내용과 전략상 역할 |
+|---|---|
+| [현행 Stage_2_S2_00.yml](Stage_2_S2_00.yml) | `Stage_2_S2_00_v2`, version `1.2.0`; prepare와 ingress의 두 task. 현행 분석의 최우선 기준이다. |
+| [Analysis_Stage_2_S2_00.md](Analysis_Stage_2_S2_00.md) | 현행 두-task 구조, 외부 인자 결속 미검증, C00–C15·입출력·운영 경계를 설명한다. |
+| [Stage_2_00_IO_info.md](../../../Stage_2_00_IO_info.md) | §3.2의 사건 입력 16개, §3.4의 Stage 1 배포 55개, §3.5의 Stage 2 직접 의존 49개와 출력 목록을 사용한다. 상단 현행 IO 보충과 보존본 기반 본문을 구별한다. |
+| [Stage_2_S2_00_outdated_9_09.yml](Stage_2_S2_00_outdated_9_09.yml) | 구형은 단일 ingress task지만 외부 request 파일이 필요하다. 단일 task 구조의 비교 기준이며 그대로 복원할 개정 정본은 아니다. |
+| [Stage_2_10_Analysis_v1.md](../../../Stage_2_10_Analysis_v1.md) | 사용자 context의 설명과 달리 실제 제목·본문·정본은 **S2_10 분석**이다. S2_00 산출물을 소비하는 downstream 계약 확인에 사용한다. |
+| [Stage_2_00_Analysis_v1.md](../../../Stage_2_00_Analysis_v1.md) | 본문이 구형 S2_00을 분석하고 상단에 현행 보충이 있다. §8의 입력·projection 제한을 교차 확인한다. |
+| [stage2_release.json](../manifest/stage2_release.json) | `/stage1_sources`, `/dependency_locks/stage1`, `/dependency_locks/stage2_direct`, `/bundle`이 실제 입력·자산 계약이다. |
+| [s2_00_inline_code_receipt.json](../manifest/s2_00_inline_code_receipt.json)·[builder](../offline_build/build_s2_00_inline_projection.py) | authoring 정본은 `Stage_2_S2_00_v.2.yml`이다. main 폴더의 version 없는 동명 YAML을 개정 정본으로 혼동하지 않는다. |
+
+작성 시 확인한 현행 배포 YAML SHA-256은 `07bc9e235d211f3d4e6886bca2faeeb1f112d525fa29fe111bd7c50c42ff9849`, 구형 `outdated_9_09` SHA-256은 `94c2744d71d222cfb5cc1b2a0d33a6cda20079439823de431eef378a2fa5c943`이다. 현행 배포본과 authoring `Stage_2_S2_00_v.2.yml`은 byte-identical이다.
+
+현행 ingress inline code와 `outdated_9_09`의 ingress inline code를 비교하면 차이는 `EXPECTED_STAGE2_RELEASE_SHA256` 상수 하나다. 따라서 request 앞단이 추가되었어도 기존 C00–C15의 의미 인계 제한이 해소되었다고 볼 수 없다. 최신 ingress를 기반으로 직접 입력 경계만 바꾸고, 필요한 의미 보완을 제한적으로 추가하는 것이 효율적이다.
+
+현재 prepare의 `__main__`은 `PREPARE_ARGUMENT_BINDING_UNVERIFIED`로 종료한다. release는 `DEV_FIXTURE_RELEASE / DRAFT_NOT_EXECUTABLE`, bundle은 `STRUCTURAL_FIXTURE`, `selected_context_refs=[]`다. 직접 인계 개정이 이 상태를 자동으로 실행 적격 또는 승인 완료로 바꾸지는 않는다.
+
+## 3. 목표 실행 흐름과 책임
+
+```text
+호출자: Stage 1 완료 결과의 사건 root + 그 결과에 대응하는 배포 root
+backend: 인증된 user/workspace 세션 + 직접 입력을 executor에 전달
+   │
+   ▼
+IN → Task_S2_00_deterministic_ingress → OUT
+       단일 code-executor.run_code
+       ① 직접 입력 형태·NFC 상대경로·workspace 결속 검증
+       ② 고정 Stage 2 release pin 검증
+       ③ 16개 사건 파일 + manifest 신호 + 55개 배포 + 49개 직접 자산
+          + module manifest/schema/조건부 release 입력의 exact closure 확정
+       ④ 동일 원격 closure 2회 읽기·bytes/hash 대조·임시 hydration
+       ⑤ C00 → C05 → run binding → C10 → C15
+       ⑥ 정상 11+E 또는 진단 5개 출력 검증·발행
+       ⑦ ingress_status.json 마지막 write/read-back → stdout receipt
+   │
+   ▼
+외부 orchestrator: barrier·정확한 산출물 집합·route 검증 → S2_10 또는 S2_40
+```
+
+C00는 입력 계약·producer·identity·seal·signal ALL 검증, C05는 review 정규화·보존검사, C10은 사건·증거·객체·당사자·slot 문맥, C15는 cluster·slice·bundle·route 구성이다. 이들은 **동일 task 내부의 메모리 처리 단계**로 유지한다. 단계마다 중간 JSON 파일을 새로 만들어 저장·재읽기하는 방식은 도입하지 않는다.
+
+별도 prepare 성공 뒤 ingress를 시작하는 task 간 게이트는 없어지고, 직접 입력 검증 실패 시 같은 Python 실행 안에서 후속 처리를 중단한다. 외부 실행자의 S2_10/S2_40 dispatch 책임과 status barrier 소비 책임은 유지한다.
+
+## 4. 최소 직접 인계 계약
+
+### 4.1 호출자가 제공할 값
+
+직접 입력은 아래 **두 문자열 필드의 닫힌 객체**로 제안한다. 이는 파일 생성 지시가 아니라 호출 데이터 예시다.
+
+```json
+{
+  "stage1_run_root_ref": "<workspace-relative Stage 1 사건 결과 root>",
+  "stage1_deployment_root_ref": "<workspace-relative 해당 Stage 1 배포 root>"
+}
+```
+
+| 정보 | 공급·검증 책임 | 최소화 이유 |
+|---|---|---|
+| `stage1_run_root_ref` | 호출자가 완료된 Stage 1 결과의 실제 root를 공급; S2_00 검증 | 16개 개별 파일 경로를 수동 작성하지 않고 release의 상대경로를 결합한다. |
+| `stage1_deployment_root_ref` | 호출자가 해당 Stage 1 결과에 대응하는 실제 배포 root를 공급; S2_00이 55개 잠금 검증 | 사건 자료와 배포 config/schema를 구별한다. 추측한 `Default_Agent` 경로로 대체하지 않는다. |
+| user/workspace 인증·hash | 기존 backend/localdocs 세션 결속 | 일반 호출 입력으로 workspace를 임의 지정하지 않는다. |
+| Stage 2 자산 root·release pin | 기존 inline 상수·빌드/배포 계약 | 호출자가 release나 output 경로를 자유롭게 바꾸지 않도록 유지한다. |
+| `request_id`·`attempt_id` | 호출 입력에서 제거; §4.3에 따른 내부 호환 처리 | 별도 ID 부여 task·request 준비 파일이 필요하지 않다. |
+
+`W/`는 localdocs 논리 workspace root다. `U=W/<stage1_run_root_ref>/`, `D=W/<stage1_deployment_root_ref>/`, `A=W/Default_Agent/Stage_2_Clean/`다. Dropbox 절대경로나 Code Executor의 로컬 mount와 동일하다고 가정하지 않는다.
+
+두 root는 이미 NFC인 canonical 상대경로여야 한다. 빈 값·절대경로·`..`·역슬래시·NUL·비정규 경로·알 수 없는 필드는 거절한다. Stage 1 완료 여부는 폴더 존재만으로 판정하지 않고 기존 handoff·writer report·identity/seal 검증으로 확인한다.
+
+### 4.2 executor에 실제 전달하는 방식
+
+**직접 인계를 함수 signature에만 적고 현재처럼 실제 진입점에서 인자가 없는 상태로 남겨서는 안 된다.** 개정 계약은 호출 데이터가 유일한 `run_code` 실행의 `run_inline_mcp`에 실제 도달하는 지점까지 포함한다.
+
+권고 함수 경계는 다음과 같다. 아래는 설계용 signature이며 완성 코드가 아니다.
+
+```python
+run_inline_mcp(direct_handoff, *, client=None)
+_inline_validate_direct_handoff(direct_handoff)
+_inline_hydrate(localdocs, temp_root, validated_handoff)
+```
+
+backend가 지원하는 기존 task input binding이 확인되면 두 root를 위 진입점에 넘긴다. 다만 현재 YAML의 `run_code` 파라미터에는 `language`, `requirements`, `network`, `timeout`, `code`만 있고 임의 `arguments`나 환경변수 입력 계약은 확인되지 않았다. `{{stage1_run_root_ref}}` 같은 템플릿 지원을 사실로 가정하지 않는다.
+
+별도 인자 binding이 없고 backend가 실행 요청의 `code`를 조립하는 기능을 제공한다면, **정적 ingress 본문과 canonical JSON을 base64로 인코딩한 데이터 literal, 고정 진입점 호출**로 한 번의 `run_code` 요청을 구성하는 방식을 대안으로 명세한다. 원시 경로를 Python 코드에 문자열 치환하지 않고 decode 후 동일한 닫힌 입력 검증을 적용한다. 본문·입력 데이터·최종 실행 code hash를 구별하고, 조립기는 임의 코드 변형을 허용하지 않는다. 현재 workflow의 `dynamic_code_allowed:false`와 inline parity 규칙에 대한 이 제한된 데이터 결속 예외도 함께 명시·검증해야 한다.
+
+두 방식은 실제 backend capability에 따라 **하나만 채택**한다. 이 문서는 어느 방식도 현 플랫폼에서 이미 지원된다고 확정하지 않는다. 구현 착수 시 확인할 외부 정보는 “호출의 두 문자열이 현재 `run_code` 진입점에 어떻게 전달되는가”로 좁힌다. 새로운 request 파일·prepare task를 그 확인의 우회책으로 되살리지 않는다.
+
+### 4.3 ID는 출력 호환에 필요한 내부 값으로 처리
+
+현행 `request_id`는 `run_binding_receipt`와 stdout, S2_10 인계 계약에 존재한다. `attempt_id`는 `publish_atomically`의 임시 staging 이름에 사용된다. 두 값을 전면 삭제하면 ingress·downstream schema와 검증기 변경이 늘어나므로 **외부 부여만 폐기하고 내부 호환 필드는 유지**한다.
+
+최소 구현안은 core 진입 전 adapter에서 다음과 같이 값을 결정하는 것이다.
+
+```text
+request_id = "S2REQ-" + canonical_digest({
+  user_context_sha256,
+  workspace_context_sha256,
+  stage1_run_root_ref,
+  stage1_deployment_root_ref,
+  expected_stage2_release_sha256,
+  pass_1_raw_hash_map_digest
+})
+
+attempt_id = "ATT-" + executor 내부에서 생성한 UUID hex
+```
+
+`pass_1_raw_hash_map_digest`는 request 파일을 제외한 실제 파일 closure를 두 read-pass에서 검증한 기존 hydration receipt의 값이다. 두 pass가 일치한 뒤 기존 `canonical_digest`로 `request_id`를 결정하므로 추가 원격 read나 새 입력 manifest가 필요하지 않다. UUID에는 Python 표준 라이브러리를 사용한다. 임시 디렉터리마다 격리되므로 원격 attempt 파일도 추가하지 않는다.
+
+`attempt_id`·현재 시각·랜덤값은 canonical output이나 run binding에 넣지 않는다. `request_id` 결정은 동일 workspace·동일 root·동일 파일 closure·동일 release에서 재현 가능해야 한다. 입력 root가 이동하면 hydration receipt의 logical path도 달라지므로, 경로가 다른 실행까지 output byte 동일성을 보장한다고 확대하지 않는다.
+
+이 내부 값은 기존 `execute_ingress(..., run_id=request_id, attempt_id=attempt_id, ...)`에 전달할 수 있어 core signature와 출력 ID 필드를 대체로 유지할 수 있다. 최종 `run_id`와 output root는 계속 기존 `run_binding_digest`에서 결정한다. 현행 binding digest의 핵심 재료는 `input_set_digest`, `stage2_release_digest`, `algorithm_digest`, `release_class`이며 request/attempt ID를 추가하지 않는다.
+
+## 5. Stage 1 원본과 배포 자산 재사용
+
+### 5.1 사건 고정 입력 16개
+
+다음은 IO 문서 §3.2의 경로를 `U/` 기준으로 묶은 목록이다. 파일 수는 그룹을 전개하면 정확히 16개다.
+
+| 묶음 | 정확한 상대경로 |
+|---|---|
+| P1 root 3개 | `evidence_indexed.json`, `evidence_event_candidates.json`, `client_goal.json` |
+| P1 routing 2개 | `routing/domain_screening.json`, `routing/domain_activation_manifest.json` |
+| P1 gate/handoff 3개 | `quality_gates/B1_evidence_indexed_gate.json`, `quality_gates/B2_event_candidates_gate.json`, `quality_gates/stage1_part1_soft_gate_handoff.json` |
+| P2 3개 | `BO.json`, `signals/signal_manifest.json`, `quality_gates/stage1_part2_review_handoff.json` |
+| P3 2개 | `legal_effect_structures.json`, `quality_gates/stage1_part3_review_handoff.json` |
+| P4 3개 | `Fact_Ledger_base.json`, `stage1_tmp/fact_ledger/fact_ledger_writer_report.json`, `quality_gates/stage1_part4_review_handoff.json` |
+
+구현의 source-of-truth는 release의 `/stage1_sources`다. 전략 표를 별도의 고정 경로 목록으로 코드에 중복 작성하지 않는다. 원본 JSON을 새 Stage 1 계약으로 변환해 저장하거나 Stage 1에 새 handoff/seal 파일을 요구하지 않는다. 필요한 Stage 2 내부 adapter는 원본 raw hash·pointer를 보존하면서 메모리 객체를 만든다.
+
+### 5.2 고정 16개 밖의 필수·조건부 입력
+
+| 입력군 | 현재 범위 | 개정 원칙 |
+|---|---|---|
+| signal payload family | `U/signals/<signal_manifest.files[i].path>` 전체 | `files[]`에서만 전개하고 행 순서·hash·semantic/integrity 구분을 유지한다. 폴더 scan으로 대체하지 않는다. |
+| 두 activation | `U/routing/domain_activation_manifest.json` 및 manifest에 포함되는 `U/signals/domain_activation_manifest.json` | 별개 경로의 원본을 유지하고 기존 semantic projection 비교를 수행한다. |
+| Stage 1 고정 배포 | `/dependency_locks/stage1/concrete_paths`의 55개 | `D/`의 runtime manifest·registry·domain config·schema를 exact path/hash로 읽는다. 사건 입력과 혼동하지 않는다. |
+| Stage 2 직접 의존 | `/dependency_locks/stage2_direct`의 49개 | 49개 전부의 기존 closure 검증을 유지한다. |
+| Stage 2 메타데이터·schema | release, module manifest, ingress/context/review schema 3개 | 위 49개와 별도로 기존 hydration에 포함한다. |
+| contract manifest·completion seal | release가 유효한 참조를 선택한 경우 | 현재 미설정 참조를 새 Stage 1 필수 파일로 승격하지 않는다. |
+
+49개 직접 자산은 S2_10 Agent·LLM binding·authority registry/release **4개**, substantive **22개**, crosscut **5개**, special-law **13개**, overlay **5개**다. 각 filename·위치는 [IO 문서 §3.5](../../../Stage_2_00_IO_info.md)와 release가 정의한다. 모든 자산을 읽어 검증하는 것과 그 본문을 모두 LLM에게 전달하는 것은 다른 작업이다.
+
+이번 개정에서는 49개를 선택된 것만 읽도록 축소하거나 공유 cache를 새로 도입하지 않는다. 그러려면 release closure·cohort·검증 정책까지 바뀐다. 가장 큰 절감은 기존 자산 재사용과 request 전달층 제거에서 얻는다. `selected_context_refs=[]`를 임의로 채우거나 49개 전체를 prompt에 넣어서 정상 handoff를 흉내 내지 않는다.
+
+## 6. 실제 변경 지점과 최소 영향 범위
+
+### 6.1 Agent와 ingress adapter
+
+| 변경 지점 | 최소 개정 내용 | 재사용하는 부분 |
+|---|---|---|
+| Agent tasks·DAG | prepare task 제거; `IN → Task_S2_00_deterministic_ingress → OUT`; ingress `wait_until: [IN]` | ingress task 이름·executor·300초·`httpx==0.28.1`·network·비 LLM 실행 |
+| task pointer | ingress의 `/Agent/Stages/0/tasks/1/parameters/code`를 `/Agent/Stages/0/tasks/0/parameters/code`로 갱신 | 단일 inline code 실행 원칙 |
+| 직접 입력 검사 | `_inline_validate_request(raw)`의 파일/6필드 계약을 두 root의 `_inline_validate_direct_handoff`로 대체 | strict JSON 처리, NFC·상대경로 검증 helper |
+| hydration | `_inline_hydrate`가 전달받은 validated handoff 사용; `INLINE_REQUEST_PATH` read·read-pass 등록 제거 | release pin, 크기·개수 상한, exact materialization plan, 두 read-pass, 원본 bytes 복제 |
+| 경로 전개 | `_inline_release_materialization_plan`의 인자를 handoff로 변경; 두 root key는 그대로 사용 | 16개·manifest 신호·55개·49개 상대경로 전개 |
+| core 호출·receipt | §4.3의 내부 ID를 기존 core에 전달; stdout도 같은 request ID 사용 | C00–C15, run binding, output schema, 정확한 artifact set 검증 |
+| 원격 발행 | request read/write 제거 외에는 기존 status-last 발행 유지 | non-status write/read-back, status 마지막 write/read-back, 기존 barrier 전체 bytes 비교 |
+
+검증과 ingress의 통합은 **하나의 task에서 차례로 처리한다**는 의미다. 실제 Stage 1/자산의 두 read-pass는 변경 중인 원본을 검출하므로 유지한다. 이를 “검증을 한 번만 한다”는 이유로 단일 read로 줄이지 않는다.
+
+고정 request 경로를 없애면 그 경로의 실행 간 덮어쓰기와 prepare→ingress 사이 직렬화 문제는 사라진다. 그러나 같은 `run_binding_digest`로 동시에 발행하는 문제까지 없어지지는 않는다. 같은 workspace/binding의 publication에는 기존 host 단일 실행 통제를 적용·확인한다. 현재 remote writer는 overwrite와 논리 barrier이므로 이를 원자적 CAS라고 부르지 않는다. 신규 lock JSON을 만드는 방식으로 실행 보장을 대신하지 않는다.
+
+### 6.2 함께 갱신할 계약·파생물
+
+아래는 **향후 YAML 개정 시** 필요한 변경 범위다. 이번 전략 작성에서는 변경하지 않는다. `R/`는 본 `Stage_2_Clean/` 패키지이고 authoring은 Stage 2 main 폴더 기준이다.
+
+| 파일/묶음 | 필요한 조치 |
+|---|---|
+| `Stage_2_S2_00_v.2.yml` → `R/agent_scripts/Stage_2_S2_00.yml` | receipt와 builder가 지정한 authoring부터 개정하고 배포본을 재투영한다. 동명 구 authoring으로 덮어쓰지 않는다. |
+| `R/runtime/s2_00_ingress.py`, `.txt` | 단일 inline code와 byte parity를 재생성한다. runtime import 자산으로 전환하지 않는다. |
+| `R/workflows/S2_00_stage1_ingress_normalize_and_bundle_compile.yml` | 두-task/고정 request 계약을 direct handoff 계약으로 변경하고 task pointer·root/ID 책임을 정정한다. |
+| `R/deployment/stage2_code_executor_binding.yml` | S2_00 row의 prepare 계약·fixed request read allowlist 제거; direct input 전달·단일 task hash와 pointer 갱신. 다른 Stage의 request 계약은 유지한다. |
+| `R/offline_build/build_s2_00_inline_projection.py`, `.txt` | `EXACTLY_TWO_TASKS_REQUIRED`·prepare 전제·두 pointer/receipt 생성을 단일 ingress 계약으로 변경한다. |
+| `R/manifest/s2_00_inline_code_receipt.json` | authoring/projection·단일 code·mirror·DAG hash와 pointer를 다시 기록한다. |
+| `R/schemas/deployment.schema.json` | 실제 S2_00 binding의 prepare 필수 규칙을 직접 인계 규칙으로 제한 변경한다. |
+| `R/schemas/ingress.schema.json` | 출력·run binding schema는 유지한다. 기존 `execution_request` 정의는 runtime 미사용으로 두어 불필요한 schema/hash 변경을 줄이고, 새 직접 입력의 runtime 닫힌 검증은 adapter에 둔다. |
+| `R/runtime/s2_00_prepare_request.py`, `.txt` | 신규 build·manifest·실행 참조에서 제외한다. 역사 파일의 물리 삭제를 개정 전제 작업으로 삼지 않는다. |
+| 영향받는 module/parent/child manifests·receipts | 변경 파일을 실제 참조하는 hash·pointer·algorithm 계약만 기존 build 순서로 재봉인한다. unrelated 본문 수정이나 전체 package 재설계는 하지 않는다. |
+| 기존 S2_00 시험·mirror | 두-task·request file 전제와 직접 입력/ID 시험을 제한 수정하고 §9의 필요한 실패·보존 검증을 수행한다. |
+
+공유 executor binding bytes가 바뀌면 다른 Stage가 그 binding hash를 참조할 수 있다. “단일 YAML만 수정”이나 “항상 몇 개 파일만 수정”이라고 미리 확정하지 않고 실제 역참조 closure를 확인한다. parent/module/self-hash의 기존 비순환 규칙을 유지하며, 직접 입력 정책의 의미 변경은 알고리즘 계약/버전에 반영한다. 빌드 산출 hash 변경은 법률 규칙 내용 변경과 구별한다.
+
+## 7. 기존 목표 달성을 위한 최소 의미 보완
+
+직접 인계는 전송 경계의 단순화다. 현행 C00–C15가 완전한 S2_10 문맥을 이미 만든다는 전제는 채택하지 않는다. [구형 분석 §8](../../../Stage_2_00_Analysis_v1.md)의 제한과 현재 inline 비교를 근거로, 다음 사항을 목표 달성 검증에 포함한다.
+
+| 제한 | 가장 작은 Stage 2 내부 보완 | 완료 증거 |
+|---|---|---|
+| 00-L2 signal adapter ID 불일치 | release의 `S2A-SIGNAL-ALL-V1`과 core의 family 검사 계약을 하나로 정합화한다. 검증을 제거하거나 모든 문자열을 허용하지 않는다. | 실제 release row에서 family mismatch가 없고 signal ALL hash·개수·activation 검사가 작동한다. |
+| 00-L4/L7 raw pointer·slice provenance | 기존 원본 adapter가 실제 배열/wrapper 위치를 결정하고, 기존 source-ref helper로 원본 row의 정확한 pointer·raw-value hash를 projection에 결속한다. | fact/BO/LES/EVENT ref를 원본 bytes에서 dereference해 같은 값·hash를 얻는다. |
+| 00-L5 fact·client goal 의미 축약 | 기존 FACT/case payload projection에 법률판단에 필요한 원문 사실·domain effects·목표 지시를 해당 cluster 범위로 전달한다. | 중요한 원문 사실·목표 지시를 S2_10용 문맥에서 원본 참조와 함께 확인한다. |
+| 00-L6/L9 signal·review·profile 전달 공백 | 기존 slice projection 배열을 해당 cluster의 명시적 source 관계로 채우고, mapped review의 내용·범위·blocking 정보도 보존한다. | 원본 occurrence와 output occurrence의 대응이 확인되고 unresolved review가 유실되지 않는다. |
+| 00-L8 slot skeleton | 원본에 존재하는 slot/fact/evidence 연결만 기존 crosswalk에 반영한다. 근거가 없으면 `UNEVALUABLE`을 유지한다. | 빈 skeleton을 완전한 연결로 오인하지 않고, 원본의 명시적 연결은 누락 없이 인계한다. |
+
+보완은 기존 adapter·source-ref·projection 함수와 기존 산출물에 집중한다. Stage 1 원본 재작성, 별도 Stage 1 규격 도입, LLM task 추가는 필요하지 않다. 기존 schema로 원문과 출처를 담을 수 없는 경우에만 해당 projection schema와 직접 소비 계약을 함께 제한 변경한다. 확인되지 않은 연결을 추론하여 채우지는 않는다.
+
+먼저 직접 인계 경계만 개정해 비교 가능한 기준을 만들고, 원본을 보존한 fixture에서 위 공백을 검사한다. **정상 ingress를 가로막거나 필요한 의미를 유실하는 항목은 완료 판정 전에 보완한다.** 기존 review/status-only 기능을 지우거나 release guard를 꺼서 시험을 통과시키지 않는다. S2_10 자체의 adapter/echo/multi-wave 미결 문제는 직접 인계 성공으로 해결된 것으로 기록하지 않는다.
+
+## 8. 효율적인 개정 순서
+
+1. **정본과 입력 계약 고정:** 현행 authoring/배포 hash, 두 root 공급 위치, backend의 실제 직접 입력 전달 방식을 확인한다. Stage 1 결과의 bytes와 경로는 고정한다.
+2. **단일 task와 adapter 경계 개정:** prepare/DAG 제거, 직접 입력 validator·hydration 인자·내부 ID·실제 진입점을 함께 변경한다. request 파일과 새 prepare 기능은 만들지 않는다.
+3. **원본 재사용·의미 인계 확인:** 16개+신호+55개+49개 closure를 그대로 사용해 C00–C15를 수행하고 §7에서 실제 드러나는 최소 adapter/projection 결함을 보완한다.
+4. **계약·projection 일괄 갱신:** authoring을 기준으로 builder·workflow·S2_00 binding·mirror·receipt·영향받는 hash closure를 한 번에 재생성한다. 중간마다 unrelated 자산을 재작성하지 않는다.
+5. **필요한 검증 종료:** §9의 정적·offline 결과를 확정하고, 허용된 release와 실제 backend가 준비된 때 동일 입력 경계의 live 검증을 수행한다. 정적 PASS와 live 성공은 따로 기록한다.
+
+작업량은 executor task **2→1**, 별도 제어 파일 **1→0**, 호출자가 부여하는 ID **2→0**으로 줄어든다. request 저장/read-back·후행 재읽기와 prepare 세션도 제거된다. 총 시간·비용 절감률은 측정하지 않았으며, 16/55/49개와 동적 입력의 핵심 검증 비용은 유지한다.
+
+## 9. 수용 기준과 검증 계획
+
+아래는 향후 구현의 검증 계획이며 이번 작성 작업에서 실행한 시험 결과가 아니다.
+
+| 검증 면 | 필수 수용 기준 |
+|---|---|
+| 실행 구조 | S2_00 Agent task와 `run_code`가 정확히 하나; ingress pointer가 `tasks/0`; IN/OUT edge와 workflow·binding·receipt가 일치한다. |
+| 실제 직접 입력 | 호출에서 주어진 두 root가 executor 진입점에 그대로 도달한다. 누락·미치환·unknown key·비NFC·절대/탈출 경로는 원본 읽기·output write 전에 거절한다. |
+| request 제거 | S2_00 실행에 `stage2_control/s2_00_request.json` read/write가 없고, 호출자가 ID를 공급할 필요가 없다. 기존 파일이 남아 있어도 소비하지 않는다. |
+| 원본·closure | Stage 1 원본의 변경은 0; 16개·55개·49개와 manifest 신호·조건부 입력을 release대로 전개한다. 한 파일 hash 불일치·원본 read-pass 변경을 검출한다. |
+| ID·재실행 | 동일 직접 입력/closure/release의 내부 request ID가 동일하고 attempt 값은 canonical 결과를 바꾸지 않는다. 기존 output root를 바꾸지 않으며 동일 bytes는 재사용하고 충돌은 거절한다. |
+| 문맥 보존 | §7의 실제 source pointer를 dereference하고 사실·목표·신호·review·명시적 slot 관계의 필요한 내용이 후속 slice에서 확인된다. 원본 미상은 미상으로 남는다. |
+| 정상 route | `TO_S2_10`/`TO_S2_10_WITH_ISSUES`; 아래 고정 11개+실행 가능 slice E개가 schema·artifact set/hash 검증을 통과한다. |
+| 진단 route | `TO_S2_40_STATUS_ONLY`; 아래 5개만 발행하고 정상 context를 만들지 않는다. 직접 입력 오류가 항상 진단 5파일을 만든다고 가정하지 않는다. |
+| 발행 실패·동시 실행 | non-status write/read-back 실패 시 유효한 새 barrier를 게시하지 않는다. 기존 barrier와 잔여 파일을 실제 확인하고 동일 binding 동시 writer 통제를 검증한다. |
+| 빌드·release | authoring↔projection↔inline/mirror parity, task pointer와 참조 hash closure, algorithm 의미 계약이 일치한다. 기존 DEV guard와 pending admission을 보존한다. |
+| live | 직접 입력 전달·인증 세션·closure 읽기·실제 발행·downstream barrier 소비를 실환경에서 확인한다. offline 함수 성공만으로 live 완료를 선언하지 않는다. |
+
+정상 고정 출력 11개는 `ingress/stage1_input_manifest.json`, `ingress/intake_report.json`, `review/issue_ledger.base.json`, `ingress/ingress_status.json`의 공통 4개와 `context/case_context.json`, `context/evidence_inventory.json`, `context/object_registry.json`, `context/party_and_title_context.json`, `context/slot_crosswalk.json`, `context/cluster_plan.json`, `context/bundle_plan.json`의 7개다. 가변 출력은 `context/cluster_slices/<cluster_id>.json`이다.
+
+진단 5개는 공통 4개와 `ingress/technical_diagnostic.json`이다. 모든 최종 파일은 `W/stage2_runs/by-binding/<run_binding_digest>/`에 저장하고 `ingress/ingress_status.json`을 마지막에 발행한다. stdout receipt와 임시 hydration 파일은 이 출력 개수에 포함하지 않는다.
+
+단일 task, 직접 입력 validator, 원본 closure, C00–C15 의미 보존, 분기 출력과 barrier가 함께 충족되어야 S2_00 개정 목표 달성으로 판정한다. 법률적 판단의 타당성, S2_10 플랫폼/model/legal admission 또는 전체 Stage 2 production readiness는 별도의 확인 대상이다.
+
+## 10. 결정·검증 기록
+
+| 결정 | 근거 | 효과 |
+|---|---|---|
+| 직접 인계와 ingress를 유일 task에 통합 | 사용자 개정 방향; 현행 prepare 인자 결속 미검증 | 별도 제어 파일과 task 사이 전달을 제거한다. |
+| 두 root만 호출 데이터로 사용 | 기존 release가 16/55/49 및 신호 경로를 정의 | 개별 파일 경로·ID 준비 작업을 줄이고 Stage 1 변경을 피한다. |
+| ID 출력 필드는 내부 호환 유지 | 현행 run binding/stdout 및 S2_10 계약 | downstream 전면 변경을 피한다. |
+| 두 read-pass·직접 자산 49개 유지 | 현행 hydration·release closure 계약 | 전송층 단순화가 무결성 검증 축소로 이어지지 않도록 한다. |
+| 필요한 의미 보완은 Stage 2 adapter/projection에 한정 | 구형 분석 §8; 현행/구형 ingress code 차이는 release pin 하나 | 입력 통합과 실제 목표 달성을 구별하면서 원본을 보존한다. |
+
+문서 작성 중 현행/구형 YAML, 두 분석 종류, IO 표, release의 55/49 경로 수, authoring 정본 및 inline code 차이를 정적으로 대조했다. 저장 후 확인에서 로컬 출처 링크 11개, Markdown fence 8개, UTF-8·종결 LF, release와 일치하는 사건 입력 16개 및 MEMORY 요약 위치·유일성이 통과했다. 참조한 원본 문서·YAML·자산 15개의 SHA-256은 작업 전후 동일했다. 이는 문서 정적 확인 결과다. YAML 개정, builder 실행·재봉인, 회귀시험, MCP/backend/live 실행, 배포·commit은 이번 작업에서 수행하지 않았다.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/agent_scripts/stage_2_s2_00_revision_strategy_v2.md

@@ -0,0 +1,196 @@
+# Stage_2_S2_00.yml 개정 전략 v2
+
+작성일: 2026-10-02. 상태: **전략서 작성 완료 / YAML 개정·실행 시험 미수행**.
+
+## 1. 목표·산출물·범위
+
+**Stage 1 사건·배포 root를 S2_00의 단일 ingress task에 직접 전달하고, Stage 1 원본을 그대로 읽어 검증·보존·정규화·묶음 구성·발행하는 것으로 S2_00을 완결한다. 별도의 `request_id`는 외부 입력, 내부 생성, 출력 모두에서 제거한다.**
+
+이번 작업의 산출물은 이 전략서와 Stage 2 `MEMORY.md`의 작업 요약뿐이다. 실제 YAML·schema·runtime·manifest·builder·배포 자산은 수정하지 않는다. 향후 구현의 유일한 개정 대상도 이 폴더의 [Stage_2_S2_00.yml](Stage_2_S2_00.yml)이다. 다른 authoring 파일부터 수정하고 이 YAML을 재생성하는 v1의 절차는 이번 범위에 적용하지 않는다.
+
+`Stage_2_S2_10.yml`, `Stage_2_S2_20.yml`, `Stage_2_S2_30.yml`, `Stage_2_S2_40.yml`의 자산 사용 schema, 인계 필드, route, 출력 수, admission·hash 호환 요구는 설계 기준과 수용 기준에서 제외한다. 해당 파일을 분석하거나 개정하는 작업도 포함하지 않는다. S2_00의 자체 입력·출력 계약과 검증은 개정 YAML의 metadata 및 inline code 안에 둔다.
+
+S2_00의 현행 기능 목표인 C00 입력 검증, C05 보존·정규화, C10 claim-neutral cluster 구성, C15 묶음·결과 발행은 유지한다. 후속 Agent에 맞추기 위한 구조·필드의 보존은 목표에서 제거한다. 이 문서의 함수 signature, 출력 구조와 변경 순서는 구현 제안이며 현 플랫폼의 지원 사실이나 실행 결과가 아니다.
+
+## 2. 확인한 기준과 v1에서 폐기할 전제
+
+| 기준 자료 | 현재 확인 내용 | v2에서의 사용 |
+|---|---|---|
+| [현행 S2_00 YAML](Stage_2_S2_00.yml) | Agent `Stage_2_S2_00_v2`, version `1.2.0`; prepare·ingress 두 task; inline C00–C15 | S2_00 내부 변경 위치와 보존할 처리 기능의 기준 |
+| [현행 S2_00 분석서](Analysis_Stage_2_S2_00.md) | 직접 인자 결속 미검증, 고정 request 파일, 정상/진단 발행, DEV release 제한 | 현재 구현과 미확인 운영 경계 구별 |
+| [개정 전략 v1](stage_2_s2_00_revision_strategy_v1.md) | 내부 request ID 유지, 기존 downstream 출력/schema와 49개 자산 유지, 여러 파일 재봉인 계획 | 사용자 원칙에 맞지 않는 전제를 식별하는 비교 자료 |
+| [현행 release](../manifest/stage2_release.json) | Stage 1 고정 사건 입력 16개와 동적 signal family; Stage 1 배포 잠금 55개; Stage 2 직접 잠금 49개; `DEV_FIXTURE_RELEASE` | Stage 1 경로·adapter·검증 근거의 확인 자료. Stage 2 전체 의존 목록을 v2에 자동 승계하지 않음 |
+
+v1의 다음 결정은 v2에서 대체한다.
+
+- 내부 `request_id = "S2REQ-" + digest(...)` 생성과 stdout·receipt 출력은 전면 폐기한다.
+- `attempt_id` UUID를 생성해 기존 core signature에 맞추는 방식도 폐기한다. 임시 작업 격리는 실행별 임시 디렉터리로 해결한다.
+- 기존 `run_binding_receipt`, `S2RUN-...` 생성, `by-binding/<digest>` 출력 경로를 유지할 호환 의무를 제거한다. 무결성 hash는 실제 검증에 필요한 용도로만 사용한다.
+- 기존 정상 11+E개·진단 5개 출력, S2_10용 bundle schema, S2_40용 status-only route를 수용 기준으로 삼지 않는다.
+- Stage 2 직접 자산 49개 일괄 읽기와 다른 Stage의 hash closure 재봉인은 개정 절차에서 제외한다.
+
+## 3. 절대 원칙과 완료 기준
+
+1. 호출 데이터는 `stage1_run_root_ref`, `stage1_deployment_root_ref` 두 값이다. 사건 자료와 배포 자료의 실제 위치를 추정하거나 새 request 파일로 중계하지 않는다.
+2. Stage 1 원본의 bytes·파일명·상대경로·원문 의미를 보존한다. 기존 사건/transaction 식별자가 원본에 있으면 출처 검증에 그대로 사용하며 새 요청 식별자로 재포장하지 않는다.
+3. prepare task, 고정 request 파일 read/write, 별도의 ID 발급·저장·출력을 제거한다. `request_id`를 이름만 바꾼 `handoff_id`·`execution_id`도 만들지 않는다.
+4. S2_00은 비 LLM deterministic task 하나로 수행한다. 입력 본문 전체를 prompt에 복사하거나 LLM task를 추가하지 않는다.
+5. 검증은 S2_00의 실제 입력·연산·출력에 필요한 것으로 한정한다. 원본의 무결성·출처·필수 내용·blocking review를 생략하여 단순화하지 않는다.
+6. 정상 결과는 원본을 추적할 수 있고 미해결 사항을 보존해야 한다. 입력 전달 성공만으로 S2_00의 기능 목표 달성을 선언하지 않는다.
+
+완료는 **두 root의 실제 인자 결속 → 원본 읽기와 필요한 검증 → 의미 보존·정규화·cluster/bundle 구성 → 자체 출력 검증 → 마지막 status 발행**이 한 task에서 성립하는 것으로 판정한다. 기존 S2_10~40에서 읽을 수 있는지는 판정 대상이 아니다.
+
+## 4. 직접 입력과 실행 경계
+
+호출 데이터의 닫힌 형태는 다음과 같다. 이는 파일로 저장할 request가 아니라 실행 인자다.
+
+```json
+{
+  "stage1_run_root_ref": "<Stage 1 사건 결과의 workspace 상대 root>",
+  "stage1_deployment_root_ref": "<그 결과에 대응하는 Stage 1 배포의 workspace 상대 root>"
+}
+```
+
+`W/`는 인증된 localdocs 논리 workspace root, `U=W/<stage1_run_root_ref>/`, `D=W/<stage1_deployment_root_ref>/`다. Dropbox 절대경로나 executor 임시 mount와 동일한 것으로 취급하지 않는다. 인증 정보는 기존 backend 세션을 사용하며 호출자가 임의 workspace를 지정하게 하지 않는다.
+
+권고 경계는 다음과 같다.
+
+```python
+run_inline_mcp(stage1_run_root_ref, stage1_deployment_root_ref, *, client=None)
+validate_direct_roots(stage1_run_root_ref, stage1_deployment_root_ref)
+hydrate_stage1(localdocs, temp_root, validated_roots)
+execute_ingress(stage1_root, stage1_deployment_root, *, output_dir, source_checks)
+publish_result(localdocs, output_root, files, status)
+```
+
+별도의 request 객체를 core에 요구하지 않는다. core의 `run_id="S2-00-REQUEST"`, `attempt_id` 필수 인자와 ID 정규식 검사는 삭제하고 필요한 경로·검증 객체만 전달한다. 내부 함수 분리는 유지할 수 있으나 추가 executor task로 나누지 않는다.
+
+두 root는 canonical NFC 상대경로인지 검사한다. 누락·빈 값·미치환 템플릿·절대경로·`..`·NUL·경로 탈출·알 수 없는 입력 필드는 원본 읽기나 출력 쓰기 전에 거절한다. Stage 1 완료 여부는 폴더 존재만으로 판단하지 않고 기존 writer report·gate/handoff와 원본 간 결속을 확인한다. 기존 완료/seal 정보가 없으면 없다고 기록하며 새 Stage 1 파일을 요구하지 않는다.
+
+실제 backend가 이 두 문자열을 `run_code` 진입점에 어떻게 전달하는지는 아직 미확인이다. 지원되는 기존 task input binding을 우선 확인한다. 실행 code 조립을 지원하는 경우에만 canonical JSON의 인코딩된 데이터 literal과 고정 호출로 두 값을 전달하는 제한된 대안을 검토한다. 원시 문자열을 Python 코드에 직접 치환하지 않는다. `{{prev...}}`의 cross-run 지원, 임의 `arguments` 파라미터, 환경변수 주입 기능을 가정하지 않는다.
+
+실제 전달 방식이 YAML 한 파일 개정으로 표현되지 않으면 **직접 입력 live 연결 미확인**으로 남긴다. 이를 이유로 prepare/request 파일을 되살리거나 backend·다른 자산의 개정을 전략 범위에 추가하지 않는다. 함수와 offline fixture 검증은 이 운영 미확인 사항과 구별하여 수행할 수 있다.
+
+## 5. Stage 1 원본 재사용과 필요한 자산만 읽기
+
+현행 고정 사건 입력 16개를 그대로 사용한다. 아래 경로는 모두 `U/` 기준이다.
+
+| 묶음 | 원본 상대경로 |
+|---|---|
+| P1 3개 | `evidence_indexed.json`, `evidence_event_candidates.json`, `client_goal.json` |
+| P1 routing 2개 | `routing/domain_screening.json`, `routing/domain_activation_manifest.json` |
+| P1 gate/handoff 3개 | `quality_gates/B1_evidence_indexed_gate.json`, `quality_gates/B2_event_candidates_gate.json`, `quality_gates/stage1_part1_soft_gate_handoff.json` |
+| P2 3개 | `BO.json`, `signals/signal_manifest.json`, `quality_gates/stage1_part2_review_handoff.json` |
+| P3 2개 | `legal_effect_structures.json`, `quality_gates/stage1_part3_review_handoff.json` |
+| P4 3개 | `Fact_Ledger_base.json`, `stage1_tmp/fact_ledger/fact_ledger_writer_report.json`, `quality_gates/stage1_part4_review_handoff.json` |
+
+signal payload는 기존 `signal_manifest.files[]`의 경로·hash·조건을 따라 읽는다. 폴더 전체 scan이나 추측한 파일 목록으로 대체하지 않는다. routing activation과 signal activation은 서로 다른 원본으로 취급하며 실제 의미 일치 여부를 확인한다.
+
+Stage 1 배포의 현행 55개 잠금 목록은 검증 근거의 기준선이다. v2에서는 각 자산이 사건 JSON 해석, schema 검증, producer/alias·domain 연결, 원본 identity 검증 중 어디에서 필요한지 S2_00 내부에서 추적한다. 필요 자산과 그 검증 의존은 유지하고, 미사용임이 확인된 자산만 읽기 대상에서 제외한다. 검토 전부터 특정 감소 개수를 약속하지 않는다. Stage 1 원본이나 배포 파일을 고쳐 개정에 맞추지 않는다.
+
+Stage 2의 현행 49개 직접 의존은 후속 작업을 위한 결속까지 포함하므로 전체를 유지하지 않는다. S2_10 YAML·LLM binding과 후속 authority/retrieval 선택용 자산은 S2_00 의존에서 제거한다. registry/config도 C05~C10에서 실제 사용하는 내용만 남기고, 남기는 이유·경로·검증 hash를 YAML 내부의 단일 자산 표에 둔다. 필요한 비실행 데이터는 읽기 전용으로 참조할 수 있으나 그 파일을 개정하거나 새 외부 schema를 만들지 않는다. 문서 안의 법률 규칙을 새로 작성하는 작업도 포함하지 않는다.
+
+자체 입력 adapter·출력 validator·경로 목록의 정본은 개정 YAML 안에서 하나로 관리한다. 기존 전체 release·module·downstream schema를 그대로 validator에 주입해 제거한 필드를 다시 요구하게 해서는 안 된다. 외부 참조가 있는 기존 schema는 실제 S2_00에 필요한 규칙과 참조 의존만 inline 자체 계약에 반영한다. 이것은 후속 호환 검사 제거이며 Stage 1 원본 검증의 면제는 아니다.
+
+## 6. C00–C15의 자체 기능 목표
+
+| 논리 단계 | 유지할 작업 | 단순화·보완 방향 |
+|---|---|---|
+| C00 | 사건·배포 원본 읽기, 필수 입력·hash·producer/transaction·gate/review 확인 | 직접 root로 전개. request/ID 검증과 downstream 자산 admission은 제거. hash 근거가 없는 입력은 무근거 상태를 보존 |
+| C05 | 증거·사실·객체·당사자·목표·LES·signal의 원본 보존과 필요한 정규화 | 원문을 덮어쓰지 않고 필요한 view만 생성. source path·정확한 JSON pointer·raw hash로 원문 연결 |
+| C10 | 원본의 명시적 관계에 따른 claim-neutral cluster와 작업 범위 구성 | 확인된 fact/evidence/BO/LES/signal 관계만 사용. 빈 slot skeleton이나 근거 없는 관계를 채우지 않음 |
+| C15 | cluster별 입력 묶음·미해결 항목·결과 검증과 발행 | 후속 Agent prompt·dispatch schema 대신 자체 bundle 표현. S2_10/40 route를 자체 처리 상태로 대체 |
+
+adapter가 wrapper/배열 위치를 잘못 해석하여 원문 pointer가 틀리거나 사실·client goal·signal·review를 축약해 의미를 잃는 문제는 S2_00 inline code 안에서 보완한다. 원문 사실, 목표 제약, 반대 자료, blocking/unresolved review, 기존 명시적 연결을 보존한다. `UNEVALUABLE`·미상은 원본 근거 없이 해결된 상태로 변경하지 않는다.
+
+원본의 fact/evidence/object/transaction ID는 의미와 참조를 구성하는 기존 값이므로 유지한다. cluster의 구조상 식별값이 필요한 경우에도 해당 묶음 참조 용도에 한정한다. 이러한 자료 식별값을 요청 ID나 실행 ID 발급의 근거로 사용하지 않는다.
+
+## 7. ID 없는 출력·재실행·임시 작업
+
+최종 출력 root는 원본 사건 root를 재사용하여 다음처럼 결정한다.
+
+```text
+O = W/stage2_runs/from-stage1/<stage1_run_root_ref>/s2_00/
+```
+
+검증된 상대 root의 경로 구성을 그대로 아래에 결합한다. 새 요청 ID, UUID, `run_binding_digest`로 출력 폴더를 만들지 않는다. `O/`가 `U/` 또는 `D/`와 겹치거나 어느 한쪽 안에 놓이는 경우는 쓰기 전에 거절한다. Stage 1 원본 트리는 읽기 전용으로 유지한다.
+
+권고 정상 출력은 다음 5개이며 cluster 수가 크거나 부분 읽기가 필요한 경우에만 가변 slice를 분리한다. 기존 11+E개 파일을 모두 보존하기 위한 빈 파일은 만들지 않는다.
+
+| 파일 | 필요한 내용 |
+|---|---|
+| `ingress/stage1_input_manifest.json` | 두 root, 읽은 원본 상대경로·raw hash·검증 근거, 기존 원본 identity가 있으면 그 값 |
+| `ingress/intake_report.json` | 필수 입력·무결성·gate 확인 결과와 누락/미검증 항목 |
+| `review/issue_ledger.base.json` | 원본 review의 내용·범위·blocking 여부·출처와 S2_00 처리 중 발견한 문제 |
+| `context/case_context.json` | 정규화 view·원본 참조, 증거/객체/당사자/LES/사실/목표/signal 관계, cluster 목록과 bundle별 원본 참조. 분리 slice 사용 시 해당 경로 |
+| `ingress/ingress_status.json` | `READY`, `READY_WITH_ISSUES`, `BLOCKED` 중 상태, 두 root, algorithm version, 실제 발행 파일 경로·hash. 마지막에 발행 |
+
+가변 파일은 필요한 경우에만 `context/cluster_slices/<cluster_ref>.json`으로 분리한다. `<cluster_ref>`는 자료 묶음 참조이며 요청/실행 ID가 아니다. 한 내용은 context 또는 slice 중 한 곳에 담고 다른 곳에서는 참조하여 중복을 줄인다. 원본 전체 사본을 새 context에 복제하지 않는다.
+
+안전하게 root를 확정하고 입력 검사를 수행한 뒤 발생한 차단은 `BLOCKED`로 기록한다. 이때 정상 context/slice는 발행하지 않으며 intake·issue ledger·technical diagnostic과 마지막 status를 발행한다. 입력 목록을 확정할 수 있을 때만 manifest도 발행한다. 입력 인자·인증 실패처럼 출력 위치를 안전하게 확정하지 못한 오류는 stdout 오류로 종료하고 결과 파일 발행을 강제하지 않는다.
+
+모든 출력의 닫힌 필드·상태별 required/forbidden artifact 규칙은 inline validator에서 정의한다. 기존 `run_binding_receipt`와 출력 schema의 `request_id`·신규 `run_id` 필수 조건은 함께 제거한다. stdout은 처리 성공 여부·상태·출력 경로·오류·마지막 status hash 정도만 담는다. 별도 ID receipt는 만들지 않는다.
+
+원본 raw hash와 산출물 hash는 변조·내용 동일성 확인을 위해 유지한다. 이 hash를 접두사와 결합하여 요청 식별자로 재출력하지 않는다. 동일 `O/`가 이미 있으면 기존 입력 경로·hash, 배포 근거, algorithm version과 발행 파일을 확인하고 일치하는 완료 결과만 재사용한다. 내용·버전이 다르거나 잔여 부분 파일이 충돌하면 덮어쓰지 않고 명시적으로 종료한다. 이번 전략은 여러 개정 버전의 결과를 같은 사건 root 아래 동시에 보관하는 새 체계를 도입하지 않는다.
+
+실행별 `TemporaryDirectory` 안에서 hydration·로컬 결과·staging을 처리한다. 임시 디렉터리의 고유한 이름은 도구 내부 자원이며 호출 필드, canonical output, stdout에 ID로 노출하지 않는다. `publish_atomically(..., attempt_id=...)`의 의존도 함께 제거한다.
+
+원격 발행은 비 status 파일 write/read-back 이후 status를 마지막에 기록하는 논리적 완료 경계로 유지한다. 임시 디렉터리가 원격 동시 writer 문제까지 해결한다고 주장하지 않는다. 같은 `O/`의 동시 writer는 기존 host 직렬화 기능을 사용할 수 있는지 확인하며, 미지원·미확인 상태에서는 동시 발행 지원을 수용 완료로 기록하지 않는다. 새 lock JSON·lock ID·CAS 지원을 가정하지 않는다.
+
+## 8. YAML 내부의 실제 변경 위치와 순서
+
+1. **범위 고정:** 현행 배포 YAML을 기준으로 두 root, S2_00 자체 목표·출력, 필수 검증과 필요한 읽기 전용 자산을 확정한다. 다른 Stage와의 호환 검토를 하지 않는다.
+2. **단일 실행 구조:** `Task_S2_00_prepare_request`를 제거한다. `task_procedure`는 `IN → Task_S2_00_deterministic_ingress → OUT`으로 바꾸고 ingress pointer를 `tasks/0`으로 정리한다.
+3. **직접 입력 진입점:** `run_inline_mcp`·`_inline_hydrate`·`_inline_release_materialization_plan`을 두 root 입력으로 변경한다. `_inline_validate_request`, request 파일의 두 read-pass, prepare 관련 상수·입출력 설명을 제거한다. 실제 원본의 두 read-pass 안정성 확인은 필요한 입력 집합에 대해 유지한다.
+4. **ID 의존 제거:** `execute_ingress`의 request용 `run_id`와 `attempt_id`, `_make_run_binding_receipt`의 요청/실행 ID 생성, `canonical_run_id`, CLI ID 옵션, staging/remote publisher·stdout의 ID 의존을 제거한다. 빈 문자열·고정 가짜 ID로 기존 signature를 통과시키지 않는다.
+5. **자체 계약·자산 의존:** Agent description·metadata와 inline code에서 전체 Stage 2 workflow/binding/schema를 런타임 필수 계약으로 연결하는 부분을 S2_00 자체 계약으로 정리한다. C00–C10에 실제 필요한 읽기 전용 원본/schema/config 검증은 남긴다. 다른 Stage 자산을 유지하려고 전체 49개 closure를 복원하지 않는다.
+6. **의미 보존과 출력:** adapter·pointer·review 처리의 실제 공백을 보완하고 C15를 자체 bundle·상태·출력 root로 바꾼다. 출력 validator, 파일 수·artifact-set 검사, publish/read-back, stdout을 함께 정합화한다.
+7. **S2_00 한정 검증:** 아래 수용 기준으로 inline 함수를 시험하고 실제 전달 가능한 환경에서 단일 task를 확인한다. 다른 Stage 시험과 패키지 전체 재봉인은 개정 범위에 넣지 않는다.
+
+향후 수정 파일은 해당 `Stage_2_S2_00.yml` 하나다. `Stage_2_S2_00_v.2.yml`, runtime mirror, 외부 workflow/binding/schema, manifest, builder는 함께 수정하지 않는다. 그 결과 기존 package builder의 parity나 parent release 봉인을 충족한다고 주장할 수 없다. 기존 builder를 돌려 이 YAML을 다시 덮어쓰는 것도 하지 않는다. 전체 패키지의 배포 승인과 S2_00 자체 기능 구현은 구별한다.
+
+## 9. 실행 허용 조건과 미확인 사항
+
+현재 release는 `DEV_FIXTURE_RELEASE`이며 현행 core에는 실제 사건 발행을 금지하는 `DEV_FIXTURE_REAL_RUN_FORBIDDEN` 방어가 있다. 후속 Agent와 무관한 인증·원본 신뢰 근거·S2_00 실행 허용 조건은 보존한다. 기존 전체 Stage 2 admission을 제거하면서 이를 임의의 `active:true`나 새 self-certified receipt로 대체하지 않는다.
+
+YAML 한 파일 안에서 기존 근거로 독립 검증 가능한 S2_00 실행 조건을 명시한다. 현재 DEV 상태만으로는 offline fixture 검증까지만 가능하다. 실제 사건 발행에 필요한 승인·backend 기능이 외부 패키지 변경을 요구한다면 그 부분은 **현재 범위에서 live 미완료**로 기록한다. 다른 Stage의 준비 상태를 S2_00 내용 설계의 제약으로 다시 가져오거나, guard를 꺼 실제 사건 시험을 통과시키는 방법은 채택하지 않는다.
+
+미확인 사항은 두 root의 실제 backend 결속, 인증 치환, 필요한 Stage 1 신뢰 근거의 완비, 같은 출력 root의 writer 직렬화, S2_00 독립 실행 허용 조건이다. 전략 작성이나 offline 함수 성공만으로 어느 것도 해결되었다고 기록하지 않는다.
+
+## 10. 수용 기준과 검증 계획
+
+아래는 향후 YAML 구현의 검증 계획이며 이번 작업에서 실행한 시험 결과가 아니다. 검증용 fixture·임시 출력은 임시 디렉터리를 사용하며 저장소에 다른 시험 자산을 새로 만들 필요는 없다.
+
+| 검증 면 | 수용 기준 |
+|---|---|
+| 개정 범위 | 실제 수정 YAML은 S2_00 배포본 하나. S2_10~40·authoring·외부 자산 수정 없음 |
+| 구조 | Agent stage 하나, ingress task·`run_code` 하나. DAG와 `tasks/0` pointer 일치 |
+| 직접 전달 | 호출한 두 root가 실행 진입점에 그대로 도달. 경로 누락·미치환·탈출·출력/원본 중첩은 read/write 전에 차단 |
+| 군더더기 제거 | prepare·고정 request 파일 read/write 0; `request_id` 입력·생성·출력 0; request를 대체하는 새 ID 0; `attempt_id` 필수 인자·출력 0 |
+| 원본·검증 | Stage 1 원본 변경 0. 고정 16개·동적 signal 및 필요한 배포/schema 검증 수행. hash 불일치, manifest 탈출, 두 read-pass 변경 검출 |
+| 자산 범위 | 실제 S2_00 사용 근거가 있는 자산만 읽음. 후속 YAML·LLM binding·후속 schema/route 계약을 요구하지 않음 |
+| 내용 보존 | source pointer dereference 결과와 hash 일치. 사실·목표 제약·증거·신호·review·명시적 관계 누락 없음. 미상·blocking 유지 |
+| 정상·차단 | 자체 상태와 실제 artifact 목록 일치. 차단 결과를 정상 context로 표현하지 않음. 원본에 없는 관계를 생성하지 않음 |
+| 재실행·발행 | 동일 완료 결과만 재사용. 불일치·부분 충돌은 거절. 비 status write/read-back 실패 시 새 정상 status를 발행하지 않음. 기존 status 존재는 별도 확인 |
+| 임시·동시 실행 | 임시 작업 디렉터리는 분리되고 출력에 임시 ID 없음. 원격 동시 발행 보장은 실증 전 미확인으로 기록 |
+| live | 허용된 환경에서 root 결속·인증·원본 읽기·결과 write/read-back·마지막 status 확인. offline PASS와 구별 |
+
+검증은 먼저 경로·ID 제거·정상/차단·원본 보존·pointer·재실행·발행 실패를 다루는 한 차례의 종합 offline 검증으로 수행한다. 수정이나 새 실패가 생겼을 때 해당 영향만 재확인한다. S2_10~40과의 E2E·호환 시험, 법률 판단의 타당성 승인, 전체 패키지 production readiness는 수용 기준에 넣지 않는다.
+
+## 11. 효율성과 남는 비용
+
+계획상 executor task는 2→1, 고정 request 파일은 1→0, 별도 request ID 생성·출력은 0으로 줄인다. prepare 호출, request 저장·read-back·재읽기, ID 호환 처리, 후속 자산의 불필요한 읽기를 제거하는 것이 절감 지점이다. 이미 Stage 1 결과를 직접 읽는 방식에 추가 ID 처리를 붙이는 것이 더 효율적이라고 주장하지 않는다.
+
+S2_00은 비 LLM 작업이므로 ID 제거 자체가 큰 모델 토큰 절감을 보장하지 않는다. inline code의 전달량·billing과 필요한 원본 검증 비용은 남는다. 속도·비용·토큰 절감률은 실제 실행 요청 크기, 읽기 횟수, task 시간과 청구 값을 측정하기 전까지 미측정으로 둔다.
+
+## 12. 작성 작업의 결정·검증 기록
+
+| 결정 | 근거 | 결과 |
+|---|---|---|
+| 두 Stage 1 root 직접 전달과 request ID 전면 제거 | 이번 사용자 절대 원칙 | v1 §4.3의 내부 호환 ID 정책 폐기 |
+| S2_00 YAML 한 파일을 향후 개정 대상으로 한정 | 사용자 범위 제한 | downstream 호환·외부 자산 재봉인 계획 제외 |
+| 원본 의미·검증 유지, 자체 출력 축소 | S2_00의 C00–C15 기능 목표 | 전송 단순화와 기능 완결을 함께 검증 |
+| 기존 root·자료 참조·hash 재사용 | 추가 요청 식별자를 만들지 않는 원칙 | 원본 보존, 출처 확인, 재실행 충돌 판별 가능 |
+| backend·live 허용 조건 미확인 유지 | 현행 S2_00 진입점과 DEV guard | 전략·offline·live·패키지 승인 상태 구별 |
+
+이번에는 이 전략서 생성과 지정 MEMORY 요약만 수행했다. 문서의 정확한 저장 경로·UTF-8·종결 LF, fence 6개·로컬 링크 5개, 사용자 원칙 반영과 요약 위치를 정적으로 확인했다. 작업 전 기준선 610개 파일 중 MEMORY를 제외한 기존 609개는 SHA-256이 동일했고, MEMORY도 요약 삽입 이외의 기존 내용은 보존했다. 새 파일은 이 전략서 하나다. YAML 개정, inline 실행, builder·release 재봉인, MCP/backend/live 시험, 배포·commit은 수행하지 않았다.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/agent_scripts/stage_2_s2_00_revision_strategy_v3.md

@@ -0,0 +1,221 @@
+# Stage_2_S2_00.yml 개정 전략 v3
+
+작성일: 2026-10-02. 상태: **전략서 작성 완료 / YAML 개정·실행 시험 미수행**.
+
+## 1. 목표·산출물·범위
+
+**Stage 1 사건·배포 root를 S2_00의 단일 ingress task에 직접 전달하고, Stage 1 결과물은 backend Python 실행 환경이 지원하는 `{{prev.###}}` 참조로 그대로 사용한다. `###`는 Stage 1의 결과물 파일이다. 원본을 검증·보존·정규화·묶음 구성·발행하는 것으로 S2_00을 완결하며, 별도의 `request_id`는 외부 입력, 내부 생성, 출력 모두에서 제거한다.**
+
+이번 작업의 산출물은 이 전략서와 Stage 2 `MEMORY.md`의 작업 요약뿐이다. 실제 YAML·schema·runtime·manifest·builder·배포 자산은 수정하지 않는다. 향후 구현의 유일한 개정 대상도 이 폴더의 [Stage_2_S2_00.yml](Stage_2_S2_00.yml)이다. 다른 authoring 파일부터 수정하고 이 YAML을 재생성하는 v1의 절차는 이번 범위에 적용하지 않는다.
+
+`Stage_2_S2_10.yml`, `Stage_2_S2_20.yml`, `Stage_2_S2_30.yml`, `Stage_2_S2_40.yml`의 자산 사용 schema, 인계 필드, route, 출력 수, admission·hash 호환 요구는 설계 기준과 수용 기준에서 제외한다. 해당 파일을 분석하거나 개정하는 작업도 포함하지 않는다. S2_00의 자체 입력·출력 계약과 검증은 개정 YAML의 metadata 및 inline code 안에 둔다.
+
+S2_00의 현행 기능 목표인 C00 입력 검증, C05 보존·정규화, C10 claim-neutral cluster 구성, C15 묶음·결과 발행은 유지한다. 후속 Agent에 맞추기 위한 구조·필드의 보존은 목표에서 제거한다. `{{prev.###}}` 사용을 backend Python 실행 환경이 허용한다는 점은 이번 사용자 추가 설명에 따른 설계 전제로 채택한다. 이 문서의 함수 signature, 자체 출력 구조와 변경 순서는 구현 제안이며 이번 작업에서 실제 YAML을 개정하거나 backend 실행을 시험한 결과는 아니다.
+
+## 2. 개정 기준과 v2에서 달라지는 전제
+
+| 기준 자료 | 기준 내용 | v3에서의 사용 |
+|---|---|---|
+| [현행 S2_00 YAML](Stage_2_S2_00.yml) | Agent `Stage_2_S2_00_v2`, version `1.2.0`; prepare·ingress 두 task; inline C00–C15 | S2_00 내부 변경 위치와 보존할 처리 기능의 기준 |
+| [현행 S2_00 분석서](Analysis_Stage_2_S2_00.md) | v2 작성 시 기준선: 기존 직접 인자 결속 미검증, 고정 request 파일, 정상/진단 발행, DEV release 제한 | 기존 구현의 기록. 결과물 참조 지원 여부는 이번 사용자 설명을 우선 적용 |
+| [개정 전략 v2](stage_2_s2_00_revision_strategy_v2.md) | root 직접 전달·ID 제거·S2_00 한정 개정; backend 결속은 미확인으로 기술 | 본 개정의 원본. 직접 전달 원칙을 유지하고 `{{prev.###}}` 지원 전제를 반영 |
+| 사용자 추가 설명 | Stage 1 결과물 파일을 `{{prev.###}}`로 사용할 수 있고 backend Python 실행 환경이 이를 허용 | 결과물 접근 방식의 설계 근거. 지원 여부 재조사를 개정 선행 조건으로 두지 않음 |
+| [현행 release](../manifest/stage2_release.json) | Stage 1 고정 사건 입력 16개와 동적 signal family; Stage 1 배포 잠금 55개; Stage 2 직접 잠금 49개; `DEV_FIXTURE_RELEASE` | Stage 1 경로·adapter·검증 근거의 확인 자료. Stage 2 전체 의존 목록을 v3에 자동 승계하지 않음 |
+
+기존 YAML·release의 설명은 v2에 기록된 기준선을 승계한다. 이번 문서 개정의 변경 근거는 사용자 추가 설명이며, 이를 별도의 live 실증 결과로 표시하지 않는다.
+
+v2의 직접 전달·ID 제거·S2_00 한정 원칙은 유지한다. v2 §4의 backend 전달 방식 탐색, code 조립 대안, 직접 입력 지원 여부를 미확인으로 두는 전제는 `{{prev.###}}`의 지원을 채택하는 것으로 대체한다. v1에서 이미 폐기한 다음 전제도 되살리지 않는다.
+
+- 내부 `request_id = "S2REQ-" + digest(...)` 생성과 stdout·receipt 출력은 전면 폐기한다.
+- `attempt_id` UUID를 생성해 기존 core signature에 맞추는 방식도 폐기한다. 임시 작업 격리는 실행별 임시 디렉터리로 해결한다.
+- 기존 `run_binding_receipt`, `S2RUN-...` 생성, `by-binding/<digest>` 출력 경로를 유지할 호환 의무를 제거한다. 무결성 hash는 실제 검증에 필요한 용도로만 사용한다.
+- 기존 정상 11+E개·진단 5개 출력, S2_10용 bundle schema, S2_40용 status-only route를 수용 기준으로 삼지 않는다.
+- Stage 2 직접 자산 49개 일괄 읽기와 다른 Stage의 hash closure 재봉인은 개정 절차에서 제외한다.
+
+## 3. 절대 원칙과 완료 기준
+
+1. 사건·배포 위치는 `stage1_run_root_ref`, `stage1_deployment_root_ref`로 직접 전달하고, Stage 1 결과물은 `{{prev.###}}`로 직접 사용한다. 기존 실행 정보와 결과 참조를 활용하며 호출자에게 별도 request나 결과 사본을 만들게 하지 않는다.
+2. Stage 1 원본의 bytes·파일명·상대경로·원문 의미를 보존한다. 기존 사건/transaction 식별자가 원본에 있으면 출처 검증에 그대로 사용하며 새 요청 식별자로 재포장하지 않는다.
+3. prepare task, 고정 request 파일 read/write, 별도의 ID 발급·저장·출력을 제거한다. `request_id`를 이름만 바꾼 `handoff_id`·`execution_id`도 만들지 않는다.
+4. S2_00은 비 LLM deterministic task 하나로 수행한다. 입력 본문 전체를 prompt에 복사하거나 LLM task를 추가하지 않는다.
+5. 검증은 S2_00의 실제 입력·연산·출력에 필요한 것으로 한정한다. 원본의 무결성·출처·필수 내용·blocking review를 생략하여 단순화하지 않는다.
+6. 정상 결과는 원본을 추적할 수 있고 미해결 사항을 보존해야 한다. 입력 전달 성공만으로 S2_00의 기능 목표 달성을 선언하지 않는다.
+
+완료는 **두 root 직접 전달·`{{prev.###}}` 결과 참조의 실제 해석 → 원본 사용과 필요한 검증 → 의미 보존·정규화·cluster/bundle 구성 → 자체 출력 검증 → 마지막 status 발행**이 한 task에서 성립하는 것으로 판정한다. 기존 S2_10~40에서 읽을 수 있는지는 판정 대상이 아니다.
+
+## 4. `{{prev.###}}` 결과 사용과 직접 실행 경계
+
+### 4.1 backend 지원을 채택하는 설계 전제
+
+Stage 2 S2_00은 Stage 1 결과물을 아래 형식으로 사용할 수 있다.
+
+```text
+{{prev.###}}
+### = Stage 1의 결과물 파일
+```
+
+**이 사용은 backend의 Python code 실행 환경이 허용한다.** 이는 사용자 추가 설명을 반영한 설계 전제다. 따라서 v2의 “`prev` 지원을 가정하지 않는다”, “backend 전달 방식을 먼저 확인한다”, “별도 code 조립 대안을 검토한다”는 접근은 적용하지 않는다. 지원 여부 확인을 개정 착수의 장애나 prepare task 부활의 이유로 삼지 않는다.
+
+단순 파일명에 적용하면 `{{prev.evidence_indexed.json}}`, `{{prev.BO.json}}`, `{{prev.Fact_Ledger_base.json}}`과 같은 형태다. 이 예시는 사용자가 제시한 형식에 실제 파일명을 대입한 것이다. `###`를 task 이름·새 ID로 바꾸지 않는다. 하위 폴더 파일과 동적 signal의 경우 실제 Stage 1 결과물에 등록된 파일 참조를 그대로 사용하고, 문서에서 임의의 별칭이나 새로운 참조 문법을 만들지 않는다.
+
+`prev` 표현식을 일반 Python 문법으로 직접 평가하는 것은 아니다. backend가 해당 참조를 해석하여 Python 실행에 제공하는 결과물을 ingress에서 사용하는 경계다. 이 문서의 예시만으로 `prev`라는 Python 객체·신규 resolver API·임의 `run_code.arguments` 파라미터를 구현 사실로 가정하지 않는다.
+
+### 4.2 두 root와 파일 참조의 역할
+
+두 root는 원본 위치·배포 검증·출처 기록·출력 위치 결정에 그대로 사용한다. 위치 정보의 형태는 다음과 같다. 이는 파일로 저장할 request가 아니라 기존 실행 정보의 직접 전달 값이다.
+
+```json
+{
+  "stage1_run_root_ref": "<Stage 1 사건 결과의 workspace 상대 root>",
+  "stage1_deployment_root_ref": "<그 결과에 대응하는 Stage 1 배포의 workspace 상대 root>"
+}
+```
+
+`{{prev.###}}`는 이 위치 정보와 함께 실제 Stage 1 결과물 파일을 사용하는 방식이다. 파일 참조 사용을 위해 별도 요청 ID를 발급하거나 caller에게 파일 목록·본문을 새 request로 재작성하게 하지 않는다. backend에서 제공된 원본 결과를 직접 사용하고, root에서 파일을 다시 찾는 별도 중계 절차로 되돌리지 않는다.
+
+`W/`는 인증된 localdocs 논리 workspace root, `U=W/<stage1_run_root_ref>/`, `D=W/<stage1_deployment_root_ref>/`다. Dropbox 절대경로나 executor 임시 mount와 동일한 것으로 취급하지 않는다. 인증 정보는 기존 backend 세션을 사용하며 호출자가 임의 workspace를 지정하게 하지 않는다. 배포 자산은 `D/`에서 필요한 항목만 읽기 전용으로 검증한다.
+
+### 4.3 단일 Python ingress의 내부 경계
+
+권고 내부 함수 경계는 다음과 같다. `stage1_results`는 backend가 `{{prev.###}}`로 제공한 결과를 ingress 안에서 다루는 메모리 값이며 별도 request 파일·새 호출자 준비 산출물이 아니다.
+
+```python
+run_inline_mcp(stage1_run_root_ref, stage1_deployment_root_ref, *, stage1_results, client=None)
+validate_direct_inputs(stage1_run_root_ref, stage1_deployment_root_ref, stage1_results)
+hydrate_stage1(localdocs, temp_root, validated_roots, stage1_results)
+execute_ingress(stage1_root, stage1_deployment_root, *, output_dir, source_checks)
+publish_result(localdocs, output_root, files, status)
+```
+
+backend에서 제공되는 실제 결과 표현에 따라 기존 adapter를 연결한다. 파일 경로/참조가 제공되면 해당 원본 파일을 사용하고, 파일 bytes나 파싱된 결과가 제공되면 그 값을 재사용한다. 표현 형식을 문서에서 하나로 단정하지 않는다. 파싱된 객체만으로 원본 raw bytes hash가 검증되었다고 주장하지 않으며, 검증에 필요한 원본 bytes가 없을 때만 기존 원본 경로에서 보완한다. 이미 제공된 원본을 불필요하게 다시 읽거나 직렬화하여 사본을 만들지 않는다.
+
+별도의 request 객체를 core에 요구하지 않는다. core의 `run_id="S2-00-REQUEST"`, `attempt_id` 필수 인자와 ID 정규식 검사는 삭제하고 필요한 경로·검증 객체만 전달한다. 내부 함수 분리는 유지할 수 있으나 추가 executor task로 나누지 않는다. 원문 결과에 따옴표·개행이 포함되어도 데이터로 보존하며 원문을 Python 소스 문자열에 직접 끼워 넣지 않는다.
+
+두 root는 canonical NFC 상대경로인지 검사한다. 누락·빈 값·절대경로·`..`·NUL·경로 탈출·알 수 없는 입력 필드는 원본 읽기나 출력 쓰기 전에 거절한다. 지원되는 `{{prev.###}}` 표현식 자체를 오류로 판단하지 않는다. backend 해석 이후에도 필수 참조가 미치환 상태이거나 결과물이 누락·잘못 대응된 경우에는 원본으로 사용하지 않고 진단한다. Stage 1 완료 여부는 폴더 존재만으로 판단하지 않고 기존 writer report·gate/handoff와 실제 제공된 결과 간 결속을 확인한다. 기존 완료/seal 정보가 없으면 없다고 기록하며 새 Stage 1 파일을 요구하지 않는다.
+
+참조 지원은 채택한 전제이며, 각 결과물의 정확한 결속·원본 동일성·한 task 내 발행 성공은 향후 구현 검증 항목이다. 이번 전략서 작성은 그 실행 검증을 수행하지 않는다. prepare/request 파일·새 ID·backend 개정을 추가하지 않고 기존 실행 환경 안에서 S2_00 YAML만 개정한다.
+
+## 5. Stage 1 원본 재사용과 필요한 자산만 읽기
+
+현행 고정 사건 입력 16개를 `{{prev.###}}`로 그대로 사용한다. 아래 경로는 원본의 `U/` 기준 상대경로이며, 실제 backend 파일 참조와 원본 출처를 대응하는 기준이다. 이 표를 새 request 파일이나 결과 사본으로 저장하지 않는다.
+
+| 묶음 | 원본 상대경로 |
+|---|---|
+| P1 3개 | `evidence_indexed.json`, `evidence_event_candidates.json`, `client_goal.json` |
+| P1 routing 2개 | `routing/domain_screening.json`, `routing/domain_activation_manifest.json` |
+| P1 gate/handoff 3개 | `quality_gates/B1_evidence_indexed_gate.json`, `quality_gates/B2_event_candidates_gate.json`, `quality_gates/stage1_part1_soft_gate_handoff.json` |
+| P2 3개 | `BO.json`, `signals/signal_manifest.json`, `quality_gates/stage1_part2_review_handoff.json` |
+| P3 2개 | `legal_effect_structures.json`, `quality_gates/stage1_part3_review_handoff.json` |
+| P4 3개 | `Fact_Ledger_base.json`, `stage1_tmp/fact_ledger/fact_ledger_writer_report.json`, `quality_gates/stage1_part4_review_handoff.json` |
+
+signal manifest 자체를 Stage 1 결과 참조로 사용하고, payload는 기존 `signal_manifest.files[]`의 경로·hash·조건에 해당하는 실제 결과물 참조를 따라 사용한다. 필요한 원본 bytes 접근만 보완한다. 폴더 전체 scan이나 추측한 파일 목록으로 대체하지 않는다. routing activation과 signal activation은 서로 다른 원본으로 취급하며 실제 의미 일치 여부를 확인한다.
+
+Stage 1 배포의 현행 55개 잠금 목록은 검증 근거의 기준선이다. v3에서는 각 자산이 사건 JSON 해석, schema 검증, producer/alias·domain 연결, 원본 identity 검증 중 어디에서 필요한지 S2_00 내부에서 추적한다. 필요 자산과 그 검증 의존은 유지하고, 미사용임이 확인된 자산만 읽기 대상에서 제외한다. 검토 전부터 특정 감소 개수를 약속하지 않는다. Stage 1 원본이나 배포 파일을 고쳐 개정에 맞추지 않는다.
+
+Stage 2의 현행 49개 직접 의존은 후속 작업을 위한 결속까지 포함하므로 전체를 유지하지 않는다. S2_10 YAML·LLM binding과 후속 authority/retrieval 선택용 자산은 S2_00 의존에서 제거한다. registry/config도 C05~C10에서 실제 사용하는 내용만 남기고, 남기는 이유·경로·검증 hash를 YAML 내부의 단일 자산 표에 둔다. 필요한 비실행 데이터는 읽기 전용으로 참조할 수 있으나 그 파일을 개정하거나 새 외부 schema를 만들지 않는다. 문서 안의 법률 규칙을 새로 작성하는 작업도 포함하지 않는다.
+
+자체 입력 adapter·출력 validator·경로 목록의 정본은 개정 YAML 안에서 하나로 관리한다. 기존 전체 release·module·downstream schema를 그대로 validator에 주입해 제거한 필드를 다시 요구하게 해서는 안 된다. 외부 참조가 있는 기존 schema는 실제 S2_00에 필요한 규칙과 참조 의존만 inline 자체 계약에 반영한다. 이것은 후속 호환 검사 제거이며 Stage 1 원본 검증의 면제는 아니다.
+
+## 6. C00–C15의 자체 기능 목표
+
+| 논리 단계 | 유지할 작업 | 단순화·보완 방향 |
+|---|---|---|
+| C00 | Stage 1 결과 참조·배포 원본, 필수 입력·hash·producer/transaction·gate/review 확인 | 결과물은 `{{prev.###}}`로 사용하고 두 root로 출처·배포를 확인. request/ID 검증과 downstream 자산 admission은 제거. hash 근거가 없는 입력은 무근거 상태를 보존 |
+| C05 | 증거·사실·객체·당사자·목표·LES·signal의 원본 보존과 필요한 정규화 | 원문을 덮어쓰지 않고 필요한 view만 생성. source path·정확한 JSON pointer·raw hash로 원문 연결 |
+| C10 | 원본의 명시적 관계에 따른 claim-neutral cluster와 작업 범위 구성 | 확인된 fact/evidence/BO/LES/signal 관계만 사용. 빈 slot skeleton이나 근거 없는 관계를 채우지 않음 |
+| C15 | cluster별 입력 묶음·미해결 항목·결과 검증과 발행 | 후속 Agent prompt·dispatch schema 대신 자체 bundle 표현. S2_10/40 route를 자체 처리 상태로 대체 |
+
+adapter가 wrapper/배열 위치를 잘못 해석하여 원문 pointer가 틀리거나 사실·client goal·signal·review를 축약해 의미를 잃는 문제는 S2_00 inline code 안에서 보완한다. 원문 사실, 목표 제약, 반대 자료, blocking/unresolved review, 기존 명시적 연결을 보존한다. `UNEVALUABLE`·미상은 원본 근거 없이 해결된 상태로 변경하지 않는다.
+
+원본의 fact/evidence/object/transaction ID는 의미와 참조를 구성하는 기존 값이므로 유지한다. cluster의 구조상 식별값이 필요한 경우에도 해당 묶음 참조 용도에 한정한다. 이러한 자료 식별값을 요청 ID나 실행 ID 발급의 근거로 사용하지 않는다.
+
+## 7. ID 없는 출력·재실행·임시 작업
+
+최종 출력 root는 원본 사건 root를 재사용하여 다음처럼 결정한다.
+
+```text
+O = W/stage2_runs/from-stage1/<stage1_run_root_ref>/s2_00/
+```
+
+검증된 상대 root의 경로 구성을 그대로 아래에 결합한다. 새 요청 ID, UUID, `run_binding_digest`로 출력 폴더를 만들지 않는다. `O/`가 `U/` 또는 `D/`와 겹치거나 어느 한쪽 안에 놓이는 경우는 쓰기 전에 거절한다. Stage 1 원본 트리는 읽기 전용으로 유지한다.
+
+권고 정상 출력은 다음 5개이며 cluster 수가 크거나 부분 읽기가 필요한 경우에만 가변 slice를 분리한다. 기존 11+E개 파일을 모두 보존하기 위한 빈 파일은 만들지 않는다.
+
+| 파일 | 필요한 내용 |
+|---|---|
+| `ingress/stage1_input_manifest.json` | 두 root, 읽은 원본 상대경로·raw hash·검증 근거, 기존 원본 identity가 있으면 그 값 |
+| `ingress/intake_report.json` | 필수 입력·무결성·gate 확인 결과와 누락/미검증 항목 |
+| `review/issue_ledger.base.json` | 원본 review의 내용·범위·blocking 여부·출처와 S2_00 처리 중 발견한 문제 |
+| `context/case_context.json` | 정규화 view·원본 참조, 증거/객체/당사자/LES/사실/목표/signal 관계, cluster 목록과 bundle별 원본 참조. 분리 slice 사용 시 해당 경로 |
+| `ingress/ingress_status.json` | `READY`, `READY_WITH_ISSUES`, `BLOCKED` 중 상태, 두 root, algorithm version, 실제 발행 파일 경로·hash. 마지막에 발행 |
+
+가변 파일은 필요한 경우에만 `context/cluster_slices/<cluster_ref>.json`으로 분리한다. `<cluster_ref>`는 자료 묶음 참조이며 요청/실행 ID가 아니다. 한 내용은 context 또는 slice 중 한 곳에 담고 다른 곳에서는 참조하여 중복을 줄인다. 원본 전체 사본을 새 context에 복제하지 않는다.
+
+안전하게 root를 확정하고 입력 검사를 수행한 뒤 발생한 차단은 `BLOCKED`로 기록한다. 이때 정상 context/slice는 발행하지 않으며 intake·issue ledger·technical diagnostic과 마지막 status를 발행한다. 입력 목록을 확정할 수 있을 때만 manifest도 발행한다. 입력 인자·인증 실패처럼 출력 위치를 안전하게 확정하지 못한 오류는 stdout 오류로 종료하고 결과 파일 발행을 강제하지 않는다.
+
+모든 출력의 닫힌 필드·상태별 required/forbidden artifact 규칙은 inline validator에서 정의한다. 기존 `run_binding_receipt`와 출력 schema의 `request_id`·신규 `run_id` 필수 조건은 함께 제거한다. stdout은 처리 성공 여부·상태·출력 경로·오류·마지막 status hash 정도만 담는다. 별도 ID receipt는 만들지 않는다.
+
+원본 raw hash와 산출물 hash는 변조·내용 동일성 확인을 위해 유지한다. 이 hash를 접두사와 결합하여 요청 식별자로 재출력하지 않는다. 동일 `O/`가 이미 있으면 기존 입력 경로·hash, 배포 근거, algorithm version과 발행 파일을 확인하고 일치하는 완료 결과만 재사용한다. 내용·버전이 다르거나 잔여 부분 파일이 충돌하면 덮어쓰지 않고 명시적으로 종료한다. 이번 전략은 여러 개정 버전의 결과를 같은 사건 root 아래 동시에 보관하는 새 체계를 도입하지 않는다.
+
+실행별 `TemporaryDirectory` 안에서 hydration·로컬 결과·staging을 처리한다. 임시 디렉터리의 고유한 이름은 도구 내부 자원이며 호출 필드, canonical output, stdout에 ID로 노출하지 않는다. `publish_atomically(..., attempt_id=...)`의 의존도 함께 제거한다.
+
+원격 발행은 비 status 파일 write/read-back 이후 status를 마지막에 기록하는 논리적 완료 경계로 유지한다. 임시 디렉터리가 원격 동시 writer 문제까지 해결한다고 주장하지 않는다. 같은 `O/`의 동시 writer는 기존 host 직렬화 기능을 사용할 수 있는지 확인하며, 미지원·미확인 상태에서는 동시 발행 지원을 수용 완료로 기록하지 않는다. 새 lock JSON·lock ID·CAS 지원을 가정하지 않는다.
+
+## 8. YAML 내부의 실제 변경 위치와 순서
+
+1. **범위 고정:** 두 root 직접 전달과 backend가 허용하는 `{{prev.###}}` 결과 사용을 전제로 S2_00 자체 목표·출력, 필수 검증과 필요한 읽기 전용 자산을 확정한다. 다른 Stage와의 호환 검토를 하지 않는다.
+2. **단일 실행 구조:** `Task_S2_00_prepare_request`를 제거한다. `task_procedure`는 `IN → Task_S2_00_deterministic_ingress → OUT`으로 바꾸고 ingress pointer를 `tasks/0`으로 정리한다.
+3. **직접 결과 사용 진입점:** `run_inline_mcp`·`_inline_hydrate`·`_inline_release_materialization_plan`을 두 root와 backend가 제공한 `{{prev.###}}` 결과를 사용하도록 변경한다. 파일 참조와 원본 source pointer를 대응시킨다. `_inline_validate_request`, request 파일의 두 read-pass, prepare 관련 상수·입출력 설명을 제거한다. 실제 원본의 두 read-pass 안정성 확인은 필요한 입력 집합에 대해 유지하되 결과 참조의 해석을 두 번 수행하는 것으로 대체하지 않는다.
+4. **ID 의존 제거:** `execute_ingress`의 request용 `run_id`와 `attempt_id`, `_make_run_binding_receipt`의 요청/실행 ID 생성, `canonical_run_id`, CLI ID 옵션, staging/remote publisher·stdout의 ID 의존을 제거한다. 빈 문자열·고정 가짜 ID로 기존 signature를 통과시키지 않는다.
+5. **자체 계약·자산 의존:** Agent description·metadata와 inline code에서 전체 Stage 2 workflow/binding/schema를 런타임 필수 계약으로 연결하는 부분을 S2_00 자체 계약으로 정리한다. C00–C10에 실제 필요한 읽기 전용 원본/schema/config 검증은 남긴다. 다른 Stage 자산을 유지하려고 전체 49개 closure를 복원하지 않는다.
+6. **의미 보존과 출력:** adapter·pointer·review 처리의 실제 공백을 보완하고 C15를 자체 bundle·상태·출력 root로 바꾼다. 출력 validator, 파일 수·artifact-set 검사, publish/read-back, stdout을 함께 정합화한다.
+7. **S2_00 한정 검증:** 아래 수용 기준으로 inline 함수를 시험하고 실제 전달 가능한 환경에서 단일 task를 확인한다. 다른 Stage 시험과 패키지 전체 재봉인은 개정 범위에 넣지 않는다.
+
+향후 수정 파일은 해당 `Stage_2_S2_00.yml` 하나다. `Stage_2_S2_00_v.2.yml`, runtime mirror, 외부 workflow/binding/schema, manifest, builder는 함께 수정하지 않는다. 그 결과 기존 package builder의 parity나 parent release 봉인을 충족한다고 주장할 수 없다. 기존 builder를 돌려 이 YAML을 다시 덮어쓰는 것도 하지 않는다. 전체 패키지의 배포 승인과 S2_00 자체 기능 구현은 구별한다.
+
+## 9. 실행 허용 조건과 미확인 사항
+
+현재 release는 `DEV_FIXTURE_RELEASE`이며 현행 core에는 실제 사건 발행을 금지하는 `DEV_FIXTURE_REAL_RUN_FORBIDDEN` 방어가 있다. 후속 Agent와 무관한 인증·원본 신뢰 근거·S2_00 실행 허용 조건은 보존한다. 기존 전체 Stage 2 admission을 제거하면서 이를 임의의 `active:true`나 새 self-certified receipt로 대체하지 않는다.
+
+YAML 한 파일 안에서 기존 근거로 독립 검증 가능한 S2_00 실행 조건을 명시한다. 현재 DEV 상태만으로는 offline fixture 검증까지만 가능하다. 실제 사건 발행에 필요한 승인·참조 지원 이외의 실행 조건이 외부 패키지 변경을 요구한다면 그 부분은 **현재 범위에서 live 미완료**로 기록한다. 다른 Stage의 준비 상태를 S2_00 내용 설계의 제약으로 다시 가져오거나, guard를 꺼 실제 사건 시험을 통과시키는 방법은 채택하지 않는다.
+
+`{{prev.###}}` 결과물 사용을 backend Python 실행 환경이 허용한다는 점은 사용자 설명으로 채택했으므로 미지원·지원 여부 미확인으로 기록하지 않는다. 이번 작성에서 실행 확인하지 않은 항목은 실제 파일 참조·두 root의 올바른 대응, 인증 치환, 필요한 Stage 1 신뢰 근거의 완비, 같은 출력 root의 writer 직렬화, S2_00 독립 실행 허용 조건이다. 이는 지원 기능의 존재와 그 기능을 사용한 개정 YAML의 실행 검증을 구별한 것이다.
+
+## 10. 수용 기준과 검증 계획
+
+아래는 향후 YAML 구현의 검증 계획이며 이번 작업에서 실행한 시험 결과가 아니다. 검증용 fixture·임시 출력은 임시 디렉터리를 사용하며 저장소에 다른 시험 자산을 새로 만들 필요는 없다.
+
+| 검증 면 | 수용 기준 |
+|---|---|
+| 개정 범위 | 실제 수정 YAML은 S2_00 배포본 하나. S2_10~40·authoring·외부 자산 수정 없음 |
+| 구조 | Agent stage 하나, ingress task·`run_code` 하나. DAG와 `tasks/0` pointer 일치 |
+| 직접 전달·결과 참조 | 두 root가 실행 진입점에 그대로 도달하고 `{{prev.###}}`가 의도한 Stage 1 결과물로 해석됨. 지원 표현식은 허용하며 해석 후 필수 미치환·누락·잘못된 파일 대응·경로 탈출·출력/원본 중첩은 사용·쓰기 전에 차단 |
+| 군더더기 제거 | prepare·고정 request 파일 read/write 0; `request_id` 입력·생성·출력 0; request를 대체하는 새 ID 0; `attempt_id` 필수 인자·출력 0 |
+| 원본·검증 | Stage 1 원본 변경 0. 참조로 제공된 고정 16개·동적 signal과 원본 경로/pointer의 대응, 필요한 배포/schema 검증 수행. 원문 따옴표·개행 보존, raw hash 불일치·manifest 탈출·필요한 두 read-pass 변경 검출 |
+| 자산 범위 | 실제 S2_00 사용 근거가 있는 자산만 읽음. 후속 YAML·LLM binding·후속 schema/route 계약을 요구하지 않음 |
+| 내용 보존 | source pointer dereference 결과와 hash 일치. 사실·목표 제약·증거·신호·review·명시적 관계 누락 없음. 미상·blocking 유지 |
+| 정상·차단 | 자체 상태와 실제 artifact 목록 일치. 차단 결과를 정상 context로 표현하지 않음. 원본에 없는 관계를 생성하지 않음 |
+| 재실행·발행 | 동일 완료 결과만 재사용. 불일치·부분 충돌은 거절. 비 status write/read-back 실패 시 새 정상 status를 발행하지 않음. 기존 status 존재는 별도 확인 |
+| 임시·동시 실행 | 임시 작업 디렉터리는 분리되고 출력에 임시 ID 없음. 원격 동시 발행 보장은 실증 전 미확인으로 기록 |
+| live | 기존 backend Python 실행 환경에서 `{{prev.###}}` 결과 사용·두 root 대응·인증·원본 검증·결과 write/read-back·마지막 status 확인. 채택된 지원 전제, offline PASS, 실제 실행 결과를 구별 |
+
+검증은 먼저 경로·결과 참조 대응·참조 누락/미치환·ID 제거·정상/차단·원본 보존·pointer·재실행·발행 실패를 다루는 한 차례의 종합 offline 검증으로 수행한다. 수정이나 새 실패가 생겼을 때 해당 영향만 재확인한다. S2_10~40과의 E2E·호환 시험, 법률 판단의 타당성 승인, 전체 패키지 production readiness는 수용 기준에 넣지 않는다.
+
+## 11. 효율성과 남는 비용
+
+계획상 executor task는 2→1, 고정 request 파일은 1→0, 별도 request ID 생성·출력은 0으로 줄인다. prepare 호출, request 저장·read-back·재읽기, ID 호환 처리, 후속 자산의 불필요한 읽기를 제거하고 `{{prev.###}}`로 이미 제공된 Stage 1 결과를 재사용하는 것이 절감 지점이다. 이미 Stage 1 결과를 직접 읽는 방식에 추가 ID 처리를 붙이는 것이 더 효율적이라고 주장하지 않는다.
+
+S2_00은 비 LLM 작업이므로 ID 제거 자체가 큰 모델 토큰 절감을 보장하지 않는다. inline code의 전달량·billing과 필요한 원본 검증 비용은 남는다. 속도·비용·토큰 절감률은 실제 실행 요청 크기, 읽기 횟수, task 시간과 청구 값을 측정하기 전까지 미측정으로 둔다.
+
+## 12. 작성 작업의 결정·검증 기록
+
+| 결정 | 근거 | 결과 |
+|---|---|---|
+| 두 Stage 1 root 직접 전달과 request ID 전면 제거 | 이번 사용자 절대 원칙 | v1 §4.3의 내부 호환 ID 정책 폐기 |
+| S2_00 YAML 한 파일을 향후 개정 대상으로 한정 | 사용자 범위 제한 | downstream 호환·외부 자산 재봉인 계획 제외 |
+| 원본 의미·검증 유지, 자체 출력 축소 | S2_00의 C00–C15 기능 목표 | 전송 단순화와 기능 완결을 함께 검증 |
+| 기존 root·자료 참조·hash 재사용 | 추가 요청 식별자를 만들지 않는 원칙 | 원본 보존, 출처 확인, 재실행 충돌 판별 가능 |
+| `{{prev.###}}`와 backend Python 실행 허용 채택 | 이번 사용자 추가 설명 | v2의 지원 여부 미확인·전달 방식 탐색 전제를 대체 |
+| 참조·root 대응과 live 허용 조건은 구현 시 검증 | 실제 YAML 개정·실행 시험은 이번 범위 밖 | 지원 전제·전략·offline·live·패키지 승인 상태 구별 |
+
+이번에는 v2를 보존하고 이 v3 전략서를 생성하며 지정 MEMORY에 요약을 삽입했다. v2의 직접 전달·ID 제거·S2_00 한정 원칙을 유지하고, `{{prev.###}}` 사용 및 backend Python 실행 환경의 허용을 목표·입력 경계·원본 사용·변경 순서·수용 기준·상태 기록에 반영했다. 저장 후 UTF-8·종결 LF·fence 8개·로컬 링크 5개, 이전 미확인 전제의 제거와 관련 절 간 정합성, 요약 위치를 정적으로 확인했다. 작업 전 기존 파일 611개 중 MEMORY를 제외한 610개의 SHA-256이 동일하며, MEMORY도 이번 요약 삽입 외의 내용은 보존했다. 새 파일은 이 전략서 하나다. 실제 YAML 개정, inline 실행, builder·release 재봉인, MCP/backend/live 시험, 배포·commit은 수행하지 않았다.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/MEMORY.md

@@ -16,6 +16,37 @@
 - 하위 에이전트(subagents)를 사용하여 핵심 테마와 교훈을 식별하고 MEMORY.md에 섹션으로 저장하라.
 - 향후 세션 시작 시 MEMORY.md의 이전 섹션을 참조하라.
 
+## 2026-10-02 — S2_00 YAML v3 직접 인계 구현
+
+한 줄 요약: 전략 v3·지정 SKILL·Code Executor notebook에 따라 S2_00을 단일 deterministic ingress로 개정했다. Stage 1 사건·배포 root와 `{{prev.###}}` 결과물을 직접 재사용하며 별도 request/attempt/run ID와 준비 task를 제거한다.
+
+- C00–C15의 원본 계약·seal·hash·보존 검증, 원본 pointer 정규화, claim-neutral cluster·의존 관계·review/signal 보존을 유지한다. 필요한 Stage 1 배포 의존만 읽고 자체 5개 산출물을 검증한 뒤 status를 마지막에 기록하며, 완료본은 byte 일치 시 재사용하고 불완전·충돌 출력은 덮어쓰지 않는다. 기존 중첩 Counter 비교 오류와 원본 배열 pointer 불일치도 수정했다.
+- 원본은 `Default_Agent/Stage_2_Clean/agent_scripts/Stage_2_S2_00_10_02.yml`, 개정 복제본은 본 폴더 `Stage_2_S2_00_v.3.yml`로 byte-identical 저장했다. 오프라인·모의 시험 39건, YAML/DAG·Python 3.11/3.12 문법, Stage 1 승인 의존 55개 hash와 선택적 의존 로딩을 확인했다. 실제 backend 치환·MCP 실행·동일 root 동시 writer·배포 성공은 검증하지 않았다.
+- 기존 `DEV_FIXTURE_RELEASE`의 실제 사건 발행 차단은 유지한다. S2_10~40·전략서·SKILL·notebook·schema·mirror·release는 변경하지 않았으며 builder/재봉인/live 실행/commit도 수행하지 않았다. 단일 YAML 구현 검증을 기존 패키지 전체 정합성이나 운영 승인으로 해석하지 않는 것이 핵심이다.
+
+## 2026-10-02 — S2_00 Stage 1 결과 참조 반영 전략 v3
+
+한 줄 요약: v2를 보존하고 `Default_Agent/Stage_2_Clean/agent_scripts/stage_2_s2_00_revision_strategy_v3.md`를 생성하여 `{{prev.###}}`(`###`는 Stage 1 결과물 파일)를 통한 원본 사용과 backend Python 실행 환경의 허용을 사용자 설명에 따른 설계 전제로 반영했다.
+
+- Stage 1 사건·배포 root 직접 전달, request ID 전면 제거, S2_00 YAML 한 파일 개정·S2_10~40 계약 제외 원칙은 유지한다. v2의 참조 지원 여부 미확인·전달 방식 탐색 전제를 대체하고 결과 참조를 목표·입력 경계·원본 사용·변경 순서·수용 기준에 연결했다.
+- 지원되는 기능의 존재와 개정 YAML에서의 실제 파일/root 대응·원본 동일성·발행 성공 검증을 구별한다. 문서 구조·로컬 링크 5개·미확인 전제 제거·요약 위치와 기존 610개 파일의 hash 보존을 정적으로 확인했다. MEMORY 기존 내용도 삽입 외에는 보존했다. 이번 작성은 v3 전략서·본 요약만 변경했으며 YAML/자산 개정·backend/live 시험·배포·commit은 수행하지 않았다.
+
+## 2026-10-02 — S2_00 한정·request ID 제거 개정 전략 v2
+
+한 줄 요약: `Default_Agent/Stage_2_Clean/agent_scripts/stage_2_s2_00_revision_strategy_v2.md`를 작성하여 Stage 1 사건·배포 root 직접 전달, 별도 `request_id` 입력·내부 생성·출력 제거, S2_00 배포 YAML 한 파일 개정을 원칙으로 확정했다.
+
+- v1의 내부 호환 ID·downstream schema/route·49개 자산 일괄 유지·다중 파일 재봉인 전제를 대체한다. S2_10~40의 자산 사용 계약을 무시하고 C00–C15 자체 기능, 필요한 원본 검증·의미 보존·자체 출력과 마지막 status만 완료 기준으로 삼는다.
+- 기존 사건 root·원본 식별값·검증 hash를 재사용하고 임시 디렉터리로 작업을 격리한다. 직접 전달에 ID 처리를 추가하는 것은 효율 향상 수단이 아니며, 불필요한 전달층·의존 읽기를 제거하는 것이 핵심 교훈이다. backend 인자 결속·원격 동시 writer·DEV guard에 따른 live 제한과 기존 패키지 봉인 미충족 가능성은 남긴다.
+- 이번 작성은 전략서·본 요약만 변경했다. 저장 경로·로컬 링크 5개·UTF-8/fence·요약 위치와 기존 609개 파일의 hash 보존을 정적으로 확인했다. MEMORY 기존 내용도 삽입 외에는 보존했다. 실제 YAML/자산 개정·실행 시험·builder·재봉인·배포·commit은 수행하지 않았다. v1은 과거 전략으로 보존한다.
+
+## 2026-10-02 — S2_00 직접 인계 개정 전략 v1
+
+한 줄 요약: `Default_Agent/Stage_2_Clean/agent_scripts/stage_2_s2_00_revision_strategy_v1.md`에 두 Stage 1 root를 직접 받아 단일 ingress task에서 검증·C00–C15·발행을 수행하고, prepare·고정 request 파일·외부 ID 부여를 없애는 최소 변경 전략을 작성했다.
+
+- Stage 1 원본과 16개+manifest 신호·배포 55개·Stage 2 직접 자산 49개, 두 read-pass·기존 출력/barrier를 재사용하며 ID는 내부 호환 값으로 처리한다. 입력 전달 단순화와 기존 slice·pointer·review 의미 보완을 구별하는 것이 핵심 교훈이다.
+- 지정된 `Stage_2_10_Analysis_v1.md`는 실제 S2_10 분석이므로 구형 S2_00 YAML·`Stage_2_00_Analysis_v1.md`와 교차 확인했다. backend 직접 입력 binding과 DEV release 제한은 미해결로 명시했다. 전략서·본 요약만 작성했으며 YAML/자산 개정·재봉인·시험/live 실행·배포·commit은 수행하지 않았다.
+- 문서 링크·16개 입력 목록·구조와 요약 위치를 정적으로 확인했고 참조 원본 15개의 SHA-256은 작업 전후 동일했다.
+
 ## 2026-10-01 — 현행 S2_00 배포 YAML 분석
 
 한 줄 요약: `Default_Agent/Stage_2_Clean/agent_scripts/Analysis_Stage_2_S2_00.md`에 현행 두-task DAG, C00–C15의 단일 ingress 실행 경계, 고정·동적 입력과 분기별 출력, 배포 자산·후속 route를 기록했다. prepare 함수의 request 저장 구현과 배포 YAML의 직접 실행 가능성을 구분하는 것이 핵심이다. 현재 네 외부 인자 결속·실패 차단·workspace 직렬화는 미검증이고, 직접 실행은 fail closed하며 DEV fixture release는 실제 사건 발행을 금지한다.