# Timeline Cards / System Card Foundation

> Canonical path: `specs/task/timeline-cards.md`
> Status: retired
> Scope: records the retired generic persisted card-anchor model.
>
> Related specs:
>
> - [`specs/message/private-channel-share-card.md`](../message/private-channel-share-card.md): channel share cards are now canonical visible messages.
> - [`specs/app/app-notification.md`](../app/app-notification.md): App interactive cards use an explicit message type and message-owned sidecar.
> - [`specs/task/embedded-view.md`](embedded-view.md): task source thread scopes do not render inline embedded task cards.

## Current status

The generic `timeline_cards` table and `system message + card envelope` runtime model are retired from the current schema and shipped write paths.

Current timeline items must choose an owning model explicitly:

- Ordinary visible transcript items are `scope_messages` with an explicit `message_type` when needed.
- Message-owned action state may live in a sidecar table keyed by `(scope_id, message_id)`.
- Non-message activity belongs in `scope_activity_events` only when it is not a transcript message.

Channel share cards follow this rule as `scope_messages.message_type = 'channel_share_card'` plus `scope_share_cards` action state. App interactive notifications use `message_type = 'app_interactive_card'` plus `service_notification_cards` render/action state. Owner quote / forward messages follow it as `message_type = 'owner_quote'` plus `scope_message_sources` provenance. New code must not recreate `timeline_cards`, a generic message-card registry, or `metadata.card.kind` as a current product extension point.

## Historical boundary

Historical migrations and compatibility fixtures may still mention `timeline_cards` or old `metadata.card.kind` envelopes because older development databases already created those artifacts. Upgrade migrations must backfill supported product data into the current message-owned shape, then remove the generic projection table from current runtime schema.

The historical embedded-task card consumer remains retired. Upgrade migrations remove retained embedded-task card rows instead of keeping a hot read fallback; new task code must not create embedded task cards, frontend list queries, renderers, or view-state storage.