3.7 KiB
ADDED Requirements
Requirement: Operator authenticates with an account session or compatibility bearer token
The console SHALL use username/password account login and a server-managed browser session as its primary authentication flow. It SHALL retain an explicit operator-supplied bearer-token compatibility path, hold that token only in browser session storage, and attach it as an Authorization: Bearer header on requests made in compatibility mode.
Scenario: No account session or token present
- WHEN an operator opens the console without a valid account session or previously entered compatibility token
- THEN the console shows username/password login with an explicit token compatibility action instead of any dashboard view
Scenario: Authentication rejected by the Cloud API
- WHEN the Cloud Control Plane responds
401to a request carrying the active account session or stored compatibility token - THEN the console clears active authentication state and returns to login with a clear message
Scenario: Tab closed
- WHEN an operator closes the browser tab running the console
- THEN any stored compatibility bearer token is discarded and is not available on the next visit
Requirement: Task dashboard
The console SHALL render a task view listing tasks by status with pagination, and SHALL show a task's detail including its attempt history, using the platform SDK's task-listing and attempt-history endpoints.
Scenario: Browse the task queue
- WHEN an operator with a
tasks:read-scoped token opens the task view - THEN the console displays tasks with their status, goal or workflow reference, and assigned device/host, and lets the operator filter by status
Scenario: Inspect a task's attempt history
- WHEN an operator selects a task from the list
- THEN the console displays that task's recorded attempts in order, including each attempt's outcome
Requirement: Device pool and host registry views
The console SHALL render the current device pool and host registry, including stale/unreachable device status, using the platform SDK's device- and host-listing endpoints.
Scenario: View devices across hosts
- WHEN an operator with a
pool:read-scoped token opens the device view - THEN the console displays every pooled device with its owning host, driver type, and current status, including
unreachablefor devices owned by a stale host
Scenario: View registered hosts
- WHEN an operator opens the host view
- THEN the console displays every registered host with its last-seen timestamp
Requirement: Plugin registry view with registration
The console SHALL render the registered plugin list and SHALL let an operator submit a new plugin manifest for registration, using the platform SDK's plugin-listing and plugin-registration endpoints.
Scenario: View registered plugins
- WHEN an operator with a
plugins:read-scoped token opens the plugin view - THEN the console displays every registered plugin with its
entry_point_kindand whether it is wired to an execution path
Scenario: Register a plugin from the console
- WHEN an operator with a
plugins:admin-scoped token submits a valid plugin manifest through the console's registration form - THEN the console calls the plugin-registration endpoint and displays the newly registered plugin on success, or the API's validation/conflict error on failure
Scenario: Registration attempted without admin scope
- WHEN an operator whose token lacks
plugins:adminsubmits the registration form - THEN the console surfaces the API's authorization error without retrying or silently discarding the submission