# Future Roadmap This roadmap contains future work only. Each section identifies its planning status; current behavior is documented outside `docs/roadmap/`. ## Upstream Forecast Change Product Status: Proposed upstream feature request; unimplemented. Weatherreporter's local Recent Changes feature is deprecated for removal by the accepted [stateless execution roadmap](ephemeral-state.md). Forecast version history and comparison are better owned by the Weather API, where the underlying forecast issuances can be retained and compared consistently for all consumers. A future Weather API feature should expose a structured change product with: - explicit current and baseline forecast issuance timestamps or identifiers; - documented baseline selection, such as a requested comparison timestamp, preceding issuance, or fixed rolling period; - location, timezone, and half-open valid-period identity; - typed changed values with previous and current values and units; - stable change categories for temperature, precipitation probability and timing, wind gusts, alerts, and aggregate hazards; - an API-owned significance classification or enough structured information for a stateless consumer to apply a documented presentation threshold; and - deterministic ordering, missing-baseline behavior, and source metadata. The API should compare forecast versions, not track a Weatherreporter client's "previous run." It should not require consumer identity, mutable cursors, or Weatherreporter-managed history. A missing baseline should be a normal empty result rather than an error. Once a stable upstream contract exists, a separate Weatherreporter roadmap may reintroduce change commentary by collecting that product and mapping it into a curated prompt-facing module. There must be no local snapshot fallback. The ordinary Weatherreporter process must remain stateless, and the upstream feature should have deterministic fixtures before adoption. ## Automatic Storm Monitoring Status: Proposed and unimplemented. Storm reporting, whether manual or automatic, is unimplemented. Possible direction: 1. Detect candidate storm events from alerts, forecast discussion, weather story context, hourly thresholds, and material forecast changes. 2. Evaluate candidates through Promptkit or another narrow evaluator adapter. 3. Keep any required storm lifecycle state in the upstream service or another explicitly designed external owner rather than silently reintroducing a Weatherreporter workspace. 4. Generate or update a storm report only when a meaningful event is present. 5. Suppress ordinary low-impact thunder or rain chances. Possible lifecycle states: - `none` - `monitoring` - `active_report` - `escalated` - `deescalating` - `resolved` Before implementation, the design must preserve scheduled report behavior, inspectable evaluator failures, and fixture coverage for deterministic candidate detection. ## Future Report Types Status: Proposed and unimplemented. Possible future report types: - a short-fuse planning report distinct from the implemented Hourly Report, if a separate product is needed - 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 New reports should preserve the boundaries documented in the [report registry internals](../internal/report-registry.md). ## Future Modules Status: Proposed and unimplemented. Possible future modules: - `hourly_table` for compact valid-period hourly facts - `forecast_delta` after an upstream forecast-change product exists - `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 the boundaries documented in [fact contracts](../internal/facts.md), [module internals](../internal/module.md), and [briefing internals](../internal/briefing.md): - keep upstream collection in app orchestration - keep upstream collection 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 output structured and deterministic ## Distributor Notification Enhancements Status: Proposed and unimplemented. Single-report and batch Distributor notification are implemented. Current behavior is documented in the [Distributor adapter guide](../internal/distributor-adapter.md), [Distributor integration guides](../integrations/distributor/), and [operations guide](../operations.md). The following enhancements remain unimplemented: - `failure_policy: warn` - durable upload retry queues - distributor-specific CLI flags - destination routing, Markdown-to-HTML transformation, public URLs, or nginx layout inside weatherreporter Any distributor enhancement should preserve the adapter boundary: weatherreporter selects explicit generated files and submits source bundles, while distributor owns destination routing and publication behavior. ## Alternate Runtime Integrations Status: Proposed and unimplemented. These ideas remain unimplemented: - 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. ## Deferred Refactors Status: Deferred. These refactors should remain deferred until new requirements or recurring maintenance costs make the added abstraction worthwhile: - broad briefing weather-signal consolidation - generic workflow engine - Cobra migration - manifest, resume, or progress system - global test helper package - logging subsystem Any future implementation should preserve the public CLI, report-output contract, report identities, module boundaries, and adapter boundaries in effect when that work begins unless a separate roadmap explicitly changes them.