73 lines
4.8 KiB
Markdown
73 lines
4.8 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Redis-backed runtime session registry is required
|
|
The system SHALL use Redis as the runtime session registry in development, test, and production environments, and SHALL NOT use an in-memory registry fallback for normal runtime registration, heartbeat, token validation, or job routing.
|
|
|
|
#### Scenario: Platform starts without Redis
|
|
- **WHEN** Platform starts or checks health while Redis is unavailable
|
|
- **THEN** runtime registry health is reported unavailable and runtime dispatch operations fail safely without assigning jobs to Runs
|
|
|
|
#### Scenario: Automated tests exercise Redis registry behavior
|
|
- **WHEN** tests cover Run registration, heartbeat expiry, token validation, or job claim routing
|
|
- **THEN** those tests use an isolated Redis database or key prefix rather than a memory-only registry
|
|
|
|
### Requirement: Run registration creates an ephemeral Redis session
|
|
The system SHALL authenticate generated Runs with durable component credentials and SHALL store only a short-lived Redis session lease for the live Run connection.
|
|
|
|
#### Scenario: Valid generated Run registers
|
|
- **WHEN** a Run submits a hello request with a valid server instance ID, component kind, component key generation, registration proof, version, target, capabilities, and capacity
|
|
- **THEN** Platform authenticates the durable component key and writes a Redis session lease scoped to that server/component identity
|
|
|
|
#### Scenario: Registration supersedes prior live session
|
|
- **WHEN** a second valid Run registers for the same server/component identity
|
|
- **THEN** Platform rotates the live Redis session token and the previous session token no longer authorizes heartbeat or job operations
|
|
|
|
#### Scenario: Invalid token is rejected
|
|
- **WHEN** a Run presents an invalid registration proof or stale component key generation
|
|
- **THEN** Platform rejects registration and does not create or renew a Redis session lease
|
|
|
|
### Requirement: Heartbeat leases expire without startup cleanup
|
|
The system SHALL represent runtime online state through Redis TTL leases that are renewed by heartbeats and naturally expire without Platform startup cleanup.
|
|
|
|
#### Scenario: Heartbeat renews lease
|
|
- **WHEN** a registered Run heartbeats with the current session token before the Redis TTL expires
|
|
- **THEN** Platform renews the Redis lease and updates the safe capability/capacity snapshot
|
|
|
|
#### Scenario: Run stops heartbeating
|
|
- **WHEN** a Run stops heartbeating beyond the configured expiry window
|
|
- **THEN** Redis expires the session keys and Platform reports that runtime connection as offline
|
|
|
|
#### Scenario: Platform restarts
|
|
- **WHEN** Platform restarts while Redis still contains live session keys
|
|
- **THEN** Platform resumes token validation and routing from Redis without scanning or cleaning stale keys at startup
|
|
|
|
#### Scenario: Redis loses session data
|
|
- **WHEN** Redis restarts or evicts runtime session keys
|
|
- **THEN** Platform treats affected Runs as offline until they register again and does not mutate durable server or job records solely because the Redis lease disappeared
|
|
|
|
### Requirement: Runtime jobs target server components instead of run endpoints
|
|
The system SHALL route durable runtime jobs by logical server/component target and SHALL NOT require a durable run endpoint row to create, validate, claim, or complete machine-side runtime work.
|
|
|
|
#### Scenario: Job is queued for a server Run
|
|
- **WHEN** Platform queues lifecycle, config, file, log, or protected-request work for a server Run
|
|
- **THEN** the durable job target identifies the server instance and `run` component rather than a run endpoint ID
|
|
|
|
#### Scenario: Run claims work
|
|
- **WHEN** a registered Run claims work with its current session token
|
|
- **THEN** Platform derives the server/component target from Redis and assigns only eligible jobs for that target
|
|
|
|
#### Scenario: Run attempts cross-server claim
|
|
- **WHEN** a Run session for one server attempts to claim, acknowledge, report progress, or complete a job targeting another server/component
|
|
- **THEN** Platform rejects the operation and preserves the durable job state
|
|
|
|
### Requirement: Runtime connection projections are safe
|
|
The system SHALL expose runtime connection health as a safe projection derived from Redis leases and durable server/component metadata, without exposing session tokens, Redis keys, raw credentials, host paths, or direct sockets.
|
|
|
|
#### Scenario: Owner views server runtime health
|
|
- **WHEN** an authorized owner views a server's runtime connection state
|
|
- **THEN** Platform returns safe status, last heartbeat time, version, target OS/architecture, capabilities, capacity, and unavailable reason
|
|
|
|
#### Scenario: Runtime session secrets remain hidden
|
|
- **WHEN** Platform Web, plugin pages, or bridge actions request runtime status
|
|
- **THEN** responses exclude session tokens, token hashes, Redis key names, raw component credentials, host paths, and sockets
|