Liti-agent-Development/Case_02_Comparison_Research/plans/s2-40-final-validation-package.md

S2_40 Final Validation Package

Objective

Implement the S2_40 deterministic final-validation, closed-rendering, review-state, sealing, and logical-commit package specified by stage_2_optimal_update_strategy_v.5-1.md.

Deliverables

• YAML_Prompts/2. Stage_2/S2_40_SOW.md
• YAML_Prompts/2. Stage_2/S2_40_assets.md
• YAML_Prompts/2. Stage_2/Stage_2_S2_40.yml
• Version-free S2_40 runtime, schema, workflow, renderer, validator, release, fixture, and test assets under YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/
• Updated shared release/hash-chain assets required to admit S2_40 without introducing a legacy v0-v3 runtime dependency
• A compact Stage 2 MEMORY.md entry

Scope and Non-Scope

In scope: offline-contract implementation, deterministic inline Python, closed rendering, V01-V18 validation, candidate freeze/resume, external-receipt validation, content-addressed writes, read-back verification, and status-last barrier behavior.

Out of scope: live AgentBackend/MCP admission, real Korean-lawyer sign-off, filing, external publication, production credential binding, and claims that 137-case legal coverage is complete when the physical rule/corpus approvals remain pending.

Known Inputs

• stage_2_optimal_update_strategy_v.5-1.md
• S2_00_SOW_v.2.md, S2_10_SOW_v.1.md, S2_20_SOW.md, S2_30_SOW.md
• S2_00_assets_v.2.md, S2_10_assets_v.1.md, S2_20_assets.md, S2_30_assets.md
• Stage_2_S2_00_v.2.yml, Stage_2_S2_10_v.1.yml, Stage_2_S2_20.yml, Stage_2_S2_30.yml
• Current Default_Agent/Stage_2_Clean/ release closure
• Local SKILL.md and test_code_executor.ipynb

Material Assumptions

• Despite the prompt label [LLM: group-parallel, immutable parts], S2_40 follows the controlling v5-1 contract and is a deterministic, exactly-one Code Executor task. It consumes S2_30 group-parallel immutable parts.
• Existing unrelated dirty-worktree changes remain untouched.
• Existing pending live/legal receipts stay pending unless this task produces actual external evidence, which it does not.

Questions That Could Change the Outcome

• Whether the deployed localdocs platform supports every claimed binary-read/write and barrier behavior is a live-admission question; offline implementation must preserve it as pending rather than assume success.
• Any upstream S2_30 contract defect that prevents trustworthy S2_40 admission must be either repaired and resealed or surfaced as a blocking upstream dependency; it may not be silently accepted.

Workstreams and Dependencies

1. Analyze controlling contracts and current package closure.
2. Draft SOW and asset inventory independently in parallel.
3. Perform exactly two independent review rounds over both documents; apply only evidenced incremental revisions.
4. Generate S2_40 assets and the authoring YAML in parallel.
5. Perform two asset-validation rounds and two YAML-validation rounds as requested, respecting available concurrency and using stable asset-family assignments.
6. Rebuild/reseal dependent manifests, bindings, receipts, and upstream hash echoes.
7. Run targeted and full regression, parity, unique-key parse, inline-code compile, release-closure, and legacy-dependency checks.
8. Update MEMORY.md with verified results and residual boundaries.

Source and Tool Plan

• Use local repository sources as the controlling implementation record.
• Use rg/rg --files for discovery and existing builder/test scripts for mechanical generation and validation.
• Use apply_patch for authored edits; use formatting/build scripts only for mechanical projections and resealing.
• Do not use live network or external legal sources unless a newly introduced legal proposition requires verification.

Validation Plan

• YAML unique-key parse and exact task_procedure/task semantics.
• Exactly one S2_40 mcp: code-executor / run_code task; no LLM fields or external Python runtime import.
• Inline Python compile, static AST guard, single-JSON stdout, localdocs user/workspace binding, and .py/.txt byte parity.
• Closed schema and path/hash/producer membership for all S2_40 inputs/outputs.
• V01-V18 fixtures, candidate freeze/resume, receipt mismatch, supersession, partial write, idempotent re-entry, barrier-last, and commit-conflict tests.
• Authoring/deployment projection parity and release/hash-chain reproducibility.
• Full S2_00-S2_40 offline regression and zero runtime references to Stage 2 v0-v3.

Approval Boundaries

