fix(stage2): validate direct S2_00 ingress

Correct Localdocs error handling and Stage 1 source adapters while preserving direct root handoff and status-last publication. Include version backups, v4-v6 copies, the v6 analysis, and execution notes.

Validation: v6 previously passed 58 regressions and a live workspace run with exit code 0 and READY_WITH_ISSUES. Confirmed staged source hashes, backup identity, Python syntax, and diff whitespace before commit.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/agent_scripts/Analysis_Stage_2_S2_00_v.1.md

@@ -0,0 +1,314 @@
+# Stage_2_S2_00.yml(v6) 분석서
+
+분석 기준일: 2026-10-02(KST). 분석 대상은 이 문서와 같은 폴더의 [Stage_2_S2_00.yml](./Stage_2_S2_00.yml)이며, Agent 이름은 `Stage_2_S2_00_v6`, Agent version은 `6.0.0`, algorithm version은 `s2_00_direct_ingress/6.0.0`이다. 대상 YAML의 SHA-256은 `63b5158eb2bb77524401ca3d15bb21c3740644c14ffa4728564354ff0db5b4a3`이다.
+
+분석의 우선 근거는 현행 YAML의 실제 코드·상수·task procedure이다. 실행 근거는 앞선 workspace 실행에서 다운로드한 v6 결과 5개를 이번 분석에서 다시 읽고 hash를 확인한 자료와 [Stage 2 작업 기록](../../../MEMORY.md)의 v6 항목이다. 기존 분석서나 개정 전략의 목표를 현행 구현으로 간주하지 않는다. S2_10~40의 YAML·자산 schema는 분석 기준에 포함하지 않았다. 이번 분석에서는 YAML 수정이나 workspace 재실행을 수행하지 않았다.
+
+## Executive Summary
+
+S2_00 v6은 Stage 1 사건 결과의 root와 배포 자산의 root를 직접 받아, 동일 workspace의 원본을 읽고 검증한 뒤 후속 작업이 읽을 수 있는 사건 context와 review 원장을 저장하는 단일 비 LLM Agent이다. 기본 사건 root는 `.`, 배포 root는 `Default_Agent`이다. 별도 request 파일이나 `request_id`·`attempt_id`를 만들지 않고, 독립 실행된 Stage 1 결과를 `prev`로 찾는 방식에도 의존하지 않는다.
+
+YAML에 등록된 실행 task는 `Task_S2_00_deterministic_ingress` 하나다. 이 task가 Code Executor의 `run_code`에 inline Python을 전달하고, Python이 Localdocs MCP를 통해 파일을 읽고 쓴다. C00·C05·C10·C15는 코드 안에서 수행하는 기능 구분이며 별도 task·LLM prompt·MCP 호출 단위가 아니다.
+
+주요 결과는 입력 목록, 입력 검증 보고서, review·issue 원장, 사건 context, 마지막 완료 상태의 5개 JSON이다. 기본 저장 위치는 workspace Root 기준 `stage2_runs/from-stage1/s2_00/v6/`이다. 차단 상태에서는 사건 context 대신 기술 진단 파일을 저장한다. 정상·차단 결과 모두 마지막 status를 완료 표지로 사용하며, 기존 완료 결과와 내용이 정확히 같을 때만 재사용한다.
+
+앞선 `10월_1일_구성` workspace 실행은 task `COMPLETED`, `exit_code=0`, `READY_WITH_ISSUES`, `PUBLISHED_STATUS_LAST`로 종료됐다. 다운로드한 결과의 검증 항목은 PASS 19개, FAIL 0개, UNEVALUABLE 2개다. 사건 context에는 증거 30개, 이벤트 71개, BO 57개, fact 57개, LES 47개, 신호 occurrence 475개와 cluster 46개가 들어 있다. review occurrence 1,128개를 보존했고, 이 중 1,126개는 `UNRESOLVED`, 2개는 `CONDITIONAL`이다.
+
+이 성공은 원본을 읽어 검증·구조화하고 결과를 저장하는 workspace 테스트의 성공이다. YAML의 허용 모드는 `WORKSPACE_EXECUTION_TEST`, 정책 분류는 `DEV_FIXTURE_RELEASE`로 유지되어 있다. producer 미확인 WARNING 11건, 원본 seal의 확인 불가, 신호 schema 검사 조건, 동일 출력 root의 동시 writer, 후속 Agent와의 연결은 별도 확인 범위로 남아 있다.
+
+근거: `run_inline_mcp`, `execute_ingress`, `publish_result` 및 다운로드한 `ingress_status.json`·`intake_report.json`·`case_context.json`·`issue_ledger.base.json`.
+
+## 전체 작업 DAG와 책임 경계
+
+### YAML에 등록된 실제 DAG
+
+```mermaid
+flowchart LR
+    IN["IN"] --> T["Task_S2_00_deterministic_ingress<br/>Code Executor run_code"]
+    T --> OUT["OUT"]
+```
+
+Stage는 `S2_00` 하나이며 `prevs: []`, `nexts: []`이다. task procedure의 `IN.nexts`가 단일 task를 가리키고, task는 `IN`을 기다린 뒤 `OUT`으로 연결된다. `OUT`은 이 task를 기다린다. `IN`·`OUT`은 procedure 경계 노드이고 별도 코드 실행 task가 아니다. Stage 1이나 S2_10을 자동 실행시키는 DAG edge는 없다.
+
+### 단일 task 내부의 처리 흐름
+
+```mermaid
+flowchart TD
+    R["사건·배포 root 및 실행 모드 검증"] --> A["backend workspace context로 Localdocs initialize"]
+    A --> H["Stage 1 원본·신호·선택된 배포 자산 hydration"]
+    H --> V["입력 계약·schema·hash·SG01·보존 관계 검증"]
+    V --> N["review occurrence 정규화 및 처리 상태 판정"]
+    N --> B{"BLOCKED인가"}
+    B -- "아니오" --> C["원본 member·명시적 관계·cluster·bundle 구성"]
+    B -- "예" --> D["technical_diagnostic 구성"]
+    C --> O["상태별 결과 5개 및 provenance·출력 계약 검증"]
+    D --> O
+    O --> S["읽은 원격 원본을 재독해 최초 bytes와 비교"]
+    S --> P["기존 출력 충돌 확인"]
+    P --> W["비 status 파일 쓰기·read-back 후 status 기록<br/>또는 동일 완료 결과 재사용"]
+    W --> E["stdout receipt 및 exit code"]
+```
+
+위 흐름의 역할은 다음처럼 나뉜다. C00~C15는 이해를 위한 대응표이며, 실행 순서가 네 개의 독립 task로 분리되는 것은 아니다.
+
+| 기능 구분 | 실제 책임 | 주요 구현 |
+|---|---|---|
+| C00 | 원본 확보, 고정 입력·정책·schema·producer·transaction·hash·gate·보존 관계 확인 | `hydrate_stage1`, `validate_ingress_contracts`, `expand_stage2_signal_all`, `verify_cross_artifact_seals`, `check_conservation` |
+| C05 | 원본의 정확한 배열 위치 판독, JSON pointer·값 digest·원문 projection 보존, review 정규화 | `_source_record_locations`, `_record_locations_for_signal`, `_provenance`, `normalize_review_items` |
+| C10 | 명시적인 원본 참조로 member를 연결하고 claim-neutral cluster 및 후보 의존 관계 구성 | `compile_case_context`, `_tarjan_scc` |
+| C15 | cluster bundle·scheduling wave·결과 파일 구성, 원본 재독, 출력 검증·발행 | `compile_case_context`, `validate_output_files`, `verify_remote_stability`, `publish_result` |
+
+### 시스템별 책임 경계
+
+| 구성 요소 | 담당 책임 | S2_00 코드가 대신 수행하지 않는 사항 |
+|---|---|---|
+| Stage 1 | 사건 원본·증거·BO·LES·fact·signal·review 결과 작성 | S2_00은 Stage 1 자료를 수정하거나 Stage 1 task를 재실행하지 않는다 |
+| Agent backend | YAML task 실행, backend 변수 치환, workspace 실행 context 제공 | S2_00은 사용자 입력 문장에서 사건 root를 추론하지 않는다 |
+| Code Executor | inline Python 실행, 지정 requirements·network·timeout 적용 | YAML 자체에 여러 Python 작업을 병렬 실행하는 task fan-out은 없다 |
+| Localdocs | workspace 파일 읽기·쓰기와 디렉터리 저장 처리 | Python 임시 디렉터리와 원격 출력의 동시성 제어는 다른 문제다 |
+| S2_00 Python | 원본 해석·검증, 구조화, 자체 출력 계약, status-last 발행 | 청구권 확정·증거의 법적 평가·소장 작성·다음 Agent dispatch는 수행하지 않는다 |
+| 후속 소비자 | 저장된 상태·hash·context·review를 읽고 후속 작업에 사용 | 어떤 후속 Agent가 어떻게 소비하는지는 이 YAML에 연결되어 있지 않다 |
+
+근거: YAML의 `Stages`·`task_procedure`, `run_inline_mcp`, `execute_ingress`, `compile_case_context`.
+
+## 실제 실행단위와 prompt 구성
+
+### 실행 설정
+
+| 항목 | 현행 값·동작 |
+|---|---|
+| Agent / Stage / task | `Stage_2_S2_00_v6` / `S2_00` / `Task_S2_00_deterministic_ingress` |
+| 실행 클래스 | `NON-LLM-DETERMINISTIC` |
+| 외부 실행 도구 | `mcp: code-executor`, `tool_name: run_code` |
+| 언어·requirements | `python`, `httpx==0.28.1` |
+| 실행 network·timeout | `agent-network`, 300초 |
+| Code Executor endpoint | `https://code-executor.mcp.eroomai.com/mcp` |
+| Localdocs endpoint | `http://mcp-localdocs:8012/mcp` |
+| 실행 entrypoint | `raise SystemExit(run_inline_mcp())` |
+| 구현 크기 | 분석 시점 YAML 3,064행, inline Python 2,992행 |
+
+### prompt의 실제 형태
+
+이 YAML에는 LLM에게 사건 내용을 전달하는 `system_prompt`·`user_prompt`·모델 선택 설정이 없다. Agent·Stage·task의 `description`은 작업 설명이고, 작업의 실제 명세는 `parameters.code`의 Python 및 그 안의 `SOURCE_POLICY`다. 따라서 자연어 사용자 입력을 바꾼다고 Python의 기본 root나 출력 계약이 바뀌지 않는다. root 변경은 inline 상수 또는 `run_inline_mcp(run_root, deployment_root)`의 인자를 통해 이루어진다.
+
+`SOURCE_POLICY`는 16개 고정 원본과 신호 payload family, 배포 의존 hash pin, adapter 결정, review 상태 매핑, 정책 분류·크기 제한을 inline JSON으로 보유한다. 외부 Stage 2 release 파일을 읽어 이 정책을 대체하는 흐름은 없다. YAML의 metadata는 설명·계약 표시이고, 실제 파일 선택·판정·저장 동작은 코드에 구현되어 있다.
+
+Localdocs 세션은 backend가 치환한 `{{__user_hash__}}`·`{{__workspace_hash__}}`를 `initialize.clientInfo`에 전달해 구성한다. 코드가 새 token이나 workspace 식별값을 발급하는 것은 아니다. 값이 미치환 상태이거나 hash 형식이 맞지 않으면 초기화 전에 실패한다. MCP protocol은 `2025-03-26`을 요구하며 session ID를 유지한 뒤 `notifications/initialized`를 보낸다.
+
+파일 접근은 `read_binary_doc`와 `write_binary_file`로 수행한다. 읽기 응답은 binary envelope의 Base64를 원본 bytes로 복원한다. JSON/SSE 응답과 일반 MCP 오류 외에, Localdocs가 정상 content block으로 돌려주는 `Error: Document not found: ...`도 구별한다. 누락 파일과 도구 실패를 JSON 파싱 오류로 혼동하지 않는 것이 v6의 실제 실행을 가능하게 한 수정 중 하나다.
+
+직접 LLM 호출이 없으므로 S2_00 자체의 사건 추론 토큰은 발생시키지 않는다. 다만 backend가 큰 inline 코드를 어떻게 전달·기록·과금하는지, requirements 준비 비용 및 전체 파이프라인 토큰 절감 효과는 이 YAML 분석만으로 확정할 수 없다.
+
+근거: task `parameters`, `SOURCE_POLICY`, `_InlineLocaldocs`, `_inline_tool_text`, `_context_hash`, `run_inline_mcp`.
+
+## In & Out 설명
+
+### In: 직접 전달되는 두 root와 실행 context
+
+| 입력 | 기본값 | 의미 |
+|---|---|---|
+| `STAGE1_RUN_ROOT` | `.` | 인증된 workspace Root에 있는 Stage 1 사건 결과의 기준 경로 |
+| `STAGE1_DEPLOYMENT_ROOT` | `Default_Agent` | Stage 1 배포 registry·schema·domain config의 기준 경로 |
+| backend user/workspace hash | backend 치환값 | Localdocs에서 접근할 user·workspace context |
+| `EXECUTION_MODE` | `WORKSPACE_EXECUTION_TEST` | 현행 YAML에서 허용하는 유일한 실행 모드 |
+
+root는 검증된 상대 경로로 취급하며 절대 경로·상위 경로 이동·미치환 템플릿을 허용하지 않는다. 사건 root `.`는 workspace 전체를 기준으로 삼기 위한 예외다. 실제 읽기는 고정 입력 경로와 signal manifest가 지정한 경로에 한정된다. 배포 root와 출력 경로의 겹침은 거절한다.
+
+### In: 고정 Stage 1 원본 16개
+
+아래 경로는 모두 사건 root에 상대적이다. 논리 입력 이름은 코드가 원본을 찾는 내부 key이며 새로운 요청 ID가 아니다.
+
+| 논리 입력 | 파일 경로 | 주요 용도·판독 구조 |
+|---|---|---|
+| `evidence_indexed` | `evidence_indexed.json` | `items[]`의 증거; 기존 ID는 `evidence_index` |
+| `evidence_event_candidates` | `evidence_event_candidates.json` | `items[]/event_candidates[]`의 이벤트; 기존 ID는 `candidate_id` |
+| `client_goal` | `client_goal.json` | 목표·제약·당사자 등 사건 운영 context |
+| `domain_screening` | `routing/domain_screening.json` | domain screening 결과 |
+| `domain_activation_manifest` | `routing/domain_activation_manifest.json` | 활성·지원·감시 domain 등 routing 근거 |
+| `b1_evidence_indexed_gate` | `quality_gates/B1_evidence_indexed_gate.json` | 증거 gate·review·진행 허용 여부 |
+| `b2_event_candidates_gate` | `quality_gates/B2_event_candidates_gate.json` | 이벤트 gate 및 최종 item·candidate 개수 |
+| `stage1_part1_soft_gate_handoff` | `quality_gates/stage1_part1_soft_gate_handoff.json` | flat review handoff와 7개 digest guard |
+| `bo` | `BO.json` | 최상위 배열; `BO_ID`와 source provenance |
+| `signal_manifest` | `signals/signal_manifest.json` | 신호 파일 목록·hash·kind·count 및 `stage2: ["ALL"]` |
+| `stage1_part2_review_handoff` | `quality_gates/stage1_part2_review_handoff.json` | flat review handoff |
+| `legal_effect_structures` | `legal_effect_structures.json` | `structure_records[]`, BO 참조 및 역색인 |
+| `stage1_part3_review_handoff` | `quality_gates/stage1_part3_review_handoff.json` | 동명 wrapper 안의 review·`counts.review_items`·finalizer |
+| `fact_ledger_base` | `Fact_Ledger_base.json` | 최상위 배열; `fact_id`·`source_bo_id`·domain effects·calculation requests |
+| `fact_ledger_writer_report` | `stage1_tmp/fact_ledger/fact_ledger_writer_report.json` | fact 개수·domain coverage·calculation readiness·최종 raw hash |
+| `stage1_part4_review_handoff` | `quality_gates/stage1_part4_review_handoff.json` | 동명 wrapper 안의 review·`counts.review_items`·finalizer |
+
+목록의 모든 고정 입력을 요구한다. 누락 입력별 criticality·impact scope를 기록하지만, 현행 `execute_ingress`는 고정 입력 집합이 완전하지 않으면 전역 `BLOCKED`로 처리한다. 일부 cluster만 남겨 정상 context를 발행하는 경로는 없다.
+
+### In: signal manifest로 확장하는 입력
+
+`downstream_read_sets.stage2`는 정확히 `["ALL"]`이어야 한다. `files[i].path`는 `signals/` 접두사가 없는 상대 경로이며, 실제 원본은 `<사건 root>/signals/<files[i].path>`에서 읽는다. 파일 순서와 occurrence를 보존하며 중복 파일 행, 미승인 kind, hash·개수 불일치는 검출한다.
+
+| 신호 kind·형태 | 처리 방식 |
+|---|---|
+| `canonical` | 의미 자료로 읽는다. SG01은 `domain_activation_manifest.domain_entries[]`, 일반 정본은 `records[]`를 occurrence로 취급한다 |
+| `domain_signal` | `domain_signal_envelope` 안의 `element_fact_candidates[]`·`opposing_fact_candidates[]`·`defense_candidates[]`를 순서대로 펼친다 |
+| `compatibility_view` | 파일·hash·개수·registry 관계를 검증하지만 의미 occurrence에 다시 합치지 않는다 |
+
+성공한 실행에서는 신호 파일 30개를 읽었다. 정본 13개, domain signal 14개, compatibility view 3개이며, 의미 occurrence는 475개다. `USED`·`UNUSED`·`UNMAPPED` 모두 보존한다. SG01의 routing 원본과 signal 원본은 별도로 읽고, 승인된 17개 필드의 의미 projection을 비교한다.
+
+### Out: 결과 파일과 저장 위치
+
+기본 출력 root는 다음과 같다.
+
+```text
+workspace Root/
+└── stage2_runs/from-stage1/s2_00/v6/
+    ├── ingress/
+    │   ├── stage1_input_manifest.json
+    │   ├── intake_report.json
+    │   └── ingress_status.json
+    ├── review/
+    │   └── issue_ledger.base.json
+    └── context/
+        └── case_context.json
+```
+
+사건 root가 `.` 이외의 상대 폴더이면 `stage2_runs/from-stage1/<stage1_run_root_ref>/s2_00/v6/`에 저장한다. `v6`는 고정 구현 개정 폴더이며 실행마다 새로 발급하는 ID가 아니다.
+
+| 결과물 | 포함 내용 |
+|---|---|
+| `ingress/stage1_input_manifest.json` | 고정 입력·동적 신호의 논리 이름, 원본 경로·raw hash·byte length·검증 상태와 읽은 배포 자산 목록 |
+| `ingress/intake_report.json` | 보존·join·digest 검증 결과, 발견한 issues, 입력별 계약 판정 |
+| `review/issue_ledger.base.json` | review의 원문 content·정확한 출처·원본 status/severity·정규화 partition·blocking, 보존 상태, 기술 issues |
+| `context/case_context.json` | 원본 member와 관계, 후보 의존·미해결 참조, cluster·bundle·wave, 목표·routing·신호·review 참조, 객체·당사자·slot 관측 참조, 활성 profile |
+| `ingress/ingress_status.json` | 처리 status·두 root·algorithm/schema·실행 모드·정책, 읽은 원본·배포 파일의 hash, 나머지 4개 결과의 hash·byte length와 완료 표지 |
+
+`BLOCKED`이면 `context/case_context.json`을 발행하지 않고 `ingress/technical_diagnostic.json`으로 대체한다. 이 경우에도 파일 수는 5개다. root·인증·hydration·발행 단계의 예외로 `FAILED`가 되면 이 5개 파일을 반드시 만든다는 보장은 없다.
+
+### 상태·stdout·재실행
+
+| 상태·발행 값 | 실제 의미 |
+|---|---|
+| `READY` | 차단 사유 없이 context를 만들 수 있고 코드가 집계하는 issues·미해결 review·원본 seal 미확인이 없는 상태 |
+| `READY_WITH_ISSUES` | context와 결과를 발행할 수 있으나 WARNING·미해결 review·확인 불가 seal 등이 남음 |
+| `BLOCKED` | 필수 입력·검증·상위 gate/review·context 구성에서 차단; 정상 context 없이 진단 결과를 발행 |
+| `FAILED` | 실행 wrapper가 잡은 runtime·transport·root·인증·발행 등 예외; stdout error로 종료 |
+| `PUBLISHED_STATUS_LAST` | 비 status 파일 4개를 write/read-back한 후 status를 마지막에 기록 |
+| `REUSED_COMPLETED_OUTPUT` | 기존 status와 결과 전체가 새 계산 결과와 byte 단위로 동일함을 확인해 재사용 |
+
+`READY`·`READY_WITH_ISSUES` receipt는 `ok=true`, exit code 0이다. `BLOCKED`는 진단 파일이 저장되어도 `ok=false`, exit code 2이며 `FAILED`도 exit code 2다. receipt에는 status·output root·publication·status hash 등이 들어가고, 별도 request ID는 없다. JSON 결과는 canonical 직렬화 후 newline을 붙여 동일성 비교에 사용한다.
+
+완료 status가 있으면 status bytes와 결과 파일 전체를 비교한다. 다른 입력·버전·내용은 `EXISTING_OUTPUT_CONFLICT`, 결과 손상은 `EXISTING_OUTPUT_CORRUPT`로 거절한다. status 없이 일부 결과가 있으면 `PARTIAL_OUTPUT_CONFLICT`로 거절한다. 동일 사건 root에서 입력을 변경한 재실행은 자동 overwrite나 새 실행 폴더 생성으로 처리되지 않는다.
+
+근거: `DEFAULT_SOURCE_CONTRACTS`, `validate_direct_roots`, `expand_stage2_signal_all`, `execute_ingress`, `validate_output_files`, `publish_result`, `run_inline_mcp`.
+
+## 작업용 고정 자산
+
+### YAML 내부에 고정된 자산
+
+| 자산 | 역할·경계 |
+|---|---|
+| inline Python | 파일 접근·검증·정규화·graph·발행의 실제 구현. 별도 Python 모듈을 배포 폴더에서 import하지 않는다 |
+| `SOURCE_POLICY.stage1_sources` | 16개 고정 입력과 `signal_payload_family`의 정확한 집합·경로·adapter·schema·producer 기대값 |
+| `SOURCE_POLICY.dependency_locks.stage1` | Stage 1 자산 55개에 대한 경로·SHA-256 pin의 허용 목록 |
+| `adapter_decisions` | 원본 envelope, signal ALL, dual SG01, P1~P4 handoff, BO·fact, domain config, review mapping, 제한된 signal writer alias의 계약 |
+| `ROW_KEYS`·review key·관계 kind 상수 | 허용 배열 위치와 review 탐색 범위, 명시적 관계·후보 의존의 판독 범위 |
+| 자체 출력 validator | 상태별 5개 파일, 상위 필드 집합·버전·root·artifact hash 등의 계약 |
+
+현재 `SOURCE_POLICY`는 `DEV_FIXTURE_RELEASE`이며, 배포 lock의 snapshot date는 `2026-08-29`이다. 55개는 전체 Stage 1 runtime release를 증명하는 목록이 아니라 이 구현이 참조할 수 있도록 고정한 범위다. lock에는 `full_stage1_runtime_release_status: STAGE1_NOT_RELEASE_READY`도 남아 있다. 이 표시는 현행 workspace 실행 성공과 서로 다른 수준의 정보다.
+
+### Stage 1 배포 root에서 읽는 자산
+
+| 자산군 | lock 범위 | 실제 선택 방식 |
+|---|---|---|
+| registry·manifest | `runtime_manifest.json`, `domains/_registry_index.json`, `signals/signal_registry.v2.json`의 3개 | registry 2개는 기본으로 읽음. `runtime_manifest.json`은 pin 목록에 있으나 기본 hydration의 필수 읽기 대상은 아님 |
+| domain config | `domains/<domain_id>/domain_config.json` 26개 | activation의 `active_domain_ids`에 들어 있는 config만 읽음 |
+| platform·signal schema | schema 및 공통 schema 26개 | 4개 고정 입력 schema ref, signal registry가 선언한 schema·domain envelope, 그들의 외부 `$ref`를 따라 선택 |
+
+26개 config의 domain은 `E-00~E-21`, `EC-00`, `X1~X3`다. 기본으로 schema ref가 있는 고정 입력은 routing activation, signal manifest, LES, fact ledger의 4개다. 나머지 고정 입력은 adapter의 필수 shape·key 확인과 개별 보존 검증을 사용한다.
+
+선택된 모든 배포 자산은 inline pin과 raw hash가 같아야 한다. 필요한 자산이 허용 목록에 없거나 hash가 다르면 hydration에서 실패한다. schema의 외부 참조는 이 로컬 허용 목록 안에서 하나의 자산으로 결속하며 외부 URL에서 schema를 내려받지 않는다.
+
+성공한 실행의 배포 자산은 35개였다. registry 2개, 활성 domain config 14개, schema 19개(공통 schema 2개 포함)이다. 사건 원본 16개와 신호 파일 30개를 합해 읽은 고유 파일은 81개다. 선언된 55개 전체를 매번 읽는 구조가 아니다.
+
+Stage 2의 별도 prompt library·renderer·dispatch schema·S2_10~40 자산은 읽지 않는다. domain config는 `active_profiles`로 보존되지만, config의 element·defense·calculation slot을 법적 판단으로 채워 넣는 실행기는 이 YAML에 없다.
+
+### 크기·보존 경계
+
+원본 한 파일은 32 MiB, hydration의 고유 입력 합계는 256 MiB까지 허용한다. strict JSON 판독은 중복 key·비표준 상수·잘못된 UTF-8 등을 거절하고, 중첩 깊이 96·item 한도 1,000,000을 사용한다. 로컬 snapshot은 경로·symlink·파일 상태 변경을 검사하고 raw SHA-256을 보유한다.
+
+코드 실행별 `TemporaryDirectory`는 hydration을 격리하고 종료 시 정리된다. 임시 폴더의 고유 이름은 출력 root나 요청 ID로 노출하지 않는다. 이 임시 작업 격리는 원격 저장소의 동일 root 동시 발행 문제를 해결하는 장치는 아니다.
+
+근거: `SOURCE_POLICY`, `hydrate_stage1`, `_schema_dependencies`, `load_json_strict`, `open_bounded_snapshot`.
+
+## Upstream/Downstream 설명
+
+### Upstream: Stage 1 결과·배포와의 결속
+
+| Stage 1 영역 | 주로 넘겨받는 자료 | S2_00이 확인하는 연결 |
+|---|---|---|
+| Part 1 | 목표·screening·activation·증거·이벤트·B1/B2 gate·P1 handoff | P1의 7개 raw digest, 증거·이벤트 참조, B2 최종 item·candidate 개수, 진행 허용 여부 |
+| Part 2 | BO·signal manifest 및 payload·P2 handoff | BO↔fact source BO multiset, BO provenance의 event 참조, 신호 파일·occurrence 보존, registry 및 SG01 대응 |
+| Part 3 | LES·P3 handoff | LES의 BO join·중복 ID·역색인·route count, P3 review count·finalizer, 기존 signal transaction 참조 |
+| Part 4 | fact ledger·writer report·P4 handoff | fact ID 순서, v8 확장 필드, writer report의 개수·coverage·readiness·최종 hash, P4 review count·finalizer |
+
+이 연결은 같은 workspace에서 파일을 읽는 자료 의존이다. YAML의 `prevs`가 Stage 1을 기다리거나 Stage 1의 실행 완료를 자동 입증하지 않는다. producer 기대값은 정책에 기록되어 있으며 원본의 제공값과 비교한다. P3·P4는 `created_by`가 최초 작성자이고 `finalized_by`가 최종 writer이므로 wrapper의 producer 판독에서 후자를 우선한다. signal writer alias는 승인된 한 쌍에만 적용한다.
+
+원본에 producer가 없으면 원본에 값을 보충하지 않고 `PRODUCER_ID_UNEVALUABLE` WARNING으로 남긴다. 고정 입력의 `raw_hash_source`는 현행 정책에서 모두 `UNAVAILABLE_DEV`이므로 별도 완료 seal로 전부 입증했다고 해석할 수 없다. 대신 실제 제공된 P1 digest·신호 manifest hash·fact writer hash를 각 기능에서 검증하고, 읽은 bytes 자체도 출력 manifest와 status에 남긴다.
+
+### Downstream: 저장된 파일을 통한 자체 handoff
+
+후속 소비자는 `ingress_status.json`의 상태와 artifact 목록·hash를 확인한 뒤, `context/case_context.json`과 `review/issue_ledger.base.json`을 읽을 수 있다. 이 문장의 소비 순서는 status-last 계약에 따른 권장 해석이며, 실제 후속 Agent가 이 순서로 읽는다는 것은 이 YAML에서 검증하지 않았다.
+
+context의 member는 BO·FACT·LES·EVIDENCE·EVENT다. 각 member는 기존 Stage 1 ID, 원문 projection, 필드별 provenance를 갖는다. 출처는 `logical_artifact_id`·정확한 `json_pointer`·원본 값의 canonical digest로 연결되며, 파일 경로·raw file hash는 입력 manifest에서 찾는다. projection은 schema·producer·metadata 등 일부 상위 key를 제외하고 나머지 값을 담으며, 제외된 값은 원본 pointer로 접근한다. 원본 전체를 output 폴더에 복제하는 방식은 아니다. `active_profiles.sha256`도 파싱된 config의 canonical digest이며, 배포 원본 bytes의 hash는 manifest의 `deployment_sources`와 구분해 읽어야 한다.
+
+cluster는 원본 참조 graph의 연결 성분이다. fact→BO, fact→evidence/event, LES→BO, BO→event, event→evidence 및 명시적인 fact 관계를 사용한다. 단순히 같은 domain이나 같은 당사자라는 이유만으로 새로운 edge를 만들지는 않는다. 다만 같은 증거에 연결된 여러 fact는 한 cluster로 합쳐질 수 있으므로 cluster를 독립 청구권이나 청구별 최종 그룹으로 해석해서는 안 된다.
+
+각 cluster의 `bundle`은 `member_refs`·`signal_indexes`·`review_refs`를 제공한다. 후보 관계 중 허용된 kind만 cluster 의존 edge로 사용하며, SCC를 묶어 scheduling wave를 계산한다. 이는 실행 순서를 설명하는 자료이지 backend task를 실제로 생성·병렬 dispatch하는 기능이 아니다.
+
+기존 원본 ID·transaction ID는 재사용한다. `CL-001` 형태의 cluster 참조와 signal occurrence용 파생 참조는 결과 내부 자료를 연결하는 값이다. 새 request·attempt·run ID를 생성하는 것과 구별된다. 소비자가 기존 S2_10~40 schema를 반드시 요구하는지, 변환이 필요한지 또는 새 소비 계약을 사용할지는 이번 분석의 확인 범위 밖이다.
+
+근거: `validate_ingress_contracts`, `check_conservation`, `bind_signal_occurrences`, `compile_case_context`, `publish_result`.
+
+## 구현과 계약 사이 확인사항 및 잔여 한계
+
+### 확인된 실행 근거와 그 범위
+
+| 확인 항목 | 확인 내용·범위 |
+|---|---|
+| 현행 구현 식별 | YAML hash `63b5158e…b5b4a3`, Agent v6, algorithm 6.0.0을 다시 확인 |
+| 실제 workspace 실행 | 앞선 실행에서 `10월_1일_구성`의 단일 task COMPLETED, exit 0, READY_WITH_ISSUES, PUBLISHED_STATUS_LAST |
+| 실행 시간 | 앞선 UI 전체 시간 5.1초, Code Executor 반환 시간 약 2.402초. 일반 성능 보장은 아님 |
+| 결과 파일 | 당시 내려받은 5개 결과를 재열람하고 status와 나머지 4개 artifact hash·byte length를 이번 분석에서 재검증 |
+| 최종 status hash | `7ea037548ea729275ce4f791d7ae2ada2d381427f1971ea6f30ccc3e4041eed3` |
+| 검증 집계 | PASS 19, FAIL 0, UNEVALUABLE 2. 후자는 LES 선언 총수·event disposition으로, 원본 미제공 값을 추정하지 않음 |
+| context 보존 | member 262개 = BO 57 + FACT 57 + LES 47 + EVIDENCE 30 + EVENT 71; 관계 385개, 미해결 참조 0 |
+| 신호·review | 신호 475개 = USED 240 + UNUSED 27 + UNMAPPED 208; review 1,128개 = UNRESOLVED 1,126 + CONDITIONAL 2 |
+| scheduling | cluster 46개, 후보 의존 관계 0개, wave 1개. scheduling 기능 전체의 다양한 graph 사례를 이 한 실행이 입증하지 않음 |
+| 앞선 회귀 검증 | 수정 세션 기록상 기존·실제 MCP 응답 시험 51건과 캡처 원본·변조 거부 시험 7건 통과. 이번 문서 작성에서 이 시험을 새로 실행한 것은 아님 |
+
+### 계약 문구와 실제 실행을 구별해야 하는 사항
+
+| 확인사항 | 현행 구현·관측 근거 | 의미와 잔여 범위 |
+|---|---|---|
+| 전역 완료 seal | `execute_ingress`는 별도 `completion_seal`·`contract_manifest`를 주입하지 않으며 고정 입력 16개 seal 상태는 모두 UNEVALUABLE | P1·신호·writer의 개별 hash 검증 및 원본 재독과 전체 run의 승인·완료 seal은 다르다 |
+| 신호별 JSON Schema 실행 조건 | registry schema는 읽지만, payload 검사는 manifest 행의 `schema`·`schema_path`가 문자열일 때 실행 | 성공한 manifest의 30개 행에는 이 두 필드가 없어 그 루프의 payload schema 검사는 수행되지 않았다. hash·count·registry·SG01 검증 성공을 모든 신호의 schema 검증 성공으로 확대하면 안 된다 |
+| schema·adapter 검사의 강도 | 고정 입력 4개는 schema ref를 사용하고 나머지는 shape·key와 별도 검증 사용; inline validator는 구현된 JSON Schema keyword 범위를 처리 | 모든 원본에 동일한 full schema 검사가 적용되지 않는다. 범용 JSON Schema 표준 전체 준수나 모든 의미 규칙 검증을 입증한 것은 아니다 |
+| review 보존과 해결 | 같은 내용도 원본 경로·pointer가 다르면 별도 occurrence로 보존; 현재 1,126건 UNRESOLVED | 1,128건은 고유 법률 쟁점 수가 아니다. handoff의 FINALIZED를 review 해결로 바꾸지 않으며 사건 판단·review 해소는 남아 있다 |
+| review unknown·blocking 표현 | 미등록 status/severity는 UNMAPPED로 보존하나 해당 매핑만으로 개별 issue를 추가하지는 않음. explicit blocking은 blocked 배열·boolean·BLOCKED status 및 BLOCKING/CRITICAL/FATAL severity 등 특정 표현으로 판정 | 정책의 unknown-value issue 문구와 실제 issue 생성은 구분해야 한다. `BLOCK` severity나 `blocks_final_drafting`만으로 S2_00 전역 차단을 자동 판정한다고 볼 수 없다 |
+| 신호 UNMAPPED | `signal_id`가 없는 occurrence는 참조 binding이 있어도 UNMAPPED로 분류; 실제 208개 보존 | 파일·개수 보존 성공과 모든 신호의 의미 식별·활용 완료는 다르다. 새 signal ID를 임의 발급해 해결하지 않는다 |
+| graph·slot 범위 | 명시적 참조 graph와 관측된 slot만 보존. profile은 담지만 slot 판정 엔진은 없음 | 공유 증거 연결을 청구권 동일성으로 볼 수 없고, 추론 관계·요건 충족·반박 slot·법적 선후 의존을 새로 확정하지 않는다 |
+| 자산 lock의 범위 | 허용 55개 중 필요한 35개를 읽은 실행; config는 active domain에 한정 | 전체 Stage 1 배포 봉인, 비활성 profile 검증, supporting/monitor config 전체 로딩의 성공을 의미하지 않는다 |
+| 출력 schema | 닫힌 상위 필드·버전·root·상태별 파일 집합·hash를 검사하고 provenance를 재검증 | 모든 중첩 출력 값에 독립적인 외부 JSON Schema 검증을 적용하는 구조는 아니다 |
+| 결과 버전 표시 | Agent·algorithm은 v6/6.0.0, 결과의 `schema_version`은 `stage2_s2_00_direct.v4` | algorithm 개정과 결과 구조 버전은 분리되어 있다. schema_version만 보고 실행 구현을 v4로 오인하면 안 된다 |
+| 전략과 현행 코드 차이 | 전략 v3의 `prev` 연결 및 개정 폴더 없는 출력 예시와 달리 현행은 직접 Localdocs 읽기·고정 `v6` 폴더 사용 | 실제 실행·경로의 판단 기준은 현행 YAML이다. `v6`는 이전 진단 보존을 위한 고정 개정 경로이며 새 실행 ID가 아니다 |
+
+### 실행·발행의 잔여 한계
+
+1. **workspace 테스트 모드만 허용한다.** 실행 성공 이후에도 정책은 DEV이며 생산 모드가 허용된 것이 아니다. Agent metadata의 `IMPLEMENTED_OFFLINE_VERIFIED`는 inline 표시이고, 실제 live 성공은 별도 실행 자료가 입증한다.
+2. **status-last는 논리적 완료 경계다.** 각 파일을 write/read-back한 뒤 status를 쓰지만, 여러 파일을 한 번에 원격 atomic transaction으로 commit하지 않는다. status 기록 뒤 read-back이 실패하면 원격 status가 존재하면서 wrapper는 FAILED를 반환할 수도 있다.
+3. **같은 출력 root의 동시 writer는 미검증이다.** 코드에 원격 lock·CAS·transaction이 없고, 존재 확인과 쓰기 사이의 경합을 임시 디렉터리만으로 막지 않는다.
+4. **재실행 복구는 자동화하지 않는다.** 동일 완료 결과는 재사용하지만 변경 입력·충돌·부분 결과는 거절한다. 정리·복구·별도 출력 위치 결정은 현행 코드의 자동 처리 범위가 아니다.
+5. **원본 재독은 시간 구간 전체의 snapshot을 보장하지 않는다.** 최초 bytes와 발행 직전 재독 bytes를 비교하지만, 재독 이후의 변경이나 서로 다른 파일 사이의 동일 시점 일관성을 원격 transaction으로 보장하지 않는다.
+6. **오류 위치에 따라 진단 파일이 없을 수 있다.** `execute_ingress` 내부에서 처리된 차단은 5개 진단 결과를 만들지만 hydration·인증·일부 입력 계약 함수·출력 검증·발행에서 바깥 wrapper로 전파된 예외는 FAILED stdout으로 끝날 수 있다.
+7. **Downstream 통합은 별도 확인 대상이다.** `nexts: []`이며 task dispatch나 소비자 schema binding이 없다. 결과가 저장됐다는 사실만으로 다음 Stage 2 Agent의 실행 가능성을 확정할 수 없다.
+8. **시간·토큰 경제성은 한 실행의 수치로 일반화하지 않는다.** 직접 파일 재사용과 단일 비 LLM task는 불필요한 전달층을 줄인다. 그러나 이 YAML은 큰 inline 정책·코드, 원본 2회 읽기, 검증·provenance·review projection을 유지하므로 비용·latency 전체를 별도 측정해야 한다.
+
+분석 결론은 현행 v6이 Stage 1 직접 인계 원칙을 구현하여, 관측한 workspace에서 원본 검증·구조화·자체 결과 발행을 성공적으로 수행했다는 것이다. 동시에 저장된 미해결 항목, 조건부로 수행되는 계약 검사, 원격 발행·후속 소비의 경계는 그대로 남아 있다.
+
+주요 코드 위치: `validate_ingress_contracts`(YAML 1019행), `expand_stage2_signal_all`(1347행), `check_conservation`(1701행), `hydrate_stage1`(2574행), `normalize_review_items`(2679행), `compile_case_context`(2738행), `execute_ingress`(2897행), `validate_output_files`(2978행), `publish_result`(3007행), `run_inline_mcp`(3025행). 행 번호는 위 SHA-256으로 식별한 분석 시점 YAML을 기준으로 한다.

Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/MEMORY.md

