jhogyu/Liti-agent-Development
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(stage2): implement S2_30 drafting

Browse Source 
Add release-bound claim-group drafting and reseal the shared P00, executor admission, and S2_00-S2_20 hash chain.
This commit is contained in:
jhogyu
2026-08-31 17:39:19 +09:00
parent daab564e81
commit 527604d42f
94 changed files with 20910 additions and 484 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Case_02_Comparison_Research/plans/s2-30-llm-drafting-package.md
+78
View File
@@ -0,0 +1,78 @@
# 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
- [x] 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.
- [x] 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.
- [x] 2026-08-31: Drafted `S2_30_SOW.md` and `S2_30_assets.md` in parallel.
- [x] 2026-08-31: Completed exactly two document-review rounds with two independent reviewers per round and applied incremental fixes.
- [x] 2026-08-31: Implemented S2_30 fixed assets and `Stage_2_S2_30.yml` in parallel.
- [x] 2026-08-31: Completed exactly two asset-review rounds and exactly two YAML-review rounds, applying one incremental revision after each round.
- [x] 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.
- [x] 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.
- [x] 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.