@mnstry/atelier 0.2.0-alpha.12 → 0.2.0-alpha.13

package/docs/blocks/claims.md

@@ -20,15 +20,28 @@ for observation/reconciliation and one non-force push only when the exact
 reviewed commit plan requested and confirmed it, no earlier local commit is
 waiting to be published, and HEAD still names the verified commit object. Sync
 never uses the network actor fallback, follows tags, or recursively publishes
-submodule refs. The local authoring HTTP client
+submodule refs.
+
+The explicitly invoked maintainer rehearsal
+`src/knowledge-health/proof/rehearse.mjs` uses
+`src/knowledge-health/proof/common.mjs` to run `npm view`, `npm install` and
+optional `npm pack` against `https://registry.npmjs.org`. These commands can use
+the public package registry. The rehearsal uses empty consumer npm configuration
+and a disposable install/cache; installation uses `--ignore-scripts`. It is a
+maintainer proof command, not an automatic local authoring or conformance
+operation, and it calls no model provider. Its `npm ls` reads the consumer
+dependency tree. This disclosure does not authorize a registry rehearsal or
+publication.
+
+The local authoring HTTP client
 refuses non-loopback URLs, the served pages authorize no external origin, and
 release audit scans every executable or markup file in the exact `npm pack`
 inventory for egress primitives. The standalone gate also scans executable and
 markup files under `src/`, `bin/`, `scripts/`, `templates/`, `examples/`, and
 `skills/`. Two limits worth stating plainly: the egress control does not
 interpret data-only `.json` or `.md` files, and it does not model
