Correct profile test boundaries and fallback coverage

docs/operations.md

@@ -19,6 +19,8 @@ persists the module snapshot and prompt data package, records Promptkit
 preparation provenance before provider execution, then persists raw output and
 execution provenance, validates the structured generated text, and renders the
 managed Markdown report from the validated text and deterministic values.
+The current receipts are transitional workspace state, not a cross-version
+profile-provenance contract.
 
 The managed report and its final metadata are saved before single-report
 Distributor notification is attempted. `--out` writes an extra operator copy;
@@ -111,8 +113,11 @@ The generated-text and render-context artifacts are written for every completed
 single-report generation.
 A report's metadata links the module snapshot, data package, preparation and
 execution receipts, managed report, generated-text artifacts, and any available single-report
-notification artifact. Batch notification artifacts are separate batch-level
-records under `notifications/batches`.
+notification artifact. These current-version receipts remain transitional; use
+the active command's classified error and explicit secure debug capture for
+prompt diagnosis rather than relying on them as a durable interface. Batch
+notification artifacts are separate batch-level records under
+`notifications/batches`.
 
 RunIDs begin with the UTC generation timestamp and report ID. A Daily RunID
 also contains its local valid date so multiple Daily reports in one batch have
@@ -186,10 +191,12 @@ remain available where they can be safely persisted.
 - A batch notification failure preserves each report's artifacts and adds the
   top-level batch notification artifact.
 
-Use the RunID from the action summary with the inspection commands above. For
-a batch failure, inspect the summary first, then inspect the affected report
-RunIDs or the batch notification path. Do not remove the whole workspace as a
-first response; retain it until the failure is understood.
+Use the action summary and its classified error first. For prompt or provider
+diagnosis, prefer an explicitly enabled secure debug capture; current-version
+receipt paths may provide supplemental context when available. For a batch
+failure, inspect the summary first, then inspect the affected report RunIDs or
+the batch notification path. Do not remove the whole workspace as a first
+response; retain it until the failure is understood.
 
 ## Operational Caveats
 

docs/roadmap/implementation.md

@@ -1,14 +1,15 @@
 # Domain-Specific Prompt Profiles Implementation Plan
 
-Status: Completed.
+Status: Stages 1–7 completed; remediation Stage 8 ready.
 
 ## Purpose And Authority
 
-This document records the completed implementation of the
+This document records the implementation and post-implementation remediation
+of the
 [domain-specific prompt profiles roadmap](domain-profiles.md). The roadmap is
-authoritative for scope, user intent, policy choices, and the implemented end
-state. This plan records the implementation sequence, verification, and exit
-gates used to reach it.
+authoritative for scope, user intent, policy choices, and the intended end
+state. This plan records implementation sequence, verification, audit findings,
+and exit gates.
 
 This plan follows the repository's
 [architecture](../policy/architecture.md),
@@ -361,6 +362,236 @@ the working tree contains only intentional changes, and the canonical
 documentation describes the implemented state. The feature is ready for code
 review and release preparation.
 
