diff --git a/docs/roadmap/initial-plan.md b/docs/roadmap/initial-plan.md
index 63a30e4..b8fa3e8 100644
--- a/docs/roadmap/initial-plan.md
+++ b/docs/roadmap/initial-plan.md
@@ -1,9 +1,13 @@
 # Preparing the initial CommandKit feature roadmap
 
-Status: agreed drafting process; checklist work pending.
+Status: initial roadmap drafted; delivery/API decisions and roadmap review pending.
 
 Date: 2026-10-07.
 
+Progress is recorded in [the initial roadmap](initial.md). Checked entries mean
+the assessment or recommendation is recorded, not that a proposed contract has
+been approved. Its Open Decisions section identifies the remaining choices.
+
 ## Purpose and use
 
 Use this checklist to prepare `docs/roadmap/initial.md`, which will describe the
@@ -24,14 +28,14 @@ Go declarations, GoDoc, and the CLI reference under the
 
 ## 1. Establish authoritative requirements
 
-- [ ] Review all nine accepted ADRs and the architecture policy.
-- [ ] Build a requirements checklist linking each requirement to its authority.
-- [ ] Review the four numbered roadmaps as evidence and design proposals:
+- [x] Review all nine accepted ADRs and the architecture policy.
+- [x] Build a requirements checklist linking each requirement to its authority.
+- [x] Review the four numbered roadmaps as evidence and design proposals:
   [CLI plan](01-cli-plan.md), [dispatcher](02-dispatch.md),
   [backend](03-backend.md), and [facade](04-facade.md).
-- [ ] Identify conflicts with accepted decisions and carry the controlling choice
+- [x] Identify conflicts with accepted decisions and carry the controlling choice
   into the new roadmap.
-- [ ] Distinguish accepted requirements, remaining design choices, and proposed
+- [x] Distinguish accepted requirements, remaining design choices, and proposed
   delivery scope. Approval of this drafting process leaves those design choices
   to be resolved during roadmap preparation.
 
@@ -70,17 +74,17 @@ Evaluate this starting recommendation:
 | Root `commandkit` | Public API; instance registry; command groups; typed bindings and presence; invocation coordination; outcomes; standard handlers; scope metadata; ConfigKit/PromptKit integration contracts; report composition. Straightforward unexported implementation can live here. |
 | `internal/cobra` | Translate backend-neutral declarations into Cobra/pflag machinery; implement parsing and help mechanics; maintain independent invocation state; translate backend-owned failures. |
 
-- [ ] Define each package's purpose, owned features, inputs, outputs, dependencies,
+- [x] Define each package's purpose, owned features, inputs, outputs, dependencies,
   and extension points.
-- [ ] Describe the boundary between the root and adapter, including how declarations
+- [x] Describe the boundary between the root and adapter, including how declarations
   and callbacks cross it while retaining supported value and error semantics.
-- [ ] Keep Cobra/pflag types and operations confined to the internal adapter and
+- [x] Keep Cobra/pflag types and operations confined to the internal adapter and
   retain root-owned public named types.
-- [ ] Evaluate whether comparison or inspection code warrants another cohesive
+- [x] Evaluate whether comparison or inspection code warrants another cohesive
   internal package, using concrete implementation and integration needs.
-- [ ] Settle package placement during roadmap preparation so the later plan gives
+- [x] Settle package placement during roadmap preparation so the later plan gives
   Luna a defined target layout.
-- [ ] Keep package structure proportionate to the actual responsibilities under
+- [x] Keep package structure proportionate to the actual responsibilities under
   the architecture and agent policies.
 
 **Result:** a target package inventory and dependency/ownership map.
@@ -97,15 +101,15 @@ Organize the inventory around these feature groups:
 | PromptKit inspection | Configuration scope, prompt/profile catalogs, and definition inspection. |
 | Consumer integration | Lazy acquisition, selector applicability, upstream public types, and application-owned callbacks. |
 
-- [ ] Assign stable feature identifiers for later implementation-plan traceability.
-- [ ] For each feature, specify its observable result, package owner, provider
+- [x] Assign stable feature identifiers for later implementation-plan traceability.
+- [x] For each feature, specify its observable result, package owner, provider
   requirements, dependencies, and completion evidence.
-- [ ] Describe CommandKit behavior and provider result contracts separately from
+- [x] Describe CommandKit behavior and provider result contracts separately from
   recommended consumer practices.
-- [ ] Build an upstream capability matrix from current supported ConfigKit and
+- [x] Build an upstream capability matrix from current supported ConfigKit and
   PromptKit public APIs, recording the inspected revisions or versions.
-- [ ] Identify which capabilities are available now and which need upstream work.
-- [ ] For each missing capability, recommend including the upstream work or
+- [x] Identify which capabilities are available now and which need upstream work.
+- [x] For each missing capability, recommend including the upstream work or
   explicitly deferring that feature, with the reason and affected targets.
 - [ ] Settle initial delivery scope before preparing the ordered implementation
   plan. Missing capabilities leave independently supported operations available.
@@ -125,17 +129,17 @@ Begin with these review candidates:
 Expand to other consumers where their implementations provide useful evidence.
 Use the repository's code-discovery workflow when locating and tracing code.
 
-- [ ] Identify reusable logic and the behavior it supplies.
-- [ ] Separate it from application-specific acquisition, schemas, domain resolution,
+- [x] Identify reusable logic and the behavior it supplies.
+- [x] Separate it from application-specific acquisition, schemas, domain resolution,
   parsers, names, statuses, and formats.
-- [ ] Evaluate the candidate against the accepted CommandKit contracts and the
+- [x] Evaluate the candidate against the accepted CommandKit contracts and the
   selected feature target.
-- [ ] For each proposed port, record the source revision, relevant symbols/files,
+- [x] For each proposed port, record the source revision, relevant symbols/files,
   adaptation work, and dependencies.
-- [ ] Verify applicable licensing and attribution treatment under the
+- [x] Verify applicable licensing and attribution treatment under the
   [OSS policy](../policy/oss.md) before copying material.
