project-tiny-context-harness 0.8.17 → 0.11.0

package/assets/README.md

@@ -73,18 +73,18 @@ It does not launch or switch models, spawn agent sessions, create branches or wo
 
 ## Capability Model
 
-| Capability | When and how to use it | What it owns |
-|---|---|---|
-| **Minimal Context** | Installed by default. Agents read and update `project_context/**` on every delivery route. | Durable goals, ownership, architecture/interface/state boundaries and repeatable verification/deployment facts. It never claims that implementation or tests passed. |
-| **Workflow Contract** | The prompt-level default after `init`, for implementation work of any complexity whenever Long-Task is not explicitly selected or already bound. There is no Skill command or `delivery-contract.yaml`. | The model-led lightweight loop: Context discovery, risk-proportional requirement/architecture judgment, one `Context Delta`, Goal-owned implementation, current-candidate project checks, failure repair, evidence-bounded Contract Conformance and Context drift. It creates no exact Fact ledger, validator result, Receipt, persisted workflow state or machine completion. |
-| **Long-Task Workflow** | Enable the `long-task` profile once, then explicitly select `long-task-workflow`, or resume an existing valid binding, when machine completion authority, recoverability or auditability is required. Task size alone never activates it. | One Source-bound Delivery Contract, Authority Lock, recoverable scoped progress, protected revision, exact declared-obligation evidence and one current-snapshot Live Final Gate. |
+| Capability             | When and how to use it                                                                                                                                                                                                                    | What it owns                                                                                                                                                                                                                                                                                                                                                                   |
+| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Minimal Context**    | Installed by default. Agents read and update `project_context/**` on every delivery route.                                                                                                                                                | Durable goals, ownership, architecture/interface/state boundaries and repeatable verification/deployment facts. It never claims that implementation or tests passed.                                                                                                                                                                                                           |
+| **Workflow Contract**  | The prompt-level default after `init`, for implementation work of any complexity whenever Long-Task is not explicitly selected or already bound. There is no Skill command or `delivery-contract.yaml`.                                   | The model-led lightweight loop: Context discovery, risk-proportional requirement/architecture judgment, one `Context Delta`, Goal-owned implementation, current-candidate project checks, failure repair, evidence-bounded Contract Conformance and Context drift. It creates no exact Fact ledger, validator result, Receipt, persisted workflow state or machine completion. |
+| **Long-Task Workflow** | Enable the `long-task` profile once, then explicitly select `long-task-workflow`, or resume an existing valid binding, when machine completion authority, recoverability or auditability is required. Task size alone never activates it. | One Source-bound Delivery Contract, Authority Lock, recoverable scoped progress, protected revision, exact declared-obligation evidence and one current-snapshot Live Final Gate.                                                                                                                                                                                              |
 
 The relationship is deliberately one-of-two at execution time: every delivery consumes Minimal Context, then the default Workflow Contract applies unless `long-task-workflow` is explicitly selected or validly bound. Complexity determines execution and verification depth; required completion authority and recoverability determine the workflow route; Long-Task-internal risk determines proof strength. Long-Task Final Gate carries Engineering Quality/Architecture Conformance and selected-design closure instead of duplicating the default Contract Conformance closure.
 
-| Task shape | Model-led, evidence-bounded handoff is sufficient | Machine-traceable complete closure is required |
-|---|---|---|
-| Local or small | Default Workflow Contract | Explicit Long-Task is available |
-| Cross-module or complex | Default Workflow Contract remains valid | Explicit Long-Task |
+| Task shape              | Model-led, evidence-bounded handoff is sufficient | Machine-traceable complete closure is required |
+| ----------------------- | ------------------------------------------------- | ---------------------------------------------- |
+| Local or small          | Default Workflow Contract                         | Explicit Long-Task is available                |
+| Cross-module or complex | Default Workflow Contract remains valid           | Explicit Long-Task                             |
 
 The base managed set also provides two explicitly triggered Open Design adapters: `design-system-authoring` generates/selects/adopts project Design Authority at cold start, while `design-resource-authoring` commissions task-local resources. They are optional upstream Skills, not a fourth mechanism and not stages inside Long-Task. Their selected outputs may feed either execution route, and `long-task-workflow` is the only active long-task execution Skill. Retired standalone authoring pointers are not installed; Long-Task inputs enter one Source-bound Contract Draft loop directly and pre-existing planning documents remain ordinary Source.
 
@@ -109,7 +109,7 @@ Start from the delivery request: either concise product intent or a detailed ini
 Use this route when an implementation delivery both genuinely needs new style-bearing design resources and requires Long-Task's machine-assurance/recovery/audit boundary. It composes existing capabilities; it is not a prerequisite for every Long-Task:
 
 1. **Enable Long-Task once.** Run `ty-context enable long-task` before selecting the workflow Skill.
-2. **Establish Design Authority only when needed.** If the project has no adopted Design Authority and the work is style-bearing, explicitly select `$design-system-authoring` to generate, select and adopt the canonical `DESIGN.md`, token source and provider binding. Skip this step when the project already has a configured Design Authority.
+2. **Establish or revise Design Authority only when needed.** If the project has no adopted Design Authority, or a selected task design has a reusable system delta, explicitly select `$design-system-authoring` in `bootstrap`, `revise` or `reconcile` mode. Candidate selection and Authority adoption are separate decisions: after the Skill presents the exact project diff and migration impact, explicitly confirm adoption. Skip this step when the current complete Authority closure already covers the style-bearing scope.
 3. **Prepare a writable initial proposal.** Put the project-native product/technical proposal at a concrete path such as `docs/initial-proposal.md`. It may be authored by the user, an external service or an explicitly requested applicable proposal capability. `design-resource-authoring` does not author the initial proposal, and no standalone intermediary authoring stage is required.
 4. **Generate and select design resources.** Select `$design-resource-authoring` with the proposal path plus the exact development scope and targets. For formal Web/App work it first reads real technical Source, then returns one reconciled proposal, selected immutable canonical resources with their manifest/dependencies, a separate implementation-feasibility input, and a validated residual `design-resource-handoff-v1`.
 5. **Start the Single-Goal delivery.** Select `$long-task-workflow` and give it the exact paths to the reconciled proposal, validated handoff, implementation-feasibility input and selected canonical resource set. The Skill authors the Source-bound Contract Draft. Its first Compile/Authority Lock always ends the current turn before implementation and says `After handling the model change, reply exactly: model checkpoint cleared, continue`; a generic continuation does not satisfy the managed prompt protocol, earlier model wording cannot skip the boundary, and Harness cannot observe the next host message or whether the model changed. After the user resumes, the parent identifies qualifying bounded packets before profile/capacity. Absent an explicit user or host prohibition, a qualifying set requires actual host calls for multiple exact `long_task_implementation` workers; host results determine zero-start or partial fallback under the Skill's six-reason rule. Worker count stays dynamic, generic substitutes remain forbidden, and the parent alone owns Source, Contract, Authority, architecture, Context, packet selection, integration, current-candidate checks, formal verification, Final Gate, close and completion.
