Files
agentic-mobile-control/openspec/specs/host-agent-console-task-submission/spec.md
T

80 lines
4.1 KiB
Markdown

## Purpose
Define how an authenticated Host Agent local Console submits Host-scoped goal tasks safely through the existing Cloud control-plane self-submission operation.
## Requirements
### Requirement: Authenticated local Console submits a Host-scoped goal task
The Host Agent local Console SHALL provide a task-submission form on its
authenticated Tasks page. The form SHALL submit a non-empty goal through the
existing Host Agent self-submission client operation, which remains scoped to
the currently authenticated Host at the Cloud boundary.
The form SHALL offer an automatic-device option and the IDs of devices that
are currently registered in the running DeviceManager. An automatic-device
submission SHALL omit the device target so that the Cloud scheduler selects an
eligible device owned by the Host. An explicit submission SHALL pass the
selected runtime device ID unchanged; in enrollment-managed deployments this
is the Cloud device ID, not the local configuration ID.
#### Scenario: Operator submits a task with automatic device selection
- **WHEN** an authenticated local Console operator submits a non-empty goal
and leaves the device selection on automatic
- **THEN** the Console invokes the existing Host self-submission operation
without a device target and the resulting task remains constrained to that
Host
#### Scenario: Operator submits a task for a listed device
- **WHEN** an authenticated local Console operator selects a currently running
device and submits a non-empty goal
- **THEN** the Console passes that runtime device ID to the Host
self-submission operation without accepting a Host ID or workflow reference
from the form
### Requirement: Local task submission is protected and locally validated
The Console SHALL require its existing valid local session and CSRF token for
every task-submission POST. It SHALL reject an empty goal or a selected device
that is no longer present in the current DeviceManager snapshot before calling
the Cloud client.
#### Scenario: Unauthenticated or CSRF-invalid request is rejected
- **WHEN** a task-submission POST has no valid local session or CSRF token
- **THEN** the Console rejects the request and does not invoke the Host
self-submission client
#### Scenario: Stale device selection is rejected locally
- **WHEN** an operator submits a device ID that is absent from the current
DeviceManager snapshot
- **THEN** the Console returns a validation error and does not enqueue a task
### Requirement: Console acknowledges a confirmed submission safely
After the Host client confirms task creation, the Console SHALL use a
post-redirect-get response to show the returned Cloud task ID and SHALL write
a bounded local history entry containing the task ID and optional target
device ID. The history entry SHALL NOT persist the task goal, Host credential,
cookie, or lease secret.
#### Scenario: Confirmed task creation is acknowledged
- **WHEN** the Host self-submission operation returns a task ID
- **THEN** the Console redirects to the Tasks page with a visible confirmation
and records a non-secret local submission audit entry
#### Scenario: Control plane rejects submission
- **WHEN** the Host self-submission operation returns a definitive rejection
such as a disabled self-submission policy or invalid target
- **THEN** the Console renders a safe error to the operator and does not report
a task ID or record a successful submission audit entry
### Requirement: Non-idempotent task creation is attempted at most once
The Host Agent client SHALL not automatically retry a Host self-submission
request after a transport failure, server error, or malformed success response.
The Console SHALL report that such a submission has an unknown outcome and
SHALL NOT claim that no task was created.
#### Scenario: Transport outcome is uncertain
- **WHEN** the task-submission request loses its response or receives a server
failure after the request may have reached the control plane
- **THEN** the client makes no second creation request and the Console informs
the operator that the task may have been queued and must be checked before
submitting again