base-layer/commandkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Plan requirements inspection implementation

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-12 16:44:39 +00:00
parent 49b7e686b3
commit 3935dcdbda
2 changed files with 456 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
docs/roadmap/requirements.md
View File

@@ -4,6 +4,9 @@ Status: accepted feature roadmap; implementation has not started. Command
placement, public API, caller-variable syntax, and initial presentation are
settled.
The [implementation plan](implementation.md) owns the ordered delivery steps and
stage completion evidence.
## Purpose and authority
Expose PromptKit's prompt requirements inspection through the optional ckprompt
@@ -298,54 +301,21 @@ Structured discovery issues stay in this report. Engine acquisition diagnostics
continue through the diagnostic stream. The implemented CLI reference will own
the final schema; these examples do not define PromptKit discovery behavior.
## Work needed from the baseline
## Delivery and documentation targets
### Public contracts and adaptation
The [implementation plan](implementation.md) defines adaptation, command
assembly, presentation, validation, and documentation work from the baseline.
The maintained composed consumer should demonstrate a partial inventory and how
supplying discovery context changes it, with both delivered reports returning
status `0`. Focused native and boundary coverage should substantiate the selected
contracts without duplicating upstream's full analysis suite or adding new
validation infrastructure, performance guarantees, or release gates.
Add `RequirementsRequest`, extend the suite and its GoDoc, and adapt
`FromEngine` through the existing acquisition path. Preserve native errors and
diagnostics. Reuse ckconfig selection instead of adding parallel configuration
loading or asking providers to construct a CommandKit-specific discovery model.
### Command assembly and invocation
Add the optional requirements group and handler, bind the prompt operand and
discovery-context flags, and integrate selected input/state preparation. Update
the empty-suite check to include the new callback. Reuse captured declarations
and binding composition; introduce a helper only where the concrete reuse makes
the flow simpler.
### Presentation and delivery
Map the native result to the selected report representation and use the existing
buffered delivery and failure paths. Keep discovery limitations separate from
acquisition diagnostics and readiness claims.
### Validation evidence
During implementation, add focused coverage using real native inspection where
practical, together with boundary doubles for lifecycle and delivery failures.
Cover independently enabled and disabled capabilities, help without acquisition,
request forwarding, the selected variable-parsing cases, selected profile/version
and session context, complete and partial inventories, structured issues, nullable
metadata, native error identity, and invocation isolation. Exercise acquisition
diagnostics and writer failures through existing outcome paths.
Extend the maintained composed consumer with fixtures that demonstrate a partial
inventory and how supplying discovery context changes it. Show that both
successfully delivered inspections return status `0`. Validate the affected
integration and composed example under the repository's existing module/workspace
procedures. Reuse established core and
configuration coverage; this feature does not justify new generic validation
infrastructure, performance guarantees, or release gates.
### Documentation and durable decisions
When implementation lands, update ckprompt GoDoc, the CLI reference, consumer
guidance, and relevant internal summaries under their existing ownership rules.
Reconcile the deferred-work entry with this feature's actual status. The new
At delivery, ckprompt GoDoc, the CLI reference, consumer guidance, and relevant
internal summaries describe the implemented capability under their existing
ownership rules. The deferred-work record reflects its actual status. The new
operation fits the existing ownership and registration boundaries and requires
no new ADR. Leave ADR 0004 unchanged. Command spelling and report/API details
no new ADR; ADR 0004 remains unchanged. Command spelling and report/API details
belong with their canonical owners when implemented.
Release documentation and module version selection follow the existing release