45 lines
3.1 KiB
Markdown
45 lines
3.1 KiB
Markdown
## MODIFIED Requirements
|
|
|
|
### Requirement: Deployment and local persistence modes share one contract
|
|
The cloud repository SHALL support PostgreSQL for deployed operation and SQLite for local development and tests through the same behavioral contract, including hosts, dynamic Host credential bindings, device enrollments, pooled devices, tasks, leases, attempts, and plugins.
|
|
|
|
#### Scenario: Start with PostgreSQL
|
|
- **WHEN** the configured database URL selects PostgreSQL and the schema is current
|
|
- **THEN** the control plane uses PostgreSQL for cloud state, enrollment idempotency, authentication lookup, and transactional assignment operations
|
|
|
|
#### Scenario: Start in local SQLite mode
|
|
- **WHEN** the configured database URL selects SQLite in a local or test environment
|
|
- **THEN** the same repository contract, including Host and device enrollment, is available with the documented single-control-plane concurrency limitation
|
|
|
|
### Requirement: Cloud schema is versioned with migrations
|
|
The system SHALL provide versioned forward and downgrade database migrations and SHALL refuse readiness when the database schema is incompatible with the running application.
|
|
|
|
#### Scenario: Upgrade an existing cloud database
|
|
- **WHEN** an operator applies the enrollment release migration to a database at revision 0001
|
|
- **THEN** existing hosts, pooled devices, tasks, attempts, and plugins are retained while nullable Host enrollment fields and durable device enrollment storage are added
|
|
|
|
#### Scenario: Downgrade the enrollment schema
|
|
- **WHEN** an operator downgrades revision 0002 while no enrollment-capable application process is connected
|
|
- **THEN** dynamic Host credential and device enrollment storage is removed while legacy cloud state from revision 0001 remains available
|
|
|
|
#### Scenario: Schema is behind at startup
|
|
- **WHEN** the application connects to a database whose schema version is not accepted by the running release
|
|
- **THEN** readiness fails with a diagnostic that does not expose credentials
|
|
|
|
## ADDED Requirements
|
|
|
|
### Requirement: Dynamic Host authentication uses durable credential digests
|
|
The Cloud Control Plane SHALL authenticate dynamically enrolled Host bearer credentials through indexed repository lookup of a cryptographic token digest and SHALL compose that lookup with existing configured credentials.
|
|
|
|
#### Scenario: Enrolled Host authenticates after Cloud API restart
|
|
- **WHEN** a non-revoked enrolled Host presents its bearer credential after the Cloud API restarts
|
|
- **THEN** the repository-backed authentication provider resolves the stored Host binding and authorizes only Host-scoped internal operations
|
|
|
|
#### Scenario: Dynamic Host credential calls a public route
|
|
- **WHEN** a dynamically enrolled Host credential is presented to a public SDK operation requiring a scope
|
|
- **THEN** the request is rejected for missing scope rather than inheriting public operator privileges
|
|
|
|
#### Scenario: Static credential deployment remains active
|
|
- **WHEN** an operator continues to configure a Host-bound credential through the existing environment configuration
|
|
- **THEN** that Host can use the existing operational protocol without performing bootstrap enrollment
|