Remove obsolete briefing snapshot artifacts

docs/cli.md

@@ -34,7 +34,7 @@ weatherreporter inspect prior [--config PATH] RUN_ID
 weatherreporter inspect sources [--config PATH] RUN_ID
 ```
 
-`generate` commands write briefing, module snapshot, data package, preflight,
+`generate` commands write module snapshot, data package, preflight,
 report, and metadata artifacts under the configured workspace. `--out` writes
 an extra Markdown copy for the operator; distributor notification uses the
 managed report path, not the extra copy. `generate storm` requires explicit

docs/internal/app-orchestration.md

@@ -6,7 +6,7 @@ This document describes the implemented workflow coordinator in `internal/app`.
 
 `internal/app` coordinates the top-level use cases after CLI parsing and config
 loading are complete. It resolves report definitions, fetches weather data,
-builds collected and derived facts, builds briefing and prompt-input artifacts,
+builds collected and derived facts, builds module snapshots and prompt-input artifacts,
 invokes Scriptorium through the adapter boundary, optionally notifies
 distributor through an app-owned notifier boundary, persists managed state, runs
 batches, and reads existing artifacts for inspection.
@@ -18,8 +18,7 @@ Inputs:
 - `GenerateRequest` for one report command
 - `BatchRequest` for morning or evening batch commands
 - `FetchBundleRequest` for explicit bundle fetch and save workflows
-- `BriefingRequest` and `ReportRequest` for package-level orchestration tests
-  and internal composition
+- `ReportRequest` for single-report generation
 - resolved report definitions from `internal/report`
 - weather data bundles from `internal/adapters/weatherapi`
 - prior snapshots loaded from `internal/state`
@@ -27,13 +26,13 @@ Inputs:
 
 Outputs:
 
-- generated report results with briefing, data package, preflight, report,
+- generated report results with module snapshot, data package, preflight, report,
   metadata, prior snapshot, Recent Changes, Scriptorium result details, and
   notification result when attempted
 - batch summaries with per-report status, artifact paths, error text, and
   notification outcome when attempted
 - saved Weather API bundle JSON for fetch workflows
-- inspection JSON values for reports, metadata, briefings, data packages, prior
+- inspection JSON values for reports, metadata, module snapshots, data packages, prior
   snapshots, and source provenance
 
 ## Boundaries
@@ -72,25 +71,24 @@ Single-report generation follows this order:
 4. Fetch a Weather API bundle.
 5. Build collected and derived facts once.
 6. Execute configured modules and save the module snapshot.
-7. Build and save the compatibility briefing snapshot.
-8. Compute Recent Changes from structured prior and current module snapshots.
-9. Build and save the YAML Scriptorium `data_package`.
-10. Run Scriptorium render preflight.
-11. Save preflight JSON when a render result is available.
-12. Save metadata for inspection.
-13. Run Scriptorium report generation to the managed report path.
-14. Copy the managed report to the requested `--out` path when provided.
-15. Save metadata with the managed report path.
-16. If distributor notification is enabled, notify using the managed report
+7. Compute Recent Changes from structured prior and current module snapshots.
+8. Build and save the YAML Scriptorium `data_package`.
+9. Run Scriptorium render preflight.
+10. Save preflight JSON when a render result is available.
+11. Save metadata for inspection.
+12. Run Scriptorium report generation to the managed report path.
+13. Copy the managed report to the requested `--out` path when provided.
+14. Save metadata with the managed report path.
+15. If distributor notification is enabled, notify using the managed report
     path as the source file.
-17. Save a distributor notification debug artifact and update metadata with its
+16. Save a distributor notification debug artifact and update metadata with its
     path.
 
 If render preflight returns both a result and an error, preflight JSON and
 metadata are persisted before the error is returned. If Scriptorium report
 generation returns an error after writing output, the managed report and
 metadata remain inspectable. Notification is not attempted after Weather API,
-briefing, prompt input, render, Scriptorium run, or metadata-save failures.
+module snapshot, prompt input, render, Scriptorium run, or metadata-save failures.
 When notification is attempted, the debug artifact records request identity,
 including rendered pipeline ID, bundle paths, accepted upload fields,
 distributor status fields, raw status report JSON when available, and redacted

docs/internal/briefing.md

@@ -4,9 +4,9 @@ This document describes the implemented briefing package boundary.
 
 ## Purpose
 
-`internal/briefing` builds structured report-specific briefing packages from
-resolved report metadata, collected weather data, and derived forecast facts.
-Briefings are curated inputs for prompt data packages, not rendered report prose.
+`internal/briefing` builds prompt-facing module values from resolved report
+metadata, collected weather data, and derived forecast facts. These values are
+curated prompt inputs, not rendered report prose or durable report snapshots.
 
 ## Inputs And Outputs
 
@@ -19,23 +19,19 @@ Inputs:
 
 Outputs:
 
-- `briefing.Package` with common metadata and one report-specific content
-  object for Daily, 3-Day, Weekend, or Storm Report
 - module registry definitions for known module IDs, stanza names, option
   shapes, fact requirements, report compatibility, and missing-data behavior
 - source-oriented module outputs for `metadata`, `current_conditions`,
   `alert_digest`, `area_forecast_discussion`, and `weather_story`
-- optional `currentConditions` prompt context from normalized
-  `/conditions/current` data when available
-- optional structured `weatherStory` context on report-specific briefing
-  objects when `/weatherstories/latest` is available
-- optional JSON file written by `briefing.Save`
+- derived module outputs such as daily summaries, daypart summaries,
+  precipitation timing, outdoor windows, and tomorrow planning
+- optional current conditions and weather story module outputs when those
+  Weather API sources are available
 
 ## Boundaries
 
 - This package selects and shapes weather facts for prompts.
-- It owns module registry validation, but app orchestration does not execute
-  modules yet.
+- It owns module registry validation and module builder behavior.
 - It does not fetch weather data, compare prior snapshots, build
   `data_package` files, invoke Scriptorium, or write workflow metadata.
 
@@ -54,23 +50,18 @@ None directly.
 
 ## State Or Manifest Behavior
 
-`briefing.Save` writes briefing JSON atomically. Managed workspace placement is
-owned by `internal/state`.
+None. Module snapshots and prompt input data packages are persisted by
+`internal/state` and composed by `internal/app`.
 
 ## Skip And Resume Behavior
 
-None. Builders either return a complete briefing package or an error.
+None. Builders either return a module output, omit optional unavailable data,
+or return an error for invalid required inputs.
 
 ## Failure Behavior
 
-- Daily briefing construction requires a Daily report definition and derived
-  daily summary.
-- 3-Day briefing construction requires a 3-Day report definition and at least
-  one derived summary.
-- Weekend briefing construction requires a Weekend report definition and at
-  least one derived summary.
-- Storm briefing construction requires a Storm Report definition and forecast
-  bundle.
+- Required derived modules return errors when their dependent facts are not
+  available.
 - Module registry construction rejects duplicate module IDs and duplicate
   stanza names.
 - Module composition validation rejects unknown modules, duplicate modules,
@@ -79,23 +70,19 @@ None. Builders either return a complete briefing package or an error.
   forecast discussion, and weather story stanzas.
 - Alert digest output distinguishes checked empty alert data from missing alert
   source data.
-- Save failures include path and operation context.
 
 ## Tests
 
 Inspect:
 
-- `internal/briefing/daily_test.go`
-- `internal/briefing/three_day_test.go`
-- `internal/briefing/weekend_test.go`
-- `internal/briefing/storm_test.go`
 - `internal/briefing/base_modules_test.go`
+- `internal/briefing/derived_modules_test.go`
 - `internal/briefing/modules_test.go`
 - `internal/app/app_test.go`
 
 ## Invariants
 
-- Briefings contain structured weather facts and source context.
+- Module outputs contain structured weather facts and source context.
 - Common metadata includes RunID, report ID, prompt ID, valid period, source
   provenance, source hashes, source warnings, and configured prompt location.
 - LLM prompt input packaging and Scriptorium execution remain outside this

docs/internal/report-registry.md

@@ -7,7 +7,7 @@ membership, output naming, artifact grouping, and comparison declarations in
 ## Purpose
 
 `internal/report` is the canonical source for report definitions. App, state,
-briefing, and CLI wiring consume resolved definitions instead of owning report
+module building, and CLI wiring consume resolved definitions instead of owning report
 identity policy themselves.
 
 ## Definition Fields
@@ -55,7 +55,7 @@ must be after start time.
 ## Boundaries
 
 `internal/report` defines report metadata and time coverage. It does not fetch
-weather data, build briefings, compare briefing contents, write state, parse CLI
+weather data, build module values, compare snapshot contents, write state, parse CLI
 flags, or invoke Scriptorium.
 
 The CLI owns public command names. The app maps those command names to report

docs/internal/state.md

@@ -13,7 +13,7 @@ Inputs:
 
 - workspace configuration
 - resolved report definition and valid period
-- briefing package
+- module snapshot
 - prompt input data package
 - preflight artifact
 - rendered report path preparation request
@@ -21,20 +21,20 @@ Inputs:
 
 Outputs:
 
-- briefing snapshot JSON path
-- prompt input data package JSON path
+- module snapshot JSON path
+- prompt input data package YAML path
 - render preflight JSON path
 - managed Markdown report path
 - metadata JSON path
 - prior comparable snapshot metadata
-- loaded briefing or data package
+- loaded module snapshot or data package
 - recent report records for inspection
 
 ## Boundaries
 
 `internal/state` owns local filesystem layout, path validation, durable writes,
 metadata reads, prior lookup, and report listing. It does not fetch weather
-data, derive forecasts, build prompt input content, compare briefing contents,
+data, derive forecasts, build prompt input content, compare module contents,
 invoke Scriptorium, import adapter result types, or parse CLI flags.
 
 Preflight persistence uses the state-owned `PreflightArtifact` shape. The app
@@ -59,7 +59,7 @@ valid-period start date for dated artifacts, and the RunID.
 
 ```text
 <workspace.root>/
