Use Promptkit for single report generation

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