Propose initial CommandKit feature roadmap

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.