Finalize audit remediation decisions for implementation planning

docs/roadmap/audit/remediation-analysis.md

@@ -1,14 +1,15 @@
 # Audit remediation analysis
 
-Status: discussion in progress; no implementation changes made.
+Status: remediation decisions agreed; ready for implementation planning. No
+implementation changes made.
 
-This document owns analysis of unresolved remediation choices, in the discussion
-order below. The [catalog](catalog.md) owns the findings, accepted remediation
+This document records analysis of the remediation choices reviewed in the
+discussion order below. The [catalog](catalog.md) owns the findings, accepted remediation
 decisions, and their status. Original audits retain detailed evidence. Record
 accepted conclusions in the catalog and mark the corresponding discussion here
 decided; a decision does not close a finding before implementation.
 
-Existing catalog decisions for F03, F10, F11, F13–F16, and F21 remain selected. In
+Existing catalog decisions for F03, F10, F11, and F13–F21 remain selected. In
 particular, performance testing is not a prerequisite for F13–F15, and F14 and
 F15 are to be designed together. CommandKit is pre-release with no consumers;
 consumer compatibility and migration are not constraints on these choices.
@@ -20,7 +21,7 @@ Straightforward correctness repairs need not wait for this discussion sequence.
 | 2 | F21 | What narrow diagnostic adaptation API would simplify both integrations? | Decided: shared public ckconfig helper; remediation pending |
 | 3 | F16 | Which flag-consumption facts can parsing and completion usefully share? | Decided: shared internal mechanics, separate caller policies; remediation pending |
 | 4 | F14–F15 | How should both operations reuse source-prefix processing? | Decided: reuse existing resolver tree; remediation pending |
-| 5 | F17–F20 | Which private extractions materially simplify the existing code? | Functions reviewed; individual recommendations pending agreement |
+| 5 | F17–F20 | Which private extractions materially simplify the existing code? | Decided: bounded private extractions, conservative F19; remediation pending |
 
 ## F10 — Flag declaration naming
 
@@ -96,7 +97,7 @@ without introducing a broader diagnostics framework?
 **Evidence:** [catalog F21](catalog.md#f21--p3-both-integrations-maintain-the-same-configkit-diagnostic-adaptation)
 links both adapters and the original analysis.
 
-**Options to examine:** a narrow public ckconfig helper returning existing core
+**Options considered:** a narrow public ckconfig helper returning existing core
 diagnostics and an explanation, or retaining private implementations if the
 shared API adds more complexity than it removes.
 
@@ -147,7 +148,7 @@ completion retain their different handling of incomplete input?
 
 **Evidence:** [catalog F16](catalog.md#f16--p3-parsing-and-completion-duplicate-flag-consumption-grammar).
 
-**Options to examine:** a small neutral consumption primitive or deliberate
+**Options considered:** a small neutral consumption primitive or deliberate
 retention of duplication where a shared helper needs extensive caller modes.
 
 **Analysis:** execution's `interpretFlagTokens` in
@@ -198,7 +199,7 @@ structure without parallel indexes or changed routing semantics?
 **Evidence:** [catalog F14](catalog.md#f14--p3-discovery-context-preparation-repeatedly-rebuilds-shared-prefixes)
 and [F15](catalog.md#f15--p3-alias-help-scans-the-entire-source-catalog-for-each-intermediate-route).
 
-**Options to examine:** traversal and descendant lookup through the existing
+**Options considered:** traversal and descendant lookup through the existing
 alias source structure, or one shared private index if the existing structure
 cannot serve both operations simply.
 
@@ -257,7 +258,7 @@ adding records, phases, or configurable mechanisms merely to shorten functions?
 [F19](catalog.md#f19--p3-typed-input-preparation-mixes-conversion-provenance-and-replay-assembly),
 and [F20](catalog.md#f20--p3-reporter-message-paths-duplicate-detail-rendering-bookkeeping).
 
-**Options to examine:** cohesive functions over existing private types, or
+**Options considered:** cohesive functions over existing private types, or
 retaining related code together where extraction only adds indirection.
 
 These are maintenance improvements, not newly established incorrect CLI
@@ -347,5 +348,26 @@ each resulting diff by whether responsibilities are easier to follow and
 existing behavioral coverage still protects the selected contracts. Tests should
 not freeze new helper boundaries or incidental private call order.
 
-**Decision:** all four recommendations pending agreement; no refactoring has
-been implemented.
+**Decision:** all four bounded extraction recommendations and the sequencing
+guidance above are accepted and recorded in the catalog. F19 remains deliberately
+conservative. No refactoring has been implemented.
+
+## Readiness for implementation planning
+
+The discussion sequence is complete. No unresolved product or architectural
+choice identified in this review blocks preparation of the implementation plan.
+The catalog's 27 findings remain open until their remedies are implemented and
+validated.
+
+The plan can assign work units, dependencies, and proportionate verification.
+Routine details such as private helper signatures, the public diagnostic
+helper's final name, and the completion fixture's replacement flag are ordinary
+implementation choices within the accepted scope. Preserve the recorded
+boundaries; revisit a decision only if concrete implementation evidence exposes
+a conflict or a materially different tradeoff.
+
+Keep F14–F15 together, repair F06 before validating F16, and coordinate the
+reporter work in F03, F07, F20, and the relevant parts of F24 without obscuring
+their separate purposes. Validation should distinguish the aligned workspace
+from independent modules. No implementation plan or production changes are
+included in this analysis update.