Use generated-view host actions
Open a completed generated view in Complexity. A host button can copy text, open a safe URL, or request a new turn. It requires an explicit click. A locked, read-only, or incomplete instance cannot execute it.
Generated source uses HostButton(label, operation, value) with copy, openUrl, or newTurn. It receives no executable callback or provider endpoint. Local Button(Action(Set/Reset)) and form Submit(label) remain separate.
Host boundary
The renderer binds a durable output key to its host callback. Mount, hydration, local calculations, reload, reconnect, and history replay never trigger an action.
Clipboard and URL actions call browser APIs directly in the click stack, preserving user activation. URLs must be absolute HTTP(S), without credentials or control characters. Local copy/open remains available on a completed output during another model run.
A new turn checks active-run and automatic-reply restrictions. Button pending state and host dispatch deduplication prevent a double click from opening another action.
New turns and MailGen actions
newTurn uses the current chat's canonical run admission with a separate query. It creates neither a chat nor a composer draft. It preserves draft text, pending attachments, mentions, references, and Submit consent. It includes no implicit UI snapshot.
Session/origin checks, authenticated transport, backend actor/chat/tenant/mailbox checks, and active-branch admission remain authoritative. Unknown network results retain the original request key and parent for explicit retry.
Tab session storage keeps only that key, parent ID, and a hash of source/action/settings identity. It stores no plaintext query, source, or input values. Reload never replays automatically. A later explicit click must match the original source and payload. The backend receipt determines whether admission already succeeded.
An old parent can replay an already accepted receipt. Without a receipt, another turn that advanced the branch makes a new request from the stale parent invalid. The transaction checks this again after browser preflight.
MailGen requests use normal enabled tools, fresh authorization, audit, and canonical operations. Generated source has no runTool, arbitrary provider operation, or generic approval endpoint. Protected actions first produce a typed proposal card. Separate confirmation sends IDs only. The backend reloads the stored payload and checks permissions, revision, and idempotent receipt.
Draft review and recovery
Completed native and custom views can show trusted Open mail and Create draft controls outside the generated tree. Their availability depends on the original enabled tools, current selection, operation grants, and mailbox access. Custom-runtime readiness does not grant draft permission.
Create draft calls the canonical writer and consumes model quota. A normal successful save needs no extra approval. The host opens the saved canonical draft after the explicit action completes. Open draft later reads that draft without generating another proposal. Existing unsaved editor changes remain intact.
A result marked requiresApply, a conflict, or a late confirmed proposal can require host review. The host retrieves the stored proposal through an authenticated route. Proposal text stays outside generated-view state and automatic model input. Its preview blocks scripts and network access.
Use Apply proposal to save the reviewed proposal. The host sends the action identity, intent version, and decision. It does not send replacement proposal text or a new baseline. The backend compares the canonical draft against the baseline captured for that review. A conflict requires a new review and version. Unsaved changes in the open editor disable Apply.
Apply saves the stored proposal without rerunning the writer or creating another draft shell. Cancel proposal settles the proposal without deleting an existing draft or cancelling an accepted mailbox command. Pending or uncertain mailbox operations can keep both decisions unavailable.
After an unknown result, use Check action status. Reload, reconnect, and another tab recover the latest intent for the exact output and action through authenticated backend reads. Recovery checks current permissions and mailbox identity. It does not execute an action, rerun the writer, or open a reader or composer automatically. A failed recovery does not authorize a new write.