-`child_process`; the reviewed `gh` and enrolled Git paths above are documented
-subprocess exceptions rather than scanner detections:
+`child_process`; the `gh`, enrolled Git and explicit maintainer `npm` paths above
+are documented subprocess exceptions rather than scanner detections:
 
 ```bash
 npm run egress:check

package/docs/blocks/inquiry-harnesses.md

@@ -0,0 +1,19 @@
+Discovery Harness and Research Harness share a local inquiry history. Discovery
+frames questions and competing explanations; Research returns source captures,
+verified assertions, contradictions and new questions. Immutable references keep
+each assessment and decision connected to the exact evidence it used.
+
+The open foundation includes qualitative assessments, explicit elicited odds,
+a simple Bayesian rate model, evidence-family checks, withdrawal tracking and
+reviewable graph proposals. Numerical results remain conditional on the declared
+model and evidence. They grant no execution or publication authority.
+
+Each harness is available as a portable capability package alongside existing
+skills. Skill Steward governs its version and repository adoption. Provider
+execution, hosted collaboration and specialized proprietary methods can use the
+same handoff and evidence contracts through separately authorized adapters.
+
+The architecture catalog calls the workflow Discovery Harness and resolves
+Discovery Engine as its historical alias. The immutable bundled v1 readiness
+pack retains its Discovery Engine title, identifiers and original digest, so
+existing release locks can use the governed upgrade path without a separate repin.

package/docs/blocks/learning-harnesses.md

@@ -0,0 +1,17 @@
+## Knowledge and Build Harnesses
+
+Knowledge Harness supports establishing, developing, evaluating, curating and
+activating a body of knowledge. Ingestion is one entry point alongside original
+writing, observation, research and build results. Contributions retain their
+domain revision, provenance, uncertainty and owner-reported review history.
+
+Build Harness records bounded objectives, exact candidates, artifact dependencies,
+attempts and distinct verification gates. Its coordination proposal can be read
+by Fabric or another adapter. The shared harness contract connects these workflows
+to Discovery, Research and Skill Steward without replacing their domain records.
+
+These are local, provider-neutral source capabilities for the next release.
+Handoffs preserve exact pins, and explicit source snapshots reveal corrections
+that require downstream reconsideration. Graph outputs remain draft proposals.
+Recorded acceptance is not authenticated authority, and local checks do not prove
+research quality or recipient acceptance. Hosted execution remains adapter-owned.

package/docs/capability-stewardship.md

@@ -0,0 +1,269 @@
+# Capability stewardship
+
+Status: source implementation for the next release. The published alpha.7
+package does not include the `capability` command. From this checkout, use
+`node bin/atelier.mjs capability ...`; the examples below use the installed
+command spelling for a package built from this source.
+
+Atelier can package a useful workflow, introduce it alongside a person's
+existing skills, and keep each repository's adoption explainable over time.
+The Skill Steward coordinates this work. People choose the purpose, boundaries
+and acceptance criteria; agents prepare, inspect and exercise the work within
+that authority; people validate consequential interpretations and publication.
+
+The foundation is local and provider-independent. A package can travel through
+Git, an offline copy or an existing distribution service. Atelier reads an
+explicit local directory. It does not download packages, execute their scripts,
+call a model, probe credentials, send telemetry or publish a release remotely.
+
+## The objects and their owners
+
+| Object | Purpose | Authority |
+| --- | --- | --- |
+| Capability | An outcome with inputs, outputs and limits | Publisher describes it; adopter judges its usefulness |
+| Skill | A standard `SKILL.md` bundle that teaches a procedure | Its instructions remain subject to the current task and host |
+| Package | Publisher/package ID, exact version, skills, dependencies, requirements and evidence | Publisher owns the source |
+| Release | Complete payload inventory and immutable digest | Integrity evidence; identity and quality remain separate |
+| Adoption | Repository ID, release pins, modes, aliases and admitted requirements | Repository owner |
+| Binding | A skill projected into one named host profile | Repository owner chooses placement; host controls actual discovery |
+| Observation | A version-, binding- and session-bound evidence reference | Caller reports it; reviewer evaluates the evidence |
+
+Stable package identity looks like `example.publisher/research`. Capability and
+skill IDs are local to that package. Display titles and installed aliases can
+change without making two publishers the same owner. Existing `atelier skills`
+commands and contracts remain compatible. The new public API is
+`@mnstry/atelier/capabilities`; its contract is
+`contracts/atelier-capability.v1.schema.json`.
+
+## Begin with the environment somebody already has
+
+Run `atelier capability inventory --surfaces surfaces.json`. The file is an
+array of explicit `{ "id", "scope", "root" }` entries. Scope is `personal`,
+`organization`, `repository`, `nested`, `plugin` or `other`. Machine paths stay
+in local configuration. There is no implicit home-directory or repository crawl.
+
+Inventory reports names, declared names, complete bundle digests, unreadable
+entries and name overlaps. It neither executes nor adopts what it finds. An
+overlap is a reason to inspect resolution and purpose; it is not a merge or
+deletion decision. Similar descriptions alone are insufficient to infer that
+two skills are equivalent. Missing surfaces and unreadable bundles remain gaps.
+
+The adoption modes are:
+
+| Mode | Result |
+| --- | --- |
+| `reference` | Record a pinned package without installing a binding or acquiring existing skills |
+| `managed` | Install selected bindings and track their exact projected bytes |
+| `customized` | Preserve an existing binding's current local bytes, its upstream release and its original projected digest |
+| `retired` | Remove clean managed bindings from discovery into preserved quarantine |
+
+Choose a new alias when an existing skill owns the desired name. Replacing a
+third-party skill is an owner-controlled migration outside this installer.
+Publish an intentional fork under a new publisher/package ID and retain its
+source provenance. A customized binding can return to management after its
+original projected bytes are deliberately restored; otherwise reconcile or
+fork it. No automatic merge of instructions is attempted.
+
+## Publish a portable package
+
+Author `capability-package.json` alongside self-contained skill directories.
+The supplied research and evidence-review examples under
+`fixtures/capability-packages/` demonstrate the complete layout. Their publisher
+identity is invented and their behavioral evaluations are explicitly unexecuted.
+
+The descriptor declares:
+
+- Identity, exact version, license and source provenance.
+- Capabilities and their inputs and outputs; skills providing those outcomes.
+- Supported host profiles and required tools and effects.
+- Exact required or optional dependency versions, release digests and capabilities.
+- Evaluation evidence, known limitations and migration guidance.
+
+Keep a skill's resources inside its own directory. An independently installed
+skill must not depend on a sibling directory the recipient might not receive.
+Publish shared executable dependencies as explicit packages or tools. Every
+relative inline Markdown resource link is checked, including links in nested
+Markdown resources. Other reference conventions and program behavior still
+require author review. Scripts are copied as inert, non-executable-mode payloads;
+this packaging code never runs them or their installation hooks.
+
+```bash
+atelier capability seal --package ./my-capability
+atelier capability verify --package ./my-capability --digest sha256:REVIEWED_DIGEST
+```
+
+Sealing exclusively creates `capability-release.json`. It includes the complete
+descriptor and the digest and size of every other file. Re-sealing into an
+existing release refuses; author the next version in a new source directory.
+Verification checks the full file closure and declared digest. Symlinks, special
+files, case-colliding payload names, unsafe paths and oversized bundles refuse.
+The limits are 512 files, 256 directories, depth 16 and 8 MiB per package.
+
+A matching digest proves the bytes match a reviewed pin. It does not authenticate
+the publisher or prove the source revision, license rights, host compatibility
+or behavioral quality. Obtain pins through your existing trusted distribution
+and review process. Signing-key discovery and a hosted registry are separate
+integrations; this implementation does not invent a new trust root.
+
+## Adopt into a repository
+
+Keep the desired adoption in a reviewed repository file, for example
+`capabilities.adoption.json`. A minimal entry is:
+
+```json
+{
+  "schema": "mnstry.atelier-capability-adoption@v1",
+  "id": "research-workspace",
+  "packages": [{
+    "id": "example.publisher/research",
+    "digest": "sha256:REPLACE_WITH_THE_REVIEWED_RELEASE_DIGEST",
+    "mode": "managed",
+    "bindings": [{
+      "skill": "inquire",
+      "host": "codex-repo-v1",
+      "alias": "team-research"
+    }],
+    "allowedTools": [],
+    "allowedEffects": ["read-workspace"]
+  }]
+}
+```
+
+The example digest above is a placeholder, deliberately not contract-valid.
+Use the actual release digest. All dependencies must be supplied and explicitly
+adopted; no dependency is downloaded or installed implicitly. Missing required
+pins and dependency cycles block the plan. Optional dependencies may be absent;
+if present, their exact pins must match.
+Each required dependency capability must have a selected provider skill bound to
+every host used by its dependent. A Codex-only dependency cannot silently satisfy
+a Claude binding. This proves declared placement, not actual host resolution.
+
+```bash
+atelier capability plan --adoption capabilities.adoption.json --source ./my-capability
+atelier capability apply --adoption capabilities.adoption.json --source ./my-capability --confirm sha256:REVIEWED_PLAN_DIGEST
+atelier capability status --session current-session
+```
+
+Repeat `--source` for multiple packages. Use `--tool TOOL_ID` only for tools the
+caller has observed as available. These are reported observations, not probes or
+permission grants. Missing tool observations or unadmitted declared effects block
+managed adoption. The plan shows requirement expansion alongside old and new
+release pins and modes. Effect declarations describe required authority; admitting
+them to a repository never grants execution permission in a host.
+
+The plan binds the repository's actual root identity, desired policy, source
+releases, observed tools, previous adoption state, notices and target bytes.
+Apply recomputes it under the shared steward operation lock and again after
+staging. Drift, unmanaged collisions, legacy-steward ownership, stale confirmation
+and reuse of an already-seen publisher/version for different bytes all refuse.
+The version-history check is local to this adopter; it is not a global registry.
+
+Local state lives in ignored `.atelier-local/capabilities/`. The repository must
+be a Git root with that private directory untracked and ignored before writes.
+Authored adoption files remain the desired source of record; status reports
+the last applied policy digest, and planning compares it with the supplied file.
+
+## Host profiles and evidence
+
+`codex-repo-v1` projects into `.agents/skills/ALIAS`; `claude-repo-v1` projects
+into `.claude/skills/ALIAS`. Both preserve the bundle and rewrite only its
+frontmatter name to the selected alias. There is no assertion that identical
+instruction bytes produce identical behavior. Each profile describes its
+placement, discovery limits, advisory permissions and required re-observation.
+
+These profiles cover repository file placement. Personal, enterprise, nested,
+plugin and session-specific discovery remain host-owned. Inspect the intended
+session's actual loaded skill and tools after adoption. The
+[Agent Skills specification](https://agentskills.io/specification) describes
+portable bundles; [Claude's host documentation](https://code.claude.com/docs/en/skills)
+describes its own discovery and precedence. An installed file alone proves neither.
+
+`capability observe --event event.json` stores a content-free event with the
+package/release, adoption generation, binding digest, host, session, observer,
+outcome, reported cause and evidence digest. The event must identify the current
+installed binding. Allowed kinds are `host-observed`, `exercise`, `feedback`
+and `evaluation`; arbitrary text and extension payloads are refused. Never encode
+source material or personal information into identifiers. Evidence stays at its
+original destination; only its digest is recorded here.
+
+`status --session ID` reports `installed: current` independently from
+`hostObserved: reported-passed` and `exercised: reported-passed`. An old generation
+or different session becomes historical evidence. These remain caller reports,
+not authenticated host receipts. Changing the adoption generation conservatively
+invalidates current-session claims, even when some binding bytes are unchanged.
+
+`capability candidates` groups current-version observations by reported cause.
+Repeated tool failures propose tool review; they do not automatically rewrite a
+skill. Repeated reports of one session/evidence pair count once. Candidate output
+does not prove causality, trigger an edit, certify quality, or retire rare skills.
+Use the existing steward's authoring checks for direct and indirect triggers,
+incomplete inputs, non-triggers, evidence gaps and boundary cases.
+
+## Updates, withdrawal and recovery
+
+Change the desired pin, review the new package and requirement delta, and repeat
+plan/apply. Every repository decides separately. `capability fleet --repo DIR`
+can inspect multiple explicitly supplied repositories and reports duplicate
+enrollment IDs and unavailable repositories. It has no multi-repository apply
+path or global atomicity claim.
+
+An explicitly supplied `--notices notices.json` array can classify an exact release
+`deprecated` or `withdrawn`, with an evidence digest. The notice contract is
+included in the capability schema. These are adopter-supplied advisories, not
+authenticated publisher announcements. Deprecation remains visible in the plan;
+withdrawal blocks managed adoption and updates of that digest while preserving
+installed files. Retirement still requires a separate exact plan. No background
+fetch or automatic deletion occurs.
+
+Successful replacement or retirement moves previous bundles into a transaction's
+`before/` directory. A durable journal precedes binding changes. If interrupted,
+future applies refuse until the operator inspects `capability recover`. Confirming
+that exact recovery plan restores the prior generation and preserves newly
+installed bundles too. Unknown bytes or changed state block recovery. A killed
+operation's lock can be reclaimed only when it is recognizably owned by this
+capability executor and its process is absent; other owners' locks remain theirs.
+
+The next capability or harness operation also checks for a recognizable dead
+owner when no adoption journal exists. Reclamation is serialized through the
+existing durable lock; a live or uncertain process, unknown owner, or changed
+lock refuses. A missing lock during cleanup never masks the original operation
+error, and a replacement owner's lock is preserved.
+
+This is a local POSIX, cooperating-writer transaction. It is not atomic across
+multiple skill directories, repositories or host sessions, and it cannot prevent
+an unrelated writer racing between filesystem checks and rename. Stop host file
+writers while applying. Windows adoption and event writes refuse. Storage ceilings, disk failure,
+permission failure and ambiguous filesystem state remain explicit refusal or
+recovery cases. Retained transaction data has no automatic garbage collection.
+
+## Research through graph integration
+
+The portable research example composes research planning, evidence review,
+synthesis and graph-integration preparation. It supplies independent inquiry
+prompts and output contracts; it works with the user's chosen research tool or
+manual execution. Its dependencies and host bindings use the same publisher and
+adopter workflow as any other capability.
+
+`capability graph --namespace ID` emits draft Markdown source documents as JSON.
+It records capability/package/release/adoption/binding and observation relations
+using Atelier's existing graph vocabulary. The command does not write canonical
+content. Review the destination and audience, materialize the selected files
+through normal authoring, then run that repository's graph build and retrieval
+checks. Graph validity establishes structure; it does not accept a research
+conclusion or grant execution authority.
+
+## Verification and next integrations
+
+`node --test test/capability-stewardship.test.mjs` exercises publisher integrity,
+multi-publisher dependencies, two repositories and two projection profiles,
+third-party coexistence, customization, clean updates, requirement admission,
+version immutability, retirement, interrupted apply/recovery, metadata evidence,
+CLI behavior and ingestion of generated documents through the real graph builder.
+The example packages disclose that no live agent has evaluated their behavior.
+
+Future adapters can add authenticated publisher evidence, actual host discovery
+receipts, dependency migrations and registry transport without making any of
+them implicit authority. A hosted service or new host needs its own integration
+and acceptance evidence. Preserve these contract distinctions when extending the
+foundation; do not turn a manifest, successful copy or reported outcome into a
+claim of authenticated publication or successful human use.

package/docs/coordination.md

@@ -0,0 +1,51 @@
+# Portable Coordination and native authority
+
+Coordination connects outcomes, owners, scopes, dependencies, directives,
+delivery, recovery and successors. It reads domain truth through typed references.
+A portfolio view cannot approve a change or manufacture a receiving receipt.
+
+`@mnstry/atelier/coordination` validates bounded outcome, dependency, directive,
+disposition and recovery observations. `coordinationView` projects them against
+an explicit time and freshness window. Missing, expired, future-dated, changed or
+ambiguous inputs remain visible. Producer references include repository identity
+and exact record digest. Dependency cycles are reported and block that chain.
+
+A receiver's reported receipt and acceptance remain separate from the producer's
+source gates. Gate reports bind an exact candidate. Passed, waived and pending
+retain their meaning; a waiver is not a passed test. Native receipt references
+are retained but not authenticated by this library. Every view exposes this
+limit and leaves completion and execution authority unestablished.
+
+Directives retain target, scope, expiry and supersession. Dispositions report
+proposed, sent, read, applied, verified or declined independently. A sent report
+does not imply reading or application; a record saying verified is still a
+native-owner report until that owner's verification is exercised. Recipient,
+repository, scope and current directive pins qualify applicability. Recovery
+retains prior/source and successor references without retiring a native task.
+
+`coordinatedBuild` includes the existing Build readiness result unchanged. Its
+native histories, independent gates and snapshot verification remain
+responsible for their own truth. Neither a portfolio observation nor a local
+projection can waive a Build blocker.
+
+## Fabric capability placement
+
+| Capability | Open-root disposition | Native responsibility |
+| --- | --- | --- |
+| Identity/provenance | Reuse domain references and immutable byte digests | Authentication and trusted custody |
+| Outcomes/owners/priorities/scope | Adapt through typed Coordination observations | Actual ownership and priority decisions |
+| Dependencies/handoffs | Reuse Harness verification; add cross-repository dependency/cycle views | Trusted snapshot acquisition and receiving receipt verification |
+| Directives/dispositions | Add scoped versioned observations and distinct stages | Sending, receiving, wakeups and authenticated acknowledgements |
+| Delivery/gates | Reuse Build candidate, attempt, decision and gate records | Commands, CI, review and deployment |
+| ADRs | Practical Judgment native-byte adapter and decision record | Repository numbering, authority and acceptance |
+| Practice/context | Learning lifecycle and scoped instruction adoption | Host context admission and observed behavior |
+| Ingestion/knowledge | One Intake source lineage, bounded ingestion, Knowledge review and context | Source rights, domain meaning and external processing |
+| Capability adoption | Capability releases, independent repository plans, Skill Steward and feedback bridge | Publisher trust, host loading and native use |
+| Recovery/retirement | Existing journal recovery plus retained successor observations | Distributed leases, backup, retention and deletion |
+| Portfolio/observability | Bounded pure views with coverage and freshness | Collectors, native dashboards and services |
+| Improvement | Inquiry, situated cases, learning proposal/evaluation/disposition | Model/provider operation and consequential judgments |
+
+Local operation requires no Fabric account or service. Hosted collection,
+distributed coordination and commercial interfaces may implement these contracts
+while retaining their own authority. A complete operated Fabric integration needs
+an exact native adapter and receiving proof; the portable views do not claim it.

package/docs/decision-practices.md

@@ -0,0 +1,111 @@
+# Decision practices
+
+This internal composition keeps a reusable decision practice inside an ordinary
+Knowledge contribution. It adds no adoption store, policy authority, scheduler,
+model route, command or package export. The format `atelier.decision-practice/v0`
+is experimental and is not a registered public contract. The existing
+instruction-adoption command, `atelier practice`, is a separate concept.
+
+A definition declares purpose, applicability, rights, required evidence roles,
+prerequisites, an existing decision request as a rubric specimen, count limits and
+the permitted reconsideration proposal. Purpose and rights statements are
+declarations; a consumer still needs its own source, actor and disclosure proof.
+The specimen establishes the task and rubric; it is not permission to reuse old
+request state or a result against different evidence.
+
+`validateDecisionPractice` inspects bounded JSON without invoking accessors.
+`prepareDecisionPracticeContribution` prepares captured contribution data for the
+existing Knowledge review path. It neither appends a record nor adopts a rule.
+`readAdoptedDecisionPractice` checks an exact contribution digest, current accepted
+review and a current activation in the supplied Knowledge history. That history
+is caller-supplied evidence, not independent proof of actor identity, current host
+permission or authenticity. Withdrawal, supersession and reconsideration remain
+the existing harness's responsibility.
+
+This portable profile deliberately bounds each complete input, including the
+supplied history, to 262,144 UTF-8 JSON bytes, 8,192 JSON members and depth 24.
+Each string also has a 262,144 UTF-16-unit limit and must not contain NUL.
+Knowledge itself accepts larger histories. A valid history outside this smaller
+profile returns `practice-input-exceeds-bounds`; it is not reported as malformed
+history. The host must supply an in-profile complete history or retain that typed
+refusal; silently truncating history cannot establish current adoption. Within
+the bounded inspected prefix, accessors, cycles, custom prototypes and sparse
+arrays remain malformed input. Reaching the traversal bound before a malformed
+value keeps the bounds refusal. Preparation reports a plain JSON history that
+fails Knowledge replay as `invalid-definition-history`; failure of the initial
+whole-input JSON copy remains `invalid-definition`. An adopted
+body must equal `JSON.stringify(definition, null, 2)`, as produced by the preparation
+function, and retain category `decision-rationale`, captured origin and locator
+`decision-practice:<definition id>`. Invalid, duplicate-key or noncanonical bodies
+return `invalid-definition`. A parsed adopted body outside the portable profile
+instead returns `practice-input-exceeds-bounds`.
+
+`evaluateDecisionPractice` returns `proceed`, `stop`, `escalate` or `refuse` with a
+typed reason. It checks declared prerequisites and count budgets, current exact
+evidence snapshots, text digests, and the existing decision request/result
+binding. Its initial internal profile maps one choice question to the three
+non-refusal outcomes. Other question forms may inform the supplied assessment,
+but no general expression language, workflow execution or confidence threshold
+is introduced. Model confidence does not establish correctness or authority.
+
+Request state must be exactly the request's evidence, in request order, using
+`<evidence id>: <exact text>` lines. Every request field except `id`, `state` and
+`evidence` must match the adopted specimen, including optional contract version
+and extensions. Each new evidence pin contains exactly `id` and `sourceRef`, with
+no extensions. The supplied result must validate against the exact
+new request digest. No provider is called or qualified by this module. An
+abstention escalates. Missing/stale evidence, unknown prerequisites, changed or
+unadopted definition, exhausted budgets, unsupported proposals and invalid rubric
+results refuse. A proposal cannot target its own definition, review or current
+activation. This protects the current definition and its reviews/activation;
+a superseded predecessor contribution is still an eligible reconsideration target.
+
+Count budgets are caller-reported consumption plus this assessment's declared
+requirements; they do not measure provider use, elapsed time or durable lifetime
+usage. The host must maintain those facts. Snapshots and records are supplied by
+the caller; their actual authority, authenticity and freshness remain host proof.
+The pure evaluator checks the complete supplied assessment envelope before a
+false prerequisite returns `stop`. It never obtains that assessment itself.
+A host that can stop before calling a provider should precheck prerequisites
+there; this module does not prove that provider work or cost was avoided.
+Malformed snapshots or timestamps also return `stale-evidence`: they cannot
+establish currency. `sourceRef` is a caller-supplied label; the host must bind it
+to the source resolved by exact retrieval.
+
+A proceeding outcome prepares an ordinary captured Knowledge contribution draft.
+Its body pins the definition, activation, reconsideration target, exact evidence,
+request digest and supplied assessment. Both preparation functions validate the
+completed draft against the existing Knowledge contribution shape before returning
+it. Pretty-print expansion beyond the writer's body limit returns
+`practice-output-exceeds-bounds` with no draft. This shape check uses a fixed
+validation-only envelope; it establishes no native record or actor authority.
+Definition preparation also checks the operating core: the complete supplied
+history, new draft data including its escaped body, and the repeated full rubric
+must fit the portable profile with 8,192 UTF-8 bytes reserved for additional
+adoption/instance metadata. Otherwise it returns `practice-output-exceeds-bounds`.
+This rejects definitions whose necessary repetition can never fit; it does not
+guarantee arbitrary future history, evidence, assessment or metadata will fit.
+The host must still validate the complete actual operating input before adoption
+and execution. A Knowledge-valid body alone proves no operating capacity.
+The assessment includes supplied provider/model/usage/extensions verbatim at the
+domain audience. Its inherited `rightsBasis` remains a declaration. The host must
+verify rights/consent and the full draft's permitted disclosure before review or
+append; this module does not sanitize an assessment or establish those permissions.
+It does not supersede the target, accept
+or activate knowledge, change native decision status, or write a file. A stale
+decision may be the subject of reconsideration; it is not smuggled into the
+draft's accepted `basedOn` dependencies. The receiving reviewer must revalidate
+the embedded references before adopting any resulting contribution.
+
+The invented journey changes a captured source, observes the existing Knowledge
+harness's dependent decision reconsideration, rejects the old local-reader
+handle, retrieves fresh exact evidence from a new explicit ingestion plan and
+prepares a separate draft. On the existing qualified POSIX reference profile, the simulated host explicitly
+appends that draft; it remains unaccepted and the original decision remains
+marked for reconsideration. Windows completes the same source-change, exact-read
+and pure-evaluation journey, then verifies the existing capability store refuses
+its write and leaves no harness history. The platform refusal does not skip the
+portable evidence or proposal checks.
+Fixtures contain simulated reviews and an invented supplied assessment. They
+establish no model quality, native actor or consent proof, Runtime database
+binding, real supported-consumer acceptance, integration review or deployment.

package/docs/decisions.md

@@ -165,3 +165,32 @@ prototype are accepted. No input is mutated.
 
 This module does not change the existing analysis adapter's default-disabled
 execution policy or accept a model proposal as an authored fact.
+
+## Capability stewardship and harnesses
+
+An optional decision provider, including Jev, belongs behind this host boundary.
+The core package has no Jev dependency or credential requirement. Its ingestion,
+inquiry, knowledge and learning workflows remain available without a provider.
+The public decision contract alone does not install or qualify an adapter.
+
+Use [Capability Stewardship](capability-stewardship.md) to inventory a provider
+capability's procedures, required tools, effects, exact release and repository
+adoption. A skill bundle can describe how to use an adapter; installing that
+bundle neither configures credentials nor enables provider execution. Record
+installation, actual host discovery, task qualification and deliberate enablement
+separately. The executing host owns the adapter, configuration, current permission,
+timeouts, budgets and revocation. No repository's adoption enables another's.
+
+Harnesses consume validated advice through their existing owners. Ingestion may
+use a qualified prioritization while retaining every selected source and coverage
+gap. Research preserves citations and contradictory evidence. Knowledge admission
+and [practical judgment](practical-judgment.md) retain their review and adoption
+steps; a provider result cannot write graph facts, accept a lesson, or install
+instructions. The [learning lifecycle](learning.md) can retain permitted outcome
+evidence for reconsideration without creating a second knowledge store.
+
+With no binding, use the existing local or manual workflow. A requested provider
+that is unavailable, unauthorized, over budget, timed out or returns malformed
+answers produces the corresponding explicit abstention. A host must not silently
+substitute a paid provider or promote an incomplete answer. Prove the ordinary
+no-provider journey and each enabled task independently before claiming adoption.