# CEO Dashboard (Manage) **Portal:** Manage · **Suite:** `ceo` (its own sidebar) · **Routes:** `manage.ceo.*` · **Nav:** Action Items (tabs: Action Items · WhatsApp Groups · Inbox) · Email · Connection · **Permission:** `view-ceo-dashboard` > **Reached by URL only — `/manage/ceo`.** There is deliberately no tile on the Hub chooser and no > entry in the Hub's menu. That page asks "which part of the business are you working on?", and an > answer that is somebody's own phone does not belong among the suites. Once you are on the path, > `useSuite`'s `OWNED_PATHS` resolves the `ceo` suite and its own sidebar takes over, so the section > behaves like any other from that point on. (Same choice as the > [Operations dashboard](/docs/modules_handbook/manage/operations/readMe.md), for the same reason.) ## What it does An admin links **their own WhatsApp number** by scanning a QR code, and then reads their chats here — every one-to-one and every group — on a page only they can open. Once a day (and on demand) an AI reads what arrived and produces two things: **what happened**, chat by chat, and **what they now have to do**, as a list they can work. It exists because the person running the business has the most important conversations on a phone nobody else can see, and no amount of CRM discipline reaches them. This does not try to move those conversations into the CRM. It reads them where they are. > **This is not the shared inbox, and it is not a second one.** A number linked here is `purpose = PURPOSE_CEO`: invisible to the Messages inbox, to the Channels page, to broadcasts, funnels, payment automations and every report — and **automated by nothing**. The AI reply engine, the flow engine, the STOP/opt-out handler and the lead linker all stand down. Nothing is ever sent from the number unless its owner types it. > **Unlinking deletes the chats.** `disconnect` hard-deletes the channel and everything captured through it (conversations, messages, attachments, stored media). The dashboard reads somebody's private WhatsApp, so "stop" has to mean the data is gone rather than hidden. The phone itself is untouched. ## How it works ### Email workspace **Nav:** Email → Inbox · Provider setup. Entry: `/manage/ceo/email?suite=ceo`. Gmail and Outlook connect through read-only OAuth (state, PKCE, ten-minute, single-use session). The existing callbacks remain `/manage/email/connect/{gmail|outlook}/callback`; the initiating session carries the owner, purpose and suite. The callback rechecks the workspace permission and returns CEO connections to `manage.ceo.email.index` with `suite=ceo`. Callback query parameters cannot change mailbox ownership or workspace. `EmailMailbox.purpose` is `ceo` for these connections and `operations` for all existing mailboxes. Every inbox, message, refresh and disconnect query scopes both owner and purpose. Operations campaign mailbox selection excludes CEO mailboxes, including for the owner and super admins. The same physical account can be independently authorized in both workspaces without reclassifying history. The page reuses `Manage/Email/InboxContent.vue` with CEO endpoints. Bodies render as escaped text. Existing bounded imports read the first 30 days and then use a five-minute overlap. The scheduler is unchanged; sync jobs check the owner's current CEO permission, active status and Manage role before contacting providers. Connect and refresh queue only reads. CEO Email has no send or campaign action. Disconnect clears tokens and retains already imported messages privately, as stated in the confirmation. Provider setup at `/manage/ceo/email/settings` also requires `manage-email-settings`. It includes Google Cloud/Entra registration steps, canonical callback URLs and encrypted client credential fields. App credentials are shared with Operations; mailbox content is separate. Secrets are excluded from page props, validation flash data and request logs. Blank secret fields preserve saved values. The user must create the provider registrations and approve each account; mocked tests do not establish a live mailbox grant. Related backend: `Manage/Email/EmailController`, `Manage/Ceo/CeoEmailController`, `CeoEmailSettingsController`, `Email/InboxQueryRequest`, `ProviderSettingsRequest`, `EmailMailboxRepository`, `EmailProviderSettingsRepository`, `EmailMailbox`, `SyncMailbox`, `MailboxProvider`, and `routes/{web,email}.php`. Related frontend: `Manage/Ceo/{Email,EmailSettings,EmailShell}.vue`, `Manage/Email/{Inbox,InboxContent,EmailPagination}.vue`, `SectionTabs`, `ManageLayout` and `useSuite`. Migration: `2026_09_16_190000_add_purpose_to_email_mailboxes.php`. Tests: `tests/Feature/Email/EmailChannelTest.php`, with isolated SQLite fixtures; MySQL migration and browser checks are recorded in the deployment report. ### The number There is no new "assistant" table: a CEO Dashboard number **is** a `whatsapp_channels` row, Bridge-provided like any QR channel, marked `purpose = WhatsappChannel::PURPOSE_CEO` and owned by the admin who scanned it (`user_id`). [`CeoChannelResolver`](/src/Ceo/Services/CeoChannelResolver.php) resolves "my number" from the signed-in user — ownership is part of the lookup, never a check bolted on after it, so no endpoint here takes a channel id at all. Everything else about it is the ordinary Bridge machinery documented in the [WhatsApp handbook](/docs/modules_handbook/manage/messages/whatsapp/readMe.md) and [wa-bridge/README.md](/wa-bridge/README.md): the same `wa-bridge` Node sidecar, the same QR → `history.set` full backfill on a fresh link, the same minute-by-minute heartbeat (`whatsapp:ping-bridge`), the same webhook ingest. The **Scan-QR modal is literally the same Vue component** as the Channels page's — it grew `qrUrl` / `stateUrl` props so it can be pointed at endpoints that carry no id. ### The isolation — six places, one flag `purpose` is checked wherever a channel could otherwise leak into shared surface. Each of these was a real hole, not a hypothetical: 1. **[ProcessInboundWhatsAppWebhook](/app/Jobs/Whatsapp/ProcessInboundWhatsAppWebhook.php)** — a CEO channel's inbound message is stored (with media), then `continue`s **before** the `NewWhatsAppMessage` broadcast and before `considerOptOut` / `considerLinkContact` / `considerNotify` / `considerCtaCapture` / `considerFlow` / `considerAiReply`. The broadcast matters as much as the engines: `whatsapp.inbox` is authorised for every inbox admin, so pushing a private message onto it would show a colleague the owner's chats. Group messages take the same branch inside `recordGroupMessage`. 2. **Defence in depth** — `considerAiReply`, `considerLinkContact`, `considerOptOut` and [GenerateAiReply](/app/Jobs/Whatsapp/GenerateAiReply.php) each early-return on a CEO channel independently, the same shape the group capture-only rule uses. 3. **[LeadVisibility::allowsConversation](/src/Auth/Support/LeadVisibility.php)** — returns **false** for a CEO thread for *everyone*, including a full-access admin and including the owner (who reads it on their own dashboard instead). This is the single chokepoint behind every shared-inbox action — open, mark read, reply, react, edit, delete — so a bookmarked or guessed conversation uuid can never reach one. 4. **[AccountVisibility::allowsWhatsappChannel](/src/Auth/Support/AccountVisibility.php)** — returns **false** for a CEO channel, which is the single check behind the shared Channels pages (show / rename / delete / QR / state / history-sync). 5. **Every channel list and picker** excludes `PURPOSE_CEO` explicitly: the Messages inbox (list, deep link, channel prop), the Channels index + its counts, the Messages dashboard, Operations, the Appointment Engine's host options, Funnels ×3, Broadcasts, Facebook projects, the AI Agent page's health counts, the unassigned-AI-profile nag, and `ChaseFollowUps` (whose bare `first()` would otherwise have chased a customer from the owner's personal number). 6. **The lead linkers** — [LinkChannelContacts](/app/Jobs/Whatsapp/LinkChannelContacts.php) still does its history-sync settle bookkeeping for a CEO channel (so the page's "copying your past chats" state stays honest) but links **no** contacts and writes **no** sync report; the hourly `whatsapp:link-contacts --existing-only` sweep skips contacts known only from a CEO number; and [LeadConversationPresenter](/src/Whatsapp/Support/LeadConversationPresenter.php) excludes them so a contact deduped by phone across both numbers cannot hang the owner's private thread off a lead's page. Locked by [CeoDashboardTest](/tests/Feature/Ceo/CeoDashboardTest.php), which proves the OUTCOME (nothing queued, no lead, no consent row, refused to a super admin, absent from the shared inbox) rather than any one guard. ### Two things that make an inbox silently empty Both were hit on the first real link, and both look identical from the page: a healthy, connected number with no chats. - **The webhook must point at THIS app.** `CeoController::webhookUrl()` registers the instance against `APP_URL`, honouring `BRIDGE_WEBHOOK_URL` **only when it names the same host**. That override exists to reach the same Laravel at a different address (local dev, where `APP_URL` is an https `.test` host Node's fetch rejects); on this box it had been pointed at a different production SITE, so the first number linked here delivered its whole history sync there. The receiving app looks the channel up by `provider_ref`, finds nothing and drops every message — nothing errors, nothing retries, the bridge's DLQ stays empty. A diverging host is now ignored with a `warning` log rather than silently obeyed. - **History only arrives on a FRESH link, so "Re-scan" alone cannot fetch it.** WhatsApp pushes a chat's past exactly once, at link time, and a still-valid session resumes instead of re-pairing — so showing a QR to a connected number changes nothing. `POST ceo/resync` logs the phone out first (`BridgeGateway::logout`, which until then had no caller anywhere in the app) and then hands back a QR; the button on the Connection page says **Re-sync my chats** for a connected number and **Scan QR** for a disconnected one. Captured messages are kept — ingest de-duplicates on `provider_message_id`, so a second backfill fills gaps and repeats nothing. The page also says this in words wherever the chat count is zero, so a row of zeros reads as "re-sync" rather than "broken". ### The inbox [CeoInboxController](/app/Http/Controllers/Manage/Ceo/CeoInboxController.php) + [Inbox.vue](/resources/js/Pages/Manage/Ceo/Inbox.vue). **The thread is built to look like WhatsApp Web; the chat list is built to look like the rest of Manage.** That split is deliberate and was the owner's call: a conversation is a conversation, so the thread follows the app people already know, but the left column is a *navigation list*, and at WhatsApp's 16px/14px scale it shouted next to every other list in the portal. It now uses the shared inbox's own sizing — 44px avatars, 14px names, 12px previews, the same search field, select and chips. **The thread, on purpose:** The person reading this is reading their OWN chats — they already know where everything is on the real thing, and every difference is something they have to relearn to do what they do all day. So: the two-tone chrome (`#f0f2f5` bars, white panes) flush inside one bordered frame, the 49px avatars with the divider starting after them, the pill filters, the wallpapered thread, green `#d9fdd3` outgoing bubbles against white incoming ones at 7.5px radius, the tail drawn only on the FIRST bubble of a run from one speaker, the time and ticks tucked INSIDE the bubble (with the last line of text reserving room for them), blue `#53bdeb` read ticks, Today/Yesterday date pills, and the green send button. Two deliberate departures: a **third column** for the AI reading — the reason this exists rather than a browser tab on web.whatsapp.com — and **no CRM furniture**. Below `xl` the panel has nowhere to sit, so the thread header carries a toggle that opens it underneath; below `md` the list and thread take turns, as they do on a phone. The wallpaper is **our own drawing** ([public/main/images/chat-pattern.svg](/public/main/images/chat-pattern.svg)), not WhatsApp's tile: the look is theirs to inspire, the artwork is not ours to copy. It is scoped by **channel**, not by lead visibility — every thread belongs to one person, so `channel_id = my channel` is the only scope there is. Groups are listed exactly like people: on a personal phone the groups are usually where the work is. What is deliberately absent: tags, assignment, AI drafts, flow controls, templates, "convert to lead". Those work a *customer* conversation. Replying is one plain text message at a time through the shared `SendWhatsAppMessage` job (which resolves a group JID for a group thread) — there is no bulk path, because anything that made it easy to send many messages from an unofficial connection would be a ban risk with no upside. Messages render through the shared [`MessagePresenter::inbox`](/src/Whatsapp/Support/MessagePresenter.php), so bubbles, statuses, attachments, group sender labels and revoked/edited markers behave exactly as they do in the team inbox. **Group @mentions read as names, not as digits.** A mention inside a WhatsApp group arrives as a raw LID — `@49263392329973` — because WhatsApp's privacy identity no longer puts a phone number in the message. On a personal phone whose most valuable chats are groups, that is most of what the owner reads: 704 of this channel's group messages carry one, naming 22 distinct people. The shared [`MentionResolver`](/src/Whatsapp/Support/MentionResolver.php) decodes them (contacts → group members → the number), the bubble paints the name over the token via `MessageText.vue`, and the chat-list preview is decoded server-side. **The AI reads the decoded text too** — `GenerateCeoDigest`, `GenerateCeoGroupBrief` and `GenerateCeoChatInsight` all build their transcript lines through `MentionResolver::render()`, because a model cannot look a LID up and a brief written over undecoded text raises follow-ups that name nobody. The full contract is in the [WhatsApp module doc](/docs/modules_handbook/manage/messages/whatsapp/readMe.md) — including why `body` itself is never rewritten. ### The WhatsApp Groups tab — is everything read, and what did it raise? [CeoGroupsController](/app/Http/Controllers/Manage/Ceo/CeoGroupsController.php) + [Groups.vue](/resources/js/Pages/Manage/Ceo/Groups.vue) · `GET ceo/groups` · the **second tab** of the module's one strip (`SectionTabs` section `ceo`: Action Items · WhatsApp Groups · Inbox). The inbox answers "what is new?". This answers "has everything my groups said been READ, and what did it put on my plate?" One row per group on the owner's phone: - **Last message** — the newest `whatsapp_messages.created_at` in the group: for a live message, when it arrived here, which answers whether the phone is still feeding the system. Backfilled history keeps its ORIGINAL time, so a history push does not make a quiet group look busy. - **AI last read** — the group's `ceo_group_cursors.last_analysed_at`, and how many messages are **not read yet**. That count follows the briefing's OWN rule (past the cursor by id, or inside `CeoGroupBrief::FIRST_RUN_HOURS` for a group never read), so "Up to date" can never describe messages the next run will read, and "not read" never describes ones it will skip. Because it follows the id, a history push shows up here: on 2026-09-16 a group read at 02:58 showed 46 unread messages that were all `is_historical` rows from 4–5 Sep, landed after the read — old by the clock, unread by the AI, and read on the next run. - **New · unassigned**, by priority — open items nobody has been handed. It is the owner's triage pile, and it empties as they assign. **Open** is everything not closed. **The group drawer carries the room's own conversation.** Above the relevance ruling sits the last `CONVERSATION_MESSAGES` (40) of that group, rendered read-only through the shared [`ConversationThread`](/resources/js/Components/Conversation/ConversationThread.vue) and the same `MessagePresenter` shape the inbox uses — so bubbles, attachments, sender labels and decoded `@mentions` all read identically. It is above the ruling deliberately: deciding whether a room is worth reading is a judgement about its content, and sending the reader to the inbox and back to make it loses the list they were working. Read-only by design — **Open the chat** goes to the real thread to reply. A CATEGORY drawer spans many rooms, so it carries no `messages` key at all. **By group | By category** is a pivot of the page (a segmented control, not a tab). A group opens a drawer with its items sectioned by category; a category opens one with its items and the group each came from. `?view=`, `?group=`, `?category=` and `?state=open|closed` all live in the URL, so a drawer survives a refresh. Everything on the tab is scoped to GROUP conversations, so the category totals are exactly the sum of the rows — items raised from one-to-one chats live on Action Items. **Sync & analyze all** is the group briefing on demand (`POST ceo/actions/brief`). There is nothing to pull: messages arrive live over the Bridge while the phone is connected, and the bridge has no fetch-newer call. What the button does is read everything past each cursor and file what it finds. A room whose new messages carry nothing readable (a revoked message, a sticker) now has its cursor advanced anyway. Before, the briefing skipped the room without moving it, and the tab would have shown those messages "not read" forever. **Not every group is worth reading — mark the rest irrelevant.** A personal phone is not a work account: beside the rooms where the business happens sit a family chat, a condo group, a school thread. Reading them costs more than tokens, and that is the part worth knowing: the briefing is capped at `MAX_BATCHES` calls and sorts rooms **busiest-first**, so the chattiest irrelevant room does not merely add noise — it **evicts a real one from the run**, and that room's cursor does not advance. The ruling lives in the **group drawer** rather than on the row, because the drawer is where the owner can see what the room actually holds (and reach the chat itself) before deciding. `PUT ceo/groups/{id}` → `CeoGroupBriefRepository::setGroupIgnored` → one row per owner + conversation in **`ceo_group_settings`**. - **Ignored means not READ**, not merely "raises no items": `GenerateCeoGroupBrief::collectRooms` checks the list before it reads a single message, so an ignored room produces no briefing line and no action items. Items it raised before it was silenced are kept — they were real when they were made. - **The default is watched, and that direction is the safe one.** A room nobody has ruled on is covered, so nothing has to be opted in. The opposite default would mean a genuinely important new group raising nothing, with no sign on screen that it had been skipped. - **An ignored room's cursor still moves**, through `skipCursor` — which deliberately leaves `last_analysed_at` and `runs` alone. Without the move, the room would build an unbounded backlog and the day the owner changed their mind the next capped run would try to swallow all of it (the failure `FIRST_RUN_HOURS` exists to prevent). Without the *omission*, the tab would print "AI last read: just now" about a room the model never saw — a lie on the one page whose whole job is answering that question. - **An ignored room SINKS to the bottom of the list**, whatever column is being sorted. This is not cosmetic: a room is usually ignored *because* it is the chattiest on the phone, so the default "newest message first" would put the one the owner just switched off straight back at the top. The single exception is sorting by the **AI reads it** column itself — that is the owner asking to review what they have silenced, so it must be able to bring them up (one click; it defaults to descending). - The tab reads the same list (`CeoGroupSetting::ignoredConversationIds`) the job does, so the page can never promise coverage the run will not deliver. An ignored row reports **0 pending** (nothing is waiting to be read), greys out, and its "AI last read" shows `—`. The headline count stays **all** groups — the label says "on this phone" — with `N ignored` underneath. ### Nav — one entry, one strip (2026-09-16) The sidebar carries **one** CEO entry, ***WhatsApp*** (renamed from *Action Items* 2026-09-16 — the entry names the MODULE, the strip names the page), landing on `/manage/ceo/actions`; `/manage/ceo` redirects there too. Everything else is the strip on the page: **Action Items · WhatsApp Groups · Inbox** (`SectionTabs` section `ceo`, renamed from `ceo-inbox` when Action Items joined it). Action Items and Inbox were two sidebar entries until then — one module reached two ways, which §15 exists to prevent, and it put the ANSWER (the to-do list) a click further away than the evidence it came from. The order is the order the work happens: what is on your plate → which room it came from → the raw chats underneath. The entry's `prefixes` must list **all three** paths, or the nav goes dark while the reader stands on two of its own pages. ### The card — what to read first [ActionItemCard.vue](/resources/js/Pages/Manage/Ceo/Partials/ActionItemCard.vue), shared by Action Items and the Groups drawer. The first version gave the priority chip, the category picker, the title, the quote and the source **the same visual weight**, and the owner's verdict was that they could not tell what to look at. It now answers four questions in the order anyone asks them: 1. **How urgent?** — a colour rail down the left edge. Same place on every card, readable scanning a column, costs no reading. The *word* sits in the controls row, so the card has one loud thing rather than three. 2. **What do I do?** — the title, the largest thing on the card, with the AI's one-line reasoning under it. 3. **Who said so?** — the evidence, as the WhatsApp exchange it came from: the room across the top, the speaker and time above the line, the line in a bubble (green when the owner said it). This was 12px grey italic — the opposite of its importance, since it is the only part a reader can CHECK. 4. **Who owns it, by when?** — the controls, under a divider, so editing never competes with reading. **The evidence is resolved, not reconstructed.** `ceo_action_items.quote_message_id` points at the actual message, matched at raise time by `CeoActionItem::messageIdForQuote` and backfilled by **`ceo:link-quotes`** (51 of 55 existing items on this install). Matching is on the quote's FIRST SENTENCE, then — only if that fails and the quote carries an `@mention` — against the DECODED bodies of the room's recent messages, because the transcript the model quotes has mentions rendered as names (`@Lee Jie`) while the stored body still holds the raw LID. A quote shorter than `QUOTE_KEY_MIN` (20 chars, e.g. *"Record in system"*) resolves to **null on purpose**: it cannot identify one message, and a wrong sender under a task is worse than no sender. The card then shows the quote with no speaker. The whole message body is deliberately never shipped — it runs past a thousand characters in a busy room and says nothing the quote does not. ### Draft the nudge, then send it — `POST ceo/actions/{id}/draft` + `/nudge` The dashboard used to stop one step short of useful: it said what was owed and by whom, then left the founder to open WhatsApp, find the person and write the message — which is the part that does not happen at 11pm. Now **Draft a message** on the card writes it ([`NudgesCeoActionItems`](/app/Http/Controllers/Concerns/NudgesCeoActionItems.php) + [`resources/prompts/ceo_item_nudge.md`](/resources/prompts/ceo_item_nudge.md)), the owner edits a word in the composer, and **Send** delivers it from their own number. - **WHO IT GOES TO IS ITS OWN QUESTION — not the assignee.** The first version conflated the two and got the commonest case exactly backwards: *"Remind Zen on commission collection"* sits in the **Wai Kit Self Reminder** room, so it is the FOUNDER'S item, and the draft dutifully wrote him a note to himself about chasing Zen. The message he wanted was **to Zen**, asking how the collection is going. So the recipient resolves as: an explicit pick in the composer → **the teammate the task NAMES** (`personNamedIn` scans the title and quote, longest name first so "Mei Xin" is not beaten by "Mei", word-bounded so "Zen" never matches inside "Zendesk") → whoever owns it. The composer's **To** is a picker, and changing it rewrites the message, because a nudge to Zen and a nudge to Boon are not the same words. The prompt is told both `to` and `owned_by` for the same reason, with an explicit rule against restating the founder's own shorthand back at the person ("Hi Zen, remind Zen about the commission" is the failure it exists to stop). - **TWO routes, never one.** Drafting spends money and sending is irreversible; a single button would do both on one press, with a message going out in the founder's name before they had read it. - **The send takes the text from the REQUEST, not the stored draft** — what the owner reads in the box is what goes out. - **It goes down the ordinary outbound path** (contact → `conversationFor` → `createOutbound` → `SendWhatsAppMessage`), so the nudge lands in the CEO inbox as a normal thread with delivery ticks, and the reply arrives where the owner is already looking. A side-channel send would be invisible the moment they answered. - The draft is **stored** (`draft_message` / `draft_for_user_id` / `drafted_at` / `nudged_at`): it cost an AI call, and one bought twice comes back subtly different. `draft_for_user_id` is part of the draft — the same task nudged to Boon and to Kexin is two different messages, and sending a draft to somebody since taken off the item is refused. - **`max_tokens` is sized for the REASONING, not the message.** The nudge is three lines and 700 looked generous; the first real draft came back cut off mid-sentence at 696 tokens, and a truncated JSON object parses as nothing — an empty draft and a bill for it. It is 2400. - The button only appears when the item CAN be chased (somebody owns it *and* has a number); otherwise the card says which of the two is missing, rather than offering a button whose only outcome is an error. ### Reading the answer — `ceo:read-replies` (hourly) Sending the nudge closed half a loop. The other half is the part that actually costs a founder: the answer lands in a room they are not reading, says *"sent it already"* or *"can I do it Friday"*, and the item sits on the list either way — done but still open, or slipping with nobody told. [`ReadCeoNudgeReplies`](/app/Console/Commands/ReadCeoNudgeReplies.php) + [`resources/prompts/ceo_item_reply.md`](/resources/prompts/ceo_item_reply.md) read it and put one line on the card. - **What counts as the answer: the first INBOUND message in that thread after the one we sent**, found by `nudge_message_id` — which is why the send stores it. Anchoring on the message rather than a clock is what makes it unambiguous: these are people the owner talks to all day, and "the newest message since this morning" would read unrelated chatter as a reply. By **id**, not timestamp, for the same reason the group cursor is: a backfill lands old messages with new ids. - **`reply_state` is separate from `status`, and that is the point.** It records what somebody SAID — *Says it is done · On it · Gave a date · Blocked — needs you · Replied*. Closing the item stays the owner's tick. Auto-closing because a person typed "done" would hand the list's accuracy to whoever replies fastest, and this module reports rather than decides. - **A promise is not a completion.** The prompt is explicit that *"will do it tonight"* is `scheduled`, never `done` — a founder who clears an item on a promise finds out a week later that nobody did it. A date THEY give does move `due_on`; nothing else about the item is touched. - **Chasing again clears the last answer** (`markNudged` nulls the reply columns): what somebody said before being asked again is not a reply to the new message, and leaving it on the card would read as though they had already come back. - **Hourly, not twice-daily** like the briefing: a reply is only useful while the founder still has the item in mind, and *"Zen said he'd do it at 3pm"* read at midnight is a fact about yesterday. It costs one small call per answer and nothing when nobody has replied. One unreadable reply is logged and retried next run rather than ending the pass. - **The card shows their ACTUAL WORDS, not only the reading.** The summary says what the answer amounts to; the bubble under it is the message itself — the thing the owner would otherwise open WhatsApp to see, which is the whole point of the card. Sent message green and right, reply white and left, so the panel reads as the exchange it is. Both clamped to four lines with the full text on hover. - **The composer COLLAPSES once a message has gone out.** An editable box under a delivered message invites the reader to change words nobody will ever see, and buries the two things that now matter — what was sent, and whether they answered. *Reply to them* / *Write another* reopens it. - Verified against a real exchange: *"Next thursday can come"* → *"我拜四有事，怎麽辦？"* read as **Blocked — needs you**, *"They are busy on Thursday and asked how to proceed."* ### Filtering by whose desk, and sending somebody their whole list Two rows of chips narrow the same list along different axes — **category** (what part of the business) and **assignee** (whose desk). A founder asks *"what is on Boon?"* as often as *"what is in Finance?"*. `?assignee=` for one person, **`?assignee=nobody`** for the pile nobody has picked up — which is the one most often wanted and which a person-only filter cannot express. Counts come through the pivot, so an item on two desks counts once for each; that is the honest answer to "how much is on Boon?". **Send someone their list** (`POST ceo/actions/summary/draft` → `/send`, [`SummaryModal.vue`](/resources/js/Pages/Manage/Ceo/Partials/SummaryModal.vue)) is the other conversation a founder has. The per-item nudge chases ONE thing; this hands a person everything open on their plate in a single message, so both sides look at the same set instead of trading one-line reminders all week. The prompt is told each item's `last_reply`, so where somebody has already answered the line acknowledges it (*"the Armani payment — you said you'd do it today, still good?"*) rather than re-asking; past eight items it names the urgent ones and counts the rest, because a wall of text on a phone is read as none of it. - **Draft comes back as JSON, not an Inertia redirect** — it opens in a modal, and a page response would close it under the reader mid-flow. - **The literal `actions/summary/*` routes are declared BEFORE `actions/{id}/*`.** Without that, `actions/{id}/draft` captures `"summary"` as the uuid and the request 404s on an item that does not exist — the same trap GUIDELINES §14 names for a bare `export` segment. Verified by route matching, because calling the controller directly hides it. - Two presses, like the nudge, for the same reasons. ### Handing an item to someone — the team Every item card ([ActionItemCard.vue](/resources/js/Pages/Manage/Ceo/Partials/ActionItemCard.vue), shared by Action Items and the Groups drawer) carries a category picker, an **assignee** and a **due date**, each saved on its own through `PUT ceo/actions/{id}`. Only the field sent is written, so setting a due date can never clear a category; clearing is an explicit null. **An item can be on SEVERAL people.** `ceo_action_item_assignees` (a pivot) replaced the single `assigned_admin_id` column in 2026-09-16's migration, which copies every existing assignment across and then DROPS the column — keeping both would leave two places answering "whose desk is this on", and GUIDELINES §2 says what happens next. Real work in these rooms lands on two desks at once ("Boon and Shawn, walk me through the Armani workflow"), and one column forced the owner to pick a favourite or leave it unassigned, which reads identically to *nobody has looked at this*. `PUT ceo/actions/{id}` takes **`assignees[]` — the whole list, every time**; an empty array is the real answer *nobody*, and the key being ABSENT is what stops a due-date edit silently clearing the owners. One bad uuid refuses the whole edit rather than being dropped, because a half-applied assignment is worse than a refused one. The picker is [`AssigneePicker.vue`](/resources/js/Pages/Manage/Ceo/Partials/AssigneePicker.vue), a checklist rather than a `