Document profile inspection API

docs/roadmap/weatherreporter-promptkit-wishlist.md

@@ -185,51 +185,23 @@ and move failures ahead of weather collection.
 
 ## Priority 3: Prompt-Independent Profile Inspection
 
-**Disposition:** Covered by the accepted
-[prompt-independent profile inspection](profile-inspection.md) roadmap.
+**Disposition:** Implemented as
+[`Engine.InspectProfile`](../../engine.go). See the
+[consumer guidance](../consumers/pkg-promptkit.md#inspect-a-profile-before-prompt-work).
 
 ### Downstream need
 
 Weatherreporter will allow operators to select an external PromptKit profile
-source and may allow an explicit profile override. It should reject a missing
-profile, unknown backend, malformed execution target, or unsatisfied credential
-requirement before collecting weather data or writing report artifacts.
-
-### Current integration option
-
-Weatherreporter can validate an explicit profile by preparing one embedded
-prompt with fixture input. Prompts that use their own default profiles can be
-validated during their normal preparation stage.
-
-This couples configuration validation to one prompt and requires placeholder
-input even when only profile and backend resolution are relevant.
-
-### Requested capability
-
-The prompt-independent `ResolveProfile` API proposed by the
-[Notarius wishlist](notarius-promptkit-wishlist.md#priority-2-prompt-independent-profile-inspection)
-would satisfy this need. It should resolve built-in, file-backed, and
-programmatic profiles, validate backend membership, report credential
-requirements without resolving credential values, and preserve typed error
-classification.
-
-### Additional Weatherreporter considerations
-
-- An explicit application profile override should be inspectable without
-  selecting a report prompt.
-- A prompt-definition inspection result may expose its default profile ID so
-  Weatherreporter can inspect that profile separately.
-- Inspection should distinguish structural profile validity from current
-  credential availability so configuration validation can apply explicit
-  application policy.
-- An optional execution-target override should be considered only if it
-  describes the same target that a later run will use.
+source and may allow an explicit profile override. It needs to reject a missing
+profile, unknown backend, or malformed execution target before collecting
+weather data or writing report artifacts, and to apply its own policy to a
+reported credential requirement.
 
 ### Value to Weatherreporter
 
-This would improve fail-fast configuration validation and give operator-facing
-errors direct profile and backend context. It is valuable but not required for
-the initial migration.
+The implemented interface improves fail-fast configuration validation and gives
+operator-facing errors direct profile and backend context. It remains optional
+for the initial migration.
 
 ## Priority 4: Eager Source Validation
 
@@ -368,8 +340,8 @@ It should not block adoption.
 
 ### Semantic Execution-Target Fingerprints
 
-**Disposition:** Deferred until prompt-independent profile inspection defines
-the resolved target whose configuration identity would be fingerprinted.
+**Disposition:** Deferred pending a separate semantic-equality design for
+resolved execution targets.
 
 The semantic target digest proposed by the
 [Notarius wishlist](notarius-promptkit-wishlist.md#priority-3-semantic-execution-target-fingerprints)
@@ -432,11 +404,10 @@ Weatherreporter would be:
 1. Add executable preparation handles, ideally sharing implementation with an
    atomic detailed-run API.
 2. Add prompt-definition inspection.
-3. Add prompt-independent profile inspection.
-4. Consider eager source validation after evaluating whether the two exact
+3. Consider eager source validation after evaluating whether the two exact
    inspection APIs are sufficient.
-5. Add structured generation errors.
-6. Add structured capacity errors and semantic execution-target fingerprints
+4. Add structured generation errors.
+5. Add structured capacity errors and semantic execution-target fingerprints
    as lower-priority operational improvements.
 
 The first item removes the only material integration workaround. Prompt and