@cavuno/board 2.0.5 → 3.0.0

package/skills/cavuno-board-job-alerts/SKILL.md

@@ -1,83 +1,97 @@
 ---
 name: cavuno-board-job-alerts
-description: Build job-alert flows with the @cavuno/board SDK — the anonymous double-opt-in surface (jobAlerts.subscribe/confirm/resendConfirmation + HMAC-token manage/unsubscribe/resubscribe/updatePreference/deletePreference) and the authenticated board.me.alerts CRUD. Covers which surface to use when, how the manage token rides, which filters actually scope delivery, and the full-replace update trap.
+description: Job-alert two-lane model with @cavuno/board. Use for anonymous double opt-in, token-managed preferences, or signed-in alert CRUD.
 ---
 
-# Job alerts: two surfaces
+# Job-alert two-lane model
 
-Two distinct surfaces. **Anonymous** (`board.jobAlerts.*`): email capture with double opt-in; later edits authenticate with an HMAC manage token from the digest email. **Authenticated** (`board.me.alerts.*`): CRUD for a signed-in board user (bearer token), active immediately — the authenticated action is the consent. Both are gated on `board.context()` → `features.jobAlerts`.
+Choose exactly one lane:
 
-## When to use
+- Anonymous visitors use `board.jobAlerts.*`: double opt-in, then an HMAC manage token from email.
+- Signed-in users use `board.me.alerts.*`: bearer-authenticated CRUD, active immediately, with up to 10 alerts per user.
 
-- Anonymous: the "email me new jobs" capture form for visitors, the confirm landing page, and the manage/unsubscribe page linked from digest emails.
-- Authenticated: an alerts section in the signed-in account area (up to 10 alerts per user).
+Both lanes are available only when `board.context()` reports `features.jobAlerts`.
 
-## When not to use
+## Anonymous lane: subscribe and confirm
 
-- Board-user sign-in itself — see `cavuno-board-auth`.
-
-## Out of scope — do not invent exports
-
-Only the methods and fields shown here exist. There is no pause/suspend: deactivation is `unsubscribe` (anonymous) or `remove` (authenticated).
-
-## Anonymous: subscribe → confirm
-
-`subscribe` requires `consent: true` (server-enforced) and sends a confirmation email. `confirm` always returns HTTP 200 — branch on `status`.
+`subscribe` requires consent and deliberately returns the same submitted response for new and existing addresses. `confirm` always resolves; its status owns the landing-page branch.
 
 ```ts snippet
-const sub = await board.jobAlerts.subscribe({
+const submitted = await board.jobAlerts.subscribe({
   email: 'ada@example.com',
   consent: true,
-  frequency: 'weekly', // the only supported cadence
-  filters: { jobFunctions: ['engineering'], remoteOptions: ['remote'], placeSlugs: ['berlin'] },
+  frequency: 'weekly',
+  filters: {
+    jobFunctions: ['engineering'],
+    remoteOptions: ['remote'],
+    placeSlugs: ['berlin'],
+  },
 });
-sub.status;               // always 'submitted' — uniform, never reveals new vs. already-subscribed
 
-// Confirm page — token from the email link:
-const res = await board.jobAlerts.confirm({ token });
-res.status; // 'confirmed' | 'already_confirmed' | 'expired' | 'not_found'
-if (res.status === 'expired') {
-  await board.jobAlerts.resendConfirmation({ email }); // status: always 'submitted'
+const result = await board.jobAlerts.confirm({ token });
+switch (result.status) {
+  case 'confirmed':
+  case 'already_confirmed':
+  case 'not_found':
+    break;
+  case 'expired':
+    await board.jobAlerts.resendConfirmation({ email });
+    break;
 }
 ```
 
-Filter caveat: only `jobFunctions`, `placeSlugs`, and `remoteOptions` scope the digest server-side; `seniorityLevels`/`salaryMin`/`salaryMax`/`salaryCurrency` are stored but do not filter delivery.
+Only `jobFunctions`, `placeSlugs`, and `remoteOptions` filter digest delivery. Seniority and salary fields are stored but do not scope delivery. The supported cadence is `weekly`.
 
-## Anonymous: the HMAC manage token
+## Anonymous lane: manage-token transport
 
