Liti-agent-Development/Case_02_Comparison_Research/plans/s2-20-deterministic-package.md

S2_20 Deterministic ReliefPlan Package

Objective

stage_2_optimal_update_strategy_v.5-1.md의 S2_20 계약을 단일 MCP Code Executor inline Python Agent로 구현하고, 필요한 고정 자산·검증 자산·release 결속을 함께 작성한다.

Deliverables

• YAML_Prompts/2. Stage_2/S2_20_SOW.md
• YAML_Prompts/2. Stage_2/S2_20_assets.md
• YAML_Prompts/2. Stage_2/Stage_2_S2_20.yml
• YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/ 아래 version-free S2_20 실행·계약·schema·runtime mirror·fixture·test·release 자산
• YAML_Prompts/2. Stage_2/MEMORY.md 작업 요약

Scope and Non-Scope

• 범위: S2_10 canonical immutable parts를 소비하여 option conservation, party/compatibility, exact case-type/rule binding, 계산, 제한된 Weaviate retrieval, reports, frozen ReliefPlan과 status-last plan barrier를 만드는 deterministic S2_20.
• 비범위: 신규 법률판단, fuzzy case-type fallback, 137종 법률 semantic sign-off, 실제 Weaviate/Code Executor live admission, S2_30 작성, S2_40 최종 render/commit.
• 기존 Stage 2 v.0~v.3 YAML runtime dependency는 0으로 유지한다.

Known Inputs

• stage_2_optimal_update_strategy_v.5-1.md
• S2_00_SOW_v.2.md, S2_00_assets_v.2.md, Stage_2_S2_00_v.2.yml
• S2_10_SOW_v.1.md, S2_10_assets_v.1.md, Stage_2_S2_10_v.1.yml
• test_code_executor.ipynb, repository SKILL.md, Stage 1 task_procedure example
• current Default_Agent/Stage_2_Clean/ release and manifest chain

Material Assumptions

• YAML의 parameters.code가 runtime 정본이고 runtime/s2_20_reduce.py 및 .txt는 byte-identical offline mirror다.
• 법률가 승인·corpus 운영·live MCP binding이 닫히지 않은 자산은 명시적으로 pending/draft 상태를 유지한다.
• 미결 binding/retrieval/calculation은 option을 소거하지 않고 scoped issue와 non-READY 상태로 보존한다.

Questions That Could Change the Outcome

• 없음. production 법률 승인과 live endpoint admission은 이번 작업의 완료조건이 아니라 별도 외부 gate로 분리한다.

Workstreams and Dependencies

1. SOW와 asset inventory 병렬 초안.
2. 두 문서의 독립 평가 2회와 증분 개정.
3. schema/data fixture 묶음과 runtime/build/test 묶음을 병렬 생성.
4. Agent YAML과 projection/release 결속 생성.
5. 자산 검증 2회, YAML 검증 2회, 전체 offline closure 검증.

Source and Tool Plan

• 로컬 canonical strategy·SOW·schema·manifest·notebook만 사용한다.
• 파일 탐색은 rg/find, 편집은 apply_patch, 검증은 Python unittest·YAML/JSON parser·hash/parity 검사로 수행한다.
• 외부 법률·API 사실을 새로 확정하지 않으므로 웹 검색은 수행하지 않는다.

Validation Plan

• YAML unique-key parse, exactly-one run_code, task_procedure DAG closure.
• inline code compile/AST, forbidden import/call/path checks, authoring↔deployment parity, .py/.txt byte parity.
• option partition/disjointness, exact predicate zero/multi behavior, stable IDs/groups, status-last write, retrieval no-fallback, calculator missing-operand branches.
• manifest/release/path/hash closure와 S2_00/S2_10 회귀검사.

Approval Boundaries

• 외부 시스템 호출·배포·법률 승인·production promotion은 수행하지 않는다.
• 사용자 소유의 관련 없는 dirty worktree 변경은 수정·삭제·stage하지 않는다.

Progress

• 요청문·AGENTS.md·MEMORY.md·v5-1 S2_20 계약·Code Executor 규칙 확인
• S2_20 SOW/assets 병렬 초안
• 문서 검증 2회 및 개정
• 고정 자산과 Agent YAML 구현
• 자산 검증·개정 2회 및 YAML 검증·개정 2회
• 전체 offline closure·재현성·비순환 hash-chain 검증
• MEMORY.md 기록

Decision Log

