@@ -10,10 +10,10 @@ Read `apps/sim/platform/AGENTS.md` first. It is the canonical ownership and code
 1. **Scope the phase.** Foundations, recipes and evidence are Phase 1. Approved product screens and their unique parts are Phase 2. Route integration, persisted state and authorization belong to Phase 3. Keep UI-only requests isolated; do not advance phases just to make a demo look real.
 2. **Resolve the product change.** Inspect the actual route first. Use the relevant live Paper bases and product states for existing anatomy, theme roles and interactions; a later explicit code-first decision supersedes an older specimen. Keep the checkpoint scoped to the affected states. For a new idea, a real product use is required, a new Paper drawing is not. Exclude Marcus.
 3. **Choose one owner.** Use `app/(shell)/<route>/_components/<component>/<component>.tsx` and a sibling CSS Module for unique anatomy. Put shared shell compositions at the nearest common route owner, generic EMCN primitives in `design-system/components/<family>/`, and design roles in foundations. Keep pages style-free. Promote the original owner on second use and update both callers. A gallery alone never justifies a variant. Apply the shared rhythm, icon and hover contract in `apps/sim/platform/AGENTS.md`; compare two real consumers for title and Cancel placement, first-line leading art and centered trailing metadata, opaque type-scaled icons, row hover and compact action gaps. Keep form chrome in Modal. Verify long-content fades on the actual scroll owner at the start, middle and end, then filter or resize until all content fits.
-   Consult the tracked component ownership map before adding markup. Choose the existing action button, navigable row, two-line activity row, picker, or disclosure by behavior. Render Base UI triggers through their controls. Trace copy/status lifetimes to the shared expiry owner; verify pause, reset, reduced motion and long tooltip limits. Compare Home/Chat reading edges and stable controls across responsive layouts, including structural rules and the actual scroll boundary.
+   Consult the tracked component ownership map before adding markup. Choose the existing action button, navigable row, two-line activity row, picker, or disclosure by behavior. Render Base UI triggers through their controls. Check a single notice and an expanded stack: the tray owns one control elevation outside its scrolling content. Trace copy/status lifetimes to the shared expiry owner; verify pause, reset, reduced motion and long tooltip limits. Compare Home/Chat reading edges and stable controls across responsive layouts, including structural rules and the actual scroll boundary.
 4. **Translate anatomy, not artboard coordinates.** Consult the installed Next docs in `node_modules/next/dist/docs` (especially project structure, CSS, Server/Client Components). Use semantic DOM, native or accessible behaviors, intrinsic size and responsive relationships. A 560px Paper modal is a preferred maximum, not a fixed width. The same modal should fit 647px and 390px viewports without new variants. Use centralized Tailwind roles, the type and material contracts, shared icon geometry and slots. Confirm the rendered DOM has the intended behavior. A searchable field accepts text, a disclosure opens by keyboard, a modal part composes directly, and a table renders the caller’s records. Repeated data takes an array, never a fixed list of numbered specimen props. Register a named native component for these cases. A new size requires a distinct, evidenced use; it isn't a device enum. Never pass styles through a composition. Trace repeated rows to their registered item and preserve the surrounding layout. Accept a typed collection, then render empty, short and longer-than-specimen data to prove that any example count can change. Keep different semantic roles distinct. Wrap Base UI primitives in EMCN when behavior involves floating layers, list navigation, cascading actions or focus management. Main-view and modal dropdowns share the same surface and rows. Preserve the caller’s value, accessible label and form submission through the owner. When editing generated files, change the source contract or compiler and regenerate the affected set.
 5. **Exercise the right states.** Build a matrix of actual themes, relevant content sizes, resting, hover, selected, error and disabled states, keyboard navigation, long data, zoom and widths between Paper examples. The workbench is tooling, not a Phase 2 product screen. Entities, including organizations, workspaces, members and chats, come only through the server fixture gate. Render empty or absent data distinctly. Focusing a control or typing in it preserves its resting chrome; verify there is no focus paint on the control or its wrappers. Test keyboard focus and restoration separately. For cascading menus, test hover travel, arrow keys, Escape one level at a time, and bounds at either edge of the viewport and inside a modal. Client interaction may open, dismiss or change steps; no authentication, persistence or network effects.