-Digest emails carry a per-subscription HMAC token. **`manage` is a GET — the token rides as query params `{ subscription, token }`. All writes are POST/DELETE — the token rides in the JSON body as `{ subscriptionId, token }`** (note the different key: `subscription` on the query, `subscriptionId` in bodies). Each preference in the manage state also carries its own `manageToken`.
+The read and write transports intentionally use different keys:
+
+- `manage` is GET with query `{ subscription, token }`.
+- Writes carry `{ subscriptionId, token }` in their body.
 
 ```ts snippet
-// Manage page, from the email link's query string:
-const state = await board.jobAlerts.manage({ subscription: subscriptionId, token });
-state.email; state.confirmed; state.unsubscribed;
-state.preferences; // [{ id, label, frequency, isActive, filters, manageToken }]
+const state = await board.jobAlerts.manage({
+  subscription: subscriptionId,
+  token,
+});
+state.email;
+state.confirmed;
+state.unsubscribed;
+state.preferences;
 
 await board.jobAlerts.unsubscribe({ subscriptionId, token });
 await board.jobAlerts.resubscribe({ subscriptionId, token });
-await board.jobAlerts.deletePreference({ subscriptionId, preferenceId, token });
+await board.jobAlerts.deletePreference({
+  subscriptionId,
+  preferenceId,
+  token,
+});
 ```
 
-`unsubscribe`/`resubscribe` also accept an optional `preferenceId` to scope to one preference. `updatePreference` is a **full replace** — `frequency` is required every time; restate the filters you aren't editing or they reset:
+`unsubscribe` and `resubscribe` accept an optional `preferenceId`. Each managed preference also includes its own `manageToken`.
+
+`updatePreference` is a full replacement. Round-trip every retained value and always send `frequency`.
 
 ```ts snippet
-const pref = state.preferences[0];
+const preference = state.preferences[0]!;
 await board.jobAlerts.updatePreference({
   subscriptionId,
-  preferenceId: pref.id,
+  preferenceId: preference.id,
   token,
-  frequency: 'weekly',   // required — restate even if unchanged
-  filters: pref.filters, // round-trip stored filters you aren't editing
+  frequency: 'weekly',
+  filters: preference.filters,
 });
 ```
 
-## Authenticated: board.me.alerts
+## Signed-in lane
 
-Bearer-authenticated CRUD. Alerts are active on create (no opt-in email). The `AlertBody` uses `placeIds` (not `placeSlugs`), and `frequency` is required.
+Authenticated alerts use `placeIds`, while anonymous alerts use `placeSlugs`. Create and update accept the same `AlertBody`; update is a full replacement.
 
 ```ts snippet
 const { data: alerts } = await board.me.alerts.list();
-alerts[0].isActive; alerts[0].lastSentAt; alerts[0].filters;
+alerts[0]?.isActive;
+alerts[0]?.lastSentAt;
+alerts[0]?.filters;
 
 const alert = await board.me.alerts.create({
   frequency: 'weekly',
@@ -85,14 +99,8 @@ const alert = await board.me.alerts.create({
   remoteOptions: ['remote'],
 });
 
-await board.me.alerts.remove(alert.id); // 204 → void; the only way to stop an alert
-```
-
-`update` is a PUT with **full-replace semantics** — the body is the same `AlertBody` as create, so round-trip every field you aren't changing:
-
-```ts snippet
-const current = await board.me.alerts.retrieve(alertId);
-await board.me.alerts.update(alertId, {
+const current = await board.me.alerts.retrieve(alert.id);
+await board.me.alerts.update(alert.id, {
   frequency: 'weekly',
   jobFunctions: current.filters.jobFunctions,
   seniorityLevels: current.filters.seniorityLevels,
@@ -102,14 +110,17 @@ await board.me.alerts.update(alertId, {
   salaryMax: current.filters.salaryMax,
   salaryCurrency: current.filters.salaryCurrency,
 });
+
+await board.me.alerts.remove(alert.id);
 ```
 
-## Verify
+Removal is the signed-in lane's stop action; there is no pause state.
+
+## Completion gate
 
