# Embedded Task View

> Canonical path: `specs/task/embedded-view.md`
> Status: retired
> Scope: records the retired inline embedded-task-card surface and the current quiet-source-thread rule.
>
> Related specs:
>
> - [`specs/task/board.md`](board.md): task detail, task discussion, checkpoints, artifacts, review, and subtasks are the current task primitives.
> - [`specs/task/agent-space-convergence.md`](agent-space-convergence.md): Task + Scope Execution convergence.
> - [`specs/task/timeline-cards.md`](timeline-cards.md): retired generic persisted-card foundation.

## Current product stance

Inline embedded task cards are retired. Creating or binding a task from a channel, DM, or reply thread must keep the source conversation quiet by default:

- The source conversation may keep source-thread/source-message references on the task.
- The source conversation may contain ordinary task references such as `#t123` when a human or agent explicitly writes them.
- High-signal task updates return to the source conversation only through explicit announcements, milestone/blocker/review-request messages, or ordinary discussion replies with clear audience intent.
- The source conversation must not receive a synthetic task-card message, persisted card row, task-card renderer state, or card-specific unread/cache state just because a task was created.

The user-visible task surfaces are:

- task detail;
- task discussion;
- checkpoints/activity;
- artifacts/review;
- subtask rollup;
- explicit announcements or ordinary task references in a conversation.

On desktop, opening an ordinary task reference uses the route-backed Task
detail dialog path and keeps the source conversation mounted but non-interactive
behind it. The reference does not create an inline Task card or a
conversation-owned detail implementation. Reload in the same tab restores the
dialog and source state. On narrow viewports, direct or cold dialog paths, new
tabs, and explicit expansion, the same canonical Task document renders as its
focused page.

## Source binding

A task may record where it came from so users and agents can navigate back to context:

- `source_thread_channel_id` identifies the source reply thread when present.
- `source_thread_parent_channel_id` and `source_thread_parent_message_id` identify the parent conversation/message for a reply-thread source.
- `source_thread_ref` stores the user-facing source target that initiated the task when available.

These fields are task metadata and navigation hints. They do not authorize a new message in the source conversation and do not imply a source-conversation projection.

## Message and renderer boundary

Current code must not add a dedicated embedded-task renderer to conversation rows. Conversation rendering may parse ordinary task references for navigation, but task-shaped UI belongs to task detail/discussion surfaces.

Old embedded-task system-card rows, if present in legacy data, are compatibility input only. Message read/query surfaces must omit them so old development data does not reintroduce source-thread noise. The compatibility filter is not a current write contract and must not be used as a new extension point.

## Active task target behavior

Active task target is explicit runtime/session state, not inferred from an inline card in the current thread.

- Agent task tools may return a structured active task target.
- Task discussion wakes may set the current task target.
- Humans or agents may clear/override the active target when multiple tasks are relevant.
- `send_message` no longer blocks ordinary channel/DM/thread replies solely because an active task target exists.

A conversation containing an ordinary task reference does not by itself select an active task target.

## Agent-authored output

Agent output follows task-native routing:

- default progress and collaboration belongs in task discussion/checkpoints/artifacts;
- explicit milestone/blocker/review/completion output may be announced back to a channel/thread with clear audience intent;
- ordinary conversation messages remain ordinary messages and must not synthesize task-card state.

## Acceptance criteria

This spec is satisfied when all of the following remain true:

1. Task creation from a source conversation records source refs without appending an embedded task card to that conversation.
2. Conversation history and sync omit legacy embedded-task system-card rows.
3. Conversation UI has no embedded-task-card renderer, card list query, or card-specific local state.
4. Task detail/discussion/checkpoint/artifact/review surfaces provide the task-shaped user experience.
5. Agent output uses task-native routing and explicit announcements instead of implicit source-thread cards.
6. Ordinary Task references navigate to the canonical Task URL and use the
   shared modal/page presentation contract from `board.md`, without closing a
   reply thread before desktop modal navigation.