@@ -16,6 +16,29 @@
 - 하위 에이전트(subagents)를 사용하여 핵심 테마와 교훈을 식별하고 MEMORY.md에 섹션으로 저장하라.
 - 향후 세션 시작 시 MEMORY.md의 이전 섹션을 참조하라.
 
+## 2026-10-02 — S2_00 v6 현행 코드·입출력·책임 경계 분석서
+
+한 줄 요약: `agent_scripts/Analysis_Stage_2_S2_00_v.1.md`에 요청한 7개 목차로 현행 v6을 분석했다. 작업 DAG·자산·상태·검증 범위는 전략의 선언보다 실제 호출 경로를 기준으로 판독해야 한다.
+
+- 단일 task 안의 C00~C15, 16개 고정 입력·manifest 신호, 배포 pin 55개와 선택 로딩, 자체 결과 5개 및 status-last·동일 완료본 재사용을 정리했다. 당시 다운로드한 실행 결과의 hash를 다시 대조했고 YAML·복제본의 hash는 보존했다.
+- 성공한 manifest에는 `schema/schema_path`가 없어 신호별 payload schema 루프가 실행되지 않는 점, 고정 입력 16개 seal의 UNEVALUABLE, 미해결 review·UNMAPPED 신호 보존, config·slot·cluster의 의미 범위, 동시 writer·복구·후속 소비 계약의 미검증을 명시했다. 문서 7개 상위 목차·코드 행 번호·로컬 링크·fence를 확인했으며 YAML 변경이나 workspace 재실행은 하지 않았다.
+
+## 2026-10-02 — S2_00 v6 실제 MCP·Stage 1 원본 판독 오류 수정 및 workspace 실행 성공
+
+한 줄 요약: 자체 fixture가 실제 Localdocs 오류 문자열과 Stage 1 v.8 배열·count 구조를 반영하지 않아 파싱 실패·오차단이 발생했다. 실제 서버 함수와 다운로드한 원본으로 재현·수정하고 workspace에서 결과 파일까지 대조해야 실행 성공을 확인할 수 있다.
+
+- Localdocs `read_binary_doc`의 `isError=false`인 `Error: Document not found: ...`를 JSON으로 파싱하던 오류를 수정했다. 누락은 해당 경로의 `LOCALDOCS_NOT_FOUND`로 구분하고 일반 도구 오류·잘못된 binary envelope는 도구명·경로를 포함해 보고한다. 이후 증거 `evidence_index`, `/items/*/event_candidates/*`·`candidate_id`, SG01 `domain_entries`, domain signal 3개 candidate 배열, compatibility view prefix, P3·P4 `counts.review_items`·`finalized_by`를 실제 Stage 1 writer 계약에 맞췄다. BO→event→evidence 연결과 B2 선언 개수 검증을 추가했으며 hash·누락·중복·review 차단 검증은 유지했다.
+- 기존·실제 서버 응답 시험 51건 및 캡처한 Stage 1 원본·변조 거부 시험 7건, YAML·Python 3.11/3.12 문법 검증을 통과했다. `10월_1일_구성`에 현행 YAML을 `Stage_2_S2_00_v6`로 등록·실행하여 task `COMPLETED`, `exit_code=0`, `READY_WITH_ISSUES`, `PUBLISHED_STATUS_LAST`를 확인했다(전체 5.1초, code executor 2.402초). 고정 출력 `stage2_runs/from-stage1/s2_00/v6/`의 5개 파일을 다운로드했고 status SHA-256 `7ea037548ea729275ce4f791d7ae2ada2d381427f1971ea6f30ccc3e4041eed3`, 나머지 4개 artifact hash·byte length, 읽은 원본·배포 파일 81개 hash를 모두 대조했다. 검증은 PASS 19·FAIL 0·UNEVALUABLE 2이며 미제공 LES 선언 총수·event disposition은 추정하지 않았다. producer 정보가 원본에 없는 11건은 WARNING으로 남기고 기존 review 1,128건을 그대로 보존한다. context는 증거 30·event 71·BO 57·fact 57·LES 47, 신호 475, cluster 46, 미해결 참조 0이다. 실행 성공은 이 workspace 테스트에 한정한다.
+- v4 원본은 `agent_scripts/Stage_2_S2_00_10_02_v.2.yml`, 중간 v5는 `agent_scripts/Stage_2_S2_00_10_02_v.3.yml`로 보존했다. 현행 `agent_scripts/Stage_2_S2_00.yml`은 overwrite했고 복제본은 본 폴더 `Stage_2_S2_00_v.6.yml`이다. v5 원격 진단을 보존하기 위해 출력만 고정 개정 폴더 `v6`로 구분했으며 별도 request/attempt ID를 만들지 않았다. Stage 1 원본·배포 및 S2_10~40은 수정하지 않았다.
+
+## 2026-10-02 — S2_00 YAML v4 실제 입력 연결 개정
+
+한 줄 요약: v3의 미치환 `prev` root·파일 참조를 제거하고, `run_inline_mcp`에 사건·배포 root를 직접 전달하여 인증된 localdocs에서 Stage 1 원본을 읽는 v4로 개정했다. 선행 task 없는 standalone 실행에 `prev` 결과가 자동 연결된다고 가정하지 않는 것이 핵심이다.
+
+- Stage 1 v.8의 상대 저장 경로에 맞춰 기본 사건 root는 `.`(인증된 workspace), 배포 root는 `Default_Agent`로 명시한다. 다른 위치는 inline 상수 또는 함수 인자로 직접 지정한다. backend 치환은 문서화된 `__user_hash__`·`__workspace_hash__`만 사용하며, root·인증 미치환 오류는 해당 입력 이름을 표시한다. request/attempt ID·준비 task·control 파일을 추가하지 않았다.
+- DEV 정책은 그대로 기록하되 `WORKSPACE_EXECUTION_TEST`만 허용하여 실행 테스트 산출물에 모드·정책 분류를 남긴다. 생산 모드는 계속 차단하며 원본·배포 pin·schema·signal/review 보존·두 read-pass·status-last·충돌 시 덮어쓰기 금지 검증을 유지한다. 기본 인자 그대로의 JSON/SSE 모의 실행을 포함한 44건과 YAML/DAG·Python 3.11/3.12 문법을 통과했다. 실제 backend 재등록·원격 실행·생산 배포 승인은 수행하지 않았다.
+- 직전 v3는 `Default_Agent/Stage_2_Clean/agent_scripts/Stage_2_S2_00_10_02_v.1.yml`로 byte-identical 보존하고 현행 YAML을 overwrite했다. 개정 복제본은 본 폴더 `Stage_2_S2_00_v.4.yml`이다. 이번 변경은 지정된 YAML 3개·MEMORY에 한정하며 S2_10~40·전략서·SKILL·notebook·release/mirror는 보존한다.
+
 ## 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를 제거한다.