Plan the Audita adoption sprint

docs/roadmap/commandkit.md

@@ -4,9 +4,9 @@
 
 **Status:** Adoption target and design decisions resolved; the upstream release
 gate is satisfied. Implementation remains pending. The
-[master roadmap](library-adoption.md) owns shared direction, exact dependency
-revisions, and sequencing; ConfigKit and
-PromptKit contracts are developed in [their](configkit.md) [outlines](promptkit.md).
+[master roadmap](library-adoption.md) owns shared direction and exact dependency
+revisions; the [implementation plan](implementation.md) owns sequencing. See the
+[ConfigKit](configkit.md) and [PromptKit](promptkit.md) outlines for their contracts.
 
 ## Baseline and Target
 
@@ -244,10 +244,8 @@ Audita processing context. Request preview and validation operate on supplied
 inputs; representative validator candidates can come from maintained fixtures
 without running proposal inference as part of request construction.
 
-Establish runtime and request construction first, then wire preview and
-validation, followed by smoke commands and assembled-CLI verification. All are
-required adoption scope. Address concrete integration blockers upstream rather
-than silently omitting standard capabilities.
+All three capabilities are required adoption scope. Address concrete integration
+blockers upstream rather than silently omitting standard capabilities.
 
 For standard CommandKit commands passed through by Audita, provide a concise
 link to the upstream documentation for the adopted version. Upstream owns their
@@ -257,50 +255,23 @@ limitations of the standard capabilities. Audita documentation covers only its
 own selectors, request construction, domain inputs, and application-specific
 behavior. Apply this documentation boundary to the whole standard command suite.
 
-## Work Outline
+## Integration Boundaries
 
-The adoption gate above is satisfied. Follow the master sequence and selected
-released dependency set when implementing this outline.
+The native `app` and PromptKit configuration scopes are distinct. Both sides of
+native comparison use their own selected inputs. Scope validation follows native
+scope behavior; process preflight checks what execution needs. The same
+engine-loading path and
+[automatic source contract](promptkit.md#automatic-prompt-sources--resolved)
+serve processing and all standard PromptKit commands. ReleaseKit supplies the
+application version; CommandKit owns standard flags, formats, help, completion,
+and outcomes, including native comparison status 3.
 
-1. Inventory Audita commands, arguments, flags, supplied empty/false/zero values,
-   streams, and exit behavior against standard declarations. Record intentional
-   migrations rather than recreating the old parser around CommandKit.
-2. Establish shared loaders and scopes using the native ConfigKit and PromptKit
-   integrations. Use the same engine-loading path for processing and every
-   PromptKit inspection, preview, validation, and smoke command, following the
-   [automatic source contract](promptkit.md#automatic-prompt-sources--resolved).
-   Keep configuration/resource inspection distinct from preparing
-   an actual domain request. Standard scope validation need not reproduce the
-   current combined settings-and-two-roles command; process setup must still
-   establish what execution needs. Review generic override forwarding explicitly.
-3. Install standard inspection and configuration commands, native formats,
-   help/version, and suite-consistent aliases/completion through supported APIs.
-   Supply the application's version identity from the ReleaseKit v0.9.0
-   integration selected in the master roadmap. Do not use a broad private CLI
-   framework around CommandKit.
-4. Adapt domain process handlers to reporting/outcome boundaries, preserving
-   transcript/artifact integrity, cancellation, and partial success. Apply the
-   resolved visibility, completion-summary, and
-   [output-failure rules](#output-failure-behavior--resolved). Establish the
-   preflight package and its [output preparation](#output-resource-preparation-during-preflight--resolved)
-   through the output-session component. The later glossary feature extends the
-   same package with its collection-readiness checks before resource preparation.
-   Standard command statuses, including comparison status
-   3, should not be forced into the old Audita-only status table without a domain
-   reason. Validate quiet mode against the transcript destination before creating
-   outputs or starting model work, using the released reporting-mode accessor.
-   Wire processing artifact capture to the released shared debug boolean; replace
-   Audita's independent debug parsing with the native binding while retaining its
-   application-owned capture behavior.
-5. Enable the standard preview, validation, and full smoke capabilities using the
-   resolved adapter and sequencing approach above. Share Audita request helpers
-   where domain additions are needed; keep generic resource inspection independent
-   of those domain inputs.
-6. Update [CLI](../cli.md), [configuration](../config.md), [operations](../operations.md),
-   [subprocess integration](../integrations/subprocess.md), examples, help,
-   completion guidance, and migration documentation with implementation. Document
-   Audita-specific behavior and link to upstream for standard command usage.
-   Adopt the dependencies and exact attribution together.
+Audita supplies typed process inputs, domain request construction, preflight,
+and output-session coordination. [Glossary readiness](glossary-stages.md#empty-collections-and-audita-preflight--resolved)
+is part of that shared phase. Standard inspection remains independent of
+processing inputs. Canonical Audita documentation owns application-specific
+behavior and the hard cutover; standard commands link to the adopted upstream
+reference. Exact selected dependencies and notices belong in attribution.
 
 ## Acceptance and Upstream Requests