Validate examples and clean up roadmap

docs/config.md

@@ -22,6 +22,8 @@ files. Environment-variable configuration is not implemented.
 
 ## Minimal Config
 
+See [examples/minimal-config.yml](../examples/minimal-config.yml).
+
 ```yaml
 weather_api:
   base_url: https://weather.api.example.com/
@@ -102,3 +104,12 @@ snapshot exists and a threshold is crossed.
 
 Configuration files should not contain secrets. The current Weather API and
 Scriptorium integration settings do not require secret fields.
+
+## Maintained Examples
+
+- [examples/minimal-config.yml](../examples/minimal-config.yml): smallest
+  useful config for generation and fetching.
+- [examples/config.yml](../examples/config.yml): production-oriented config
+  covering implemented fields.
+
+Both example files are loaded by the config test suite.

docs/roadmap/documentation.md

@@ -66,10 +66,8 @@ unimplemented work belongs only under `docs/roadmap/`.
   the canonical contributor workflow document.
 - `docs/policy/documentation.md` - keep. It is the controlling documentation
   policy for this migration.
-- `docs/roadmap/initial.md` - split and delete or replace. Much of it now
-  describes completed implementation work; extract only still-future content
-  into a future-only roadmap and remove this stale initial roadmap from the
-  current documentation map.
+- `docs/roadmap/future.md` - keep as the future-only project roadmap. The stale
+  implementation roadmap was removed after deferred work was extracted.
 - `examples/config.yml` - keep and lightly update. It is a maintained
   production-oriented example config and should be validated against the
   implemented config loader.
@@ -97,8 +95,7 @@ Documents that are stale or in the wrong canonical home:
 
 - `docs/policy/development.md` contains proposed layout, MVP wording, and future
   design notes that should live in roadmap docs or be removed once implemented.
-- `docs/roadmap/initial.md` should not be treated as a current implementation
-  guide. It mixes completed MVP planning with deferred work.
+- `docs/roadmap/future.md` is the current home for deferred project work.
 - `README.md` links to the implementation roadmap. The README should link to
   current user/operator/developer docs and, if useful, a future-work roadmap
   that is clearly labeled as such.
@@ -125,7 +122,8 @@ Examples:
 
 Links likely needing verification:
 
-- README links to `docs/roadmap/initial.md`.
+- README should link only to current user/operator/developer docs unless a
+  clearly labeled future-work link is needed.
 - Internal docs should link to canonical integration docs instead of repeating
   Scriptorium or Weather API details.
 - Operations and troubleshooting should link to CLI and config reference rather
@@ -380,7 +378,8 @@ Links likely needing verification:
 - Purpose: future-only project work extracted from stale roadmap material.
 - Canonical scope: deferred features such as automatic storm monitoring, if
   still desired.
-- Source-of-truth areas: `docs/roadmap/initial.md` and current code boundaries.
+- Source-of-truth areas: current code boundaries and deferred work already
+  extracted into this file.
 - Acceptance criteria: no completed MVP tasks; no claims of current behavior;
   each item is clearly labeled proposed, accepted, deferred, or rejected.
 
@@ -436,9 +435,8 @@ Links likely needing verification:
   current project behavior.
 - `docs/integrations/scriptorium.md`: keep `--input data_package=<path>` as the
   documented input contract. Do not reintroduce `--vars-file` or `promptvars`.
-- `docs/roadmap/initial.md`: do not update it as current docs. Extract
-  still-future work into `docs/roadmap/future.md`, then delete or replace the
-  stale file.
+- `docs/roadmap/future.md`: keep only deferred work and avoid completed
+  implementation history.
 - `examples/config.yml`: keep as production-oriented config. Validate it with
   config-loading tests or an equivalent non-secret check.
 - `examples/minimal-config.yml`: add only if the implementation agent also adds
@@ -729,11 +727,11 @@ archive, remote storage, or resume behavior because those are not implemented.
 - Goal: validate examples and ensure roadmap docs contain only future/planned
   material.
 - Files to create/update/delete/move: update `examples/config.yml`; optionally
-  create `examples/minimal-config.yml` with validation coverage; extract
-  future-only content from `docs/roadmap/initial.md` into
-  `docs/roadmap/future.md`; delete or replace `docs/roadmap/initial.md`.
+  create `examples/minimal-config.yml` with validation coverage; keep
+  `docs/roadmap/future.md` as the future-only roadmap after removing stale
+  implementation-history material.
 - Repository areas to inspect: `internal/config/*`, config tests,
-  `docs/roadmap/initial.md`, current implemented feature set.
+  roadmap docs, current implemented feature set.
 - Acceptance criteria: examples load successfully; roadmap files are clearly
   future-only; no completed MVP stage plan is linked as current docs.
 - Suggested validation commands: config example loading test, `go test ./...`,
@@ -800,7 +798,5 @@ Manual review items:
 
 No questions block a correct documentation roadmap or migration.
 
-Recommendation: during the migration, delete or replace
-`docs/roadmap/initial.md` after extracting any still-valid future work into a
-future-only roadmap. Do not treat `docs/roadmap/initial.md` as current project
-documentation.
+Recommendation: keep `docs/roadmap/future.md` future-only. Do not reintroduce
+completed implementation-history material as current project documentation.

docs/roadmap/future.md

@@ -0,0 +1,51 @@
+# 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.