-  snapshots/<artifact_group>/<YYYY-MM-DD>/<run_id>.briefing.json
+  snapshots/<artifact_group>/<YYYY-MM-DD>/<run_id>.modules.json
   snapshots/<artifact_group>/<YYYY-MM-DD>/<run_id>.metadata.json
   data-packages/<artifact_group>/<YYYY-MM-DD>/<run_id>.data_package.yaml
   preflight/<artifact_group>/<YYYY-MM-DD>/<run_id>.render.json
@@ -67,7 +67,7 @@ valid-period start date for dated artifacts, and the RunID.
   reports/<artifact_group>/<run_id>.md
 ```
 
-Metadata is stored beside briefing snapshots and links the briefing, data
+Metadata is stored beside module snapshots and links the module snapshot, data
 package, preflight, report paths, notification path when attempted, and
 configured prompt location. Report listing walks metadata files under the
 snapshots directory.
@@ -97,7 +97,7 @@ notification is attempted and include rendered distributor pipeline ID, bundle
 ID, idempotency key, bundle paths, upload status, latest run status, and
 redacted errors.
 
-Inspection helpers read existing metadata, briefing, and data package files.
+Inspection helpers read existing metadata, module snapshot, and data package files.
 Missing metadata directories return no inspection records or no prior snapshot
 rather than creating state.
 

docs/internal/weather-data.md

@@ -6,7 +6,7 @@ This document describes Weather API ingestion into `weatherdata.Bundle`.
 
 `internal/adapters/weatherapi` fetches normalized weather data from one
 configured Weather API endpoint and assembles the bundle consumed by forecast
-derivation and briefing builders. Briefing builders expose normalized current
+derivation and module builders. Module builders expose normalized current
 conditions and weather story context when those sources are available.
 
 ## Inputs And Outputs
@@ -29,7 +29,7 @@ Outputs:
 
 - The adapter owns HTTP calls, response-envelope handling, source hashing, and
   decoding into internal bundle types.
-- It does not derive dayparts, resolve report periods, build briefings, compare
+- It does not derive dayparts, resolve report periods, build module values, compare
   snapshots, write report state, or invoke Scriptorium.
 
 ## Config Fields Used

docs/operations.md

@@ -52,22 +52,18 @@ workspace/
   snapshots/
     daily/
       YYYY-MM-DD/
-        <run_id>.briefing.json
         <run_id>.modules.json
         <run_id>.metadata.json
     three-day/
       YYYY-MM-DD/
-        <run_id>.briefing.json
         <run_id>.modules.json
         <run_id>.metadata.json
     weekend/
       YYYY-MM-DD/
-        <run_id>.briefing.json
         <run_id>.modules.json
         <run_id>.metadata.json
     storm/
       YYYY-MM-DD/
-        <run_id>.briefing.json
         <run_id>.modules.json
         <run_id>.metadata.json
   data-packages/
@@ -136,7 +132,7 @@ Each generated report writes metadata that links:
 - RunID, report ID, variant, and prompt ID
 - generation time, timezone, and valid period
 - source location, source hashes, and source warnings
-- briefing snapshot path
+- module snapshot path
 - prompt input data package path
 - preflight output path
 - managed Markdown report path
@@ -169,9 +165,9 @@ report generation has a distinct retry identity. The default bundle path uses
 the valid-period start date, artifact group, and RunID. Distributor owns
 destination merge, retention, and derived snapshot behavior such as `latest`.
 
-Notification happens after final metadata save. Weather API, briefing, module
-snapshot, data-package, render preflight, Scriptorium run, and metadata-save
-failures do not trigger notification. A notification failure fails that report.
+Notification happens after final metadata save. Weather API, module snapshot,
+data-package, render preflight, Scriptorium run, and metadata-save failures do
+not trigger notification. A notification failure fails that report.
 In a batch, other reports continue, the failed report includes notification
 fields in the JSON summary, and the batch returns nonzero.
 

docs/policy/architecture.md

@@ -5,11 +5,11 @@ This document defines the development principles for this Go project. It is inwa
 ## weatherreporter
 `weatherreporter` is a deterministic weather briefing and report-preparation application. It consumes normalized weather data from the internal weatherfeeder-backed API, derives report-specific module snapshots and prompt packages, compares module snapshots against prior runs, and invokes an external prompt runner to produce human-facing reports.
 
-The application should keep meteorological data selection, daypart grouping, threshold detection, forecast-period resolution, and recent-change comparison inside Go domain packages. LLM prompts should receive curated briefing packages rather than raw unbounded source payloads wherever practical.
+The application should keep meteorological data selection, daypart grouping, threshold detection, forecast-period resolution, and recent-change comparison inside Go domain packages. LLM prompts should receive curated module-based prompt packages rather than raw unbounded source payloads wherever practical.
 
-Report types must be defined through a registry or equivalent mechanism. Each report definition should declare its report ID, prompt ID, valid-period resolver, briefing builder, comparison strategy, and output naming behavior. Avoid scattering report-type conditionals across CLI and orchestration code.
+Report types must be defined through a registry or equivalent mechanism. Each report definition should declare its report ID, prompt ID, valid-period resolver, module composition, comparison strategy, and output naming behavior. Avoid scattering report-type conditionals across CLI and orchestration code.
 
-Generated reports must be associated with explicit metadata, including report type, location, generation time, valid period, source product timestamps or hashes, briefing snapshot path, and output path. Recent Changes must be based on structured snapshot comparison rather than comparison of rendered Markdown report text.
+Generated reports must be associated with explicit metadata, including report type, location, generation time, valid period, source product timestamps or hashes, module snapshot path, and output path. Recent Changes must be based on structured snapshot comparison rather than comparison of rendered Markdown report text.
 
 `scriptorium` is an external adapter, not domain logic. Subprocess execution must be isolated under `internal/adapters/scriptorium`, use context-aware execution, avoid shell interpolation, capture actionable stderr, and keep scriptorium-specific flags from leaking into domain packages.
 

docs/policy/development.md

@@ -23,7 +23,7 @@ Developers and LLM coding agents should use it with
 - `internal/module`: module IDs, config items, output envelopes, and snapshots.
 - `internal/report`: report definitions, valid periods, batches, output names,
   and comparison declarations.
-- `internal/briefing`: report-specific briefing package builders.
+- `internal/briefing`: prompt-facing module value builders and module registry.
 - `internal/changes`: structured Recent Changes comparison.
 - `internal/promptinput`: Scriptorium `data_package` construction and
   validation.

docs/troubleshooting.md

@@ -195,7 +195,7 @@ Diagnostic: inspect stdout for the JSON summary and stderr for compact status
 lines.
 
 Safe fix: use the failed report's artifact paths from the summary, then inspect
-metadata, sources, briefing, and data package for that RunID.
+metadata, sources, module snapshot, and data package for that RunID.
 
 Relevant docs: [CLI reference](cli.md), [Operations guide](operations.md).