Use Promptkit for single report generation

docs/cli.md

@@ -80,7 +80,7 @@ time, valid period, and status:
 ```
 
 When available, the summary also includes `reportPath`, `metadataPath`,
-`dataPackagePath`, `preflightPath`, `generatedTextRawPath`, `generatedTextResultPath`,
+`dataPackagePath`, `preparationPath`, `executionPath`, `generatedTextRawPath`,
 `generatedTextPath`, and `renderContextPath`. `outputPath` is included only
 when `--out` wrote an extra copy. Distributor notification, when attempted,
 adds `notificationPath` and may add a compact `notification` object.

docs/config.md

@@ -147,9 +147,9 @@ source keys are `observations`, `current`, `narrative`, `alerts`, `discussion`,
 
 ### `promptkit`
 
-Promptkit configuration prepares the local executor and prompt/profile checks.
-Scriptorium remains the active generator until the Promptkit execution workflow
-is enabled.
+Promptkit configuration selects the executor and prompt/profile checks for
+every `generate` command. Scriptorium settings remain in use by batch commands
+while their compatibility workflow remains active.
 
 | Field | Default | Rules |
 | --- | --- | --- |

docs/development.md

@@ -5,8 +5,8 @@ Weatherreporter. It provides a concise repository orientation and routes each
 kind of change to its canonical documentation.
 
 Weatherreporter is a Go CLI that collects normalized weather data, derives
-deterministic report facts and module snapshots, invokes Scriptorium for
-generated text, renders managed Markdown reports, and can upload completed
+deterministic report facts and module snapshots, executes Promptkit for
+single-report generated text, renders managed Markdown reports, and can upload completed
 reports through Distributor. Start with the [README](../README.md) for product
 context and the [architecture policy](policy/architecture.md) for system
 boundaries and invariants.
@@ -27,7 +27,7 @@ boundaries and invariants.
 | Report definitions, valid periods, report IDs, output naming, or batch composition | [Report registry internals](internal/report-registry.md) and [app orchestration internals](internal/app-orchestration.md) | Report definitions own selection and period rules; orchestration owns execution. |
 | Module IDs, module composition, briefing values, or prompt-facing exports | [Module contract internals](internal/module.md), [module builder internals](internal/briefing.md), and [prompt-input internals](internal/prompt-input.md) | These own module contracts, value construction, and the curated prompt-package boundary. |
 | Recent Changes comparison | [Changes internals](internal/changes.md) and [operations guide](operations.md) | The internal guide owns structured comparison; operations owns user-visible artifact behavior. |
-| Scriptorium commands, subprocess execution, prompt inputs, or result handling | [Scriptorium integration](integrations/scriptorium.md), [Scriptorium adapter internals](internal/scriptorium-adapter.md), and [prompt-input internals](internal/prompt-input.md) | These separate the external CLI contract, subprocess boundary, and input construction. |
+| Prompt execution, profiles, prompt inputs, or result handling | `internal/promptexec`, the Promptkit adapter, and [prompt-input internals](internal/prompt-input.md) | These separate the executor contract and input construction. |
 | Generated-text schemas, validation, render contexts, templates, or Markdown rendering | [Generated-text internals](internal/generatedtext.md), [report-template internals](internal/reporttemplate.md), and [report template guide](templates.md) | These own structured text, renderer implementation, and the maintainer-facing template surface. |
 | Workspace paths, metadata, atomic persistence, lookup, inspection, or recovery | [State internals](internal/state.md), [operations guide](operations.md), and [troubleshooting guide](troubleshooting.md) | These separate implementation, operator workflows, and symptom-based recovery. |
 | Distributor bundles, uploads, notification artifacts, or failures | [Distributor adapter internals](internal/distributor-adapter.md), [Distributor integration contracts](integrations/distributor/), and [operations guide](operations.md) | These separate adapter behavior, external contracts, and operational lifecycle. |
@@ -46,7 +46,7 @@ present before introducing a new package or abstraction.
 | `internal/cli` | Command parsing, flags, help, output, and command wiring. |
 | `internal/app` | Generation, batches, collection coordination, notification, and inspection orchestration. |
 | `internal/config` | Configuration defaults, loading, precedence, secrets, and validation. |
-| `internal/adapters` | Weather API, Scriptorium, and Distributor boundaries. |
+| `internal/adapters` | Weather API, Promptkit, Scriptorium batch compatibility, and Distributor boundaries. |
 | `internal/weatherdata`, `internal/forecast`, `internal/facts` | Normalized source facts and deterministic derivation. |
 | `internal/report`, `internal/module`, `internal/briefing`, `internal/changes` | Report registry, module contracts and values, and structured comparison. |
 | `internal/promptinput`, `internal/generatedtext`, `internal/reporttemplate` | Prompt packages, generated-text validation, render contexts, and Markdown templates. |

docs/internal/app-orchestration.md

@@ -8,12 +8,12 @@ application-facing interfaces used for tests.
 ## Inputs And Outputs
 
 The package accepts generate, resolved-report, batch, explicit-collection, and
-inspection requests. Generation and batch requests may supply collector,
-renderer, store, and notifier implementations for tests; production defaults
-use the focused packages.
+inspection requests. Generation and batch requests may supply collaborators for
+tests; single-report generation uses a Promptkit executor, while batch requests
+retain a renderer for their compatibility workflow.
 
-A report result contains the module snapshot, prompt package, Scriptorium
-results, generated-text artifacts, report and metadata
+A report result contains the module snapshot, prompt package, prompt
+provenance, generated-text artifacts, report and metadata
 paths, prior snapshot, Recent Changes, and notification information. A batch
 result contains aggregate counts, per-report outcomes, and an optional batch
 notification. Inspection returns persisted values only.
@@ -31,45 +31,47 @@ safe project-owned identity and provenance values.
 
 ## Single-Report Workflow
 
-`GenerateDetailed` first collects weather data, then resolves the requested
-report using the configured registry and current time, and finally calls
-`GenerateReport` with that explicit collection. It returns no result when
-collection or resolution fails.
+`GenerateDetailed` resolves the requested report using the configured registry
+and current time, verifies the exact Promptkit prompt and selected profile, and
+only then collects weather data. Inspection failure produces no collection or
+managed artifacts.
 
-`GenerateReport` requires a non-nil normalized bundle and then performs this
+Single-report generation requires a non-nil normalized bundle and then performs this
 ordered work:
 
 1. Select a state store, determine artifact destinations, and locate a prior
    compatible snapshot.
 2. Build report facts and deterministic module snapshots, then save the module
    snapshot and calculate Recent Changes.
-3. Build and save the prompt data package, run Scriptorium render preflight,
-   save any preflight result, and save initial metadata.
-4. Run structured Scriptorium generation, validate and save generated text,
-   build and save a render context, and render the managed Markdown template.
-5. Optionally make an output copy, save final metadata, optionally notify
+3. Serialize and save the prompt data package once, then use those exact bytes
+   for Promptkit execution.
+4. Save preparation provenance and V2 metadata from the preparation callback
+   before provider execution. Save execution provenance after raw output is
+   persisted, then save updated metadata.
+5. Validate and save generated text, build and save a render context, and
+   render the managed Markdown template.
+6. Optionally make an output copy, save final metadata, optionally notify
    Distributor from the managed report path, and save metadata again when a
    notification path is produced.
 
-Every report looks up its catalog definition, runs structured Scriptorium
-output to the raw artifact, preserves the structured run result, validates and
+Every single report looks up its catalog definition, saves raw Promptkit output,
+preserves safe preparation and execution provenance separately, validates and
 saves generated text, builds and saves a render context, then renders the
-embedded Markdown template. Schema, template, and subprocess details remain in
-their [generated-text](generatedtext.md),
-[report-template](reporttemplate.md), and [Scriptorium adapter](scriptorium-adapter.md)
+embedded Markdown template. Schema and template details remain in their
+[generated-text](generatedtext.md) and [report-template](reporttemplate.md)
 owners.
 
-If preflight returns a result with an error, the result and initial metadata are
-saved before the error returns. If report generation fails after a managed path
-is prepared, metadata still records that path; output copies and notification
-are skipped. Generated-text failures preserve the latest artifact reached
-before failure when it was saved.
+Preparation and operational execution failures save classified receipts and
+metadata before returning. A completed Promptkit validation rejection saves raw
+output, an execution receipt, and metadata before returning. If later report
+generation fails, the result retains every reached safe artifact path; output
+copies and notification are skipped until rendering succeeds.
 
 ## Batch And Inspection Workflows
 
 `RunBatchDetailed` collects once, asks the report registry to plan the batch
-from that collection, and invokes `GenerateReport` independently for every
-planned report using the same collection and state store. Per-report
+from that collection, and invokes its isolated Scriptorium compatibility helper
+independently for every planned report using the same collection and state store. Per-report
 notification is suppressed. A failed report is recorded and does not prevent
 later planned reports from running.
 
@@ -87,13 +89,13 @@ provenance. They neither collect data nor invoke Scriptorium or Distributor.
 ## Boundaries And Failure Propagation
 
 The app layer does not parse flags, load configuration files, implement Weather
-API transport, construct Scriptorium argv, or define report registry policy. It
+API transport, invoke provider SDKs, or define report registry policy. It
 coordinates the relevant collaborators and preserves their error context.
 
-- Collection failure stops a single report or batch before resolution or
-  planning completes.
-- State, fact, module, prompt-input, or preflight failures stop that report
-  before report generation.
+- Prompt inspection failure stops a single report before collection or durable
+  writes. Collection failure stops a single report or batch before planning.
+- State, fact, module, prompt-input, preparation, or execution failures stop
+  that report before later report generation.
 - A terminal Distributor failure is returned with the saved notification
   information when available.
 - Batch failures are represented per report and through aggregate batch status.
@@ -108,7 +110,8 @@ Focused tests are in `internal/app/app_test.go` and
 
 - Production workflows collect through `internal/collect`.
 - A report uses one explicit normalized collection throughout its generation.
-- Render preflight precedes report generation.
+- Prompt preparation provenance and metadata are persisted before provider
+  execution.
 - Recent Changes compare structured module snapshots.
 - Reports render from a validated typed context, never directly from a raw
   prompt package.

docs/internal/cli.md

@@ -14,8 +14,8 @@ batch execution to `internal/app`.
 
 `Runner` also owns a project-owned prompt-executor factory seam. Its production
 factory maps `promptkit` configuration to the Promptkit adapter, while tests can
-inject a factory without importing dependency types. Construction is retained as
-a separate seam until the generation workflow begins using that executor.
+inject a factory without importing dependency types. Each `generate` request
+constructs one executor after configuration loads and passes it to the app.
 
 For inspection, it loads configuration, builds the appropriate app inspection
 request, and writes the returned value. Inspection is read-only; the inspected

docs/operations.md

@@ -15,10 +15,10 @@ weatherreporter generate today --out ./today.md
 ```
 
 A generation collects weather data, resolves the report period, builds and