+## Post-Implementation Review
+
+Stages 1–6 implemented the intended production behavior and passed their
+offline verification gates. A subsequent review found no high-severity runtime
+defect, but identified three test-quality issues and one remaining validation
+obligation:
+
+- one app test asserted durable preparation and execution artifact provenance,
+  contrary to the active-execution boundary and accepted ephemeral-state
+  direction;
+- an adapter-package test depended upward on app orchestration and duplicated
+  test ownership;
+- embedded fallback profiles were inspected but not exercised through one
+  prepared execution with a provider fake; and
+- the roadmap's representative model-evaluation policy had no recorded
+  evidence.
+
+Stages 7 and 8 address those findings without changing the profile catalog,
+selection precedence, report assignments, prompt content, generated-text
+schemas, or default offline test contract.
+
+## Stage 7: Correct Test Ownership And Fallback Execution Coverage
+
+### Goal
+
+Remove accidental durable-state and cross-layer test commitments while adding
+one focused offline execution test for the embedded fallback path.
+
+### Work
+
+1. Rewrite `TestGenerateDetailedPreservesSelectedProfileThroughExecution` so
+   it protects active workflow behavior only:
+
+   - retain the Hourly default, day-scale default, and global-override cases;
+   - assert the profile ID sent in `promptexec.ExecuteRequest`;
+   - have the executor fake record the preparation and execution values it
+     emits, then assert their logical profile ID and effective backend/model;
+   - do not load preparation, execution, or metadata files to establish a
+     durable profile-provenance contract; and
+   - remove artifact-content scans whose fake inputs cannot contain an endpoint
+     or credential.
+
+2. Preserve meaningful safety coverage at the boundary that can expose the
+   sensitive value:
+
+   - retain adapter mapping coverage proving an endpoint from a real Promptkit
+     profile does not enter `promptexec.ProfileInspection`;
+   - retain app error coverage proving dependency errors containing an endpoint
+     or credential are replaced by a bounded classified error; and
+   - do not add profile endpoints or credentials to project-owned execution
+     types merely to make a leakage test possible.
+
+3. Remove `internal/app`, app configuration, and report-registry dependencies
+   from `internal/adapters/promptkit/adapter_test.go`. Move the assembled
+   application-preflight test to a new app-owned external integration test,
+   such as `internal/app/prompt_profile_integration_test.go` with package
+   `app_test`:
+
+   - construct the real Promptkit adapter through its public `New` function;
+   - call the public app prompt-inspection operation;
+   - supply a deterministic credential lookup rather than reading the process
+     environment; and
+   - cover Hourly, one representative day-scale default, the explicit
+     `weather-deep` global override, and a same-ID endpoint-only
+     `weather-light` override. The asset contract tests already own the exact
+     mapping for all four prompts, so the integration test need not repeat all
+     four.
+
+4. Add one adapter-owned, offline fake-client execution test using the real
+   embedded Hourly prompt at `1.1.0` and selected profile `weather-light`.
+   Execute through the normal prepared adapter path and assert:
+
+   - the preparation callback runs before the fake provider;
+   - preparation and execution report logical profile `weather-light`, backend
+     `openrouter`, and model `deepseek/deepseek-v4-flash`;
+   - the fake provider request targets `deepseek/deepseek-v4-flash`; and
+   - schema validation completes without contacting a live service.
+
+   One execution case is sufficient because Promptkit owns uniform source
+   precedence and the adapter's inspection tests already cover fallback,
+   operator file, operator directory, built-in, and explicit in-memory layers.
+
+5. Reconcile the profile-related current-state documentation:
+
+   - it may accurately describe fields present in current preparation and
+     execution receipts;
+   - it must not promise cross-version readability or characterize those
+     receipts as the profile feature's durable target architecture; and
+   - troubleshooting should prefer active command errors and explicit secure
+     debug capture, mentioning current-version receipts only as transitional
+     state if they remain useful before the ephemeral-state refactor.
+
+6. Do not change production profile resolution, prompt definitions, state
+   schemas, artifact validators, or the ephemeral-state roadmap in this stage.
+
+### Tests
+
+Run:
+
+```sh
+go test -count=1 ./internal/promptassets ./internal/adapters/promptkit ./internal/app ./internal/cli
+go test -count=1 -race ./internal/promptassets ./internal/adapters/promptkit ./internal/app ./internal/cli
+go test -count=1 ./...
+go vet ./...
+go run ./cmd/weatherreporter --help
+git diff --check
+```
+
+Review the changed tests against the testing policy and confirm that adapter
+tests own adapter behavior, app tests own orchestration, and state tests remain
+the sole owner of durable artifact format and validation details.
+
+### Exit Gate
+
+Active profile selection and effective-model propagation remain protected
+without adding a durable-provenance commitment; the adapter test package no
+longer imports the app layer; one embedded fallback profile completes prepared
+execution through a provider fake; and every required check passes offline.
+
+## Stage 8: Evaluate The Initial Model Ladder
+
+### Goal
+
+Produce explicit release-candidate evidence that the selected models are
+acceptable for their intended report tiers and that a representative local
+override provides the promised operator experience.
+
+This is an opt-in evaluation stage, not an ordinary automated-test stage. It
+requires operator-approved provider credentials, network access, and a local
+OpenAI-compatible endpoint. Do not mark it complete when those prerequisites
+are unavailable; report the missing prerequisite instead.
+
+### Corpus
+
+Use four representative, secret-free YAML data packages: one each for Daily,
+Today, Tomorrow, and Hourly. The set must include at least one package with
+precipitation windows and at least one with none. Remove precise private
+location identifiers or other operationally sensitive values without changing
+the meteorological relationships being evaluated.
+
+Record a SHA-256 hash and a short, non-sensitive description for each package.
+Do not commit full packages or generated prose unless the user separately
+approves them as repository fixtures.
+
+### Execution Matrix
+
+Run these six evaluations from the exact package bytes:
+
+| Case | Package | Profile |
+| --- | --- | --- |
+| Hourly default | Hourly | `weather-light` |
+| Daily default | Daily | `weather-balanced` |
+| Today default | Today | `weather-balanced` |
+| Tomorrow default | Tomorrow | `weather-balanced` |
+| Deep comparison | The same Daily package used above | `weather-deep` |
+| Local override | The same Hourly package used above | operator-defined `weather-light` endpoint profile |
+
+After the successful local-override case, stop or deliberately address an
+unavailable test endpoint and repeat it as a negative control. Confirm that the
+request fails visibly and does not call or select an embedded remote profile.
+This negative control is not an additional quality-evaluation case.
+
+Use a temporary, untracked evaluation harness beneath the module when exact
+package replay is needed. It should call the existing Promptkit adapter and
+project-owned execution contract rather than duplicate prompt loading,
+rendering, or schema validation. Remove the harness and all unapproved raw
+outputs before completing the stage. Never print or record credentials.
+
+### Evaluation Record
+
+Add a concise `## Evaluation Record` section to
+`docs/roadmap/domain-profiles.md`. For every case, record:
+
+- evaluation date, logical profile, effective backend, and exact model
+  reported by execution;
+- corpus hash, validation outcome, latency, prompt/completion/total token use,
+  and provider-reported or contemporaneously calculated cost;
+- whether every generated claim is supported by the deterministic package;
+- whether hazards, periods, uncertainty, and precipitation timing are used
+  correctly;
+- whether `precipitation_timing` is exactly an empty string for the no-window
+  case;
+- a short usefulness assessment for summary and forecast discussion; and
+- any provider, alias, or local-endpoint caveat observed.
+
+Do not include credentials, endpoints, complete effective parameter maps,
+full data packages, rendered prompts, or full generated responses in the
+record. The secure debug directory may be used temporarily for operator review
+and remains operator-managed.
+
+### Acceptance Rules
+
+- Every case must complete strict JSON Schema validation without repair.
+- Generated prose must contain no material unsupported weather claim or
+  contradiction of deterministic hazards, periods, or uncertainty.
+- Precipitation timing must agree with the deterministic windows and use the
+  required empty-string representation when no window exists.
+- The local override must select the operator model without modifying a prompt
+  or application code and must not fall back to a remote profile when the local
+  endpoint is unavailable.
+- Latency, tokens, and cost must be recorded, but this initial evaluation does
+  not impose an invented numeric threshold. The operator decides whether the
+  observed tradeoff remains acceptable for the named tier.
+- If a default case fails schema or factual acceptance, do not weaken the
+  schema or prompt to accommodate the model. Reopen the concrete model or
+  profile-setting decision in the feature roadmap and leave this stage
+  incomplete.
+
+### Verification
+
+After removing temporary evaluation material, run:
+
+```sh
+go test -count=1 ./...
+git diff --check
+git status --short
+```
+
+Confirm that the only intended repository change from this stage is the
+concise evaluation record and any roadmap status correction required by its
+result. Do not add live credentials, provider-dependent tests, a permanent
+benchmark framework, or release notes before a release version is selected.
+
+### Exit Gate
+
+All six cases satisfy the acceptance rules, the roadmap contains concise and
+safe evaluation evidence, no temporary corpus or response material remains in
+the repository, and the default suite remains offline. Set this plan back to
+`Status: Completed` only after both Stages 7 and 8 have passed.
+
 ## Open Questions
 
 None. The model identifiers, profile settings, report assignments, version