-- [ ] Identify reusable examples or fixtures that demonstrate meaningful behavior.
-- [ ] Use representative simple and complex consumer examples to evaluate whether
+- [x] Identify reusable examples or fixtures that demonstrate meaningful behavior.
+- [x] Use representative simple and complex consumer examples to evaluate whether
   the proposed API removes repeated infrastructure and remains practical to wire.
 
 Sibling checkout links are review references. CommandKit implementation and
@@ -146,19 +150,19 @@ provenance and adaptation requirements for proposed ports.
 
 ## 5. Resolve implementation choices explicitly
 
-- [ ] Recommend construction, registration, command-group, and typed-binding API
+- [x] Recommend construction, registration, command-group, and typed-binding API
   shapes, including presence-aware inputs.
-- [ ] Select narrow provider representations against concrete integration needs,
+- [x] Select narrow provider representations against concrete integration needs,
   reusing upstream public types where useful.
-- [ ] Define acquisition lifetime and any justified dependency coordination or
+- [x] Define acquisition lifetime and any justified dependency coordination or
   result reuse, with callback ownership clear.
-- [ ] Specify configuration and context selectors and their applicability.
-- [ ] Define diagnostic presentation responsibility and delivery-failure handling.
-- [ ] Select report formats, framing, and schemas for the included operations.
-- [ ] Define comparison selection inputs for included diff capabilities.
-- [ ] Select the module baseline and supported dependency versions using the
+- [x] Specify configuration and context selectors and their applicability.
+- [x] Define diagnostic presentation responsibility and delivery-failure handling.
+- [x] Select report formats, framing, and schemas for the included operations.
+- [x] Define comparison selection inputs for included diff capabilities.
+- [x] Select the module baseline and supported dependency versions using the
   applicable policies and current dependency requirements.
-- [ ] For viable alternatives, record a recommendation and a short analysis of
+- [x] For viable alternatives, record a recommendation and a short analysis of
   each alternative.
 - [ ] Resolve choices that would otherwise require Luna to invent public behavior
   or package boundaries while following the implementation plan.
@@ -172,15 +176,15 @@ resolved to the depth needed by the later implementation plan.
 
 ## 6. Define completion and prepare the handoff
 
-- [ ] Define observable completion criteria for each included feature.
-- [ ] Cover supported commands, capability discovery, native YAML preservation,
+- [x] Define observable completion criteria for each included feature.
+- [x] Cover supported commands, capability discovery, native YAML preservation,
   outcomes, backend isolation, and representative public API usage.
-- [ ] Identify proportionate evidence under the [testing policy](../policy/testing.md),
+- [x] Identify proportionate evidence under the [testing policy](../policy/testing.md),
   prioritizing real adapter behavior and the supported public consumer boundary.
-- [ ] Identify documentation and attribution deliverables as their corresponding
+- [x] Identify documentation and attribution deliverables as their corresponding
   implementation lands.
-- [ ] Review the complete draft against its requirements checklist and package map.
-- [ ] Make upstream work, deferrals, and unresolved decisions visible in the draft.
+- [x] Review the complete draft against its requirements checklist and package map.
+- [x] Make upstream work, deferrals, and unresolved decisions visible in the draft.
 - [ ] Review the targeted end state before translating it into implementation tasks.
 - [ ] Prepare the subsequent staged plan with ordered tasks, prerequisites, precise
   deliverables, and completion checks mapped to the roadmap's feature identifiers.
