Clarify future roadmap statuses

docs/roadmap/future.md

@@ -1,17 +1,14 @@
 # Future Roadmap
 
-This roadmap contains project work that is not implemented. Current behavior is
-documented outside `docs/roadmap/`.
+This roadmap contains future work only. Each section identifies its planning
+status; current behavior is documented outside `docs/roadmap/`.
 
 ## Automatic Storm Monitoring
 
-Manual Storm Report generation is available through:
+Status: Proposed and unimplemented.
 
-```sh
-weatherreporter generate storm --start TIME --end TIME
-```
-
-Automatic storm-event evaluation is not implemented.
+Manual Storm Report generation is implemented; see the [CLI reference](../cli.md).
+Automatic storm-event evaluation remains unimplemented.
 
 Possible direction:
 
@@ -37,6 +34,8 @@ 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
@@ -46,12 +45,13 @@ Possible future report types:
 - 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`.
+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
@@ -71,7 +71,9 @@ 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:
+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
@@ -82,9 +84,13 @@ Future module work should preserve these boundaries:
 
 ## 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:
+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
@@ -100,7 +106,9 @@ while distributor owns destination routing and publication behavior.
 
 ## Alternate Runtime Integrations
 
-These ideas are not implemented:
+Status: Proposed and unimplemented.
+
+These ideas remain unimplemented:
 
 - native LLM client inside `weatherreporter`
 - database-backed state
@@ -119,6 +127,8 @@ 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: