87 lines
3.3 KiB
Markdown
87 lines
3.3 KiB
Markdown
# Future Roadmap
|
|
|
|
This roadmap contains project work that is not implemented. Current behavior is
|
|
documented outside `docs/roadmap/`.
|
|
|
|
## Deferred: 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 when available, 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.
|
|
|
|
## Deferred: 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.
|
|
|
|
Each item needs its own design note before implementation. Non-roadmap docs
|
|
must not describe these as available behavior.
|
|
|
|
## Deferred: 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:
|
|
|
|
- Weather API optional-source specification/helper refactor: consider when
|
|
additional Weather API sources make per-source fan-out, policy handling, and
|
|
provenance wiring repetitive enough to obscure adapter behavior.
|
|
- Broad briefing weather-signal consolidation: consider when multiple briefing
|
|
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.
|
|
- Plugin architecture: defer until there is a concrete external extension
|
|
contract and at least one implemented extension point.
|
|
- 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, and adapter boundaries unless a separate roadmap
|
|
explicitly changes them.
|