diff --git a/docs/roadmap/initial.md b/docs/roadmap/initial.md
new file mode 100644
index 0000000..ee77df6
--- /dev/null
+++ b/docs/roadmap/initial.md
@@ -0,0 +1,690 @@
+# Initial CommandKit feature roadmap
+
+Status: proposed implementation target; open decisions require review before the
+staged implementation plan is prepared.
+
+Date: 2026-10-07.
+
+## Purpose and authority
+
+This document defines the proposed end state of the initial library: packages,
+features, integration contracts, dependencies, and completion evidence. It is
+prepared using [the agreed checklist](initial-plan.md). It does not sequence
+implementation tasks or describe existing Go code. CommandKit currently has no Go
+module or dispatcher implementation.
+
+The [architecture policy](../policy/architecture.md) and nine accepted ADRs control
+this proposal. Recommendations below fill in implementation choices; they do not
+become accepted architecture merely by appearing here. Exact exported contracts
+will belong in Go declarations and GoDoc; implemented operator contracts will
+belong in `docs/cli.md`.
+
+### Requirements and traceability
+
+| Requirement | Authority | Feature targets |
+| --- | --- | --- |
+| Own dispatch; use explicit instance registries, composable groups, typed inputs, and capability-based standard families. Keep application domain behavior with applications. | [ADR 0001](../adr/0001-command-dispatch-and-inputs.md) | REG-01, INPUT-01, INV-01, INT-01 |
+| Use Cobra/pflag internally; initially rebuild backend state for each invocation. | [ADR 0002](../adr/0002-cobra-backend.md) | BACK-01, INPUT-01 |
+| Expose one root facade with root-owned public named types and no backend leakage. | [ADR 0003](../adr/0003-public-facade.md) | API-01, BACK-01 |
+| Supply standard help/version and available configuration/PromptKit inspection operations; families may support different subsets. | [ADR 0004](../adr/0004-standard-inspection-surface.md) | HELP-01, VER-01, CFG-01–05, PK-01–03; deferred DIFF-01, CAT-01 |
+| Return explicit classifications and recommended statuses; preserve supported cause identity and report delivery failures. | [ADR 0005](../adr/0005-invocation-outcomes.md) | OUT-01 |
+| Apply namespace/resource-first grammar, options after the complete command path, interspersed operands, presence, and selected repetition rules. | [ADR 0006](../adr/0006-command-grammar.md) | INPUT-01, HELP-01 |
+| Preserve native effective YAML; prepare all selected show views before writing; frame aggregate display as separate documents. | [ADR 0007](../adr/0007-native-yaml-reports.md) | CFG-03 |
+| Compare safe semantic snapshots with sensitivity union and explicit coverage gaps when comparison is enabled. | [ADR 0008](../adr/0008-semantic-configuration-diff.md) | deferred DIFF-01 |
+| Declare scope capabilities; default to `app`; preserve the meaning and coverage of `all`; order scopes consistently. | [ADR 0009](../adr/0009-configuration-scopes.md) | CFG-01–05, INT-01 |
+
+The [four earlier roadmaps](01-cli-plan.md), [dispatcher proposal](02-dispatch.md),
+[backend proposal](03-backend.md), and [facade proposal](04-facade.md) supply design
+evidence. Carry these controlling corrections into implementation:
+
+- Singleton flags use the last supplied occurrence, including mixed `--name value`
+  and `--name=value` spellings. Repeatable flags accumulate in order.
+- Every configuration operation, including `validate`, defaults to `app`.
+- Straightforward private implementation may live in the root package. A
+  forwarding-only facade and a separate internal engine are unnecessary targets.
+- Partial capabilities remain useful; neither scopes nor families need every verb.
+- Preparing every selected view before report output is a `config show`
+  requirement. Other operations have their own output timing.
+- The older acquisition graph, shared-load mandates, selector inheritance rules,
+  illustrative Go declarations, and exact report layouts remain proposals.
+
+## Recommended initial delivery scope
+
+Deliver the dispatcher, public registration/binding API, identity/outcomes, and
+inspection operations supported by ConfigKit v0.5.0 and PromptKit v0.12.0.
+Applications can use CommandKit without registering either integration; the Go
+module still declares the dependencies used by its bundled helpers.
+
+| Family | Initial target |
+| --- | --- |
+| Identity and discovery | `help`, command/group help, `version`, explicit CommandKit version selection |
+| Configuration | `config scopes`, `validate`, `show`, `sources`, `explain`, including explicit aggregate validation/display |
+| PromptKit configuration | The `promptkit` configuration scope, independently of definition inspection |
+| PromptKit definitions | `promptkit show prompt`, and a documented projection for `promptkit show profile` subject to OD-3 |
+| Application commands | Typed custom leaf commands, nested groups, and groups with their own runnable handler |
+
+Recommend deferring catalog listing and semantic comparison until the owning
+libraries expose the required public contracts. These are accepted standard
+operations with deferred implementation, not rejected features. Their absence
+must appear accurately in help and capabilities. **OD-1** considers including
+upstream enhancements in the initial delivery instead.
+
+This scope provides meaningful configuration inspection immediately and avoids
+requiring an initial consumer migration to wait for every future capability.
+
+## Target packages and dependencies
+
+Create two production packages. Keep comparison and inspection helpers as private
+root implementation when needed; the current target does not justify another
+production package or a public integration subpackage.
+
+| Package | Purpose and owned features | Inputs and outputs | Dependencies and extension points |
+| --- | --- | --- | --- |
+| Root `commandkit` | Sole public facade; registry, typed bindings, standard handlers, provider integration, reports, identity, and outcomes | Accepts metadata, typed command declarations, acquisition callbacks, context, arguments, and caller streams; returns registration errors and invocation outcomes | Standard library, public ConfigKit/PromptKit APIs, YAML encoder, and the internal adapter. Consumers extend through commands, groups, parsers, scopes, and supported provider callbacks. |
+| `internal/cobra` | Routing/parsing/help adapter; fresh backend state; conversion of backend-owned failures | Accepts neutral command/flag/operand metadata, binding callbacks, and invocation callbacks; returns neutral parse/help results and classified syntax failures | Cobra/pflag and standard library. Its bridge is internal and carries no Cobra/pflag objects back to the root. |
+
+Dependency direction is root → adapter → Cobra/pflag. The adapter does not import
+the root. Root command declarations are lowered into the adapter's small neutral
+bridge; closures bind freshly allocated typed inputs and invoke root/application
+handlers. The root translates bridge failures into its public outcomes. Reuse
+standard `context.Context`, `io.Writer`, and ordinary Go values at this boundary.
+
+Keep registry policy, capability checks, standard handlers, and reports in the
+root. Cobra supplies routing and parsing machinery; its defaults must be adapted
+where they differ from the accepted grammar. Do not copy its entire API into
+CommandKit or introduce a selectable backend abstraction.
+
+### Module baseline
+
+Recommend the following reproducible starting baseline, rather than floating
+dependencies or sibling `replace` directives:
+
+| Item | Proposed baseline | Reason |
+| --- | --- | --- |
+| Module | `gitea.maximumdirect.net/eric/CommandKit` | Matches project identity and the existing library suite's module convention. |
+| Go | `1.25.5` | Matches PromptKit v0.12.0's declared minimum; ConfigKit v0.5.0 declares 1.25.0. |
+| ConfigKit | `v0.5.0` | Reviewed released inspection API. |
+| PromptKit | `v0.12.0` | Reviewed released configuration and named-definition inspection API. |
+| Cobra | `v1.10.1` | Concrete initial pin implementing the accepted backend decision. Its [module declaration](https://github.com/spf13/cobra/blob/v1.10.1/go.mod) requires pflag v1.0.9. |
+| pflag | `v1.0.9` | Match that Cobra baseline; its [module declaration](https://github.com/spf13/pflag/blob/v1.0.9/go.mod) fits the selected Go baseline. |
+| YAML encoder | `go.yaml.in/yaml/v4 v4.0.0-rc.6` | Match ConfigKit's existing dependency for CommandKit-owned YAML reports. Native configuration writers remain authoritative. |
+
+These pins are a proposal, not a claim that they are the newest releases. Resolve
+and review the actual module graph and license notices when adding dependencies.
+OD-1's expanded delivery alternative would require released upstream versions
+containing its new capabilities and a revised capability assessment.
+
+## Public API and integration model
+
+### API-01: public facade
+
+**Owner:** root. **Prerequisites:** registry and invocation contracts below.
+
+Expose an application handle with private state and a small deliberate method
+set. Recommend construction from application identity and registry options,
+registration methods for groups/standard suites, and invocation with context,
+arguments, and caller streams. Keep runtime dependencies in handler closures or a
+separate typed execution dependency parameter; they are not parsed CLI fields.
+Construction automatically installs help and version from identity/build metadata.
+Provider registration assembles the other standard families' supported operations.
+
+The target concepts are identity, application/registry handle, command/group
+declarations, typed bindings, presence, invocation environment, outcome, and scope
+registration. Public named CommandKit types live in the root. Public ConfigKit
+and PromptKit types are deliberate integration dependencies where useful.
+Exact names/signatures are settled through **OD-2** before the Luna plan.
+
+**Completion evidence:** an external consumer uses only the root facade to
+register and execute commands; public signatures, callbacks, fields, constraints,
+and method sets contain no backend/internal types. No public aliases, anonymous
+embedding, loosely typed bridge values, or returned backend errors defeat this
+boundary. Caller-supplied values/errors retain their documented treatment.
+
+### REG-01: instance registry and command groups
+
+**Owner:** root. **Provider requirements:** none. **Depends on:** API-01.
+
+Use one metadata declaration for each command's path, description, operands,
+flags, bindings, and handler. Compose groups explicitly per application instance.
+Support nested custom commands and a group that has both children and a runnable
+handler. Groups without handlers show help when invoked bare.
+
+Reject duplicate command paths and replacement of standard handlers. Own the
+`config` namespace when installed and `promptkit` when installed: applications
+cannot insert private children underneath them. Additional application families
+remain registerable without needing the standard families' verb subsets.
+
+Build standard command availability from declared capabilities. Validate missing
+wiring at registration; never load files to discover operations. Return errors
+from registration rather than allowing registration order to choose a winner.
+
+**Completion evidence:** two separate instances have independent registries;
+collisions and reserved-family violations return clear errors; nested custom
+groups work; partial standard suites expose only their available operations.
+
+### INPUT-01 and BACK-01: typed inputs and adapter behavior
+
+**Owners:** root for bindings/presence; adapter for backend mechanics.
+**Provider requirements:** none. **Depends on:** REG-01.
+
+Recommend generic command factories with explicit typed flag/operand setters and
+a typed handler. Allocate the input struct for each invocation. A presence wrapper
+such as `Supplied[T]` carries a value and whether it was supplied; omission differs
+from an explicitly supplied empty string, false, or zero. A repeatable binding
+collects ordered values. Support ordinary scalar conversions and caller-provided
+typed domain parsers without handler lookups by flag name.
+
+Metadata expresses required operands/flags, counts, and declared incompatible
+combinations. Parsing and declared input-shape failures are usage outcomes;
+application domain validation stays with the application handler. Do not infer
+additional incompatibilities from parser convenience.
+
+Apply ADR 0006's grammar through the adapter: standard long lowercase hyphenated
+flags, separated/equal string values, boolean presence or explicit boolean value,
+`--` termination, options after the full command path, and interspersed options
+and operands within that command. Help bypasses missing execution requirements;
+unknown help paths/flags still fail as usage errors.
+
+Initially rebuild the Cobra tree and binding state for each invocation. Repeated
+calls retain no prior values, slices, or presence bits. Caller closures keep their
+own lifecycle; this design does not establish concurrent dispatch support.
+
+**Completion evidence:** public invocations exercise the real adapter, explicit
+zero/false/empty values, omission, singleton last-wins, ordered repetition,
+interspersed operands, termination, and repeated executions with fresh inputs.
+Help routing must follow CommandKit's grammar even where Cobra differs.
+
+### INV-01 and OUT-01: invocation, outcomes, and diagnostics
+
+**Owner:** root, with syntax adaptation in the adapter.
+**Provider requirements:** handlers/acquisition callbacks. **Depends on:** INPUT-01.
+
+Pass caller context to handlers and acquisition callbacks. CommandKit does not
+create the executable entry point, install signal handlers, or call `os.Exit`.
+Return explicit success, usage, operational, or application-domain classification,
+recommended status, and supported cause identity. Standard statuses are 0, 2, and
+1 respectively for success, usage, and operational failure. Preserve an
+application handler's explicit domain classification and suggested status.
+
+Recommend making root invocation the single presenter of CommandKit diagnostics.
+Standard handlers return report/delivery information and safe diagnostic data;
+the adapter suppresses its own automatic error printing. Use public
+`configkit.WriteDiagnostics` for ConfigKit diagnostics and neutral presentation
+for syntax errors. Pair diagnostics with supplied source records where useful.
+Do not print an owning-library diagnostic twice through nested CommandKit paths.
+
+Return a delivery indication so callers can distinguish a diagnostic already
+presented from one whose write failed. Preserve both the operation cause and a
+delivery error when both occur; do not replace either with a backend error.
+Warnings alone allow success. Report or diagnostic writer errors are operational
+failures and can leave partial output. **OD-2** includes this public result shape.
+
+Callbacks control their own output. Consumer guidance should recommend returning
+diagnostics to the standard path and avoiding repeated presentation, without
+prescribing all downstream error handling. Upstream APIs determine how much
+underlying error identity survives; CommandKit cannot recover causes an upstream
+library deliberately withholds.
+
+**Completion evidence:** usage guidance appears on the diagnostic stream;
+reports appear on the report stream; warnings permit success; callback,
+cancellation, report-write, and diagnostic-write failures are classified correctly;
+public causes remain usable with `errors.Is`/`errors.As` where supported.
+
+### INT-01: acquisition and provider contracts
+
+**Owner:** root. **Depends on:** registry, typed inputs, outcomes.
+
+Recommend a typed configuration-suite factory parameterized by an
+application-owned inspection-context input. It installs the standard input
+bindings once, plus explicit typed application selector bindings, and scope
+registrations with acquisition callbacks. A simple consumer uses an empty context
+type. A complex consumer supplies campaign or other domain selection as typed
+fields. Exact assembly is part of OD-2; do not require a universal untyped service
+container or handler access to parser objects.
+
+Each scope declares supported operations and obtains a captured view only on an
+invocation that needs it. Use small operation-specific interfaces/callbacks:
+native effective writer; source reader; safe explanation reader/writer; and
+validation callback. Reuse `configkit.SourceInfo`, `Diagnostic`, `Path`, and
+`Explanation` rather than creating parallel provenance types. A bundled generic
+ConfigKit helper connects a loader returning `*configkit.Result[T]`; a PromptKit
+helper connects engine acquisition and `ConfigurationInspection`. Missing an
+operation must not require dummy implementations of other interfaces.
+
+For a selected operation, acquire its scope once and retain that view through
+reporting. A bundled helper can reuse the same loaded result for diagnostics and
+the report. Aggregate show retains all selected views before writing. Other
+operations need no application-wide cache or dependency graph.
+
+When an engine depends on application configuration, the application acquisition
+callback composes that dependency. It may share results in an invocation-local
+closure. Document that pattern, without requiring one universal loading method,
+forbidding consumer effects, or promising that arbitrary callbacks never reload.
+Recommend sharing inspection and execution loading/resolution where practical.
+
+**Completion evidence:** metadata-only commands do not invoke acquisition;
+single-scope operations acquire only their target; aggregate show observes its
+preparation rule; simple and complex consumer examples require no parallel
+dispatcher, manual standard-command parser, or duplicated standard report logic.
+
+## Standard command features
+
+All features below belong to the root; routing, flag conversion, and help
+mechanics use the adapter. Their common prerequisites are REG-01, INPUT-01,
+INV-01, and OUT-01. Provider requirements and additional dependencies are stated
+per feature. The following flags/report shapes are recommended implementation
+targets, subject to the open decisions below.
+
+### HELP-01 and VER-01: help and identity
+
+- Help describes installed standard and custom commands using registry metadata.
+  Root bare invocation, `help [COMMAND…]`, `--help`, and `-h` follow ADR 0006.
+- Recommend `version` and `version --scope commandkit`; default output is only
+  application identity. Version subjects are separate from configuration scopes.
+- Application identity is supplied at construction. Recommend obtaining embedded
+  CommandKit identity from Go build information, respecting module replacement
+  metadata; use an explicit development/unknown label when a tag is unavailable.
+  Do not invent a separate integer CLI version. Recommend a text default and
+  optional `--format yaml` for version records.
+
+**Provider requirements:** identity metadata only. **Completion evidence:** help,
+version, and discovery work with missing/invalid configuration and never invoke
+acquisition callbacks. Default version excludes dependency inventory; explicit
+CommandKit selection identifies the embedded component accurately.
+
+### CFG-01: scope metadata and selection
+
+`config scopes` lists identifiers and supported operations in order: `app`,
+`promptkit`, then additional identifiers alphabetically. Recommend text by default
+and `--format yaml` producing `scopes: [{name, operations}]`.
+
+All installed configuration operations use `--scope NAME`, defaulting to `app`.
+`validate` and `show` additionally accept `all`. Check requested coverage before
+acquisition. An unsupported scope/operation is usage failure with available
+choices; `all` never silently skips a scope. If `app` is absent, its default
+selection fails with useful choices rather than silently selecting another scope.
+
+**Provider requirements:** registration metadata only. **Completion evidence:**
+discovery matches installed handlers and partial capabilities; aggregate coverage
+errors occur before any acquisition; ordering and defaults match ADR 0009.
+
+### CFG-02: validation
+
+`config validate` invokes the selected provider's configuration load/validation
+boundary. ConfigKit's bundled helper regards successful load and required owning
+validation as success. PromptKit's helper constructs/obtains a valid engine;
+it does not run a prompt or probe model availability. Application domain context
+validation, when needed for its inspection view, belongs in its callback.
+
+Recommend text by default and `--format yaml` with a `scopes` sequence of completed
+validation records (`name`, `valid`). For `all`, preflight capability coverage,
+then validate in scope order and report successful scopes as they complete;
+stop on the first operational failure. Diagnostics explain the failure and the
+outcome indicates incomplete completion. This timing is an initial proposal,
+distinct from show's accepted preparation rule; **OD-4** considers alternatives.
+
+**Provider requirements:** validation/acquisition callback and safe diagnostics.
+**Depends on:** INT-01, CFG-01. **Completion evidence:** default validates `app`;
+explicit `all` validates requested coverage; invalid configuration yields status 1;
+warnings alone do not fail; no model execution is triggered by bundled handlers.
+
+### CFG-03: native effective display
+
+`config show` writes the selected scope's owning-library effective YAML. It must
+not marshal `Result.Config`, reinterpret defaults, remove nulls, or rebuild the
+native document from runtime structs. Recommend YAML as its sole initial format;
+accept `--format yaml` for explicitness.
+
+For `--scope all`, acquire and complete required owning validation of every view
+before writing any report bytes. Compose separate native documents in scope order,
+with YAML separators and scope-label comments. Recommend `---` followed by
+`# scope: NAME` before each document. Single-scope show writes native output
+without an added scope envelope. Preserve native content; framing must account
+for any native document marker without creating accidental empty documents.
+
+**Provider requirements:** native writer plus successful acquisition/validation.
+**Depends on:** INT-01, CFG-01. **Completion evidence:** single native output is
+preserved; aggregate YAML has one labeled document per selected scope in order;
+a later acquisition failure leaves no successful prefix; writer failure returns
+operational failure and may leave partial output.
+
+### CFG-04: source inventory
+
+`config sources` exposes the selected captured view's public source records.
+Retain the owning source IDs, labels, paths, kinds, layers, underlay indices, and
+import locations where available; missing fields do not acquire invented values.
+Keep owning-library record order. Recommend readable text by default and
+`--format yaml` with `{scope, sources}` and explicit snake-case source fields.
+
+**Provider requirements:** public source reader and acquisition.
+**Depends on:** INT-01, CFG-01. **Completion evidence:** acquired and synthetic
+records remain identifiable; import references correlate with owning IDs;
+reporting does not reload files or confuse provenance with effective values.
+
+### CFG-05: path explanation
+
+Recommend `config explain --path POINTER`, including an explicitly supplied empty
+pointer for the root. Use public `configkit.ParsePath`; malformed pointers are
+usage errors and unknown effective/historical paths are operational lookup
+failures. Do not treat a native writer's empty output as successful lookup.
+
+Text defaults to the owning `WriteExplanation` rendering. Recommend
+`--format yaml` with `{scope, path, effective, origin, history, secret_reference}`.
+Preserve `present`, `redacted`, and the owner's YAML fragment in each value
+snapshot; represent fragments as strings so absence/null/masked values remain
+unambiguous. Canonicalize paths through public `Path.String()`. Preserve owning
+provenance, reasons, dependencies, and reference names, not credential values.
+
+**Provider requirements:** safe public explanation and native text writer.
+**Depends on:** INT-01, CFG-01. **Completion evidence:** known current and removed
+historical paths work, root-pointer presence works, invalid/missing paths have
+distinct outcomes, and safe snapshots survive YAML report conversion.
+
+### PK-01: PromptKit configuration integration
+
+The bundled helper acquires an engine through the application callback, then
+uses `Engine.InspectConfiguration()` and its public native writers, sources,
+diagnostics, and explanation methods. Register these capabilities under the
+`promptkit` scope. Registration of this scope neither requires nor implicitly
+installs definition inspection.
+
+**Provider requirements:** engine/configuration-inspection acquisition.
+**Depends on:** INT-01, CFG-01–05. **Completion evidence:** native PromptKit YAML
+and ConfigKit-compatible provenance are exposed through the standard family;
+aggregate show can combine it with `app` without translating either document.
+
+### PK-02 and PK-03: named definition inspection
+
+Recommend these command inputs:
+
+```text
+app promptkit show prompt ID [--version VERSION] [--format text|yaml]
+app promptkit show profile ID [--format text|yaml]
+```
+
+Both acquire the engine lazily and pass the invocation context to the public
+inspection method. Prompt-version omission follows PromptKit's own selection
+semantics. Missing named definitions are operational lookup failures. These
+operations do not render/execute prompts, resolve credential values, or generate
+model output through CommandKit's handlers; application acquisition retains its
+own behavior.
+
+Prompt reports include ID, selected version, opaque hash, declared default profile,
+input definitions in declaration order, and declared output contract. Use explicit
+YAML fields rather than depending on incidental Go struct serialization. An
+output-contract value of `json` is domain metadata, not a JSON report format.
+
+Profile reports include the named ID, backend-completed static target fields,
+credential environment-variable name, and direct-credential requirement. Recommend
+an initial documented projection excluding arbitrary `ExtraParams`, with an
+explicit report indication that those parameters are omitted. Do not present an
+omitted map as empty or claim this projection is a complete effective target.
+**OD-3** weighs this useful current-release subset against waiting for an
+owner-redacted complete result.
+
+**Provider requirements:** public `InspectPrompt`/`InspectProfile` respectively;
+each capability can be registered independently. **Depends on:** INT-01 and the
+chosen report projection. **Completion evidence:** text and YAML preserve selected
+public metadata; profile credentials are reported as requirements/references;
+unknown IDs and cancellation retain supported public error identity; help never
+constructs an engine.
+
+## Selectors, reports, and ownership
+
+Recommend a shared standard selection input for acquisition-bearing inspection
+commands, carrying presence-aware `--config` and singleton `--overlay`.
+Application callbacks interpret their values using the owning loader. Omission
+delegates discovery/default selection; an explicitly empty overlay can represent
+the loader's no-overlay selection. The application
+supplies schema, filesystem/source construction, imports, and domain resolution.
+PromptKit integration does not assume its configuration is at the application
+root path; its callback maps selectors to its acquisition path.
+
+Register application context flags through typed bindings with declared scope
+applicability. For example, a Narratio campaign selection can matter to `app`
+inspection and to engine acquisition derived from that application view. Reject
+explicit selectors that do not apply to any selected scope with a usage diagnostic;
+for `all`, route each selector to the scopes that declare it. Metadata/help should
+state applicability. Validate declared selector combinations before acquisition;
+domain lookup/validation remains operational. **OD-4** reviews this proposed
+selection contract. Do not infer application-specific campaign or session policy.
+
+Recommend text defaults for CommandKit-owned summaries and YAML alternatives;
+`config show` is native YAML. CommandKit owns report schemas for summaries,
+source/explanation projections, and definition reports. Owning libraries own the
+native documents and safe values. Select schema fields deliberately and document
+them with implementation; no separate schema-version integer is proposed.
+
+| Responsibility | Owner |
+| --- | --- |
+| Command paths, shared grammar, standard handlers, metadata/help, selection preflight, report framing, outcomes | CommandKit |
+| Typed custom input mechanics and routing | CommandKit; custom domain meaning remains with the application |
+| Configuration composition, recorded resolution, provenance, sensitivity, native effective/explanation rendering | ConfigKit/PromptKit through supported public APIs |
+| Source discovery, application schema and domain validation/resolution, engine construction, runtime dependencies | Application callbacks |
+| Custom session/execution commands, effects, outputs, and domain results | Application |
+| Process context/signals, streams, final status mapping, process exit | Application entry point |
+
+Safe owning-library inspection is required for enabled standard operations. This
+does not promise that arbitrary configuration or prompt content is suitable for
+public disclosure, and CommandKit does not inspect arbitrary consumer error
+objects to enforce a broader confidentiality policy.
+
+## Upstream capability evidence
+
+The following clean sibling revisions were reviewed on 2026-10-07. They are
+evidence snapshots, not build dependencies.
+
+| Repository | Reviewed revision | Released API baseline |
+| --- | --- | --- |
+| ConfigKit | `dc09959cca4e105f49ec316c6d4ba585bd2340bd` | v0.5.0 |
+| PromptKit | `4b8169da286917fde7875425bb32b799b12c6af3` | v0.12.0 |
+| Scriptorium | `723fee9c466789fd3b6cca5492bf2edf99f4136c` | Consumer evidence |
+| Notarius | `66fa5585c1190581e96ec42102ce745c3869ba6d` | Consumer evidence |
+| Narratio | `8afb49c01808c04bc73f782d1619e87c8c2cd312` | Consumer evidence |
+| Audita | `3b4933256eff84327b812e7ae12babf743bc04a6` | Consumer evidence |
+
+| Capability | ConfigKit v0.5.0 | PromptKit v0.12.0 | Delivery consequence |
+| --- | --- | --- | --- |
+| Validated acquisition | `Load`/recorded resolution with application definition | `NewEngine` and application acquisition | Include CFG-02; do not add a parallel validator. |
+| Native effective YAML | `Result[T].WriteEffective` | `ConfigurationInspection.WriteEffective` | Include CFG-03 and PK-01. |
+| Sources/diagnostics | Public result/load-error source and diagnostic records | Configuration-inspection sources/diagnostics | Include CFG-04 and OUT-01. |
+| Safe path explanation | `Explain`, `WriteExplanation`, public `Path` | Equivalent configuration-inspection methods | Include CFG-05. |
+| Named prompt metadata | Outside its resource domain | `Engine.InspectPrompt` and `PromptInspection` | Include PK-02. |
+| Named effective profile target | Outside its resource domain | `Engine.InspectProfile`; credential-reference fields are documented, but `ExtraParams` is arbitrary copied data | Include the OD-3 projection only after its contract is selected. |
+| Catalog enumeration | Outside its resource domain | No public prompt/profile enumeration API found | Defer CAT-01; recommend upstream captured catalog inspection. |
+| Safe full semantic comparison snapshot | No dedicated public structured tree plus full sensitivity/coverage contract found | No corresponding configuration snapshot API found | Defer DIFF-01; recommend upstream safe snapshot support. |
+
+Relevant public declarations are [ConfigKit inspection](../../../ConfigKit/inspection.go),
+[metadata](../../../ConfigKit/metadata.go), [PromptKit configuration inspection](../../../promptkit/configuration_inspection.go),
+[engine methods](../../../promptkit/engine.go), and [inspection types](../../../promptkit/types.go).
+ConfigKit's `HistoricalPaths`, `Explain`, and redacted YAML provide useful pieces;
+they do not expressly define the full comparison representation required by ADR
+0008. Deriving a comparison contract from these pieces would require an explicit
+owning-library agreement and design, rather than assuming masks imply equality.
+
+### Deferred capability targets
+
+- **DIFF-01:** acquire two independently resolved selections of one scope through
+  public safe snapshots. Preserve absent/null/empty distinctions and scalar
+  semantics, recursively compare mappings, compare ordered sequences atomically,
+  apply sensitivity union, and report differences plus gaps in text/YAML. Completed
+  comparisons succeed even with differences/gaps. Snapshot data must describe
+  hidden paths and supported reasons without fetching secrets. Comparison selector
+  syntax/inheritance must be decided when bringing this feature into delivery.
+- **CAT-01:** list captured prompt/version entries and named profiles through public
+  owning catalog APIs; deterministic reports describe actual loaded definitions.
+  Do not infer catalogs from configuration YAML or inspect sibling internals.
+- **Complete PK-03:** obtain a safe owner-defined profile projection, including
+  provider parameters and their disclosure treatment, before expanding the initial
+  report beyond its selected coverage.
+
+Do not create empty handlers, pretend capabilities, or unused public snapshot
+types for these deferred targets. Future upstream contracts should inform their
+representations. Future FeedKit-like families can supply appropriate operations
+without supporting comparison or configuration scopes.
+
+## Reuse assessment and consumer fit
+
+Use the reviewed revisions above to evaluate extraction; no source is copied by
+this roadmap. Prefer existing public owning writers over porting their renderers.
+
+| Candidate | Useful behavior | Adaptation and boundary |
+| --- | --- | --- |
+| [Notarius configuration handlers](../../../notarius/internal/cli/configkit_commands.go): `runConfigEffective`, `runConfigExplain` | Load an application result and call native ConfigKit writers; canonical path parsing and lookup handling | Retain the acquisition-to-writer pattern. Replace application scopes, manual flag sets, output/status handling, and loader coupling with INT-01/CFG-03/05. The application keeps its loader and domain selection. |
+| Same file: `runConfigProfile`, `runConfigValidate` | Named profile inspection and application-specific validation examples | Evaluate inputs and callback needs. Their JSON report, private wrappers, and runtime/domain validation are not standard contracts. |
+| [Scriptorium inspection dispatch](../../../scriptorium/internal/adapter/cli/inspect.go): `inspectCommand` | Lazy engine acquisition and named inspection followed by formatting | Keep upstream method use. Replace private dispatch, `context.Background`, output-file behavior, old command paths, and integer-status plumbing with caller context, streams, and outcomes. |
+| [Scriptorium report projections](../../../scriptorium/internal/format/inspection.go): `FormatPromptInspection`, `FormatProfileInspection` | Explicit prompt/profile field projection and readable presentation | Prompt DTO fields are a useful starting inventory. Replace JSON output with YAML and select OD-3's profile coverage; its raw `ExtraParams` serialization must not become an assumed redacted report. |
+| [Narratio comparison](../../../narratio/internal/app/config_diff.go): `ConfigDiff`, `configDiffWithDependencies` and comparison helpers | Independent resolved selections, deterministic path records, and add/remove/change presentation | Evidence for future DIFF-01. Its application projection/digests, overlay-only operands, shared campaign policy, and absence of ADR 0008 sensitivity-gap semantics require redesign; no initial direct port is proposed. |
+
+Recommend implementing the small integration glue from these public contracts,
+using consumer code as behavioral evidence. If a substantive helper or fixture is
+actually copied/adapted, record its source commit, affected symbols/files,
+modifications, and required notices when it lands. Scriptorium and Notarius grants
+are GPL-3.0-or-later; CommandKit is LGPL-3.0-or-later. Common ownership does not by
+itself change those grants. Resolve applicable reuse rights or an author's
+deliberate licensing choice before any such copy under the
+[OSS policy](../policy/oss.md). No blanket source-port permission is inferred.
+
+Use secret-free synthetic fixtures reflecting existing consumer scenarios:
+defaults plus overlays and historical deletion, inherited profiles, explicit
+zero/false selectors, missing definitions, and a second scope that fails during
+aggregate show. Existing consumer cases can inform these fixtures; entire
+application schemas/workspaces need not be imported.
+
+Two maintained public examples should substantiate infrastructure reduction:
+
+1. **Simple ConfigKit consumer:** register one application loader and its schema,
+   use bundled scope wiring, then register a typed custom command. Standard help,
+   parsing, validation, native show, sources, and explanation need no private CLI
+   handlers or formatters.
+2. **Complex consumer modeled on Narratio/Scriptorium:** register app and PromptKit
+   scopes plus named definition inspection, with typed campaign/context selection;
+   compose app → engine acquisition in consumer code; retain a custom
+   `session restore` group/handler. Standard paths and report composition remain
+   CommandKit-owned while campaign/session meaning stays with the application.
+
+Review the declaration and callback burden against the existing handlers. If
+these examples require the consumer to recreate dispatch, standard input parsing,
+or standard report projection, revisit the API before making the Luna plan.
+
+## Explicit deferrals
+
+In addition to DIFF-01, CAT-01, and complete profile projection, defer JSON report
+output, shell completion, output-file management, backend selection, a plugin
+framework, general dependency injection, concurrent-dispatch guarantees, and
+implementation of additional library families. None is needed to prove the
+initial selected feature target. Application-owned commands remain extensible.
+
+Consumer migrations, release publication, and ReleaseKit integration are separate
+work. Initial implementation should be a usable module with maintained examples;
+source-release tooling is planned under the release policy when preparing a
+releasable candidate. Do not create placeholder publisher commands or a binary
+build matrix.
+
+## Completion and implementation-plan handoff
+
+The initial target is complete when the included feature IDs have their stated
+observable behavior and evidence, and the selected open-decision outcomes are
+reflected consistently in the API and CLI contracts.
+
+Use proportionate deterministic, offline behavioral evidence under the
+[testing policy](../policy/testing.md): public consumer tests with the real adapter
+for grammar/presence/state, real local ConfigKit/PromptKit fixtures for inspection,
+and controlled acquisition/writer failures at those boundaries. Review the public
+type/dependency boundary directly; choose automation only where its distinct
+protection justifies maintenance. Do not retest complete upstream libraries or
+add blanket coverage, race, scanner, or platform gates.
+
+Maintain these substantive documents/artifacts as implementation lands:
+
+- GoDoc for exact exported contracts, ownership, errors, and lifecycle.
+- `docs/cli.md` for installed standard syntax, formats, scope coverage, and outcomes.
+- Consumer guidance and complete simple/complex examples; link to owning upstream
+  configuration contracts instead of duplicating schemas.
+- `docs/internal/overview.md` describing the two implemented packages and their
+  actual boundary. Add focused internal/integration documents only where useful.
+- Dependency/source attribution and applicable license/notice material in the
+  change that incorporates it, under the OSS policy.
+- Contributor commands and orientation updates once the Go module and validation
+  commands actually exist; preserve existing policy ownership.
+
+Before writing the staged Luna plan, review the proposed delivery scope and
+resolve OD-1–4. Translate included IDs into ordered tasks with prerequisites,
+precise API/CLI deliverables, and completion checks. Carry deferred IDs forward
+without scaffolding them. That subsequent plan should make the selected public
+contracts concrete enough that the implementation agent need not invent them.
+
+## Open Decisions
+
+### OD-1: current-release delivery or upstream expansion first?
+
+**Recommendation:** adopt the initial scope above against released ConfigKit
+v0.5.0/PromptKit v0.12.0; defer DIFF-01 and CAT-01. Most duplicated inspection
+infrastructure can be removed now. Capability-based assembly already accommodates
+later additions without requiring every family/scope to acquire those verbs.
+
+**Alternative:** include public safe snapshots and catalog inspection in upstream
+work before completing the initial CommandKit implementation. This delivers the
+broader standard suite together and avoids an interim subset. It expands the
+initial effort into multiple independently released libraries and requires their
+data contracts, versions, and comparison selection rules to be selected first.
+Choose it if comparison/catalog inspection are required for initial adoption.
+
+### OD-2: exact typed registration and outcome API shape
+
+**Recommendation:** use an application handle, composable groups, generic command
+factories with explicit typed binding setters, and generic standard-suite helpers.
+Handlers receive typed inputs plus a separate invocation environment; return a
+root-owned outcome carrying classification, suggested status, cause, and delivery
+information. Reuse public upstream inspection records through small capabilities.
+This supports an ordinary input struct and avoids parallel consumer parsing.
+Go generic methods are unavailable, so generic entry points should be package
+functions/factories rather than methods with their own type parameters.
+
+**Alternative:** use typed descriptor/builders that collect bindings before a
+non-generic registration call. This can offer readable fluent assembly and stronger
+construction guidance, but adds builder surface and potentially more conversion
+machinery. Evaluate it against both consumer examples before choosing signatures.
+
+For failure delivery, recommend one outcome carrying both the operation cause and
+delivery failure, with a clear diagnostic-delivery indication. A viable alternative
+is `(Outcome, error)`, with the error reserved for invocation/delivery failures.
+That follows familiar Go conventions but needs a precise rule preventing the same
+failure from being ambiguously represented in both results. Resolve this alongside
+the constructor, binding helpers, captured-view assembly, and stream placement;
+neither signature is approved by this roadmap.
+
+### OD-3: initial profile-report coverage
+
+**Recommendation:** ship a documented current-API projection of named profile
+identity, static effective target fields, and credential requirements/reference
+names. Explicitly report that arbitrary provider parameters are omitted. This
+exposes useful backend-completed inspection now while keeping the coverage honest.
+It does not impose a new upstream confidentiality guarantee or promise complete
+effective-profile output.
+
+**Alternative:** defer PK-03 until PromptKit provides an owner-redacted complete
+profile inspection representation with provider-parameter treatment. This yields
+one fuller report contract and keeps sensitivity decisions entirely upstream,
+but delays useful named-profile inspection and expands upstream prerequisites.
+Directly serializing all current `ExtraParams` does not establish safe inspection
+semantics and is not a substitute for choosing a disclosure contract.
+
+### OD-4: standard selector and validation-report behavior
+
+**Recommendation:** use presence-aware `--config` and singleton `--overlay`, plus
+explicit typed context bindings with scope applicability. Use `--path` for
+configuration explanation and operands for named definitions. Validate coverage
+and declared input combinations before acquisition. For aggregate validation,
+report completed scopes in order and stop at the first operational failure.
+Use the proposed text/YAML schemas above. This is a small consistent initial
+operator surface; native show retains its separate preparation requirement.
+
+**Alternative:** expose distinct application/engine source flags and acquire all
+validation results before emitting one aggregate report. Separate selectors make
+independent source selection explicit and complete validation results are useful
+for tooling. They increase input vocabulary and need a defined aggregation/error
+model. Adopt these where actual consumers need independent roots or comprehensive
+validation in one invocation, rather than assuming every engine follows the app
+selection. A narrower variant retains shared selectors and only changes validation
+aggregation. Decide these report/selection details before publishing contracts.