Plan the stateless execution refactor

docs/roadmap/future.md

@@ -3,6 +3,40 @@
 This roadmap contains future work only. Each section identifies its planning
 status; current behavior is documented outside `docs/roadmap/`.
 
+## Upstream Forecast Change Product
+
+Status: Proposed upstream feature request; unimplemented.
+
+Weatherreporter's local Recent Changes feature is deprecated for removal by
+the accepted [stateless execution roadmap](ephemeral-state.md). Forecast
+version history and comparison are better owned by the Weather API, where the
+underlying forecast issuances can be retained and compared consistently for
+all consumers.
+
+A future Weather API feature should expose a structured change product with:
+
+- explicit current and baseline forecast issuance timestamps or identifiers;
+- documented baseline selection, such as a requested comparison timestamp,
+  preceding issuance, or fixed rolling period;
+- location, timezone, and half-open valid-period identity;
+- typed changed values with previous and current values and units;
+- stable change categories for temperature, precipitation probability and
+  timing, wind gusts, alerts, and aggregate hazards;
+- an API-owned significance classification or enough structured information
+  for a stateless consumer to apply a documented presentation threshold; and
+- deterministic ordering, missing-baseline behavior, and source metadata.
+
+The API should compare forecast versions, not track a Weatherreporter client's
+"previous run." It should not require consumer identity, mutable cursors, or
+Weatherreporter-managed history. A missing baseline should be a normal empty
+result rather than an error.
+
+Once a stable upstream contract exists, a separate Weatherreporter roadmap may
+reintroduce change commentary by collecting that product and mapping it into a
+curated prompt-facing module. There must be no local snapshot fallback. The
+ordinary Weatherreporter process must remain stateless, and the upstream
+feature should have deterministic fixtures before adoption.
+
 ## Automatic Storm Monitoring
 
 Status: Proposed and unimplemented.
@@ -14,7 +48,9 @@ Possible direction:
 1. Detect candidate storm events from alerts, forecast discussion, weather
    story context, hourly thresholds, and material forecast changes.
 2. Evaluate candidates through Promptkit or another narrow evaluator adapter.
-3. Persist storm lifecycle state.
+3. Keep any required storm lifecycle state in the upstream service or another
+   explicitly designed external owner rather than silently reintroducing a
+   Weatherreporter workspace.
 4. Generate or update a storm report only when a meaningful event is present.
 5. Suppress ordinary low-impact thunder or rain chances.
 
@@ -54,8 +90,7 @@ Status: Proposed and unimplemented.
 Possible future modules:
 
 - `hourly_table` for compact valid-period hourly facts
-- `forecast_delta` if a separate stanza is useful beyond current Recent
-  Changes
+- `forecast_delta` after an upstream forecast-change product exists
 - `weekend_planning` if weekend-specific planning guidance needs a dedicated
   deterministic stanza
 - `storm_window_summary` if manual or automatic storm reports need a dedicated
@@ -79,7 +114,7 @@ contracts](../internal/facts.md), [module internals](../internal/module.md), and
 - 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
+- keep module output structured and deterministic
 
 ## Distributor Notification Enhancements
 
@@ -92,10 +127,8 @@ behavior is documented in the [Distributor adapter guide](../internal/distributo
 unimplemented:
 
 - `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
 
@@ -138,6 +171,7 @@ maintenance costs make the added abstraction worthwhile:
 - 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.
+Any future implementation should preserve the public CLI, report-output
+contract, report identities, module boundaries, and adapter boundaries in
+effect when that work begins unless a separate roadmap explicitly changes
+them.