178 lines
6.7 KiB
Markdown
178 lines
6.7 KiB
Markdown
# 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.
|