Publish an application-owned lawpack authoring boundary #195

Problem

Edict can consume and validate an application-owned lawpack closure, but an application repository cannot yet produce that closure through a public Edict boundary.

The public application build requires one root lawpack followed by its complete dependency closure, then loads canonical manifest, exports, adapter, and target-configuration artifacts before compilation. The public syntax crate exposes typed lawpack models and decode/validation functions. The only checked-in writer, however, is the repository-internal cargo xtask lawpack-goldens --write path, whose artifact constructors and fixture coordinates are hard-coded for Edict's own Hello Echo, causal-cell, workspace-snapshot, and workspace-patch fixtures.

That leaves a real application such as Jim with two unacceptable choices:

• copy Edict's internal fixture generator into the application; or
• hand-author canonical CBOR and digests.

Neither is a legitimate ownership boundary. Jedit must own the jedit.text@1 definitions and generated closure; Edict must own the canonical construction and validation rules.

Evidence

At the current #194 head (8a2d021525e7c92e154a139086851d7a3e3f0a8a):

• edict application build reads one source plus a complete lawpack closure and validates it before provider invocation: crates/edict-cli/src/application_build.rs#L153-L225.
• the application manifest fails closed without a root plus complete dependency closure: crates/edict-cli/src/application_build.rs#L992-L1002.
• the public syntax API exports typed models and decode_lawpack_bundle, but no corresponding lawpack encoder/builder: crates/edict-syntax/src/lib.rs#L142-L155.
• the internal writer dispatches only lawpack-goldens: xtask/src/main.rs#L45-L103.
• its artifact constructors and coordinates are fixture-specific: xtask/src/lawpack_goldens.rs#L16-L85, xtask/src/lawpack_goldens.rs#L209-L242.

Required capability

Publish a deterministic, application-facing lawpack authoring boundary that takes reviewable typed definitions and emits the canonical artifacts already consumed by edict application build.

The boundary must keep three roles distinct:

1. the application owns coordinates, exported types/constants/helpers/effects/profiles, adapter declarations, and resource references;
2. Edict owns schema checking, canonical encoding, digest formation, closure validation, and atomic publication;
3. the provider/runtime remains uninvolved during lawpack authoring.

The exact review format is a design choice, but callers must not need to construct CanonicalValue, write CBOR, or reproduce Edict's digest framing.

Acceptance criteria

• A public CLI or stable library boundary accepts one bounded, reviewable application-owned lawpack definition.
• The definition can express the complete current edict.lawpack/v1 manifest and export surface, including exported bounded types, constants, Edict-authored pure helper bodies and costs, semantic effects, obstructions, operation profiles, dependencies, verifier metadata, and target-adapter references.
• The boundary emits canonical manifest.cbor, exports.cbor, adapter/configuration artifacts where declared, and lowercase digest sidecars suitable for an exact source import.
• Emitted bytes are validated through the same public decoders and complete-closure checks used by application build before publication.
• Byte-identical definitions produce byte-identical artifacts and digests across repeated runs and different caller working directories.
• Mutating a semantic helper body, type, constant, effect/profile obligation, dependency, adapter, or resource reference either moves the appropriate identity or fails with a stable structured error.
• Duplicate coordinates, namespace escapes, incomplete dependency closure, malformed pure Core, cost/budget violations, unresolved resources, and digest substitution fail closed without partial publication.
• Publication is atomic and removes or refuses stale artifacts according to a documented policy.
• A standalone fixture outside the Edict repository proves that an application can author, generate, vendor, and then build against its own lawpack without copying xtask/src/lawpack_goldens.rs.
• Topic-shelf documentation distinguishes review input, generated canonical artifacts, application source, provider package, and runtime receipt.

First consumer

Jedit #296 will use this boundary to author and vendor Jim's jedit.text@1 closure for ReplaceRange.edict, then pass that exact closure to Edict's public application build.

The Jedit oracle is test expectation only. It must not be accepted as lawpack source or executable semantics.

Non-goals

• no Jim, Jedit, rope, buffer, ReplaceRange, or TextWindow vocabulary in Edict production code;
• no Echo runtime behavior or provider invocation during authoring;
• no handwritten executable package or caller-authored graph patch;
• no weakening of canonical-CBOR, digest, namespace, dependency, helper-purity, or adapter-validation rules;
• no claim that authoring alone completes Edict Compile bounded control flow and digest-bound pure lawpack helpers into Core #192 or Jedit #296.

Dependencies

• Compile bounded control flow and digest-bound pure lawpack helpers into Core #192 owns source-to-Core bounded control flow and digest-bound helper use.
• Lower branch-yield result joins into Core #194 supplies compiler-produced Core branch-result joins used by the first consumer.
• Slice: Author and prove Jim's first Edict operation ReplaceRange jedit#296 owns ReplaceRange.edict and the application vocabulary.