-- [ ] Subscribe form sends `consent: true` and shows a uniform "check your email" message on `status: 'submitted'` (never reveals already-subscribed).
-- [ ] Confirm page branches on all four statuses (including `expired` → resend).
-- [ ] Manage page reads `subscription` + `token` from the email link's query string; writes send `subscriptionId` in the body.
-- [ ] Editing one preference field leaves the others intact (full-replace round-trip, both surfaces).
-- [ ] Alert UI only promises filtering on job function / place / remote option.
-- [ ] Alert UI offers weekly cadence only and never sends a legacy daily value.
-- [ ] Alert surfaces are hidden when `features.jobAlerts` is false.
+- The feature flag hides both lanes when disabled.
+- Anonymous subscribe sends `consent: true` and reveals no subscription existence.
+- The confirm UI handles all four statuses, including resend after expiry.
+- Manage reads use `subscription`; manage writes use `subscriptionId`.
+- Editing one field preserves every other field in both full-replace APIs.
+- UI promises only weekly delivery filtered by job function, place, and remote option.

package/skills/cavuno-board-jobs/SKILL.md

@@ -1,58 +1,55 @@
 ---
 name: cavuno-board-jobs
-description: Browse, search, and render jobs with the @cavuno/board SDK — jobs.list, jobs.search, jobs.retrieve, jobs.similar. Covers the slim card vs full job shapes, catalog pagination (count/limit/offset + opaque cursor), filters, and the candidate-paywall gatedCount.
+description: Job catalog reads with @cavuno/board. Use for job browse or search, job detail, similar jobs, candidate gating, or full-catalog iteration.
 ---
 
-# Jobs: browse, search, detail
+# Jobs
 
-The highest-traffic surface. Listing and search return slim `PublicJobCard`s; the detail endpoint returns the full `PublicJob`.
+Use cards for collections and the full job for detail: `jobs.list`,
+`jobs.search`, and `jobs.similar` return `PublicJobCard`; only
+`jobs.retrieve` returns `PublicJob`.
 
-## When to use
+Company-scoped collections use `companies.listJobs`. The ungated embeddable
+widget uses `embed.jobs`.
 
-- Listing/search/keyword/location pages.
-- The job-detail page and its "similar jobs" rail.
+## Browse and paginate
 
-## When not to use
+`jobs.list(query)` returns `JobCardListEnvelope`: `data`, `count`, `limit`,
+`offset`, `hasMore`, `nextCursor`, optional `relatedSearches`, and optional
+`gatedCount`.
 
-- Company-scoped listings — use `companies.listJobs` (same card shape).
-- The ungated embeddable widget — use `embed.jobs`.
-
-## List and render cards
-
-`jobs.list` returns a `JobCardListEnvelope`: catalog pagination fields plus `data: PublicJobCard[]` and optional `relatedSearches`.
+`JobsListQuery` accepts `limit` (1–100), `cursor`, `offset`, `companyId`,
+`companySlug`, `remoteOption`, `employmentType`, `seniority`, `location` with
+`radius` in kilometres, `category`, and `skill`. Repeated `seniority` values
+are OR-matched. `offset` takes precedence over `cursor`, so choose one paging
+mode per request.
 
 ```ts snippet
-const page = await board.jobs.list({ limit: 20, seniority: ['senior', 'lead'] });
-page.count;        // total matches ("X jobs")
-page.hasMore;      // more pages exist
-page.nextCursor;   // opaque forward token, or null
-for (const card of page.data) {
+const first = await board.jobs.list({
+  limit: 20,
+  seniority: ['senior', 'lead'],
+});
+const second = first.nextCursor
+  ? await board.jobs.list({ limit: 20, cursor: first.nextCursor })
+  : null;
+const page3 = await board.jobs.list({ limit: 20, offset: 40 });
+
+for (const card of first.data) {
   card.title;
   card.company?.name;
-  card.links.public; // canonical /companies/:companySlug/jobs/:jobSlug
+  card.links.public;
 }
 ```
 
-### Filters and pagination
-
-`JobsListQuery` supports `limit` (1–100), `offset` (takes precedence over `cursor`), `cursor`, and filters: `companyId`, `companySlug`, `remoteOption`, `employmentType`, `seniority` (single or repeated → OR-matched), `location` + `radius` (km), `category`, `skill`. Paginate by passing back `nextCursor`, or use numbered pages with `offset`:
+Render `links.public` as the canonical
+`/companies/:companySlug/jobs/:jobSlug` URL.
 
-```ts snippet
-const p1 = await board.jobs.list({ limit: 20 });
-const p2 = p1.nextCursor
-  ? await board.jobs.list({ limit: 20, cursor: p1.nextCursor })
-  : null;
-// or numbered pages:
-const page3 = await board.jobs.list({ limit: 20, offset: 40 });
-```
+### Filter companies by public slug
 