@@ -117,7 +117,9 @@ Use this route when an implementation delivery both genuinely needs new style-be
 One concrete invocation sequence is:
 
 ```text
-$design-system-authoring Generate, select and adopt the project design system for this style-bearing scope. Skip this request when DESIGN.md is already configured.
+$design-system-authoring Bootstrap the project design system for this style-bearing scope, present candidates and the exact project diff, and stop for a separate adoption confirmation. Skip this request when the complete current Authority closure already covers the scope.
+
+After reviewing the selected candidate and exact diff: explicitly adopt design-system candidate <candidate-id>.
 
 Prepare a writable project-native initial proposal at docs/initial-proposal.md for <delivery scope>.
 
@@ -135,7 +137,7 @@ Other valid routes remain available:
 - **Delivery that first needs design resources:** follow the design-first sequence above, then feed the revised proposal plus selected immutable resources and the validated handoff to either the default Workflow Contract or `long-task-workflow`, based on recovery and completion-authority needs.
 - **Design-resource-only request:** stop after `design-resource-authoring`; do not create a Long-Task Contract unless implementation delivery was also explicitly selected.
 
-The design-system step is user-selected, normally at project cold start; no command or downstream Skill runs it automatically. `design-resource-authoring` gates only style-bearing work when Design Authority is unconfigured. Low-fidelity structure, IA/flow and semantics-only state studies remain available without that gate. A pre-existing planning or proposal document remains ordinary Source, not a recommended intermediate service.
+The design-system step is user-selected; no command or downstream Skill runs it automatically. It can bootstrap a new Authority, revise an existing one, or reconcile a user-promoted DRA Authority-delta candidate. `design-resource-authoring` gates only style-bearing work when Design Authority is unconfigured, and task-resource selection never implies system adoption. Low-fidelity structure, IA/flow and semantics-only state studies remain available without that gate. A pre-existing planning or proposal document remains ordinary Source, not a recommended intermediate service.
 
 ## Try It In 60 Seconds
 
@@ -187,7 +189,7 @@ The smoke packs the local workspace, installs it into a disposable repo and vali
 
 ```sh
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.8.17.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.11.0.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -196,12 +198,12 @@ If it fails, open a [Source preview report](https://github.com/Seven128/project-
 
 ## Positioning
 
-| Adjacent tool type | Use it for | Harness stance |
-|---|---|---|
-| Spec-first kits | Turning a feature idea into structured specs and plans. | Complementary; Harness keeps durable repo facts beyond one feature spec. |
-| BMAD-style workflows and full Tiny Context processes | Role/process ceremony for selected work. | Lighter automatic route; explicit machine assurance stays opt-in. |
-| Task Master-style planners | Backlog decomposition and task state. | Complementary; Harness does not own backlog state. |
-| Context7/Serena-style retrieval | External docs, symbols or repository retrieval. | Complementary; Harness owns local intended boundaries. |
+| Adjacent tool type                                   | Use it for                                              | Harness stance                                                           |
+| ---------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------ |
+| Spec-first kits                                      | Turning a feature idea into structured specs and plans. | Complementary; Harness keeps durable repo facts beyond one feature spec. |
+| BMAD-style workflows and full Tiny Context processes | Role/process ceremony for selected work.                | Lighter automatic route; explicit machine assurance stays opt-in.        |
+| Task Master-style planners                           | Backlog decomposition and task state.                   | Complementary; Harness does not own backlog state.                       |
+| Context7/Serena-style retrieval                      | External docs, symbols or repository retrieval.         | Complementary; Harness owns local intended boundaries.                   |
 
 ## Minimal Context
 
@@ -216,7 +218,32 @@ minimum graph-relevant area/role Context
 
 Only near-universal recovery facts should use `read_policy = "default"`; specialized architecture, contract, deployment and historical detail should be task-triggered `on-demand` Context. Before deciding `Context Delta`, the Agent also runs one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment language. Matching files are merged with manifest candidates and filtered by semantic relevance. This is not a vector or persistent retrieval system and creates no index, cache, registry, search state or authority.
 
-`ty-context doctor` reports the deterministic default read footprint, per-file/total soft-budget overages, byte-identical default files and `DESIGN.md` authority status. These are advisory maintenance signals, not a new validation gate or workflow state. If genuine near-universal recovery facts exceed a byte heuristic, preserve the facts and accept the warning; never omit, obscure or misclassify required Context merely to fit the budget.
+`ty-context doctor` keeps the deterministic default-footprint report and also inspects every Context Markdown file, including unregistered files. It reports default/on-demand/legacy/unregistered byte distribution, the largest on-demand file, per-file size and maximum line length, trigger fan-out, explicit local Markdown-link integrity, and duplicate opt-in declarations such as `<!-- ty-context-declare Fact-ID: OBS-001 -->`. New findings are advisory by default; `--strict` is an explicit project choice and is never added to CI implicitly. Genuine recovery facts take precedence over byte and line heuristics.
+
+Schema v4 continues to accept `default`, `on-demand`, `always`, `optional` and `never-default`. Only `default` enters the default set directly; every registered node referenced through `default_children` enters transitively regardless of policy. Version 0.10 warns about the three legacy values without reinterpreting or automatically migrating them. In particular, `always -> default` can expand the footprint, while `never-default` plus an incoming default-child edge remains current-compatible but contradictory migration input that must be resolved explicitly.
+
+The separate explicit `ty-context upgrade` path can convert the retired pre-v4 `[[context_units]]` table name when every legacy table has a provably simple single-line representation. It renames the table, removes only retired `id`/`area` fields and preserves every untouched byte and line ending. Complex or mixed-format TOML and current/legacy path conflicts become `manual_required`; ordinary `sync` never performs this migration.
+
+Context maintenance commands share the same Catalog interpretation as validation and Doctor:
+
+```bash
+ty-context route --task "change the weather map contract" --path apps/client/src/map.ts --explain
+ty-context context inspect project_context/areas/main/weather.md --task "change the weather map contract"
+ty-context context create --path project_context/areas/main/weather.md --role domain
+ty-context context register --path project_context/areas/main/weather.md --role domain
+ty-context context move --from project_context/deployment.md --to project_context/deployment/index.md
+ty-context context transaction status
+```
+
+`route` is an experimental, stateless literal candidate diagnostic over all eligible `project_context/**`, including clearly labelled unregistered files. Its versioned JSON, fixed candidate/content/output budgets, stable ordering, explanations and byte costs do not establish Authority, participate in the default footprint or satisfy the Workflow-required bounded search. Budget exhaustion returns an explicitly incomplete result. These Router budgets apply after the Shared Catalog has completed repository-wide Context discovery and metadata collection; 0.10 deliberately leaves that traversal complete. A future total-discovery cap must be Catalog-owned, propagate typed incompleteness to every consumer and make Router return `complete: false`/exit `4`; a Router-only walker or silently truncated Validate/Doctor result is not allowed. `context inspect` reports one file's registration, Role, read metadata, default reasons, explicit backlinks, stable-key conflicts and optional route explanation without writing files.
+
+Version 0.10.1 added only the bounded `context create` write. It publishes one Role-specific TODO-only Markdown scaffold below `project_context/**`, labels it unregistered, refuses unsafe paths and existing/concurrently appearing targets, and reports the unchanged default footprint. It never edits `context.toml`, never creates durable product or architecture facts, and has no combined register or force-overwrite option. Replace every TODO with real owner facts before separately registering the file; a placeholder scaffold intentionally fails registered-Context recoverability.
+
+The completed 0.10.x mutation commands are dry-run-first. `context register` accepts one existing, recoverable, unregistered file, emits only canonical `default`/`on-demand` policy values and appends one parser-validated `[[context]]` block without rewriting untouched TOML. `context move` accepts one uniquely registered Context/Area owner, patches that owner plus structured `default_children`, rebases explicit CommonMark links inside all Context Markdown, reports exact prose/code/config references without changing them, and refuses apply while its bounded repository scan is incomplete or unresolved. A missing target directory is part of the recoverable plan.
+
+Applied registration and move share current-byte/file-identity CAS, synchronized same-directory temporaries, a fully validated candidate-tree overlay, deterministic commit order, live after-state validation and `context transaction status|rollback|complete`. Current writes use `context-mutation-journal-v3`, whose immutable digest-linked generations bind each NFC logical key to its exact physical path. `context-mutation-journal-v2` remains recovery-readable with equal logical and physical paths. Pre-v2 journals require a version-matched package or explicit manual recovery and are never guessed or rewritten. Recovery records and compares complete before/published endpoint snapshots (content, mode and available file identity), accepts only exact journal-owned partial temporaries and refuses external conflicts, unowned links or a newly active Long-Task binding. Long-Task first Compile, activation, in-place Revision and mutation recovery serialize through the existing Active Authority lock, and each Long-Task write path refuses an unfinished journal. If an already-active binding conflicts with crash recovery, recovery writes nothing: end that binding through the legitimate Long-Task lifecycle, complete or roll back the transaction, then freshly Compile/rebind and perform any required Authority Revision. This is deterministic cooperative crash recovery, not a claim of filesystem-wide multi-file atomicity or hostile-writer mutex. There is no `--force`, manual lock deletion or implicit whole-Manifest normalization path.
+
+These Context commands use classified exits: `0` completed, `2` arguments, `3` blocking Catalog, `4` incomplete scan budget, `5` I/O/path safety and `6` internal; ordinary route ambiguity and unresolved paths remain completed diagnostic results.
 
 Typical roles are area/domain, contract, foundation, decision-rationale, implementation-index, verification and deployment. Context owns durable intended boundaries; code owns current implementation; tests, CI, browser/runtime evidence and people own behavior and product acceptance.
 
@@ -318,9 +345,9 @@ The generated canonical implementation source remains the sole owner of exact va
 
 Formal Web/App handoff also indexes one separate `design-resource-implementation-feasibility-v1` JSON Source per target. It records current platform, framework/runtime, UI system, token/theming adapter, component-owner roots and route-owner roots; non-observed dispositions carry a reason instead of a fabricated value. Every material component-family × target × condition profile binds the complete matching V1 Fact or intersecting V2 Rule set and has one or more capability/feasibility-Source-backed reuse/compose/extend/theme/create candidates or an explicit blocker. Composite multi-primitive strategies, per-platform candidates and authorized planned owners are allowed. Browser-only capability cannot be relabeled as a native-App/React Native substrate. Exact visual values remain in canonical resources and are rejected from feasibility prose; DRA cannot choose a required production realization without independent technical authority. V1 uses an exact condition partition and symbolic V2 uses reachable, disjoint and exhaustive regions. New V1 bundle publication requires the input; direct preflight keeps legacy implementation handoffs readable and reports `technical feasibility not declared` when absent, while a `reference` target may truthfully omit it without that limitation.
 
-Unresolved substrate observations are target-wide rather than representative: every `decision_required` or `unavailable` observation must be named by an exact blocker in every material family × condition cell, blocker and marked-Source projection observation-ref sets must match, and no-family vacuity fails. Candidate cells require observed component-owner roots. Exact motion or ambiguous time values remain canonical-resource data, while explicit build/compile/test/startup/latency/timeout/network/benchmark/runtime-cost durations are valid technical feasibility prose.
+Unresolved substrate observations are target-wide rather than representative: every `decision_required` or `unavailable` observation must be named by an exact blocker in every material family × condition cell, blocker and marked-Source projection observation-ref sets must match, and no-family vacuity fails. Candidate cells require observed component-owner roots. Across observation reasons, costs, risks and blocker descriptions, compact, spaced and singular/plural `millisecond|msec|ms|second|sec|s` durations use one classifier: motion context always blocks, explicit build/compile/test/startup/latency/timeout/network/benchmark/runtime/render cost context is valid, and an otherwise context-free time literal fails closed. Exact motion or ambiguous time values remain canonical-resource data.
 
-For Long-Task consumption, every `file`/`path_glob` target and carrier, every `verified` carrier and every planned non-empty carrier is proven wholly inside observed component/route roots; a partial or indeterminate match fails. Empty component refs remain invalid in standalone Contract validation. Full activation may defer that one check only for an all-blocker-only surface with valid route and exact blocker closure; candidate, mixed, legacy, missing-feasibility and fake-binding cases fail. An open target-blocking External Confirmation reaches `blocked_external`, never `machine_accepted`, without adding or changing the sole Final Gate.
+For Long-Task consumption, every `file`/`path_glob` target and carrier, every `verified` carrier and every planned non-empty carrier is proven wholly inside observed component/route roots; a partial or indeterminate match fails. Empty component refs remain invalid in standalone Contract validation. Full activation may defer that one check only when every target is modern blocker-only, with a valid route and exact blocker closure; a legacy target cannot borrow that exception. Pure-legacy surfaces retain their historical non-empty component-Binding compatibility but gain no feasibility claim. Once any modern feasibility target appears, each component Binding must be consumed by a modern candidate-bearing cell's actual unique match; legacy consumes none, so an extra Binding cannot be laundered through a mixed surface, while an explicitly matched Binding may be shared by modern targets. An open target-blocking External Confirmation reaches `blocked_external`, never `machine_accepted`, without adding or changing the sole Final Gate.
 
 Ready handoff requires exact set equality: `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`, together with complete material-with-facts or honestly supporting-only resource closure. The canonical per-target manifest is the sole complete Fact/Census/proof index. New authoring keeps the shipped `design-resource-handoff-v1` marker and adds `representation: manifest_backed`; YAML carries only residual Source/scope/resource/target/closure/coverage/proposal binding, and preflight hydrates the same complete V1 object from the frozen manifest. Older embedded V1 remains read-compatible. UI symbolic V2 is explicit opt-in; V1 remains the default. An opted-in target uses `design-resource-handoff-v2`, `representation: symbolic_rules_v2` and `design-resource-observable-rule-manifest-v2`; constant located expected values and mutually exclusive canonical regions preserve exact point meaning. Applicability either keeps legacy exact remainder rows or uses package-owned property profiles, frozen Inspector custom-property closure and explicit unique instance exceptions, while every logical subject-property point retains one disposition. Fact Rule, required-method semantic obligation and set-valued non-interference certificate identities remain separate. `ready` is emitted only after unresolved dispositions and blockers are absent, V1 proof policies pass, and an `exact_target`'s full-target layout and pixel region unions each cover the complete reachable domain. Omitted axes require both Source-side and production-side proof through frozen closed-world static dependency closure, restricted-IR exact equivalence or finite complete-domain exhaustive equivalence; dynamic/reflected/unfrozen/external or sampled dependencies block. Preflight resolves immutable resources and exact locators, recomputes canonical DAG/region/certificate identity and rejects missing, overlapping, gapped, unresolved, unsupported, stale or value-conflicting input. Exploration remains schema-free.
 
@@ -344,15 +371,25 @@ An explicit Long-Task is the strong authority carrier of the same shared obligat
 
 Combined design-and-implementation work may author candidates in ordinary Outcomes/Stages, but a candidate or planned target cannot authorize fidelity implementation. The selection must become real marked Context-reachable Source plus its owning Context/`DESIGN.md` reference and, after Authority Lock, an adopted Authority Revision. Browser visual ACs may use `ui_browser` for diagnostic localization, but current machine closure remains External Confirmation; a browser proxy, detached route or deep link cannot prove a native/root journey that can fail independently. Resource integrity and `visual_render` cannot satisfy selected-target implementation conformance. Frozen baselines are verifier inputs, generated actual renders/diffs are current artifacts, and subjective approval remains external. This adds no `uiux_delivery` block, visual Claim type, resource registry, risk level, lifecycle state, Gate, required design directory, per-Control screenshot matrix or universal pixel threshold.
 
-`ty-context doctor` keeps its compatible `missing | unconfigured | configured` project-level status and adds advisory Design Authority Index, token-source and classified-reference signals. It explicitly does not infer surface implementation readiness; that requires the owning Screen/Control meaning, selected target/constraints and project-owned verification.
+`ty-context doctor` keeps its compatible `missing | unconfigured | configured` project-level status and adds advisory complete-closure, token-projection, extra-file and normative-link diagnostics. Structural bundle errors remain visible without turning visual judgment into a machine claim. Doctor does not infer surface implementation readiness; that still requires the owning Screen/Control meaning, selected target/constraints and project-owned verification.
 
 Static guidance tests prove routing text, positive/negative analysis rules, distribution, projection and canonical ownership—not real host Skill activation, Agent adherence, map-design quality, runtime cost, performance or ROI. The optional delivery-mechanism benchmark provides a fixed fresh-agent UI/UX Context/target-recovery task with routing gold and a hidden production oracle; only independent paired runs may support effectiveness or ROI conclusions.
 
 ### Explicit Design System Authoring
 
-Use `design-system-authoring` only when the user explicitly asks to initialize, generate, select, adopt, replace or repair the project design system/design style. Installation makes the cold-start capability available but never runs it automatically. The Skill discovers live Open Design MCP resources/tools, feature-detects design-system lifecycle methods and, when the current MCP exposes design systems only as resources, uses the same installed Open Design daemon's official generation/revision/accept API. It never copies provider prompts or pretends daemon generation is an MCP tool.
+Use `design-system-authoring` only when the user explicitly asks to `bootstrap`, `revise` or `reconcile` the project design system/design style. A DRA `authority_delta_candidate`, missing `DESIGN.md` or ordinary UI work never invokes it automatically. The Skill discovers live Open Design capabilities and keeps provider execution in the Skill layer; the package-local `@google/design.md` adapter performs deterministic lint/parse/export/diff only and is not a generator or provider runtime.
+
+Root `DESIGN.md` is the unique Authority entry, human revision owner and first-bundle editable exact-Token owner. Bundle adoption writes the exact `<!-- ty-context-design-authority-format: bundle-v1 -->` machine declaration as the first non-empty Markdown body line after supported YAML front matter and creates the sparse `design_system/authority.manifest.json`; the marker and manifest are required as a pair. The manifest owns only sorted closure membership and `closure_digest`; it does not copy revision, direction or Token values. Missing, renamed, empty or invalid manifest under the marker, an orphan manifest, a moved/duplicate/non-canonical marker, or non-portable physical path casing fails closure. `design_system/tokens.json` is deterministic DTCG output from supported DESIGN front matter, never an independently edited authority. Component, pattern, motion and platform children exist only for real reusable rules. A true unmarked project without a manifest remains a compatible one-file closure.
+
+The machine identity is the entry plus complete closure digest; the human revision is diagnostic. Closure validation rejects unsafe or duplicate paths, case collisions, symlink/hardlink aliases, invalid UTF-8/BOM, generated-Token drift and incomplete normative local links. A subordinate change stales DRA recovery/handoff and Long-Task bindings even if the revision label is unchanged. Read-only inspection is available through:
 
-Generation produces candidates. Explicit human selection—or explicit delegated selection with known criteria—precedes adoption. The selected system is reconciled into canonical project `DESIGN.md`, exactly one authored exact-value token source/generation direction and only the owning durable surface/interaction Context. Open Design provider ID/revision/digest and project binding are synchronization provenance, not a second authority. Provider success, artifact readiness, selection, authority adoption and `get_project.designSystemId` binding verification are reported separately.
+```bash
+ty-context design-authority inspect --format json
+ty-context design-authority tokens
+ty-context design-authority tokens --from-entry
+```
+
+Generation produces candidates. Explicit human selection—or explicit delegated selection with known criteria—comes first; after the exact project diff and migration impact are visible, a separate explicit adoption confirmation is required. Adoption updates the root entry and only necessary sparse owners, deterministically regenerates Tokens, publishes a new closure digest, rebinds affected DRA resources and reruns their checks. Open Design provider ID/revision/digest and project binding remain synchronization provenance, not another authority. Provider success, artifact readiness, selection, adoption and `get_project.designSystemId` binding verification are reported separately.
 
 ### Optional Design Resource Authoring
 
@@ -362,6 +399,8 @@ The Skill fixes the requested output or development content as a hard scope ceil
 
 Inside that ceiling, DRA records selected existing coverage, new gaps and preservation obligations. An outside-ceiling effect returns existing `decision-required` with reason `scope-expansion-required`; only the user can expand the ceiling. A durable Product/Surface/Screen/Design change updates its actual owner before generation resumes. Style-bearing commissions carry Source-derived `style_application` fields only where needed plus an archetype-specific `quality_commission` for primary challenges, desired/avoided visual character, real copy/data, reference roles and design-side shared-family reuse. These are task-local Provider inputs, not files, states, scores, Authorities or routing records.
 
+After a task direction is selected, DRA performs one non-authoritative Authority Delta Assessment against the exact current closure: `consistent_with_current_authority`, `task_local_variance` or `authority_delta_candidate`. A one-task variance declares `precedent: forbidden`; a reusable local variance must reach a named Screen Contract owner. A system delta is only a pure candidate packet and stops DRA until the user separately invokes DSA `reconcile`. The strict optional JSON form is read-only validated with `ty-context design-resource authority-delta validate <assessment.json> --json`; it cannot select, adopt, write Authority or invoke a provider. After adoption, the handoff binds the new closure and reruns affected preflight/resource checks.
+
 Formal generation, a major design revision and critical regeneration use the highest eligible live model and that model's highest supported reasoning effort. Eligibility first preserves required tools, visual/context capability, authentication and data boundaries; provider capability ordering or documented replacement evidence establishes rank. The Skill never guesses from price, model name, release date or list order. An unrankable choice fails closed as `highest_performance_unverified`; an uncontrollable or unobservable provider result is reported with the same qualification and is never described as a confirmed highest-tier run. This policy creates no model registry, scheduler or persistent routing state.
 
 For formal Web/App implementation output, “complete” defaults to the finest applicable observable Fact granularity described above. Before commissioning generation, the Skill builds the Expected Fact Universe, freezes the Inspector/Census obligation, and reads real technical Source for the platform, framework/runtime, UI system, token/theming adapter, component owners and route owners. It passes those constraints and the adopted design-system identity into a live capability matched to the resource archetype, then requires the returned canonical source/manifest to express every applicable cell. It separately authors the feasibility document described above; each material family/condition has a candidate or blocker, while production-owner selection remains downstream. It does not wait for downstream implementation to discover missing states, anatomy-part styling, responsive/platform/text-scale behavior, motion, accessibility, assets or basic implementability.
@@ -401,15 +440,19 @@ Use `long-task-workflow` only when explicitly selected or when the current workt
 - a complete Final Gate on one current snapshot;
 - a Stop Hook that rejects stale completion.
 
-Its proof claim is conditional and precise: if Source is complete and accurate at the declared observable granularity, projection preserves that meaning and every actual applicability cell is expanded, then `AcceptedDeliveryTerminal`—exactly a fresh `machine_accepted` result with no pending External Confirmation—implies no declared machine-observable drift remains only because every machine obligation has frozen Expected authority, package-admitted current Actual, Harness-computed comparison/verdict, attributable static-production or direct-process observation, causal Counterfactual evidence and current Final-Gate snapshot proof. `machine_accepted_external_pending` proves only the admitted machine scope; full delivery remains qualified and the native Goal is untouched. The workflow cannot discover undeclared requirements or prove arbitrary physical/external observation sound.
+Its proof claim is conditional and precise: if Source is complete and accurate at the declared observable granularity, projection preserves that meaning and every actual applicability cell is expanded, then `AcceptedDeliveryTerminal` is either a fresh `machine_accepted` result when no blocking external fulfillment is required, or a fresh `delivery_accepted` result when every blocking external obligation also has a valid exact record. Machine obligations still require frozen Expected authority, package-admitted current Actual, Harness-computed comparison/verdict, attributable static-production or direct-process observation, causal Counterfactual evidence and current Final-Gate snapshot proof. Every blocking External Record v2 retains exact per-obligation identity/evidence, a current challenge, whole-candidate identity, immutable artifact snapshots and a detached Ed25519 signature verified against a protected Source-bound public key. That verifies possession of the bound key, not a real-world identity beyond the Source binding. Legacy Record v1 and `machine_accepted_external_pending` are audit-only and cannot close. The workflow cannot discover undeclared requirements or prove arbitrary physical/external observation sound.
+
+Compile conserves Source meaning below the Source-item level. From the existing Semantic Fact Manifest it derives one internal view of every Source item and every strict-UTF-8 material attachment, canonical specification, repository-preservation input, external constraint, delegated instruction and textual design resource; it does not infer text from extensions, and unreadable or ambiguous text blocks. It deterministically covers headings, material paragraphs, nested list/table/quotation/Given-When-Then rows, fenced code/configuration and textual HTML and proves that all nonblank lines are exactly the disjoint union of Fragment lines and allowed pure separators. Every derived Fragment has one explicit `fact_bearing`, `supporting_basis`, `superseded`, `decision_required` or `scope_excluded` disposition. Reverse delivery-Fact provenance, anchors, semantic-cell identity and Claim modal polarity prevent supporting, supersession or exclusion from hiding an independent requirement. A `source_integrity` Fact cannot replace `delivery_semantic` meaning, and this remains part of the existing Source inventory and Semantic Fact Manifest rather than another ledger.
+
+Proof adequacy is also structural. Closed method and standard-property profiles are unioned with observation-scope, quantifier, Claim-kind and Control-field floors; prose keywords are advisory only. Presence proves only existence, while transition/sequence, product effect, boundary provenance, durable readback, identity/data state, population, fault/recovery, concurrency/idempotency, performance/capacity and selected-design/runtime semantics retain their stronger typed capabilities. A new unclassified standard property fails closed; a `custom.*` method or custom property without a standard profile cannot machine-close. A Check with no claim-bearing Assertion is diagnostic and contributes zero completion. Preflight generates machine and external candidates per exact Claim/Fact × method × applicability obligation, then accepts exactly one route: machine/external overlap, duplicate same-kind routes and no route are `unreachable`; broad `impact_claims` never removes a machine Assertion.
 
 Compile derives an internal `CompiledObservationAuthority` projection for every machine Claim or Fact × required-method obligation; it is not a new Contract Authority, state or registry. The first admitted slice has only two machine paths. `package_static_json_exact` reads plain exact implementation/configuration content from a UTF-8 JSON production carrier that already exists in the pre-run snapshot, retains the same no-follow file identity/digest after the runner, matches the Binding and is not Source/Context/Contract/expected material or evidence/report/status/verifier output; Harness selects the fixed RFC 6901 `/observations/<stable Fact-or-obligation identity>` locator and applies package duplicate-key/UTF-8/size/depth/pointer limits. Prepare-all mutation observation plus per-file pre/post identity/hash rejects transient and persistent runner swaps; it proves static content, not runtime consumption. `package_process_json_exact` applies only to a Source-backed `runtime_family: process`, `role: product` target and a direct root `project_binary` whose target and complete argv match that authority. Each required target has one canonical Source technical-obligation target covering key, role, family, root, complete argv and capabilities. Compile derives one declaration-stable process-runtime closure containing the exact Source-backed root, exact Claim/Counterfactual production carriers and only finite argv values that resolve to a production Binding. Every `root_argv` member remains the exact child-visible token: classification never splits spaces, strips quotes or rewrites backslashes. The closed grammar examines an independent token or one explicit `--name=value`; supported standalone switches remain labels and unsupported compound syntax receives no machine closure. Raw token and derived locator stay distinct. Quote-bearing, POSIX/UNC absolute, drive-prefixed, slash/backslash-platform-ambiguous and all scheme-shaped colon-prefix references outside the exact lowercase decimal `node:<number>` allowlist fail closed before execution unless explicitly routed to the existing external TCB/External Confirmation boundary. Parent segments resolve from declared `cwd` before repository containment is decided, so an in-repository `..` is legal and a true escape is not. Exact/pattern Bindings may own glob, extensionless or space-containing files; unmatched safe values and the exact lowercase decimal `node:<number>` and digits-only `<hours>:<minutes>` colon scalars are allowed but not copied. Compile neither broadly role-scans nor copies all `input_paths`; role separation applies only to actual closure members. Global Checks project Outcome Bindings into internal `{ outcome_key, local_key, binding_ref, binding }` records using `<outcome>.<binding>`: logical refs remain distinct while identical physical paths may be copied once, with no authored-Contract or registry change. Exact planned closure members may be absent through Compile but must materialize at Final Gate. Harness copies only that closure into an OS-temporary snapshot and binds its identity into host attestation. The child receives the unchanged raw argv and the minimal runner environment with no observation-path, challenge or protocol variable, then emits exactly one bounded `ty-context-product-observation-v1` envelope on stdout; compatible Cross-Check and implicit-preserved Facts share that Raw Execution/envelope while retaining independent result identities. This proves only exact values emitted by the Source-backed product root on the declared JSON output surface. An embedded dependency that cannot be explicitly production-bound or a Claim that cannot bind to that surface requires External Confirmation. The public project payload remains v3; no v4, shell/URI/dependency parser or general UI/native observer is introduced.
 
 Project-submitted v3 actual/value digest, comparison, `passed`, verdict and capability records are compatibility diagnostics only; they never supply Actual or completion authority. The current package-derived capability slice is exact/presence plus host-derived `target_runtime`. `interaction_trace`, `state_delta`, `design_conformance` and every other capability without a package-derived implementation require blocking External Confirmation even when a project record is present. Custom/`named_external_tcb` Oracles, wrappers, browser/native/device sessions, layout/pixel/accessibility/motion, protected observation, tolerance/mask and custom locators likewise cannot machine-close an obligation. Every machine Counterfactual needs package-admitted baseline and mutated observations on the same compiled process-closure identity, a mutation target in its production-carrier set, exact affected/preserved/allowed-fan-out accounting, equal obligation universes and host-derived process liveness; no-observation never skips validation. Existing Contracts are not silently rewritten, and target/closure TCB changes invalidate prior Active Authority, Progress, Evidence and Receipts for acceptance.
 
-An honestly unsupported Contract does not need a dummy verifier. Existing External Confirmations may cover exact ordinary/global and Semantic Fact Claim identities through `impact_claims`, while each Semantic Fact proof keeps its explicit `confirmation_ref`. An external-only Outcome sets `success_path_required: false`; a Stage Gate may omit its machine Check only when a `blocks_target: true` confirmation impacts that gate's result Claim. Missing result lineage, a non-blocking confirmation or a declared machine success path without a real success Check fails Preflight/Compile. A valid external-only route ends as `blocked_external`, never machine accepted.
+An honestly unsupported Contract does not need a dummy verifier. `target_profile.completion_authority` is `machine_only` or `declared_authorities`; legacy omission deterministically defaults to the fail-safe `machine_only` route and Preflight reports migration guidance. A blocking External Confirmation under `declared_authorities` must name its declared actor/owner, target, environment, Given/When scenario, evidence requirements and exact per-obligation rows with Claim, applicability, Fact/proof/method/capability and Expected-authority lineage. An external-only Outcome sets `success_path_required: false`; a Stage Gate may omit its machine Check only when a blocking confirmation covers that gate's result Claim. Missing decomposition/result lineage, an aggregate Boolean, a non-blocking confirmation or a declared machine success path without a real success Check fails Preflight/Compile. A valid unfulfilled route is `blocked_external`; after exact fresh fulfillment and a complete passing Final Gate it becomes `delivery_accepted`, never machine accepted.
 
-Direct-process observation is bounded containment, not an absolute hostile-code sandbox. Its TCB includes the host OS/filesystem/process APIs, Node runtime, snapshot-copy and no-follow/digest checks, stdout capture/decoder, timeout, process-tree inspection and cleanup. Frozen subtraction controls reopen transient/persistent carrier swaps or descendant/timeout leaks if the corresponding watcher/pre-post or containment/cleanup responsibility is removed, so those existing mechanisms remain; no additional edge mechanism is claimed. It does not claim to stop an intentionally malicious executable from escaping the copied closure, accessing ambient machine/network resources or evading every OS process-tree mechanism; workloads needing that adversary boundary require an external sandbox or External Confirmation.
+Direct-process observation is bounded containment, not an absolute hostile-code sandbox. On Windows, every contained execution uses the package-owned byte-identified PowerShell 5.1/7 and C# helper: it creates the declared executable suspended, assigns it to a fresh Job with `KILL_ON_JOB_CLOSE`, resumes only after assignment, bounds streams/timeout/overflow and accepts evidence only after `ActiveProcesses == 0`. Short-lived roots cannot outrun descendant enrollment, helper/identity/protocol drift fails closed, and there is no PID/CIM polling fallback. Non-Windows keeps the existing process-group/tree path; ordinary non-contained direct spawn is unchanged. The wider TCB still includes the host OS/filesystem/process APIs, Node runtime, snapshot-copy and no-follow/digest checks and stdout capture/decoder. It does not claim to stop intentionally malicious code from escaping the copied closure or using ambient machine/network resources; workloads needing that adversary boundary require an external sandbox or External Confirmation.
 
 Raw/revised proposals, selected design resources and mixed attachments enter one Source-bound Contract Draft loop immediately. Complete input inventory, stable keys, Product Control-level meaning, selected-resource design facts, acceptance/risk coverage, direct/derived/delegated/evidence-backed provenance, Source ownership and Contract mapping converge together. Every non-empty line in declared Markdown Source must belong to one Material `ty-source-item` block, one validated `design-resource-handoff-v1` or `design-resource-handoff-v2` formal block, or a closed-grammar background block: `markdown-structure` permits only text-free anchors/horizontal rules and `provenance` permits only `ty-source-provenance` comments with fixed `input`, `mode`, conditional `source` and optional `sha256` fields. A text-bearing heading or free-form provenance field can express authority and is therefore rejected as background. Arbitrary background prose and all other unclassified text fail closed. At least one marked technical obligation carries `aspect=architecture` and maps to an independently provable architecture obligation. If an unknown preference could materially change comparative research or selection, the workflow asks before Preflight/Compile can succeed. Once criteria are clear, a defensible recommendation is written into real Source with its delegation, preference/evidence basis and exact meaning; it is never hidden only in YAML. High-risk action remains an external confirmation. A pre-existing planning document's structure never blocks authoring.
 
@@ -441,7 +484,7 @@ One module-private-branded acquisition runtime constructs the interaction record
 
 The catalog derives 86 executions and 586 formal artifacts: 516 base files, 30 compute records, 10 State ledgers plus 10 State payloads, and 10 prompts plus 10 Provider events. Formal capacity is 650 files/364.625 MiB and complete run-set capacity is 4,379 files/974.3125 MiB, including explicit headroom and two excluded self-referential controls; overflow or an unexpected file fails closed. The Evidence Candidate contains all code/schema/Context/test/package-version/protocol bytes. A Promotion Commit must be its direct child and add exactly four package-/TCB-external governance records while mechanically preserving materialized-package, benchmark and runtime/TCB identities; drift requires recollection and reaudit. Runtime TCB v2 binds the clean Node launch, executable path/hash, worker/protocol source identities, parser/transport and all limits. The benchmark implementation identity includes `npm_command_spec.mjs`, the Provider protocol/worker and its owner-local finite dependency checker; working-tree, Git-object, collection and Promotion paths recompute closure and bind the actual executing repository root.
 
-Real collection remains `external_pending`: the Starward-derived fixture lacks authorized original incident design/runtime evidence, the complete original-to-sanitized mapping and retention/publication authorization; no retainable invocation-bound Provider usage/price material or State-retention Source has been supplied for this delivery. Synthetic controls prove only structure and may not be presented as formal-positive evidence. The implementation therefore remains Level 3 until qualified real evidence, the sole verifier's complete positive report, independent audit and explicit owner promotion all close. Package 0.8.15 is the historical frozen Evidence Candidate identity; package 0.8.17 is the current Level-3 package candidate and inherits none of its package, benchmark or runtime/TCB evidence. `capability_level` remains `level_3`, `level_4_claimed` remains false, and no formal-positive result or actual Promotion exists. Provider readiness means only that local configuration, credential presence and the clean worker launch envelope permit one bounded attempt. Public `independent_evidence_admitted` means packet structure/source binding only; `total_roi_supported` and `total_roi_positive` remain the complete-evidence and positive-ROI authorities.
+Real collection remains `external_pending`: the Starward-derived fixture lacks authorized original incident design/runtime evidence, the complete original-to-sanitized mapping and retention/publication authorization; no retainable invocation-bound Provider usage/price material or State-retention Source has been supplied for this delivery. Synthetic controls prove only structure and may not be presented as formal-positive evidence. The implementation therefore remains Level 3 until qualified real evidence, the sole verifier's complete positive report, independent audit and explicit owner promotion all close. Package 0.8.15 is the historical frozen Evidence Candidate identity; package 0.8.18 is the published predecessor; package 0.9.0 is the prior unpromoted Level-3 candidate; package 0.11.0 is the current Level-3 package candidate and inherits none of their package, benchmark or runtime/TCB evidence. `capability_level` remains `level_3`, `level_4_claimed` remains false, and no formal-positive result or actual Promotion exists. Provider readiness means only that local configuration, credential presence and the clean worker launch envelope permit one bounded attempt. Public `independent_evidence_admitted` means packet structure/source binding only; `total_roi_supported` and `total_roi_positive` remain the complete-evidence and positive-ROI authorities.
 
 The mechanism's own Final-Gate Oracle reads fixed-test-ID machine reports and compares complete wrong-candidate versus correct-control workflow statuses. A runtime capability requires `wrong candidate != machine_accepted` and `correct candidate == machine_accepted` through the real lifecycle; command exit plus token/string presence proves documentation consistency only. ROI is computed by a separate verifier and never enters a safety Fact verdict.
 
@@ -451,7 +494,7 @@ The package-owned non-UI Compact Carrier realizes that separation without anothe
 
 A separate read-only Global Product Conformance Check is required only for weak-observability work that also has multiple Stages or multiple required product runtime families. It starts at a required root product target, has independent Raw Execution and runs within the existing Final Gate. Single-Stage, single-family work retains the existing same-Check sensitivity path and pays no extra conformance run.
 
-The platform owns physical Goal/session lifecycle. A later session runs `resume` to reconstruct semantic state; Tiny Context does not recreate the prior physical Turn. Machine acceptance covers only `declared_machine_authority` and reports `native_goal_effect: none`. Before completing the platform-native Goal, the Agent performs a veto-only comparison of current Goal/user meaning against accepted marked Source and checks for pending revisions, unresolved blockers or omissions; this guard may block and repair, but it never supplies acceptance proof.
+The platform owns physical Goal/session lifecycle. A later session runs `resume` to reconstruct semantic state; Tiny Context does not recreate the prior physical Turn. Accepted Final/Stop/close results cover `declared_delivery_authority` and report `native_goal_effect: none`; Harness never completes the platform-native Goal itself. Before completing that Goal, the Agent performs a veto-only comparison of current Goal/user meaning against accepted marked Source and checks for pending revisions, unresolved blockers or omissions; this guard may block and repair, but it never supplies acceptance proof.
 
 ### CLI
 
@@ -467,6 +510,11 @@ ty-context long-task verify <workdir> [--outcome <key>] [--check <key>] [--expla
 ty-context long-task status <workdir>
 ty-context long-task resume <workdir>
 ty-context long-task doctor <workdir>
+ty-context long-task external prepare <workdir> [--confirmation <key>]
+ty-context long-task external submit <workdir> --confirmation <key> --record <path>
+ty-context long-task external status <workdir>
+ty-context long-task external rotate <workdir> --confirmation <key>
+ty-context long-task external revoke <workdir> --confirmation <key>
 ty-context long-task final-gate <workdir>
 ty-context long-task stop-check <workdir> [--message <text>]
 ty-context long-task close <workdir>
@@ -479,10 +527,12 @@ ty-context long-task abandon <workdir> [--force-corrupt-state]
 - `diagnose-revision` performs a side-effect-free candidate Compile. Only a scope-only candidate may run existing active Check identities with unchanged runner/verifier authority. Other mechanically bounded repairs return an automatic-revision preview without runner execution; decision-relevant Product/Claim/target/acceptance/forbidden-boundary/runner-type-or-effect/verifier-kernel changes return a user-decision preview, while risk downgrade is rejected. Output always has `acceptance_authorized: false`, `progress_written: false` and `pending_revision_written: false`.
 - `compile --revise` auto-adopts monotonic or mechanically bounded revisions. Decision-relevant revisions return `authority_revision_pending` plus the exact id, deterministic material summary, `user_decision_reasons` and a self-contained `decision_brief`, then fail closed until that exact id carries the user's decision. Present the brief first; mechanically relay an already explicit task-specific decision only when it covers every reason. Candidate edits produce a new id and invalidate old approval. Adoption emits `authority_revision_adopted`, invalidates affected evidence and returns to rolling execution; it never means delivery completion.
 - `verify` writes scoped per-Check Progress Records only after rechecking active task/revision/compiled/worktree identity and applying the same workspace categories against the immutable baseline. A concurrent revision returns `active_authority_changed_during_verify` and writes no stale progress. `verify --explain` is read-only: it groups selected Main Raw Executions, lists applicable Counterfactual invocations and declared retry-attempt bounds, executes nothing and writes no Progress.
-- `status` reports each Outcome as `unverified`, `progress_passing`, `progress_failing`, `progress_stale` or `blocked_external`. It derives `stages`, `ready_stages` and an advisory acceptance/verification Outcome frontier from current Progress without persisting Stage completion. The legacy `ready_for_implementation` field is a compatibility alias for that projection, not an implementation gate. Status also reports the fresh Final Receipt as `final_workflow_status` (or `null` after drift), target profile/state, the active Contract's complete `external_confirmations` and the single `pending_authority_revision` decision when present. `progress_passing` is targeted repair evidence rather than “Outcome complete”; `progress_stale` is a freshness fact rather than a current pass or immediate rerun command, and `final_workflow_status: null` means unfinished. It reads the common-dir authority snapshot and reports a missing or mismatched workdir cache as a repairable diagnostic.
-- `resume` is read-only and reports task identity, risk, relevant Context, Git state, the same Final/target/Stage/external/pending decision surfaces, ready Outcomes, findings and an advisory verification/repair next action from the common-dir authority snapshot. That action never restricts implementation order.
-- `final-gate` requires a clean candidate commit, first rejects stale accepted authority inputs, recompiles Source authority and captures semantic plus raw protected-input identity for the Contract/fragments, Source, full Controlling Context, verifier/runner, recursively frozen local verifier dependencies, verification inputs and workdir inputs. It reruns every required Check on one Git-tree snapshot, then recompiles and re-hashes the full protected set; any race fails closed before acceptance. Its Receipt derives each Stage as `passed`, `failed`, `blocked_external` or `blocked_dependency`, and derives `target_state` as `not_accepted`, `blocked_external` or the Contract's exact `implementation_complete`, `target_profile_usable` or `production_release_ready` qualification.
-- `stop-check` and `close` run that Live Final Gate themselves. They never trust status, progress, a Receipt or compiled cache for acceptance; success clears only the accepted identity through CAS. Every accepted Stop emits one non-blocking terminal-scope `systemMessage`; external-pending results additionally name all confirmations. Final/Stop/close report `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`; close also reports `closed_scope: machine_authority`. `status: closed` means only that machine Authority was cleared, not that the native Goal or complete external delivery finished.
+- `status` reports each Outcome as `unverified`, `progress_passing`, `progress_failing`, `progress_stale` or `blocked_external`. It derives `stages`, `ready_stages` and an advisory acceptance/verification Outcome frontier from current Progress without persisting Stage completion. The legacy `ready_for_implementation` field is a compatibility alias for that projection, not an implementation gate. Status also reports the fresh Final Receipt as `final_workflow_status` (or `null` after drift), target profile/state, declared confirmations, live per-confirmation fulfillment results and the single pending Authority Revision decision. Its non-persisted `repair_frontier` groups Findings by root, names Source fragments/Facts/proofs/Expected and Actual evidence, implementation/verification owners, minimum diagnostic reruns and still-fresh diagnostic Progress. It explicitly cannot accept and protects Source, Expected, Claims, proof authority, external scope, comparator and applicability from repair without Authority Revision.
+- `resume` is read-only and reports task identity, risk, relevant Context, Git state, the same Final/target/Stage/external/pending decision surfaces, ready Outcomes, enriched findings, the derived Repair Frontier and an advisory next action from the common-dir authority snapshot. That action never restricts implementation order.
+- `external prepare` emits current-candidate packets, the current challenge, Source-bound actor/key identity, signable canonical payload digest, exact obligation Expected/method/capabilities and evidence requirements while explicitly denying acceptance. `external submit` accepts one strict `long-task-external-confirmation-record-v2`, then in order validates Active Authority/freshness, schema, whole candidate, challenge, actor, Ed25519 signature, exact obligation and result-kind sets, immutable artifact snapshots and objective comparators before atomic storage. `external status` re-evaluates identity/signature/challenge/artifact integrity; `external rotate` changes the challenge; `external revoke` removes the named record and rotates its challenge. These mutations share the Active Authority lock with finalization. Failed/unable rows, declared-only actors and Record v1 remain non-accepting.
+- Programmatic v2 producers can import `parseExternalConfirmationRecordV2`, `externalConfirmationRecordV2Hash` and `externalConfirmationV2SignablePayload` from the package root, sign the canonical payload outside Harness with the actor-held private key and then submit the complete record. Harness exposes verification but no private-key reader or v2 signing command/helper. The exported v1 parser/hash/`signExternalConfirmationRecordV1` remain legacy audit compatibility only; their local hash is not authentication and can never fulfill a blocking obligation.
+- `final-gate` requires a clean candidate commit, rejects stale accepted authority inputs, recompiles Source authority, captures the complete protected-input and provisional Finalization Identity, and runs every semantic Check once on one Git-tree snapshot. It then enters one short existing-lock finalization CAS—without rerunning machine Checks—to recheck Authority, candidate/workspace fingerprint, compiled/verifier freshness, every external record/challenge/signature/artifact/evaluation and the exact Finalization Identity. Final Receipt v3 binds `finalization_identity_sha256` and emits only `machine_accepted`, `delivery_accepted`, `blocked_external` or `needs_work`.
+- `stop-check` and `close` run that same Live Final Gate and use the same transaction to publish the Receipt and, only for a fresh accepted identity, clear Active Authority. A mutation at any covered race point produces a non-accepted result, preserves Authority and cannot leave a fresh accepted Receipt. Historical v3 Receipts without `finalization_identity_sha256`, legacy `machine_accepted_external_pending`, pending rows, failures and stale/invalid records remain audit-only and fail-closed. Final/Stop/close report `acceptance_scope: declared_delivery_authority` and `native_goal_effect: none`; close also reports `closed_scope: complete_long_task_authority`.
 - `abandon` is explicit non-success cleanup. `--force-corrupt-state` is reserved for invalid/mismatched/legacy-unrecoverable state or a stale active lock and removes only deterministic local active state plus `<workdir>/.ty-context/**`; Contract, Source, Context and Git content are preserved.
 
 ### Delivery Contract
@@ -490,9 +540,15 @@ ty-context long-task abandon <workdir> [--force-corrupt-state]
 `long-task-delivery-v2` keeps Product Authority, Technical Boundary Authority and Acceptance Authority as logical sections of one file. Compact YAML omits only deterministic defaults; the normalized Contract and all hashes are identical to the expanded form. The compiler derives machine Claims for observable results, atomic Requirements, control fields including location, non-completing outcomes, technical obligations and forbidden shortcuts:
 
 <!-- long-task-public-contract-example:start -->
+
 ```yaml
 schema_version: long-task-delivery-v2
-semantic_fact_manifest: {key: example-semantic-facts, source_path: plans/example.md, sha256: "1111111111111111111111111111111111111111111111111111111111111111"}
+semantic_fact_manifest:
+  {
+    key: example-semantic-facts,
+    source_path: plans/example.md,
+    sha256: "1111111111111111111111111111111111111111111111111111111111111111",
+  }
 task:
   id: example-task
   title: Example task
@@ -502,6 +558,7 @@ task:
     description: The example is usable from its declared runtime root.
     required_state: target_profile_usable
     required_target_refs: [example-runtime]
+    completion_authority: machine_only
   execution_targets:
     - key: example-runtime
       description: Example product runtime
@@ -548,7 +605,7 @@ outcomes:
       - key: runtime-root-success
         target_ref: example-runtime
         journey_role: success
-        dimensions: [{key: runtime-state, value: ready}]
+        dimensions: [{ key: runtime-state, value: ready }]
         given_refs: [source-ready]
         when_refs: [inspect-result]
     semantic_fact_bindings:
@@ -557,6 +614,9 @@ outcomes:
         - fact_ref: example.result.observable
           claim_ref: semantic_fact.example.result.observable
           applicability_ref: runtime-root-success
+        - fact_ref: example.architecture.boundary
+          claim_ref: semantic_fact.example.architecture.boundary
+          applicability_ref: runtime-root-success
       proofs:
         - proof_ref: example.result.observable.runtime
           fact_ref: example.result.observable
@@ -566,6 +626,14 @@ outcomes:
           authority: machine
           check_ref: runtime
           assertion_ref: semantic-fact-ac
+        - proof_ref: example.architecture.boundary.runtime
+          fact_ref: example.architecture.boundary
+          method: exact_value
+          proof_surface: runtime_behavior
+          evidence_capabilities: [semantic_fact]
+          authority: machine
+          check_ref: runtime
+          assertion_ref: architecture-semantic-fact-ac
     product:
       observable_result: What a user or system can observe
       result_applicability_refs: [runtime-root-success]
@@ -574,7 +642,13 @@ outcomes:
       owner:
         label: Owning product or module boundary
         context_refs: [project_context/areas/main.md]
-        path_globs: ["src/**", bin/example-runtime.exe, tests/runtime.mjs, tests/verify-runtime.mjs]
+        path_globs:
+          [
+            "src/**",
+            bin/example-runtime.exe,
+            tests/runtime.mjs,
+            tests/verify-runtime.mjs,
+          ]
       requirements:
         - key: observable
           statement: The outcome is observable.
@@ -612,10 +686,22 @@ outcomes:
       checks:
         - key: runtime
           journey_roles: [success, stage_gate]
-          execution_target: {target_ref: example-runtime, entrypoint: root}
+          execution_target: { target_ref: example-runtime, entrypoint: root }
           scenario:
-            given: [{key: source-ready, statement: The planned source carrier is available.}]
-            when: [{key: inspect-result, statement: Inspect the result through the declared runtime.}]
+            given:
+              [
+                {
+                  key: source-ready,
+                  statement: The planned source carrier is available.,
+                },
+              ]
+            when:
+              [
+                {
+                  key: inspect-result,
+                  statement: Inspect the result through the declared runtime.,
+                },
+              ]
           proof_surface: runtime_behavior
           runner:
             type: project_binary
@@ -651,6 +737,14 @@ outcomes:
               evidence_capabilities: [semantic_fact]
               operator: equals
               expected: true
+            - key: architecture-semantic-fact-ac
+              criterion: The exact architecture boundary Fact passes its frozen comparison.
+              claims: [semantic_fact.example.architecture.boundary]
+              applicability_ref: runtime-root-success
+              observation: architecture_semantic_fact_result
+              evidence_capabilities: [semantic_fact]
+              operator: equals
+              expected: true
             - key: architecture-ac
               criterion: Preserve the observable module as the single state owner.
               claims: [obligation.preserve-observable-owner]
@@ -678,14 +772,28 @@ outcomes:
       counterfactual_controls:
         - key: replace-observable-semantics
           binding_key: observable-carrier
-          claims: [result, requirement.observable, obligation.preserve-observable-owner, semantic_fact.example.result.observable]
+          claims:
+            [
+              result,
+              requirement.observable,
+              obligation.preserve-observable-owner,
+              semantic_fact.example.result.observable,
+              semantic_fact.example.architecture.boundary,
+            ]
           check_key: runtime
           mutation:
             type: replace_text
             path: src/observable.ts
             match: "observable = true"
             replacement: "observable = false"
-          expected_assertion_failures: [result-ac, observable-ac, architecture-ac, semantic-fact-ac]
+          expected_assertion_failures:
+            [
+              result-ac,
+              observable-ac,
+              architecture-ac,
+              semantic-fact-ac,
+              architecture-semantic-fact-ac,
+            ]
           preserved_assertions: [runtime-liveness]
         - key: make-relations-applicable
           binding_key: observable-carrier
@@ -699,6 +807,7 @@ outcomes:
           expected_assertion_failures: [relations-na-ac]
           preserved_assertions: [runtime-liveness]
 ```
+
 <!-- long-task-public-contract-example:end -->
 
 In this example `bin/example-runtime` is the product root, not a verifier wrapper. It emits one stdout JSON object shaped as `{"schema_version":"ty-context-product-observation-v1","observations":{"<compiled-observation-identity>":<actual>}}` with exactly the identities compiled for the shared Raw Execution. Harness supplies no output path, challenge or protocol environment variable; a v3 verifier payload cannot substitute for this product envelope.
@@ -719,6 +828,7 @@ V2 authoring requires at least one real `source_path` and one `source_claim`. Du
 
 ```markdown
 <!-- ty-source-item:start key=save-failure kind=requirement -->
+
 Saving failure preserves the user's input and shows the reason.
 <!-- ty-source-item:end -->
 ```
@@ -753,10 +863,14 @@ Raw Execution identity binds frozen runner identity plus canonical declared Envi
 
 The workdir `.ty-context/compiled-contract.json` is only a rebuildable cache projection. Previous authority, the immutable initial base, risk floor and Final Gate identity come only from the common-dir snapshot. Commit, verifier migration, clear and abandon share one active-state lock; Final/Verify recheck identity and Stop/close use accepted-identity CAS. Observer identity, Compile admission policy and TCB changes invalidate existing Active Authority, Progress and Receipt acceptance; no custom Oracle, wrapper or machine-to-external migration is inferred. Corrupt continuity is recovered explicitly with `abandon --force-corrupt-state`.
 
-Final Gate may run only Contract-declared verification commands and never production mutation/deployment/payment/migration execution. Retry defaults to none and is allowed once only for `transient_once` + idempotent + read-only/test-sandbox runners. Runners receive a minimal environment whitelist plus only declared environment requirements. Protected authority/proof inputs reject symlinks and detectable hardlinks. Network isolation remains external. Receipts are audit-only (`reusable_for_acceptance: false`). Human, CI, deployment and product confirmation live only in `external_confirmations`; a machine pass with pending confirmations reports `machine_accepted_external_pending`, which is outside the complete-delivery accepted-terminal theorem and cannot complete the native Goal.
+Final Gate may run only Contract-declared verification commands and never production mutation/deployment/payment/migration execution. Retry defaults to none and is allowed once only for `transient_once` + idempotent + read-only/test-sandbox runners. Runners receive a minimal environment whitelist plus only declared environment requirements. Protected authority/proof inputs and external records reject unsafe path/symlink/integrity behavior. Network isolation remains external. Receipts are audit-only (`reusable_for_acceptance: false`). Pending blocking confirmation yields `blocked_external`; failed, unable, invalid, stale or unreachable proof yields `needs_work`; fresh exact blocking records plus passing machine obligations yield `delivery_accepted`. Non-blocking confirmations are advisory and do not change `machine_accepted`. No status directly completes the native Goal.
 
 ## Compatibility And Migration
 
+The 0.10 line preserves Schema v4, all five read policies and the exact existing default-footprint behavior. Router remains experimental and does not replace the Workflow bounded search. `context create` does not register; `register` and `move` are explicit dry-run-first operations with recoverable transactions. No automatic legacy-policy conversion or workspace migration occurs.
+
+Version 0.11 adds an opt-in sparse Design Authority bundle without migrating existing projects. A project with only an unmarked root `DESIGN.md` remains a valid one-file closure. Bundle adoption is one explicit DSA/Authority Revision that inserts the canonical `bundle-v1` marker and creates `design_system/authority.manifest.json`; `tokens.json` is generated from DESIGN and not a second editable owner. Existing DRA handoffs that omit the full identity remain compatible only for a true one-file project. Once adopted, retaining either half while removing or invalidating the other fails closed, and raw `DESIGN.md`-only bindings must be regenerated or rebound to the complete current closure. A deliberate return to one-file Authority removes both halves only through explicit DSA adoption/Authority Revision; the package can enforce the current marker/manifest pair and stale active bindings, but a fresh checkout containing neither half has no authenticated historical registry from which to infer a prior bundle. No upgrade command invents subordinate owners, Token values, adoption or Authority revision.
+
 Version 0.6.0 retires the V1 schema/runtime and repo-local Hook. Enable, disable and upgrade remove only exact Tiny Context managed Hook entries. Relocated package-owned absolute commands are recognized only when known managed status and package layout match; similar-name user Hooks remain. Upgrade never imports V1 progress or Receipts into V2 authority. Delivery Set, `composite-campaign` and `composite-long-task` commands are non-executing tombstones.
 
 Version 0.6.0 defined the first public V2 semantics while retaining the `long-task-delivery-v2` schema name and physical `outcome_files` parser form. It introduced the former optional Source Plan helper without adding Schema, CLI, Preflight, Compile, Validator, Receipt, Authority or state. Current releases integrate those Source-authoring semantics into `long-task-workflow` and retain the old Skill only as a compatibility pointer. Preflight and direct Compile use one activation-safety kernel.
@@ -795,7 +909,7 @@ make validate-harness
 
 The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
 
-`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.8.17.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.11.0.tgz` under the preview output directory.
 
 ## Community And Further Reading