Plan shared debug bindings and reporting mode access

docs/roadmap/shared-debug-binding.md

@@ -1,7 +1,8 @@
 # Shared debug binding and reporting-mode access
 
 Status: agreed scope and public behavior; not implemented. OD-1 and OD-2 are
-resolved; no significant open decisions remain.
+resolved; no significant open decisions remain. The
+[implementation plan](implementation.md) owns the ordered stages and verification.
 Baseline: `69257066e21c12ea3492237ebee072598adea60c`.
 
 ## Purpose and authority
@@ -10,7 +11,7 @@ Applications should be able to receive the boolean value of CommandKit's
 `--debug` flag through normal typed input binding. Applications that need the
 resolved reporting mode should also have a read-only invocation API.
 
-The [Audita request](audita-feature-request.md) motivated this work. Subsequent
+The original Audita request motivated this work. Subsequent
 discussion selected a broader distinction: application debug behavior and CLI
 reporting visibility are separate choices. Audita's original requirement that
 capture follow reporting mode is an application policy, not a CommandKit
@@ -63,6 +64,11 @@ declared default with `Set=false`; an explicitly supplied false produces
 binding semantics: every supplied value must be valid, and the last value wins.
 Other reporting flags do not rewrite the bound debug value.
 
+Shared bindings retain ordinary capture, identity, presence, and application
+semantics through `CaptureFlags`, `FlagValues.ApplyTo`, and `ApplySuppliedTo`.
+Renaming the boolean to an ordinary application name makes it independent of
+core debug input while retaining its ordinary binding behavior.
+
 The following examples appear after a complete command path. They show the
 ordinary false-default binding and the existing mode-selection rules together:
 
@@ -148,52 +154,18 @@ Progress and report format remain separate selections. Keep the public type
 independent of internal/backend types and avoid a second mutable copy of the
 resolved mode. A second accessor on `Reporter` is unnecessary for this scope.
 
-## Implementation work
-
-1. **Implement ordinary binding attachment and metadata handling.** Use the
-   selected `BoolFlag` form and the accepted application metadata rules above.
-   Preserve application defaults, presence, requiredness, and short spellings;
-   combine help without changing core reporting selection. Preserve ordinary
-   validation for unrelated names and bindings; do not broadly disable reserved
-   name or collision checks.
-2. **Connect shared parsing to typed input.** Update declaration validation,
-   metadata bridging, and backend value extraction together. Register one
-   effective debug flag, retain canonical occurrence order and supplied
-   spellings, and deliver its values through normal input preparation. Keep
-   reporting reduction based on the same parsed occurrences, including for
-   commands that have no application debug binding. Reuse current mechanisms;
-   a general observer registry, alternate parser, or subscription lifecycle is
-   not needed for this feature.
-3. **Preserve binding composition.** Review `CaptureFlags`, `FlagValues.ApplyTo`,
-   and `ApplySuppliedTo` in [flag_values.go](../../flag_values.go). A shared
-   binding should participate through the existing identity and presence
-   machinery. Review `RenameFlag` if a special binding marker is introduced:
-   renaming to an ordinary application name must not accidentally keep reading
-   core debug input. Avoid adding separate storage or application callbacks just
-   to carry this boolean.
-4. **Expose the mode query.** Reuse reporter state and its synchronization as
-   appropriate; document the zero-value, invocation lifetime, and concurrent-read
-   behavior. Do not expose backend objects or add public mutation APIs.
-5. **Update canonical documentation when implemented.** Update binding and
-   invocation GoDoc, the reserved-name wording in `FlagMeta`, and the
-   [CLI reference](../cli.md#placement-and-aliases). Add a short example to the
-   [consumer guide](../consumers/guide.md#invocation-reporting) contrasting a
-   bound debug boolean with an explicit mode query. Explain application effects
-   in application help using the accepted metadata rules. Record the core API
-   addition in the applicable release note. Retire this roadmap through the
-   normal documentation lifecycle when complete.
+## Scope and documentation
 
 This is core work. It does not require ConfigKit or PromptKit API additions or
 adoption of Audita's artifact implementation. Binding other core flags, adding
 mode setters, or creating a general flag-sharing framework is not part of this
 sprint; that scope limit is not a permanent prohibition on later capabilities.
 
-## Validation and completion checklist
+## Completion criteria
 
-Follow the [testing policy](../policy/testing.md): test the public behavior and
-reuse existing parser and reporting coverage rather than duplicate it wholesale.
-The table above supplies representative boundary expectations, not a request
-for separate copies of the same cases at every layer.
+The table above supplies representative boundary expectations. The
+[implementation plan](implementation.md) assigns test ownership and verification
+under the [testing policy](../policy/testing.md).
 
 - [ ] A registered application command receives the shared debug boolean and
   presence through normal typed input preparation, including when quiet or
@@ -212,15 +184,14 @@ for separate copies of the same cases at every layer.
   overriding that default, and ordinary requiredness/presence behavior. Help
   combines core and application explanations and distinguishes the application
   default; local short spellings use existing collision and alias rules.
-- [ ] Replace obsolete blanket rejection assertions for the allowed binding
-  form. Preserve ordinary metadata handling without new debug-specific
-  restrictions beyond the selected boolean binding contract.
-- [ ] Run focused binding/parser/reporter tests, then the core suite and aligned
-  integration suites using the [developer guide](../development.md). The shared
-  parser change justifies checking that standard integration commands still
-  register and execute. No live providers or Audita processing tests are needed.
+- [ ] The allowed boolean binding is accepted while unsupported/custom-parser
+  debug declarations and other reserved reporting declarations retain their
+  ordinary validation. Metadata handling adds no debug-specific restrictions
+  beyond the selected boolean binding contract.
 - [ ] GoDoc and consumer guidance distinguish boolean input from reporting
   mode, and canonical docs describe the implemented registration exception.
 
-For this documentation pass, review baseline accuracy, scope, links, and
-whitespace only. Implementation and the unchecked items above remain future work.
+Canonical binding and invocation GoDoc, the CLI reference, consumer guidance,
+and the applicable core release note will describe the implemented exception
+and mode query. The implementation plan owns the steps to reach and verify
+these criteria; the unchecked items remain future work.