Organizing and continuing conversations

Delivery scope: partition grouping, the complete inbox, reversible closing and durable external task reuse are independent of AI preparation. First-prompt summaries and related-conversation suggestions remain planned until the naming-service connection is approved and installed. Delivery status records validation and deployment evidence.

The inbox groups conversations by their partition name, like projects in a repository sidebar. Each partition has a count and can be collapsed. Delegated work belongs under its parent conversation and is collapsed until expanded. Open, Closed and All views use the complete accessible catalog; a display limit must never silently hide older conversations. Search includes partition names, titles, descriptions, categories and delegated work. The same inbox is available from the desktop chat and the phone's Threads link. Select visible and bulk close act only on expanded, matching conversations; collapsing a partition clears its selection.

Grouping uses the conversation's original context partition, falling back to its stored partition when no context is available. A conversation kept in the user's home can appear under the partition it discusses without changing its storage path or access rules. This is a local projection, so existing conversations group immediately without model calls or metadata backfills. Categories remain optional secondary labels; changing a label does not move a conversation between partitions.

Planned: first message and continuation

When the preparation service is available, the composer prepares a title and a short description of the first prompt. Partition grouping is derived from context. The original draft, selections and attachments remain available throughout preparation. A relevant open conversation can be suggested, with two explicit choices:

• Continue thread appends the draft to the selected conversation after rechecking that it is still an accessible, caller-owned, open root conversation.
• Start new creates one conversation with the prepared metadata and the original first message.

Current deployed adapters use normal creation while the service is absent; they do not issue an unhandled preparation request or delay sending. The optional choice flow is tested with a fake preparation service and is enabled only by a future integration.

The choice happens before creating a runnable thread. Matching never merges conversations, closes an older conversation, or launches its task. Titles and descriptions from other conversations are matching data, never instructions. Failure leaves the draft intact. A new edit invalidates a pending suggestion. Retrying an uncertain submission keeps its operation identifiers.

MeshNode.Description describes the original request. It is distinct from Thread.Summary, the latest result used by delegation. A continued conversation retains its existing title, description and category. Manual edits remain authoritative. Thread paths remain stable when names change.

Closing and Undo

Close moves a conversation to the Closed view without deleting its messages or changing its children. Bulk close reports each result independently. Conversations with running or queued work, including active delegated work, are skipped. Selection and counts describe root conversations. Delegated child paths are rejected by both the batch operation and the owning thread handler; older root paths without an _Thread segment remain supported. Accessible orphaned children stay visible, but cannot be selected for root-conversation close.

The parent's running and queued state is checked atomically by its owner. The active-child check uses a query snapshot, because multiple thread owners do not share an atomic transaction. A child may start after that snapshot. Closing never cancels or edits it; the parent remains in Open while any accessible child is active, even when the parent's own status is closed.

Undo carries the specific close operation and persisted version. It restores the prior idle or cancelled state only while that exact close is still current. Later input, edits, reopening, or a different close invalidate the receipt. A close retry with the same operation identity recovers the original receipt, including its original persisted version; it cannot mint a fresh Undo receipt for an intervening edit. Accepted close identities remain recorded after reopening, Undo, and new input, so an old close request cannot close resumed work again. Explicitly sending new input to a closed conversation reopens it; retrying an already accepted input does not.

The owning thread hub evaluates the condition and performs the update. A remote mirror's per-property merge cannot safely enforce a close or Undo precondition: it can merge a stale Done write with newly queued input. The request/response boundary also gives clients an actual acceptance receipt instead of guessing that a fire-and-forget write succeeded.

Reuse from Codex and other clients

A durable external task identifies its conversation using the authenticated user, client name and task id. The conversation lives in that user's home; the page or namespace discussed is message context and can change without creating another conversation. Reconnects and transport session ids do not change the mapping. Forked tasks have distinct task ids. Starting an intentionally separate conversation requires a new task id.

Each send also carries its own stable request id. Creation and message retries recover the same conversation and receipt. A repeated request id with a different payload is rejected. Accepted message fingerprints remain after ingestion so an old retry cannot enqueue the same work again. None of these identifiers grant access: ordinary mesh permissions and the persisted origin are checked before reuse. Read-only MCP calls do not create conversations.

Implementation boundaries

ThreadPreparation is a read-only protocol. ContinueThreadRequest is the explicit suggested-choice commit; SubmitThreadMessageRequest is an acknowledged ordinary follow-up, including shared and delegated conversations. CloseThreadsRequest and UndoThreadClosuresRequest share the same lifecycle operations across native, React and Blazor clients. Standard layout controls render the shared user inbox at {user}/Threads, also embedded by the shared Threads landing page. MCP callers retain operationId with the selected paths when retrying an uncertain close_threads response; omitting it deliberately starts a new close action.

Tests cover catalogs larger than 100 rows, hidden children, queued work, closed-state transitions, stale Undo receipts, retries after ingestion, changed retry payloads, preservation of drafts and attachments, and both choices in the actual phone composer. The typed and voice entry points use the same preparation flow.