docs/troubleshooting.md

@@ -1,7 +1,10 @@
 # Troubleshooting
 
-Keep failed workspace artifacts in place. When a RunID is available, start
-with `weatherreporter inspect metadata RUN_ID` and use the paths in its result.
+Start with the command's classified error. When content-rich prompt diagnostics
+are needed, enable a new run with `--llm-debug-dir` and handle the resulting
+secure capture as sensitive. Current-version workspace receipts can provide
+additional context when present, but are transitional state rather than a
+long-term troubleshooting interface.
 
 ## Prompt inspection or credentials fail before collection
 
@@ -20,9 +23,10 @@ the selected profile's YAML, ID, backend or endpoint, and model. If the model
 is unexpected, first check the global `promptkit.profile` selection and then
 look for a same-ID definition in the configured file or directory.
 
-The preparation and execution receipts named by run metadata retain the
-selected profile ID and effective backend/model for diagnosis, but not an
-endpoint or credential. See the maintained
+Current-version preparation and execution receipts may retain the selected
+profile ID and effective backend/model, but not an endpoint or credential.
+Use them only as supplemental context after the active command error or an
+explicit secure debug capture. See the maintained
 [local `weather-light` profile example](../examples/weather-light-local-profile.yml).
 
 ## Local model endpoint is unavailable
@@ -36,10 +40,11 @@ does not probe endpoints or automatically use a remote profile instead.
 ## Preparation, capacity, or execution fails
 
 A preparation failure occurs before provider work; an execution failure occurs
-after preparation. Both leave safe provenance and metadata when reached. A
-capacity error for one batch report does not retry that report or prevent later
-independent reports. Inspect the preparation or execution path, correct the
-profile/backend condition, and create a new run. See [operations](operations.md).
+after preparation. A capacity error for one batch report does not retry that
+report or prevent later independent reports. Correct the profile or backend
+condition identified by the bounded command error, then create a new run.
+Use explicit secure debug capture only when additional content-rich diagnostics
+are necessary. See [operations](operations.md).
 
 ## Generated text fails validation