-persists the module snapshot and prompt data package, runs Scriptorium
-preflight, then persists generated-text artifacts, validates the structured
-generated text, and renders the managed Markdown report from the validated text
-and deterministic values.
+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 managed report and its final metadata are saved before single-report
 Distributor notification is attempted. `--out` writes an extra operator copy;
@@ -56,20 +56,21 @@ workspace/
   snapshots/<artifact_group>/<YYYY-MM-DD>/modules.<run_id>.json
   snapshots/<artifact_group>/<YYYY-MM-DD>/metadata.<run_id>.json
   snapshots/<artifact_group>/<YYYY-MM-DD>/generated_text_raw.<run_id>.json
-  snapshots/<artifact_group>/<YYYY-MM-DD>/generated_text_result.<run_id>.json
+  snapshots/<artifact_group>/<YYYY-MM-DD>/prompt_execution.<run_id>.json
   snapshots/<artifact_group>/<YYYY-MM-DD>/generated_text.<run_id>.json
   snapshots/<artifact_group>/<YYYY-MM-DD>/render_context.<run_id>.json
 
   data-packages/<artifact_group>/<YYYY-MM-DD>/data_package.<run_id>.yaml
-  preflight/<artifact_group>/<YYYY-MM-DD>/render.<run_id>.json
+  preflight/<artifact_group>/<YYYY-MM-DD>/prompt_preparation.<run_id>.json
 
   notifications/<artifact_group>/<YYYY-MM-DD>/distributor.<run_id>.json
   notifications/batches/<batch>/<YYYY-MM-DD>/distributor.<batch_run_id>.json
 ```
 
-The generated-text and render-context artifacts are written for every report.
-A report's metadata links the module snapshot, data package, preflight artifact,
-managed report, generated-text artifacts, and any available single-report
+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`.
 
@@ -128,12 +129,12 @@ RunID is an error; use `inspect reports` to obtain a valid value.
 Keep the workspace when a run fails: artifacts reached before the failure
 remain available where they can be safely persisted.
 
-- A preflight failure can leave the preflight artifact and metadata.
+- A preparation failure can leave its classified receipt and metadata.
 - A report-generation failure can leave the managed report, module snapshot,
   data package, and metadata.
-- A generated-text failure can leave raw text, the structured run result, or a
-  validated generated-text and render-context artifact, depending on where it
-  stopped.
+- A completed prompt validation rejection leaves raw text, an execution receipt,
+  and metadata. Later generated-text failures can also leave validated text and
+  a render-context artifact, depending on where they stopped.
 - A single-report notification failure preserves the report and final metadata,
   including its notification artifact when it was written.
 - A batch notification failure preserves each report's artifacts and adds the