Record namespace selector applicability and profile inspection behavior

docs/roadmap/future.md

@@ -111,6 +111,11 @@ Output-contract overrides and appended-message flags are deferred below.
 These are CLI features; general-purpose helpers for
 application-internal PromptKit use are outside CommandKit's ownership boundary.
 
+[Roadmap OD-3](promptkit-v0.19.0.md#od-3-namespace-flags-and-loader-defaults)
+records the agreed namespace-selector applicability, including the limited role
+of profile selection in requirements inspection. That selection follows the
+released upstream identity requirement; it does not change prompt dependencies.
+
 - **Focused backend inspection.** Defer a standard backend detail command
   until a released PromptKit version provides a suitable public backend
   inspection capability. The operator task is to inspect one backend's

docs/roadmap/promptkit-v0.19.0.md

@@ -233,8 +233,8 @@ from a loader's engine view.
 Qualified IDs pass through native selection unchanged. Captured references,
 configuration inspection, and namespace/collection inventories retain their
 native meanings. Existing `--namespace`/`--all-namespaces` catalog filters
-continue to describe filtering. Install new selectors only on operations where
+continue to describe filtering. Install selectors according to the agreed
-they have a defined use; define that applicability table during implementation.
+applicability table in OD-3 and verify their use at the upstream call boundary.
 
 ### Shared configuration capabilities
 
@@ -778,7 +778,11 @@ Default tests remain offline and independent of real credentials.
   explicit empty values clear only the selected default. Qualified selections
   and catalog filters retain their native meanings. Custom scoped loaders remain
   usable without the option. Canonical namespace names and scoped aliases match
-  OD-3, with an explicit applicability table.
+  OD-3 and its agreed applicability table. Requirements inspection retains
+  optional profile selection and profile namespace resolution; help explains
+  that the profile establishes report identity, not discovered dependencies.
+  Cover prompt-default fallback, missing profile selection, and explicitly
+  selected short profile IDs without rewriting configured default references.
 - [ ] The full configuration suite retains six subcommands. Explanation
   discovery and validation diagnostics are modes of existing commands, with
   capability-aware help and selected mode/flag combination checks.
@@ -893,9 +897,9 @@ The core ownership, JSON representation conventions, text printing/templates,
 universal-format, automatic-selection, and joint format-delivery decisions are
 now agreed above. Remaining details are listed under
 [remaining core reporting implementation details](#remaining-core-reporting-implementation-details).
-Provider JSON number decoding is agreed in OD-2. Outstanding integration choices
+Provider JSON number decoding and namespace applicability are agreed in OD-2
-are namespace applicability in OD-3, empty comparison collections and binding
+and OD-3. Outstanding integration choices are empty comparison collections and
-design in OD-9, and override grammar/acquisition details in OD-11. Exact helper
+binding design in OD-9, and override grammar/acquisition details in OD-11. Exact helper
 names and report layouts otherwise remain ordinary implementation choices, not
 unresolved scope.
 
@@ -1099,9 +1103,38 @@ selection can retain their own loading behavior without enabling the option.
 | `--llm-profile-namespace` | `--profile-namespace` |
 | `--llm-backend-namespace` | `--backend-namespace` |
 
-Keep catalog `--namespace` filtering separate. Applicability to individual
+**Agreed applicability:** install only namespace selectors used by the operation
-commands and exact public helper signatures remain design tasks; install only
+when the application enables the standard namespace option.
-selectors with a defined use for that operation.
+
+| Operation | Resource-resolution namespace selectors |
+| --- | --- |
+| `promptkit show prompt` | Prompt |
+| `promptkit show profile` | Profile |
+| `promptkit requirements show` | Prompt and profile |
+| `promptkit requirements validate` | Prompt, profile, and backend |
+| `promptkit show prepared` | Prompt, profile, and backend |
+| `promptkit test KIND`, including `all` | Prompt, profile, and backend |
+| Resource catalogs | None; retain existing namespace filters |
+| Configuration inspection | None; configuration inspection remains global within the selected configuration scope |
+
+Verify this table against the native calls during implementation. Do not install
+a selector for symmetry when an operation cannot use it. Exact public helper
+signatures remain implementation choices.
+
+**Agreed requirements-inspection behavior:** retain optional profile selection
+and the profile namespace selector. In released PromptKit v0.19.0, requirements
+inspection selects and verifies a profile identity, using the explicit profile
+or the prompt's default, and includes that identity in the report. It fails when
+neither supplies a profile or the selected profile does not exist. The profile
+need not be execution-ready or have working credentials.
+
+The selected profile does not change the discovered prompt inputs or variables;
+analysis uses the captured prompt templates, supplied variables, and session
+context. Help must explain that profile selection establishes the reported
+identity, not a different set of prompt requirements. The profile namespace
+qualifies explicitly supplied short profile IDs; it does not rewrite the prompt's
+configured default reference. Preserve this released upstream behavior without
+adding a CommandKit workaround for profile-independent requirements inspection.
 
 ### OD-4: Configuration path and metadata presentation