Cleanup after implementation of the module architecture and remove completed roadmap files

docs/roadmap/future.md

@@ -3,7 +3,7 @@
 This roadmap contains project work that is not implemented. Current behavior is
 documented outside `docs/roadmap/`.
 
-## Deferred: Automatic Storm Monitoring
+## Automatic Storm Monitoring
 
 Manual Storm Report generation is implemented through
 `weatherreporter generate storm --start TIME --end TIME`. Automatic storm-event
@@ -34,30 +34,56 @@ Acceptance criteria before implementation:
 - evaluator failures are inspectable and do not create noisy report output;
 - manual Storm Report generation remains available.
 
-## Deferred: Alternate Runtime Integrations
+## Future Report Types And Modules
 
-These ideas are not current behavior:
+The module-based prompt package architecture is implemented. Future work should
+add only modules backed by implemented upstream facts and clear report needs.
 
-- native LLM client inside `weatherreporter`;
-- database-backed state;
-- public HTTP API;
-- multi-location selection;
-- daemon mode;
-- multi-user authorization;
-- plugin system.
+Possible future report types:
 
-Each item needs its own design note before implementation. Non-roadmap docs
-must not describe these as available behavior.
+- `next_6_hours` or another short-fuse planning report;
+- event-specific reports with stable event IDs;
+- storm review or yesterday-style reports using historical observations;
+- archive-focused report variants if generated report history becomes a
+  first-class product.
 
-## Deferred: Distributor Notification Enhancements
+Possible future modules:
+
+- `hourly_table` for compact valid-period hourly facts;
+- `forecast_delta` if a separate stanza is useful beyond current Recent
+  Changes;
+- `weekend_planning` if weekend-specific planning guidance needs a dedicated
+  deterministic stanza;
+- `storm_window_summary` if manual or automatic Storm Reports need a dedicated
+  prompt-facing storm-window module;
+- separate AFD section aliases, such as `afd_key_messages`,
+  `afd_short_term_text`, and `afd_long_term_text`, if separate stanzas prove
+  more useful than `area_forecast_discussion.options.sections`;
+- SPC, radar, QPF, snow/rain total, or historical-observation modules once
+  upstream sources and report requirements exist.
+
+QPF fields such as `measurable_qpf_total_in` and `max_hourly_qpf_in` should
+remain omitted until a real upstream quantitative precipitation source is
+represented in `CollectedFacts`.
+
+Future module work should preserve these boundaries:
+
+- collect upstream facts once per report run;
+- keep upstream fetching out of modules;
+- keep broad reusable calculations in `DerivedFacts`;
+- keep prompt-facing field shape inside module builders;
+- use typed options for configurable module behavior;
+- keep module snapshots structured and deterministic for Recent Changes.
+
+## Distributor Notification Enhancements
 
 Distributor notification currently uploads one managed Markdown report per
-successful generated report through the configured HTTP upload endpoint.
+successful generated report through the configured HTTP upload pipeline.
 
 These enhancements are not current behavior:
 
 - `failure_policy: warn`;
-- uploading metadata, briefing snapshots, data packages, or preflight artifacts;
+- uploading metadata, module snapshots, data packages, or preflight artifacts;
 - polling distributor status after upload acceptance;
 - durable upload retry queues;
 - distributor-specific CLI flags;
@@ -69,7 +95,26 @@ Any distributor enhancement should preserve the existing adapter boundary:
 weatherreporter selects explicit generated files and submits source bundles,
 while distributor owns destination routing and publication behavior.
 
-## Deferred: Cleanup Refactors
+## Alternate Runtime Integrations
+
+These ideas are not current behavior:
+
+- native LLM client inside `weatherreporter`;
+- database-backed state;
+- public HTTP API;
+- multi-location selection;
+- daemon mode;
+- multi-user authorization;
+- plugin system;
+- dynamic module loading;
+- user-defined module code;
+- YAML-defined module schemas;
+- module-owned Weather API fetching.
+
+Each item needs its own design note before implementation. Non-roadmap docs
+must not describe these as available behavior.
+
+## Cleanup Refactors
 
 The initial cleanup pass intentionally left these refactors out because the
 current implementation does not yet make them worth the added abstraction.
@@ -81,14 +126,12 @@ more expensive:
 - Weather API optional-source specification/helper refactor: consider when
   additional Weather API sources make per-source fan-out, policy handling, and
   provenance wiring repetitive enough to obscure adapter behavior.
-- Broad briefing weather-signal consolidation: consider when multiple briefing
+- Broad briefing weather-signal consolidation: consider when multiple module
   builders repeatedly derive the same weather signals and tests begin to need
   coordinated fixture updates.
 - Generic workflow engine: defer unless generation, inspection, recovery, or
   future background workflows gain enough shared step semantics to justify a
   declared execution model.
-- Plugin architecture: defer until there is a concrete external extension
-  contract and at least one implemented extension point.
 - Cobra migration: defer while the standard-library CLI remains small,
   explicit, and covered by parser tests.
 - Manifest, resume, or progress system: defer until operators need resumable
@@ -101,5 +144,5 @@ more expensive:
   artifact output.
 
 Any future implementation should preserve the existing public CLI, artifact
-paths, report identities, and adapter boundaries unless a separate roadmap
-explicitly changes them.
+paths, report identities, module boundaries, and adapter boundaries unless a
+separate roadmap explicitly changes them.