browser/openspec/changes/repair-run-runtime-state-and-log-recovery/specs/runtime-observation-freshness/spec.md

ADDED Requirements

Requirement: Platform exposes observation freshness with lifecycle projection

Platform SHALL expose the last Run-projected server lifecycle state together with a generic observation freshness derived from the bound Run endpoint's status and heartbeat age. Freshness MUST be distinct from the server lifecycle state.

Scenario: Bound Run is fresh

• WHEN the bound Run endpoint has an accepted recent heartbeat within the configured freshness interval
• THEN Platform SHALL expose the server runtime observation as fresh
• AND the lifecycle projection MAY be presented as currently observed

Scenario: Bound Run heartbeat is overdue

• WHEN the bound Run endpoint is offline, disabled, or beyond the configured heartbeat freshness interval
• THEN Platform SHALL expose the runtime observation as unverified or unreachable
• AND it MUST retain the last lifecycle projection rather than convert it to stopped

Requirement: Management views label unverified runtime state

Server list, server detail, and management terminal views SHALL show when a displayed lifecycle state is not currently vouched for by a fresh bound Run. They MUST NOT label a stale lifecycle projection as current process truth.

Scenario: Last observation was running but Run is offline

• WHEN the last lifecycle projection is running and the bound Run is unreachable
• THEN the management UI SHALL show the last observed running state with an offline or unverified qualifier
• AND it MUST NOT display the server as confirmed online solely from the persisted projection

Scenario: Management terminal opens while Run is unverified

• WHEN an operator opens the management terminal for a server whose bound Run is unverified
• THEN the terminal SHALL show that live delivery depends on Run recovery
• AND it SHALL continue to display accepted historical logs through the bounded SSE replay

Requirement: Explicit server stop remains Run-observed

An operator-requested stop SHALL remain a Platform-authorized intent executed by Run's generic supervision and plugin-declared lifecycle action. Platform SHALL project stopped only from the resulting Run observation or accepted lifecycle result.

Scenario: Operator stops a server while Run is available

• WHEN an authorized operator requests a server stop and the bound Run completes the declared stop action
• THEN Platform SHALL project the reported stopped process state
• AND the UI SHALL present the result as a current observation while the Run remains fresh