-6. **Prove it.** Run the structural audit against real code, regenerate/check relevant files, render the app in a real browser, and compare rendered geometry, type, icon ink/weight and interactions with the product contract and relevant Paper states. Exercise empty, full, stress and flag-off. Retire unused variants and resolve every affected use. Measure the shell inset against both sides of the footer, the Home greeting against its navigation row, and adjacent chat line boxes across thinking, tools and prose. Compare primary and destructive confirmation lightness changes in both themes. Check that dismissing a recent stays neutral, expand/collapse controls share a height, and message metadata remains visible as the pointer crosses into its toolbar. Verify isolation and the repository gates. Report covered keys/states separately from visual comparisons; record unresolved differences and durable verification paths. Stop at the authorized phase.
+6. **Prove it.** Run the structural audit against real code, regenerate/check relevant files, render the app in a real browser, and compare rendered geometry, type, icon ink/weight and interactions with the product contract and relevant Paper states. Exercise empty, full, stress and flag-off. Retire unused variants and resolve every affected use. Measure the shell inset against both sides of the footer, the Home greeting against its navigation row, and adjacent chat line boxes across thinking, tools and prose. Compare primary and destructive confirmation lightness changes in both themes. Check that dismissing a recent stays neutral, expand/collapse controls share a height, and message metadata remains visible as the pointer crosses into its toolbar. Keep type roles stable across breakpoints and at browser zoom. Source clock, age and date labels from `platform/lib/time.ts`; verify SSR, rollovers and metric/range controls together. Compare count alignment and notification action placement with existing controls before introducing markup. Verify isolation and the repository gates. Report covered keys/states separately from visual comparisons; record unresolved differences and durable verification paths. Stop at the authorized phase.
 
 **Product and desktop.** Map the feature to its existing route, feature owner, shared controls and both host compositions. Calendar events or workspace summaries can be unique, while their type, left/stacked text alignment, insets and action menus remain system-owned. Keep one renderer for browsers and Electron: see the Platform contract and `apps/desktop/README.md`. Use the typed preload adapter to detect desktop, leave OS window controls native, and exercise the actual desktop shell with a disposable profile. Cover fullscreen, split/expanded panels, compact takeover and returning to the previous tab. Keep real native execution and persisted resources for Phase 3.
 
 
@@ -20,9 +20,9 @@ The running product and the latest approved direction govern implementation. Use
 
 Keep routes thin. Colocate each feature component, its CSS Module and private helpers in `app/(shell)/<segment>/_components/<component>/`. `(shell)/_components/` owns parts shared by its descendant routes (navigation, conversation composer, session). Generic controls live in `design-system/components/<family>/`; import the same implementation everywhere. Each CSS Module belongs to its component folder. Base UI adapters inside EMCN may share the named `*.shared.module.css` button and popup recipes. Product components compose the corresponding EMCN controls through props. The workbench may render product owners. Product code and its variant-use graph exclude workbench modules. No customer-facing development notices. Unimplemented external actions stay unavailable.
 
-Use `design-system/styles/rhythm.css` for title/detail, list and action gaps (2px), row insets and icon sizing. Separate sibling rows with the sidebar list gap, without divider rules. Borders delineating surfaces and actual data rules, such as chart axes, serve different purposes. Align a leading avatar or glyph with the first text line; center trailing metadata, badges and actions against the whole row. Align action ink with adjacent text by extending the hit area into the margin. Chat thinking, tool labels and prose share that text edge. Composer and message action groups use the same compact gap. Custom calendar, chart and summary rows use the same type, spacing and tooltips.
+Use `design-system/styles/rhythm.css` for title/detail, list and action gaps (2px), row insets and icon sizing. Separate sibling rows with the sidebar list gap, without divider rules. Borders delineating surfaces and actual data rules, such as chart axes, serve different purposes. Align a leading avatar or glyph with the first text line; center trailing metadata, badges and actions against the whole row. Align action ink with adjacent text by extending the hit area into the margin. Chat thinking, tool labels and prose share that text edge. Composer and message action groups use the same compact gap. Custom calendar, chart and summary rows use the same type and spacing. An icon that identifies a two-line notification aligns to the title; its trailing action group centers against the full row. Email thread counts and the notification trigger use the same centered inline label/count spacing. The notification trigger takes the compact secondary (Invite) button surface, and has no chevron. The tray applies control elevation once around its scroll viewport; stacked notices do not cast shadows on one another. An active popup stays above the tray, including at narrow widths. Labelled range pickers and inline ellipsis menus need accessible names, not redundant tooltips; keep tooltips on top-level icon actions.
 
