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

Accept the captured declaration architecture and align documentation

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-10 16:19:45 +00:00
parent 8f86852456
commit 160604095c
10 changed files with 325 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
docs/roadmap/registration-api.md
View File

@@ -18,10 +18,12 @@ completed alternatives comparison is retained in Git history.
[ADR 0001](../adr/0001-command-dispatch-and-inputs.md) owns explicit registration,
typed inputs, and command ownership.
[ADR 0010](../adr/0010-optional-integration-modules.md) owns optional module
boundaries and convenient integration registration. The
[module roadmap](modules.md) tracks extraction work. Reconcile the namespace
lifetime decision below with the relevant ADR and architecture-policy wording
before implementation; this API design does not silently rewrite those records.
boundaries and convenient integration registration.
[ADR 0011](../adr/0011-captured-declarations-and-installation.md) records the
captured-declaration model, optional-family namespace lifetime, and separated
input/shared-state lifetimes. The [architecture policy](../policy/architecture.md)
reflects those boundaries. The [module roadmap](modules.md) tracks extraction
work; this API design remains a target rather than implemented behavior.
Design for the best consumer API without preserving current implementation
signatures or machinery. Existing code can supply evidence and reusable work,
@@ -200,9 +202,9 @@ Scope-specific parsed values stay separate from shared acquisition state through
the selected `Suite[I, S]`: `NewInput` initializes each selected scope's input,
while `NewState` initializes `S` once for the selected inspection invocation.
Providers receive both explicitly. Pointer inputs are independently initialized,
not shallow copies of a single pointer. The detailed lifetime table below makes
this change from the comparison's mixed context model explicit; it does not
require arbitrary deep copies or prohibit pointer inputs or shared pointer state.
not shallow copies of a single pointer. The detailed lifetime table below
spells out those calls without requiring arbitrary deep copies or prohibiting
pointer inputs or shared pointer state.
## Selected core declarations
@@ -1208,19 +1210,18 @@ is installed. An absent/no-op family reserves nothing. A domain group using an
uninstalled integration name is permitted, but blocks later installation of the
same root with a collision. Root-only placement is independent of that lifetime.
This clarifies an ambiguity rather than assuming that earlier broad reservation
wording already specifies the same lifetime. The durable documents need deliberate
alignment before implementation:
The documentation alignment is complete:
| Owner | Required alignment before implementation |
| Owner | Recorded decision |
| --- | --- |
| ADR 0001 | Clarify the reservation lifetime through the ADR change process if its accepted wording is interpreted as unconditional reservation |
| ADR 0010 | Retain core/integration dependency and convenient-composition boundaries; exact factories now return captured declarations |
| Architecture policy | State installed-family ownership uniformly for config and promptkit; align its public facade rules with ADR 0010 |
| Staged module implementation plan | Specify eager capture, error retention, neutral bindings, scope isolation, examples, and release adoption using this finalized API |
| [ADR 0011](../adr/0011-captured-declarations-and-installation.md) | Captured declarations, atomic installation batches, installed-family ownership, root-only placement, and separate input/shared-state lifetimes |
| [ADR 0001 status](../adr/0001-command-dispatch-and-inputs.md#status) | Remains accepted, with refinements recorded in ADR 0011 and its decision text preserved |
| [ADR 0010](../adr/0010-optional-integration-modules.md) | Core/integration dependency boundaries remain in effect; ADR 0011 refines registration and supersedes the migration-guide requirement for this unreleased prototype |
| [Architecture policy](../policy/architecture.md) | Uniform installed-family ownership, optional integration facades, and declaration/input boundaries |
| [Module roadmap](modules.md) | Final API selected; documentation alignment completed; extraction and release adoption still pending |
A new or superseding ADR can record the lifetime clarification where needed;
accepted decision text is not revised silently. The [module roadmap](modules.md)
now references this finalized API. Policy/ADR reconciliation and a staged
implementation plan remain pending; this document does not claim that those
records are already aligned or authorize implementation.
A staged module implementation plan remains to be written from this finalized
API and the module roadmap. It should specify eager capture, error retention,
neutral bindings, scope isolation, maintained examples, and release adoption.
The documentation alignment neither implements these changes nor authorizes
implementation by itself.