135 lines
4.6 KiB
Markdown
135 lines
4.6 KiB
Markdown
# 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.
|