Files
weatherreporter/docs/adr/0001-stateless-execution.md

4.3 KiB

0001: Make Weatherreporter Execution Stateless

Status: Accepted

Date: 2026-08-01

Context

Weather reports are ephemeral products. Forecasts and current conditions change continuously, so the useful response to an old, failed, or superseded report is normally a new generation rather than replaying or inspecting a prior run.

The existing run-addressed workspace retains module snapshots, prompt inputs, execution receipts, generated text, rendered reports, metadata, and notification receipts. That provenance store accumulates operational history whose recovery and compatibility obligations are disproportionate to the value of an ephemeral weather report. It also exists solely to support local Recent Changes comparison for a rarely used report section.

The accepted Stateless Execution Roadmap defines the feature scope and implementation plan. This decision records the durable rationale for the resulting architecture.

Decision

Weatherreporter will operate as a stateless transformation pipeline:

Weather API input
  -> deterministic facts and modules
  -> Promptkit data package and generated text
  -> repository-owned Markdown rendering
  -> operator-owned report output
  -> optional Distributor upload

Ordinary invocations will retain intermediate values only for the active process and will publish one operator-owned Markdown output atomically. A failed or canceled generation must not truncate or partially replace an existing selected output. Single-report Distributor notification follows successful publication; batch notification follows successful publication of every planned report.

Weatherreporter will remove local Recent Changes comparison instead of retaining application state to support it. It will remove run-addressed workspace artifacts, historical inspection, and backward-compatible workspace decoding. RunIDs may remain active correlation and Distributor idempotency values, but will not identify retained application history.

Explicit --llm-debug-dir capture remains the sole diagnostic-file exception. The operator selects and manages that secure location; ordinary execution does not create an implicit debug location or a general logging store, and debug capture must continue to exclude credentials.

Any future forecast comparison must use a structured product supplied by the Weather API rather than local Weatherreporter history. The proposed Upstream Forecast Change Product defines the required upstream direction. A future integration must not add a local snapshot fallback.

Alternatives Considered

Retain The Bounded Current-State Design

Retaining a managed workspace with current metadata, receipts, and snapshots would preserve inspection and local comparison, but keeps an application-owned history subsystem, artifact compatibility burden, and recovery surface that do not match the report lifecycle.

Time-Based Retention

Expiring workspace material after a fixed period reduces accumulation but still requires retention policy, cleanup behavior, failure handling, and historical format support. It does not remove the mismatch between retained provenance and ephemeral report products.

Bounded Run History

Keeping only a fixed number of prior runs limits storage volume but still makes Weatherreporter responsible for run selection, comparison, inspection, and state migration. It also creates arbitrary history gaps without establishing an authoritative forecast baseline.

Consequences

The CLI, configuration, prompt-input, workspace, and inspection contracts will change together. Legacy workspace material will not be migrated, decoded, or automatically deleted; operators remain responsible for any desired cleanup.

Current action results will carry active identity, selected profile, safe effective model information, output location, notification result, and safe errors instead of historical artifact paths. Tests will protect atomic output, batch and notification ordering, explicit secure debug capture, and the absence of ordinary application-managed state.

This decision deliberately leaves the Weather API responsible for any future forecast-history comparison. It avoids a cache, archive, retention engine, manifest, resume mechanism, or replacement inspection surface in Weatherreporter.