-### Company filter via public slug
-
-`companySlug` is the public URL identity (what listing URLs carry). Prefer it
-over `companyId` in frontends — the API resolves slugs server-side. Unknown
-slugs are **ignored** (they contribute no matches, not an error); an entirely
-unknown set yields an empty result list with `count: 0`. Combined with
-`companyId` as a union when both are set. Cap is 10 values.
+Frontend URLs carry `companySlug`; pass it directly to the API. Unknown slugs
+contribute no matches, and a wholly unknown set returns `count: 0` with empty
+`data`. When `companyId` and `companySlug` are both present, their matches form
+a union. Each accepts at most 10 values.
 
 ```ts snippet
 const page = await board.jobs.list({
@@ -63,7 +60,9 @@ const page = await board.jobs.list({
 
 ## Search
 
-`jobs.search` posts a `JobsSearchBody` (free-text `query` + structured `filters`) and returns a `JobCardSearchEnvelope`. The same `companySlug` rule applies under `filters`:
+`jobs.search` posts `JobsSearchBody`: free-text `query`, structured `filters`,
+and pagination. It returns `JobCardSearchEnvelope`; `companySlug` has the same
+semantics inside `filters`.
 
 ```ts snippet
 const results = await board.jobs.search({
@@ -78,32 +77,35 @@ const results = await board.jobs.search({
 });
 ```
 
-## Detail and similar
+## Render detail and similar jobs
 
 ```ts snippet
-const job = await board.jobs.retrieve('senior-chef'); // full PublicJob
-job.description;       // HTML
+const job = await board.jobs.retrieve('senior-chef');
+job.description; // HTML
 job.officeLocations;
 job.company?.slug;
+
 const rail = await board.jobs.similar('senior-chef', { limit: 5 });
 ```
 
-## The candidate paywall: gatedCount
+## Surface candidate gating
 
-On gated boards, some results are hidden from anonymous/unentitled viewers. `gatedCount` is how many were withheld for the current viewer (absent/0 when entitled). Surface it as an upsell rather than pretending the list is complete:
+On a gated board, `gatedCount` reports results withheld from the current
+viewer. Render it as an upsell. The same optional-auth endpoint returns the
+entitled view when called with that board user's bearer token.
 
 ```ts snippet
 const page = await board.jobs.list({ limit: 20 });
-if (page.gatedCount && page.gatedCount > 0) {
-  // e.g. "Sign in to see N more roles"
+if ((page.gatedCount ?? 0) > 0) {
+  // Render “Sign in to see N more roles”.
 }
 ```
 
-A board-user bearer token on the same call returns the entitled (ungated) view — the endpoint is optional-auth, one URL for both anonymous and personalized reads.
+## Walk the full catalog
 
-## Full-catalog walks: paginate()
-
-For sitemaps, feeds, or exports, never hand-roll the cursor loop — `paginate()` iterates items (or raw pages via `.pages()`) until `hasMore` is false, and drops `offset` after the first page (offset would win over the cursor and re-serve the same page forever):
+Use `paginate()` for sitemaps, feeds, and exports. It advances the opaque
+cursor until `hasMore` is false and removes `offset` after the first request;
+retaining the offset would make it win over the cursor and repeat a page.
 
 ```ts snippet
 import { paginate } from '@cavuno/board';
@@ -114,11 +116,17 @@ for await (const card of paginate(board.jobs.list, { limit: 100 })) {
 const first500 = await paginate(board.jobs.list).toArray({ limit: 500 });
 ```
 
-Iteration order is stable only under an explicit sort/search — a churning board reorders default browse results between pages.
+Default browse order can move while a board changes. Supply an explicit sort
+or search whenever iteration order must stay stable.
+
+## Completion gate
 
-## Checklist
+Finish only after every applicable check passes:
 
-- [ ] Listing/search use `PublicJobCard`; detail uses `PublicJob`.
-- [ ] Job links use `links.public` (canonical `/companies/:companySlug/jobs/:jobSlug`).
-- [ ] Pagination via `nextCursor` or `offset`, not client-side slicing.
-- [ ] `gatedCount` surfaced as an upsell, not hidden.
+- Collections render `PublicJobCard`; detail renders `PublicJob`.
+- Every job link comes from `links.public`.
+- Pagination returns the final page once and ends with `nextCursor: null`.
+- A gated anonymous response renders its `gatedCount` upsell, while an
+  entitled request renders the ungated view.
+- Full-catalog code uses `paginate()` and any order-sensitive walk has an
+  explicit sort or search.

package/skills/cavuno-board-messaging/SKILL.md

@@ -1,86 +1,77 @@
 ---
 name: cavuno-board-messaging
-description: Build the board-user messaging inbox with the @cavuno/board SDK — me.conversations (list, unreadCount, retrieve, listMessages, start, reply, markRead, archive), me.messages (edit, unsend, report), me.blocks. Covers the polled-REST contract (no realtime transport in v1), visibility-aware polling, the unread badge, and read receipts.
+description: Polled messaging contract with @cavuno/board. Use for inboxes, unread badges, threads, read receipts, message moderation, or user blocks.
 ---
 
-# Messaging: the polled inbox
+# Polled messaging contract
 
-Employer↔candidate direct messaging for signed-in board users. The v1 transport is **polled REST by design** — there is no realtime primitive; near-live UX comes from re-fetching on an interval (3–5s is the reference cadence).
+Messaging is authenticated employer-to-candidate REST. Near-live behavior comes from polling at a 3–5 second cadence while the page is visible. `list`, `listMessages`, and `unreadCount` are the transport; the SDK exposes no realtime subscription.
 
-Out of scope — do not invent exports: no websockets, no SSE, no `subscribe`/`onMessage` — polling `list` / `listMessages` / `unreadCount` IS the contract.
+## Keep the poll visible
 
-## When to use
-
-- The inbox page, unread badge, thread view, and composer.
-- Edit/unsend, report-a-message, and block flows.
-
-## When not to use
-
-- Anonymous visitors — every method here requires a signed-in board user (see `cavuno-board-auth`).
-- Job applications themselves — messaging an applicant *starts from* an application, but the application surface is `board.me.applications.*`.
-
-## Poll while visible
-
-Poll only while the tab is visible — stop on hide, resume (with an immediate refresh) on show:
+Refresh immediately on start or return to the tab, and maintain at most one timer.
 
 ```ts snippet
-const POLL_MS = 4000; // 3–5s reference cadence
+const pollMs = 4000;
 
-async function refresh() {
+async function refreshInbox() {
   const [{ count }, inbox] = await Promise.all([
-    board.me.conversations.unreadCount(), // distinct unread threads → badge
+    board.me.conversations.unreadCount(),
     board.me.conversations.list({ limit: 20 }),
   ]);
-  render(count, inbox.data);
+  renderInbox(count, inbox.data);
 }
 
 let timer: ReturnType<typeof setInterval> | undefined;
-function start() {
-  void refresh();
-  timer ??= setInterval(refresh, POLL_MS);
+function startPolling() {
+  void refreshInbox();
+  timer ??= setInterval(refreshInbox, pollMs);
 }
-function stop() {
-  clearInterval(timer);
+function stopPolling() {
+  if (timer) clearInterval(timer);
   timer = undefined;
 }
+
 document.addEventListener('visibilitychange', () => {
-  document.visibilityState === 'visible' ? start() : stop();
+  if (document.visibilityState === 'visible') startPolling();
+  else stopPolling();
 });
-start();
+startPolling();
 ```
 
-Each inbox row is a `Conversation`: `lastMessageAt`, `lastMessageSnippet`, `hasUnread`, and a live-resolved `counterparty` (`displayName`, `avatarUrl`, `companyName`, `handle`). `list({ archived: true })` is the archived view; `archive`/`unarchive` move a thread per-side and are idempotent.
+Inbox rows include `lastMessageAt`, `lastMessageSnippet`, `hasUnread`, and the live-resolved `counterparty` with `displayName`, `avatarUrl`, `companyName`, and `handle`. `list({ archived: true })` reads the archived view; `archive` and `unarchive` are idempotent and per-side.
 
-## The thread: header, messages, read receipts
+## Render a thread faithfully
 
-The header and the messages are separate calls. Messages come oldest-first; unsent messages are tombstones (empty `body`, `deletedAt` set) — render a placeholder, don't filter them out.
+Header and messages are separate reads. Messages arrive oldest-first. An unsent message is a tombstone with empty `body` and non-null `deletedAt`; preserve its position with a placeholder.
 
 ```ts snippet
-const convo = await board.me.conversations.retrieve(conversationId);
-convo.viewerRole;              // 'employer' | 'candidate'
-convo.viewerLastReadMessageId; // my last-read pointer (null = never)
-
+const conversation = await board.me.conversations.retrieve(conversationId);
 const { data: messages } = await board.me.conversations.listMessages(
   conversationId,
   { limit: 50 });
-for (const m of messages) {
-  m.body;     // '' when unsent (tombstone)
-  m.readAt;   // read receipt — when the recipient read it, or null
-  m.editedAt; // non-null after an edit
+
+conversation.viewerRole;
+conversation.viewerLastReadMessageId;
+
+for (const message of messages) {
+  message.body;
+  message.deletedAt;
+  message.readAt;
+  message.editedAt;
 }
 
-await board.me.conversations.markRead(conversationId); // idempotent
+await board.me.conversations.markRead(conversationId);
 ```
 
-Call `markRead` when the viewer opens the thread — it clears `hasUnread` and drives the counterparty's `readAt` receipts.
+Call `markRead` when the viewer opens the thread. It clears their unread state and advances read receipts for the counterparty.
 
-## Sending
+## Send
 
-`start` cold-initiates a candidate (employer-only) and converges on the existing thread; `startAboutApplication` messages an applicant in application context; `reply` continues a thread. Each returns the created `Message`.
+`findExisting` routes to an existing thread. Employer-only `start` cold-initiates a candidate; `startAboutApplication` begins in application context; `reply` continues a thread. Each send returns a `Message`.
 
 ```ts snippet
-// Route to an existing thread instead of opening a composer:
-const { conversationId } = await board.me.conversations.findExisting({
+const existing = await board.me.conversations.findExisting({
   candidateBoardUserId,
 });
 
@@ -93,28 +84,31 @@ await board.me.conversations.reply(first.conversationId, {
 });
 ```
 
-Sends are gated server-side (messaging enabled, cold-message rule, per-pair daily limits, blocks) — failures arrive as `messaging_*` `BoardApiError` codes; branch with the guards from `cavuno-board-errors`.
+The server enforces messaging enablement, cold-message rules, pair limits, and blocks. Handle `messaging_*` `BoardApiError` codes with `cavuno-board-errors`.
 
-## Edit, unsend, report, block
+## Edit, moderate, and block
 
-Your own messages can be edited or unsent within a 15-minute window. Reporting a message addressed to you auto-blocks its author.
+Own-message edits and unsends have a 15-minute window. Unsend is idempotent and creates a tombstone. Reporting a message addressed to the viewer automatically blocks its author.
 
 ```ts snippet
-await board.me.messages.edit(messageId, { body: 'fixed typo' });
-await board.me.messages.unsend(messageId); // tombstones; idempotent
+await board.me.messages.edit(messageId, { body: 'Fixed typo' });
+await board.me.messages.unsend(messageId);
 
-const { blocked } = await board.me.messages.report(messageId, {
-  reason: 'spam', // 'spam' | 'harassment' | 'misrepresentation' | 'other'
+const report = await board.me.messages.report(messageId, {
+  reason: 'spam',
 });
 
-await board.me.blocks.create({ boardUserId }); // silent; idempotent
+await board.me.blocks.create({ boardUserId });
+const blocked = await board.me.blocks.status(boardUserId);
+await board.me.blocks.remove(boardUserId);
 ```
 
-`board.me.blocks.list()` / `.remove(boardUserId)` / `.status(boardUserId)` round out blocking.
+Report reasons are `'spam' | 'harassment' | 'misrepresentation' | 'other'`. `board.me.blocks.list()` enumerates blocks.
 
-## Verify
+## Completion gate
 
-- [ ] Kill the network tab timer: polling stops when the tab is hidden, resumes on focus with a fresh read.
-- [ ] Send from a second account: the badge (`unreadCount().count`) and `hasUnread` flip within one poll interval.
-- [ ] Open the thread: `markRead` fires once and the sender sees `readAt` populate on their next poll.
-- [ ] Unsend a message: it renders as a tombstone (empty `body`), not a gap.
+- Hiding the tab stops the timer; returning starts one timer and refreshes immediately.
+- A second account's message updates `unreadCount().count` and `hasUnread` within one interval.
+- Opening a thread calls `markRead`; the sender later sees `readAt`.
+- Unsend renders a tombstone in place.
+- Messaging policy errors produce deliberate UI states rather than a generic success path.