• Local file creation and non-destructive tests are authorized.
• No external write, filing, publication, production promotion, secret access, or dependency installation.

Progress

• Read governing repository rules and Stage 2 memory.
• Identify the controlling S2_40 deterministic boundary.
• Draft SOW and asset inventory.
• Complete document review round 1.
• Complete document review round 2.
• Implement assets and authoring YAML.
• Complete asset validation rounds 1 and 2.
• Complete YAML validation rounds 1 and 2.
• Reseal the package and run full validation.
• Update Stage 2 memory.

Decision Log

Date/Stage	Decision	Basis	Consequence
2026-09-01 / intake	Treat S2_40 as deterministic rather than LLM-direct	v5-1 §§0, 2, 9, 16 and the five-task execution constitution	GPT-5.6 settings do not appear in the S2_40 task; S2_30 remains the group-parallel LLM owner
2026-09-01 / trust boundary	Preserve live and legal admission as pending	No live Code Executor, external receipt, corpus approval, or lawyer sign-off is authorized or available	Offline verification cannot be reported as production readiness
2026-09-01 / final YAML audit	Apply the second YAML audit without opening a third review loop	The requested two YAML review/revision loops are complete; remaining work is implementation correction and deterministic verification	Finish full S2_00/S2_10 hydration, zero/N review requests, RESUME digest recomputation, generated-output schema checks, and strict production gates locally

Evidence Ledger

Claim/Issue	Source or Test	Status	Notes
S2_40 is deterministic	v5-1 §§0, 2, 9, 16, 20	VERIFIED	Exactly one release-bound inline Python task
S2_40 is the final single writer	v5-1 §§3.4, 9.4	VERIFIED	Owns final ledger, documents, status, seal, and commit receipts
S2_40 barrier is control/run_status.json	v5-1 §§0.5, 3.3, 9.5	VERIFIED	Must be written last after content read-back
Live/legal readiness	Current manifests/receipts and later tests	PENDING	Must remain evidence-separated

Risks and Failure Modes

• Mixing S2_30 LLM fan-out semantics into S2_40.
• Treating an untrusted upstream part, external receipt, or workspace-local manifest as its own trust anchor.
• Hash cycles among parent release, module manifest, bindings, admission receipts, candidate package, and operational commit receipts.
• Partial writes becoming consumable before the final status barrier.
• Renderer accepting arbitrary free text in structured relief sections.
• Review-required legal uncertainty being converted into global no-save.
• Existing user changes being overwritten or staged accidentally.

Results and Residual Uncertainty

• Final authoring artifacts: S2_40_SOW.md 879 lines / SHA-256 6930cd6438ae29187d01c7bf463cf308d34e90c73d4e755b5573ab92090f4a04, S2_40_assets.md 528 lines / ed518213100971fde44aca385890761d8b7b2f86ad2c18a29b5f960d46ec8787, and Stage_2_S2_40.yml 3,575 lines / 5cbe2ac9aa73d95a5fa4e6cf71d7d8f0ad83aa05536f573c13e42505ef5d46f7.
• The rebuilt module manifest contains 222 modules. Raw parent release SHA-256 is 9fa85bb94c5f14f675dcdaa0cf94d06745b21675d97797539ffc14015dcc9f53; S2_10 and S2_30 child raw hashes are cb49a4501116e46d935933b739b6679b11d961ff8e36abefea35dab6b25508fb and e6dd6abe44b39de462ea01f5e78aa39c70bbf47e0b75e08d224615a297d2135f.
• Eight no-write projection/child/shared checks and an independent temporary-output module/parent reproducibility build passed. The release validator returned PASS, zero errors, and four expected pending findings.
• Offline regression passed 240/240: S2_00 70, S2_10 42, S2_20 42, S2_30 37, and S2_40 49. Python/documentation mirrors passed 62/62 and S2_00/S2_20/S2_30/S2_40 authoring/deployment projection parity passed 4/4.
• Runtime/deployment/release dependency on legacy Stage 2 v0-v3 is zero. A v.3 path remains only inside a negative fixture that proves such an injected dependency is rejected.
• Final state is IMPLEMENTED_OFFLINE_VERIFIED / LIVE_AND_LEGAL_ADMISSION_PENDING. The four pending validator findings are full-137 approved relief-rule coverage, parent production admission, signed deterministic backend admission, and live S2_40 secret/Code Executor binding. No live execution, legal sign-off, filing, or production promotion was performed.