Plan staged CommandKit implementation

docs/roadmap/initial.md

@@ -1,7 +1,6 @@
 # Initial CommandKit feature roadmap
 
-Status: selected initial implementation target; ready for staged implementation
-planning.
+Status: selected initial implementation target; unimplemented.
 
 Date: 2026-10-07.
 
@@ -9,9 +8,9 @@ Date: 2026-10-07.
 
 This document defines the selected 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.
+prepared using [the agreed checklist](initial-plan.md). Implementation steps belong
+in [the implementation plan](implementation.md). This document describes the target
+state; CommandKit currently has no Go module or dispatcher implementation.
 
 The [architecture policy](../policy/architecture.md) and nine accepted ADRs control
 this roadmap. The delivery scope, typed API model, selector/report behavior, and
@@ -122,10 +121,11 @@ containing the new public APIs and a revised capability assessment.
 **Owner:** root. **Prerequisites:** registry and invocation contracts below.
 
 Expose an application handle with private state and a small deliberate method
-set. Use 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.
+set. Use construction from application identity and explicit initial command
+registrations, 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.
 
@@ -135,9 +135,8 @@ registration. Public named CommandKit types live in the root. Public ConfigKit
 and PromptKit types are deliberate integration dependencies where useful.
 Use generic package functions/factories with explicit typed binding setters and
 composable groups. Go methods cannot declare their own type parameters, so generic
-entry points belong in package functions/factories. Exact names/signatures and
-captured-view assembly will be specified in the staged plan using this selected
-model before implementation begins.
+entry points belong in package functions/factories. Typed declarations and captured
+views retain their selected ownership and supported public value/error semantics.
 
 **Completion evidence:** an external consumer uses only the root facade to
 register and execute commands; public signatures, callbacks, fields, constraints,
@@ -246,9 +245,8 @@ 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. Specify exact assembly in the staged plan using generic suite helpers and
-small capabilities; do not require a universal untyped service container or handler
-access to parser objects.
+fields. Generic suite helpers and small capabilities provide this assembly without
+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:
@@ -568,9 +566,9 @@ Two maintained public examples should substantiate infrastructure reduction:
    `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.
+The declaration and callback burden should demonstrate infrastructure reduction
+against the existing handlers. Consumers should be able to use these examples
+without recreating dispatch, standard input parsing, or standard report projection.
 
 ## Explicit deferrals
 
@@ -586,7 +584,7 @@ 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
+## Completion criteria
 
 The initial target is complete when the included feature IDs have their stated
 observable behavior and evidence, and the selected roadmap choices are reflected
@@ -612,11 +610,3 @@ Maintain these substantive documents/artifacts as implementation lands:
   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.
-
-The delivery scope, typed API/outcome model, full profile coverage, and
-selector/validation behavior have been selected. Translate included IDs into
-ordered tasks with prerequisites, precise API/CLI deliverables, and completion
-checks. Specify exact Go declarations, binding helpers, captured-view assembly,
-and stream placement in that staged plan using the selected model. Carry deferred
-IDs forward without scaffolding them. The plan should make the selected public
-contracts concrete enough that the implementation agent need not invent them.