2026-09-02 01:05:41 +08:00
commit 04bac1f6e2
2200 changed files with 489415 additions and 0 deletions
@@ -0,0 +1,67 @@
# Creation-owned Automation runtime placement
## Outcome
The surface that creates an Automation owns its execution placement for the
Automation's lifetime:
- Desktop creation produces a `desktop` Automation and continues to use the
  authenticated desktop runner introduced by the existing Automations work.
- Web and Cloud Chat creation produce a `cloud` Automation. Den schedules the
  occurrence, wakes the owner's existing OpenWork Cloud container when it is
  stopped, and runs a native OpenWork thread headlessly inside that container.
Both surfaces read the same Den Automation and run history. Placement is shown
on list cards and receipts, but it is not an editable setting. Moving execution
between Desktop and Cloud requires creating a new Automation on that surface.
## Cloud lifecycle
A Cloud agent run reserves and persists its worker, workspace, native thread,
and deterministic user-message identity before it submits the prompt. Lease
recovery reattaches to that thread and observes-or-submits that exact message
instead of starting duplicate work. Den heartbeats the run while it waits,
requires an observed idle state after forwarding cancellation, records native
assistant/tool events and usage, and keeps active Cloud runs out of idle-stop
selection. Run deadlines include container wake-up and request admission.
Cloud creation requires the current owner to have an existing per-user Cloud
worker and an authorized model. It does not silently allocate a new Cloud
environment. A stopped worker is valid and is woken at execution time; a
missing or failed runtime is recorded as a durable failure and moves the
Automation to needs-attention. Timeouts are terminal receipts rather than
automatic retries because an agent may already have produced external side
effects; the user can inspect the native run and choose Run now explicitly.
Runtime readiness polling retains its pre-existing 120-second cap and terminal,
non-retryable outcome; signed-preview routing does not add another queued attempt.
Before prompt admission, Den probes and repairs the worker's persisted
`openwork-cloud` MCP registration for the selected model. A missing Connect
configuration or model projection becomes durable needs-attention rather than
a headless run that silently lacks the user's connected services.
The native thread client uses both the collaborator token and the internal
host credential when it talks directly to the resolved Cloud runtime. No provider
credential or worker token is copied into the Automation receipt.
## Relationship to Workflow Automations
Workflow Automations from the Workflow Artifacts work remain Cloud-owned
and keep their existing Den Code Mode executor. This feature adds ordinary
agent actions as a second Cloud execution kind; it does not change Script
snapshot validation or artifact result retention.
## Verification boundary
Focused tests cover the Cloud-only MCP creation contract, deterministic prompt
admission, terminal errors, cancellation observation, dual worker credentials,
Cloud wake/idle lifecycle behavior, runtime-specific agent guidance, and
cross-surface execution labels. Den Web provides once/daily/weekly create and
edit flows plus activate/deactivate, archive, run-now, cancel, native thread,
usage, and event receipt controls. The testkit acceptance tape covers the
Web/Desktop creation language and verifies that no placement picker is exposed.
The deployment-shaped Daytona journey—stop a real user's container, let a due
occurrence wake it, execute against live model and Connect configuration, then
observe idle shutdown again—remains required for the production rollout and
merge decision. It is intentionally not claimed by local or mocked proof.