weatherreporter/docs/roadmap/future.md

Future Roadmap

This roadmap contains future work only. Each section identifies its planning status; current behavior is documented outside docs/roadmap/.

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 Scriptorium or another narrow evaluator adapter.
3. Persist storm lifecycle state.
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.

Future Modules

Status: Proposed and unimplemented.

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 the boundaries documented in fact contracts, module internals, and briefing internals:

• 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 snapshots structured and deterministic for Recent Changes

Distributor Notification Enhancements

Status: Proposed and unimplemented.

Single-report and batch Distributor notification are implemented. Current behavior is documented in the Distributor adapter guide, Distributor integration guides, and operations guide. The following enhancements remain unimplemented:

• 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

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 existing public CLI, artifact paths, report identities, module boundaries, and adapter boundaries unless a separate roadmap explicitly changes them.