Liti-agent-Development/Case_02_Comparison_Research/plans/s2-30-llm-drafting-package.md

S2_30 LLM joint-drafting package implementation

This ExecPlan is a living implementation record for the S2_30 package. It follows docs/PLANS.md and records only the scope of this task.

Purpose / Big Picture

Implement the fourth Stage 2 task, S2_30, as a release-bound GPT-5.6 Sol legal-drafting Agent that consumes one frozen S2_20 claim-group dispatch per invocation and emits one schema-closed JSON draft-part result. Multiple sealed group invocations may run in parallel, while each Agent invocation remains a single LLM task and never writes shared final documents. S2_40 remains the sole owner of validation, rendering, final storage, review state, and commit.

Progress

• 2026-08-31: Read project behavior rules, Stage 2 YAML skill, Code Executor notebook, Stage 2 MEMORY, v5-1 strategy, and current S2_10/S2_20 package contracts.
• 2026-08-31: Confirmed the existing P00 prefix contains S2_10-only language and therefore cannot be byte-reused in S2_30 without a stage-neutral rewrite and coordinated S2_10 reseal.
• 2026-08-31: Drafted S2_30_SOW.md and S2_30_assets.md in parallel.
• 2026-08-31: Completed exactly two document-review rounds with two independent reviewers per round and applied incremental fixes.
• 2026-08-31: Implemented S2_30 fixed assets and Stage_2_S2_30.yml in parallel.
• 2026-08-31: Completed exactly two asset-review rounds and exactly two YAML-review rounds, applying one incremental revision after each round.
• 2026-08-31: Resealed the affected S2_10/shared parent-child release and S2_00/S2_20 handoff hashes without changing their legal-workflow ownership.
• 2026-08-31: Passed S2_00 70/70, S2_10 41/41, S2_20 41/41, S2_30 34/34, all builder checks, release validation with zero errors, and 50/50 Python/mirror parity.
• 2026-08-31: Appended the final compressed implementation lesson to Stage 2 MEMORY.md.

Surprises & Discoveries

• The current stage_2_common_cache_prefix says it is an S2_10 bundle and forbids outputs that S2_30 legitimately needs. A truly common P00 must retain only stage-neutral legal safety, provenance, injection-defense, structured-output, fixture, and review limits. S2_10-only rules move to P10; S2_30 rules live in P30.
• AgentBackend wildcard fan-out requires a parent task that emits dynamic_fanout. The package therefore keeps S2_30 as an LLM-DIRECT stage while binding exactly one non-legal embedded Code Executor planner task; the shared admission contract classifies only that execution unit as deterministic helper and never classifies S2_30 itself as a deterministic stage.
• The shared binding serializer emits list rows as - stage_id without the older two-space indentation. S2_20's bounded text verifier now accepts exactly one canonical zero- or two-space S2_20 row and continues to reject duplicates or incomplete live admission.
• Parent-member lists include byte-identical .txt documentation mirrors, while the module manifest records them in documentation_mirrors rather than modules. The release validator must treat both collections as parent-closure members.
• Current S2_20 has structural 137-case coverage but no lawyer-approved relief Markdown or executable rule branches. S2_30 can be implemented and offline-validated with structural fixtures, but production legal drafting must remain blocked pending real rule/corpus/authority/model/platform/legal admission.

Decision Log

• Decision: S2_30 contains one wildcard LLM task family, one non-legal inline Code Executor dispatch/context planner, and zero reducers. Rationale: task_procedure wildcard fan-out is the only documented Liti-agent mechanism that binds request-scoped {{item.*}} data without inventing a native variable syntax. The planner validates and materializes exact sealed references but cannot perform legal reasoning, drafting, permanent-ID minting, or persistence.
• Decision: cache-owner execution is a singleton dispatch followed by a separately invoked follower batch after an external owner-complete receipt. Rationale: one wildcard invocation cannot itself prove owner-first cache sequencing.
• Decision: P00 is rewritten as a stage-neutral common cache prefix and projected byte-identically into both S2_10 and S2_30. Rationale: the current P00 contains S2_10-specific output prohibitions that conflict with S2_30.
• Decision: P30 is YAML-inline and externally mirrored only as a build/review source. P31/P32/S30 remain canonical JSON dynamic blocks supplied by the sealed dispatch item. Rationale: static prompt reviewability and caching are improved without delegating prompt authorship to the orchestrator.
• Decision: offline tests may prove syntax, schema, byte parity, hash closure, and deterministic adapter oracles only. They do not prove live platform binding, model quality, Korean-law correctness, or production admission.
• Decision: P32 remains cohort-common; relevant S2_10 case material stays in S30. Follower dispatch requires a closed owner-completion receipt that binds its self-hash, P32 hash, and cohort material digest.
• Decision: signed canary and external admission receipts are admitted only through exact schema/status/effect/capability/evidence/issuer/signature/scope/expiry checks. Pending receipts remain production-blocking.