-Home and Chat share a centered, border-box reading column (maximum width and inline gutter). Align the resting Home greeting with the Home navigation row using the shell’s shared row origin **inside** the moving content. The unpadded viewport keeps the fade at the window edge. The web opener sits at the expanded sidebar toolbar’s 12px top inset on every route. On Home it scrolls with the page. Electron keeps both controls in its native titlebar. Keep the same shell inset immediately above and below the footer. Major dashboard/sidebar sections are independently spaced at 24px. Responsive layouts can wrap, collapse or split panels; button height, padding and type stay stable.
+Home and Chat share a centered, border-box reading column (maximum width and inline gutter). Align the resting Home greeting with the Home navigation row using the shell’s shared row origin **inside** the moving content. The unpadded viewport keeps the fade at the window edge. The web opener sits at the expanded sidebar toolbar’s 12px top inset on every route. On Home it scrolls with the page. Electron keeps both controls in its native titlebar. Keep the same shell inset immediately above and below the footer. Major dashboard/sidebar sections are independently spaced at 24px. Responsive layouts can wrap, collapse or split panels; button height, padding and type stay stable. Composer draft and placeholder keep the same type role across widths and themes; browser zoom and user text scaling still apply.
 
 Use `ControlRow` for the sidebar, identity controls, panel tabs, recent links, wrapping workspace choices and horizontal destination links. The row owns its 30px height, 8px inset and the placement and hover of a 24px action, including a leading remove button that replaces an existing glyph. Workspace names, the Workspaces launcher and its tab title are text-only. A recent without a glyph keeps its remove action at the end. Keep the link, tab or button semantics on the rendered element, with sibling actions outside it. Whole section headers reveal their chevron on hover; identity controls need none. Ordinary text and icon triggers use `Button` / `IconButton`, including Base UI menu triggers. Pass icons and labels through their slots. Binary switches stay pill-shaped; clicking the selected half of a two-choice segment switches to the other half. Native keyboard choice navigation still selects its destination.
 
@@ -38,6 +38,8 @@ Each chat message owns a continuous hover area from its content through its acti
 
 Interface strokes have one non-scaling optical weight in CSS pixels. Size glyphs relative to the control’s type, capped at the shared icon size. Paint interface strokes with opaque semantic ink so overlapping segments do not darken; branded artwork and chart marks retain their own geometry. Neutral quiet controls gain the hover surface without changing ink. Destructive and primary confirmations change perceived lightness by the same amount within each theme; check rendered colors, not blend percentages. Destructive menu commands turn red on hover or keyboard highlight. A compact × dismisses a tab, recent, draft attachment or recipient with the ordinary quiet IconButton. Callers choose intent, never paint. A selectable menu row gains the same surface and promotes its glyph from secondary to primary ink on hover or active keyboard navigation. Selection, disabled and inverse controls have distinct semantics. Never change stroke thickness, spacing or radius on hover. Render interface glyphs through `Icon`. A unique data graphic may own accessible, labeled SVG and paint its own marks. DOM focus alone adds no paint.
 
+Use [the shared Platform time formatters](lib/time.ts) for displayed ages, clocks, calendar ranges and chart dates. Keep raw instants or ISO calendar days in data. Relative ages use a single reference instant for the surface: now below one minute, whole minutes below an hour, hours below 24 hours, then `1d ago` until 48 hours. After that show an ordinal date, including the year when it differs. Preserve calendar days across time zones. Pass the viewer’s zone for a locally composed message. Fixture time is server-gated and fixed for reproducible rendering. A Home activity chart keeps one visibility setting and one period across modes: Build shows Tasks run and Search shows Searches made. Both draw real dated daily counts; the axis, tooltip and Customize Home label must agree with the selected metric.
+
 ## Public API
 
 - A page supplies data, semantic slots, supported variants and callbacks. It owns no CSS, inline styles, Tailwind classes or visual overrides, including layout around a component. A composition with its own spacing is itself a recipe with an owner. No `className`, `style`, utility pass-through, arbitrary JSX prop spread or per-screen colors/geometry.