Clarify future roadmap documentation

docs/roadmap/future.md

@@ -5,18 +5,22 @@ documented outside `docs/roadmap/`.
 
 ## Automatic Storm Monitoring
 
-Manual Storm Report generation is implemented through
+Manual Storm Report generation is available through:
-`weatherreporter generate storm --start TIME --end TIME`. Automatic storm-event
-evaluation remains deferred.
 
-Proposed direction:
+```sh
+weatherreporter generate storm --start TIME --end TIME
+```
 
-1. detect candidate events deterministically from alerts, forecast discussion,
+Automatic storm-event evaluation is not implemented.
-   weather story context, hourly thresholds, and material forecast changes;
+
-2. evaluate candidates through Scriptorium or another narrow evaluator adapter;
+Possible direction:
-3. persist storm lifecycle state;
+
-4. generate or update Storm Reports only when a meaningful event is present;
+1. Detect candidate storm events from alerts, forecast discussion, weather
-5. suppress ordinary low-impact thunder or rain chances.
+   story context, hourly thresholds, and material forecast changes.
+2. Evaluate candidates through Scriptorium or another narrow evaluator adapter.
+3. Persist storm lifecycle state.
+4. Generate or update Storm Reports only when a meaningful event is present.
+5. Suppress ordinary low-impact thunder or rain chances.
 
 Possible lifecycle states:
 
@@ -27,41 +31,41 @@ Possible lifecycle states:
 - `deescalating`
 - `resolved`
 
-Acceptance criteria before implementation:
+Before implementation, the design must preserve scheduled report behavior,
+manual Storm Report generation, inspectable evaluator failures, and fixture
+coverage for deterministic candidate detection.
 
-- scheduled reports and manual Storm Reports remain stable;
+## Future Report Types
-- candidate detection has fixture coverage;
-- evaluator failures are inspectable and do not create noisy report output;
-- manual Storm Report generation remains available.
-
-## Future Report Types And Modules
-
-The module-based prompt package architecture is implemented. Future work should
-add only modules backed by implemented upstream facts and clear report needs.
 
 Possible future report types:
 
-- another short-fuse planning report distinct from the implemented Hourly
+- a short-fuse planning report distinct from the implemented Hourly Report, if
-  Report, if a separate product is needed;
+  a separate product is needed
-- event-specific reports with stable event IDs;
+- event-specific reports with stable event IDs
-- storm review or yesterday-style reports using historical observations;
+- storm review or yesterday-style reports using historical observations
 - archive-focused report variants if generated report history becomes a
-  first-class product.
+  first-class product
+
+New reports should keep report identity, prompt IDs, templates, valid-period
+resolution, artifact grouping, batch output names, and comparison policy inside
+`internal/report`.
+
+## Future Modules
 
 Possible future modules:
 
-- `hourly_table` for compact valid-period hourly facts;
+- `hourly_table` for compact valid-period hourly facts
 - `forecast_delta` if a separate stanza is useful beyond current Recent
-  Changes;
+  Changes
 - `weekend_planning` if weekend-specific planning guidance needs a dedicated
-  deterministic stanza;
+  deterministic stanza
 - `storm_window_summary` if manual or automatic Storm Reports need a dedicated
-  prompt-facing storm-window module;
+  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`;
+  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.
+  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
@@ -69,76 +73,61 @@ represented in `CollectedFacts`.
 
 Future module work should preserve these boundaries:
 
-- collect upstream facts once per report run;
+- collect upstream facts once per report run
-- keep upstream fetching out of modules;
+- keep upstream fetching out of modules
-- keep broad reusable calculations in `DerivedFacts`;
+- keep broad reusable calculations in `DerivedFacts`
-- keep prompt-facing field shape inside module builders;
+- keep prompt-facing field shape inside module builders
-- use typed options for configurable module behavior;
+- use typed options for configurable module behavior
-- keep module snapshots structured and deterministic for Recent Changes.
+- keep module snapshots structured and deterministic for Recent Changes
 
 ## Distributor Notification Enhancements
 
-Distributor notification currently uploads one managed Markdown report per
+Distributor notification uploads one managed Markdown report per successful
-successful generated report through the configured HTTP upload pipeline.
+generated report through the configured HTTP upload pipeline. The following
+enhancements are not implemented:
 
-These enhancements are not current behavior:
+- `failure_policy: warn`
+- uploading metadata, module snapshots, data packages, or preflight artifacts
+- durable upload retry queues
+- distributor-specific CLI flags
+- distributor workspace scanning
+- destination routing, Markdown-to-HTML transformation, public URLs, or nginx
+  layout inside weatherreporter
 
-- `failure_policy: warn`;
+Any distributor enhancement should preserve the adapter boundary:
-- uploading metadata, module snapshots, data packages, or preflight artifacts;
-- durable upload retry queues;
-- distributor-specific CLI flags;
-- making distributor scan the weatherreporter workspace;
-- handling destination routing, Markdown-to-HTML transformation, public URLs,
-  or nginx layout inside weatherreporter.
-
-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.
 
 ## Alternate Runtime Integrations
 
-These ideas are not current behavior:
+These ideas are not implemented:
 
-- native LLM client inside `weatherreporter`;
+- native LLM client inside `weatherreporter`
-- database-backed state;
+- database-backed state
-- public HTTP API;
+- public HTTP API
-- multi-location selection;
+- multi-location selection
-- daemon mode;
+- daemon mode
-- multi-user authorization;
+- multi-user authorization
-- plugin system;
+- plugin system
-- dynamic module loading;
+- dynamic module loading
-- user-defined module code;
+- user-defined module code
-- YAML-defined module schemas;
+- YAML-defined module schemas
-- module-owned Weather API fetching.
+- 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
+## Deferred Refactors
 
-The initial cleanup pass intentionally left these refactors out because the
+These refactors should remain deferred until new requirements or recurring
-current implementation does not yet make them worth the added abstraction.
+maintenance costs make the added abstraction worthwhile:
 
-Revisit these only when new source types, report types, operational
+- broad briefing weather-signal consolidation
-requirements, or recurring maintenance costs make the duplication materially
+- generic workflow engine
-more expensive:
+- Cobra migration
-
+- manifest, resume, or progress system
-- Broad briefing weather-signal consolidation: consider when multiple module
+- global test helper package
-  builders repeatedly derive the same weather signals and tests begin to need
+- logging subsystem
-  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.
-- 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
-  runs, checkpoint recovery, or richer audit trails than the current durable
-  artifacts and metadata provide.
-- Global test helper package: defer while package-local helpers keep tests
-  clear; revisit only if setup duplication starts to hide behavior.
-- Logging subsystem: defer until there are recurring operator diagnostics that
-  cannot be handled with current errors, metadata, inspection commands, and
-  artifact output.
 
 Any future implementation should preserve the existing public CLI, artifact
 paths, report identities, module boundaries, and adapter boundaries unless a