Date/Stage	Decision	Basis	Consequence
2026-08-31 / intake	S2_20은 단일 inline Python task로 고정	v5-1 §0.5, §4.2, §16.1 및 Code Executor 계약	내부 C20~C35 DAG는 함수 호출 순서와 task_procedure 주석/계약으로 표현하고 runtime task는 늘리지 않음
2026-08-31 / trust boundary	법률·corpus·live admission 미완료를 offline 구현과 분리	현 parent release와 MEMORY 상태	offline fixture PASS를 production-ready로 표현하지 않음
2026-08-31 / asset round 1	PENDING branch schema 통과만으로 구현완료를 선언하지 않음	독립 asset/schema 감사에서 approved projection·FK·calculation·retrieval 및 release helper 불일치 확인	pure-core·inline·schema·release tools를 동일 canonical 계약으로 개정 후 Round 2 수행
2026-08-31 / YAML round 1	trust anchor·partial-write·dynamic legal asset 검증을 inline task 내부에서 닫음	독립 감사의 admission/CAS 순서·legal-review path·manifest membership finding	최종 barrier 전에 detached admission·host CAS를 검증하고 모든 부분 쓰기를 diagnostic에 보존
2026-08-31 / YAML round 2	admission signature material에 backend capability receipt hash를 포함하고 final barrier 쓰기를 partial-write 계약으로 포섭	두 번째 독립 감사 residual finding 2건	지정된 2회 루프 종료 후 전체 regression·hash chain 재검증
2026-08-31 / closure	parent→module manifest, detached admission→parent+executor binding의 비순환 결속을 확정	builder reproducibility와 실파일 SHA-256 semantic audit	parent는 executor binding을 비해시 external trust-root로만 지시하며 admission은 PENDING을 유지

Evidence Ledger

Claim/Issue	Source or Test	Status	Notes
S2_20 내부 순서	v5-1 §7	VERIFIED	C20/C21 → C25/C26 → C22 and C27~C29 → C30 → C35
exactly-one inline Python	v5-1 §0.5, §4.2, §16.1	VERIFIED	external runtime import 금지
MCP execution shape	test_code_executor.ipynb, repository YAML guide	VERIFIED_STATIC	run_code(language, code, timeout) 및 localdocs session binding
current S2_20 physical assets	Default_Agent/Stage_2_Clean/ inventory	IMPLEMENTED_OFFLINE_VERIFIED	115-path parent allowlist, schema/registry/runtime/build/fixture/test·projection·receipt 구현
pending branch output schema	tests/s2_20/test_inline_output_schema.py	VERIFIED_STATIC	synthetic 1 option의 34 output, 24 fixed asset, S2_10 option schema 통과; approved/live branch 증거는 아님
release chain audit	builder reproducibility + read-only semantic hash audit	VERIFIED	module member actual hash, parent/module/binding/admission, S2_00/S2_20 projection·mirror, S2_10 child parent 결속과 금지 cycle 검사 PASS
regression suites	tests/s2_00, tests/s2_10, tests/s2_20	VERIFIED_OFFLINE	70/70, 39/39, 41/41 PASS; .py/.txt 42/42 parity PASS

Risks and Failure Modes

• 계획 자산을 구현 완료로 오인하는 위험.
• parent/child release hash cascade 누락.
• case-type/rule/corpus 미승인 상태를 fuzzy 또는 generic fallback으로 숨기는 위험.
• Weaviate 결과를 법률판단이나 사건 사실로 승격하는 위험.
• runtime code와 .py/.txt mirror drift.

Results and Residual Uncertainty

S2_20 SOW·asset inventory·단일 inline Code Executor Agent와 version-free 실행/계약/검증 자산을 구현했다. 최종 offline 증거는 S2_00 70/70, S2_10 39/39, S2_20 41/41, Python/TXT 42/42 parity, projection/release reproducibility·비순환 hash-chain PASS다.

다만 현 snapshot은 구조적 137 case-type catalog만 보유하며 법률가 승인 rules/relief/*.md 0/137, executable branch 0, authority/corpus/law-value admission 미완료, 상류 typed calculation operand·기존 증거표목 부재 상태다. live Code Executor·Weaviate·host CAS·E2E·대한민국 변호사 검수·production admission은 수행하지 않았으므로 최종 상태는 IMPLEMENTED_OFFLINE_VERIFIED / LIVE_AND_LEGAL_ADMISSION_PENDING이다.