146 lines
5.7 KiB
Markdown
146 lines
5.7 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 implemented through
|
|
`weatherreporter generate storm --start TIME --end TIME`. Automatic storm-event
|
|
evaluation remains deferred.
|
|
|
|
Proposed direction:
|
|
|
|
1. detect candidate events deterministically 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`
|
|
|
|
Acceptance criteria before implementation:
|
|
|
|
- scheduled reports and manual Storm Reports remain stable;
|
|
- candidate detection has fixture coverage;
|
|
- evaluator failures are inspectable and do not create noisy report output;
|
|
- manual Storm Report generation remains available.
|
|
|
|
## Future Report Types And Modules
|
|
|
|
The module-based prompt package architecture is implemented. Future work should
|
|
add only modules backed by implemented upstream facts and clear report needs.
|
|
|
|
Possible future report types:
|
|
|
|
- another 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.
|
|
|
|
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:
|
|
|
|
- collect upstream facts once per report run;
|
|
- keep upstream fetching 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 currently uploads one managed Markdown report per
|
|
successful generated report through the configured HTTP upload pipeline.
|
|
|
|
These enhancements are not current behavior:
|
|
|
|
- `failure_policy: warn`;
|
|
- uploading metadata, module snapshots, data packages, or preflight artifacts;
|
|
- durable upload retry queues;
|
|
- distributor-specific CLI flags;
|
|
- making distributor scan the weatherreporter workspace;
|
|
- handling destination routing, Markdown-to-HTML transformation, public URLs,
|
|
or nginx layout inside weatherreporter.
|
|
|
|
Any distributor enhancement should preserve the existing 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 current behavior:
|
|
|
|
- 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.
|
|
|
|
## Cleanup Refactors
|
|
|
|
The initial cleanup pass intentionally left these refactors out because the
|
|
current implementation does not yet make them worth the added abstraction.
|
|
|
|
Revisit these only when new source types, report types, operational
|
|
requirements, or recurring maintenance costs make the duplication materially
|
|
more expensive:
|
|
|
|
- Broad briefing weather-signal consolidation: consider when multiple module
|
|
builders repeatedly derive the same weather signals and tests begin to need
|
|
coordinated fixture updates.
|
|
- Generic workflow engine: defer unless generation, inspection, recovery, or
|
|
future background workflows gain enough shared step semantics to justify a
|
|
declared execution model.
|
|
- Cobra migration: defer while the standard-library CLI remains small,
|
|
explicit, and covered by parser tests.
|
|
- Manifest, resume, or progress system: defer until operators need resumable
|
|
runs, checkpoint recovery, or richer audit trails than the current durable
|
|
artifacts and metadata provide.
|
|
- Global test helper package: defer while package-local helpers keep tests
|
|
clear; revisit only if setup duplication starts to hide behavior.
|
|
- Logging subsystem: defer until there are recurring operator diagnostics that
|
|
cannot be handled with current errors, metadata, inspection commands, and
|
|
artifact output.
|
|
|
|
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.
|