Context and Orientation

Authoring files live under YAML_Prompts/2. Stage_2/. Version-free deployment files live under YAML_Prompts/2. Stage_2/Default_Agent/Stage_2_Clean/. The existing parent release is manifest/stage2_release.json; S2_10 has its own child release and LLM binding. S2_30 will receive analogous projection, binding, receipt, schema, workflow, fixtures, tests, and child release while extending the shared module manifest and parent release.

Plan of Work

1. Write the SOW and asset inventory, then execute the two requested document-review rounds.
2. Add P30, S2_30 schema/workflow, builder-validator fixtures/tests, deployment binding, receipts, and child release. Update the shared cache policy and regression manifest only where the S2_30 contract requires it.
3. Rewrite P00 to stage-neutral text and update the S2_10 authoring projection and its sealed descendants. Preserve P10 and S2_10 dynamic item semantics.
4. Create Stage_2_S2_30.yml with IN -> Task_S2_30_dispatch_planner -> Task_S2_30_draft_group_* -> OUT. Inline P00/P30 and the complete MCP Code Executor planner; dynamic blocks contain only canonical JSON data fields.
5. Run the exact requested review loops, then regenerate module/parent/child/projection/binding/receipt hashes in dependency order.
6. Run all S2_00, S2_10, S2_20, and S2_30 offline tests, parity checks, no-legacy-dependency scans, and release reproducibility checks.

Concrete Steps

All commands run from Case_02_Comparison_Research/YAML_Prompts/2. Stage_2/ unless stated otherwise.

1. Inspect and edit with rg, sed, and apply_patch only.
2. Validate YAML unique keys and structure with the repository's existing Python test helpers.
3. Run python3 -m unittest discover -s Default_Agent/Stage_2_Clean/tests/s2_00, then the corresponding s2_10, s2_20, and s2_30 suites.
4. Run S2_10/S2_30 projection builders in check mode and the shared release validator.
5. Verify every generated .py has a byte-identical .txt mirror and scan the implementation for runtime references to Stage 2 v0-v3.

Validation and Acceptance

Acceptance requires: exact common-prefix scalar equality between S2_10 and S2_30; S2_30 model binding openai/gpt-5.6-sol/xhigh/medium/responses; one wildcard LLM task family, one inline non-legal planner, and no reducer; required task_procedure DAG; P31/P32/S30 dynamic-data-only fields; strict schema/provenance/source-plan hash checks; immutable per-group ownership; native-adapter retry/persist contract; child/parent/module hash closure; .py/.txt parity; all offline suites passing; and honest pending live/model/legal receipts. No acceptance statement may call the package production-ready.

Idempotence and Recovery

Builders must be deterministic and support check mode. Re-running them on unchanged inputs must reproduce byte-identical projections and hashes. If a hash-bound upstream file changes, regenerate descendants in topological order rather than editing receipt hashes manually. Never reset or discard unrelated dirty files.

Artifacts and Notes

Primary outputs are S2_30_SOW.md, S2_30_assets.md, Stage_2_S2_30.yml, and version-free assets under Default_Agent/Stage_2_Clean/. This task deliberately does not create real 137-case lawyer-approved relief rules, a live Weaviate corpus, a production model benchmark, or a Korean-lawyer approval receipt.

Final offline seal: parent release SHA-256 579e4c896cf16bf2fab1482bc6327319035b1c320528bb818d36d3f9036c1b81; S2_30 child SHA-256 90b96d0e00d0491f7dfafe3b9f2cec3a1055d64fe4979780fe00af849257e884; S2_30 producer contract digest 337fd978acb335e89ef3ee859bf2333403858b370cbc5466d601317ba027fe4a. Release validation is PASS with two honest pending findings: full 137 legal rule/sign-off coverage and parent live admission.

Interfaces and Dependencies

S2_30 consumes a closed dispatch item containing group identity, release/hash bindings, P31 rule-and-pack JSON, P32 common-authority JSON, and S30 frozen-group JSON. It returns one raw JSON object conforming to schemas/draft_atoms.schema.json. A release-bound native adapter validates and rewrites deterministic IDs, persists four immutable group parts, controls one retry, and issues a group receipt. S2_40 alone consumes completed parts and renders final pleadings.