# Future Roadmap

This roadmap contains project work that is not implemented. Current behavior is
documented outside `docs/roadmap/`.

## Automatic Storm Monitoring

Manual Storm Report generation is available through:

```sh
weatherreporter generate storm --start TIME --end TIME
```

Automatic storm-event evaluation is not implemented.

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 Storm Reports 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,
manual Storm Report generation, inspectable evaluator failures, and fixture
coverage for deterministic candidate detection.

## Future Report Types

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 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
- `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:

- 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

Distributor notification uploads one managed Markdown report per successful
generated report through the configured HTTP upload pipeline. The following
enhancements are not implemented:

- `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

These ideas are not implemented:

- 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

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.