Program: production familiar delegation with optional Daytona cloud execution

[BunsDev]

Goal

Deliver the smallest production-connected OpenCoven Chat slice that proves a real authorized familiar can perform bounded remote work through the canonical OpenCoven stack, survive interruption, return a durable result, and account for paid cloud usage correctly.

This is not a generic Grok-style bot-platform rebuild. It is the first evidence-backed parity milestone.

Product outcome

From production Chat, an authenticated principal can:

1. select an existing familiar;
2. submit one bounded repository diagnosis/test mission;
3. bind the mission to the exact authorized familiar root/revision and canonical runtime authority;
4. optionally execute the accepted mission through the paid Daytona execution surface;
5. close/reopen or reconnect Chat without losing authoritative progress;
6. inspect execution state, bounded evidence/artifacts, usage, and any required approval;
7. cancel safely;
8. recover a terminal result without duplicate effects.

No merge, publication, protected familiar mutation, or generic shell/filesystem/network authority is implied by this milestone.

Canonical ownership

• familiar-contract: portable familiar identity and revision semantics.
• coven-threads: protected mutation/approval decisions.
• psyche: task, lane, lease, approval, receipt, retry, and recovery semantics.
• coven: daemon authority, persistence, sessions, execution, and state transitions.
• coven-runtimes: accepted capability/runtime descriptors and conformance.
• sdk: constrained public client/binding surface.
• coven-agents: paid product account/subscription state, bounded execution admission, Daytona lifecycle, tenant credential custody, usage/evidence.
• chat: presentation, connection UX, bounded client state, native integration, packaging.

Chat and billing state MUST NOT become alternate identity, authorization, orchestration, or runtime authorities.

Required work graph

A. Canonical execution binding

Define and implement the producer-consumer contract that binds an accepted mission to:

• authenticated principal authority;
• exact familiar_root_id and revision/digest;
• operation/mission identity;
• accepted runtime/capability profile;
• bounded execution scope and lease;
• immutable attempt identity for retry/recovery.

Unknown or unavailable authority fails closed. A client-supplied field may never grant authority.

B. Daytona production boundary

Prove the configured execution profile rather than relying on provider defaults:

• explicit CPU/memory/disk bounds in the pinned snapshot/profile;
• one bounded process attempt per accepted execution;
• hard timeout and cancellation;
• descendant/process cleanup evidence;
• attempt-scoped credential cleanup;
• safe persistent-sandbox reuse or a fenced reset before reuse;
• idempotent reconciliation for uncertain provider outcomes.

C. Native Chat send/delegate path

Extend the current read-only production surface with the narrowest typed operation needed to submit and observe this mission. Preserve existing native security law:

• no browser-direct HTTP;
• no generic native request/execute command;
• no renderer-visible secrets;
• no broad shell/filesystem/network/opener capability;
• bounded inputs/outputs/deadlines/cancellation;
• authenticated-context binding for caches and late responses.

Demo success does not count as acceptance.

D. Paid cloud admission

Reuse the existing Stripe/entitlement foundation. Initial policy:

• one paid cloud plan;
• one disclosed included allowance and resource profile;
• no automatic overage for the first pilot;
• hosted Checkout/Customer Portal where platform policy permits;
• webhook-signature-verified entitlement projection;
• duplicate/stale/reordered billing events remain idempotent;
• subscription loss stops admission of new paid work without redefining familiar ownership or identity;
• billing/security revocation semantics remain distinct.

E. End-to-end acceptance matrix

At minimum verify:

• successful bounded remote mission;
• Chat close/reopen and reconnect during execution;
• duplicate submit/idempotency replay;
• cancellation before launch and after launch;
• canonical authority unavailable;
• stale familiar revision/authority;
• subscription expired/revoked before dispatch;
• entitlement changes during an already-authorized running attempt;
• provider timeout after ambiguous start;
• failed cleanup/reset;
• terminal result/artifact retrieval;
• exact usage reservation/settlement without double accounting.

Release boundary

This issue is complete only when the exact packaged Chat candidate and exact canonical producer/SDK/Coven Agents revisions have evidence for the end-to-end journey. Unit tests, mock execution, source-only E2E, Daytona-only smoke tests, or green ordinary CI do not individually prove completion.

Do not market this as full Grok parity. The correct claim is a verified familiar-execution beta.

Sequencing

1. Finish/verify existing Chat protected real-authority conformance blockers and SDK dependency work; do not weaken canary locks.
2. Land the canonical execution-binding contract at the producer/SDK boundary.
3. Prove Daytona resource/containment/reconciliation invariants.
4. Add the narrow native Chat submit/observe/cancel operation.
5. Exercise billing admission in shadow/test mode, then a bounded paid pilot after live Stripe evidence.
6. Only after repeat usage, expand to reusable skills/routines, notifications/mobile oversight, additional workflows/providers.

[BunsDev]

Work graph created:

• Implement narrow production delegate/observe/cancel path for one familiar mission #155 — narrow production delegate/observe/cancel path.
• OpenCoven/coven-agents#261 — canonical familiar execution authority adapter before Daytona dispatch.
• OpenCoven/coven-agents#262 — Daytona resource bounds, process containment, cleanup, and safe sandbox reuse evidence.
• OpenCoven/coven-agents#263 — Stripe paid-cloud pilot policy, entitlement UX, and live-evidence gate.

Recommended critical path: existing Chat protected conformance/SDK blockers → #261 contract → #262 production execution evidence → #155 native integration → #263 live paid-pilot enablement. UI work for #155 may proceed in parallel only against the agreed typed contract; mocks do not establish production acceptance.

Do not merge these concerns into one implementation PR: authority contract, provider containment, native Chat integration, and billing should remain independently reviewable.