145 lines
5.0 KiB
Markdown
145 lines
5.0 KiB
Markdown
# 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.
|
|
|
|
Manual Storm Report generation is implemented; see the [CLI reference](../cli.md).
|
|
Automatic storm-event evaluation remains 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 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
|
|
|
|
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` 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](../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 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](../internal/distributor-adapter.md),
|
|
[Distributor integration guides](../integrations/distributor/), and
|
|
[operations guide](../operations.md). 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.
|