crmSlice.tsperf(crm): stop shipping list rows what they cannot render
Follows the event projection with the other two thirds of the payload. On the
same 50-row page: 2,809 KB -> 1,173 KB.
userTasks was 58% of it. The list had no status filter at all, so every task
ever attached to a conversation went over the wire — 650 deleted, 329
agent_deleted and 268 done against 59 todo on one page; 341 renderable out of
6,935 org-wide. Every list surface filters to todo before drawing (the tasks
cell, the current/future action columns, the kanban card), so the rest was
never rendered. Filtering to todo + recommended takes it 1,621 KB -> 175 KB.
The blobs on a task are small (~350 bytes of task_output on a todo task), so
this is deliberately a row filter and not a narrower field projection: the
execution ids and chat_thread_id / task_group_id drive execution mode when a
task is opened from a card, and trimming them would risk that for a few KB.
customFields was 522 KB. Two things, neither of them the values themselves:
54% of entries carry no value at all (4,028 of 7,506), and an absent entry
renders exactly what an empty one does — every reader is `field?.value || null`
— so they are skipped unless they still have a signal dot to draw. And 31% of
the bytes were envelope (id, conversationId, agentExecutionId, editedBy,
lastEdited, createdAt) that no list surface reads; every lookup goes through the
field name. updatedAt stays, because getCustomFieldsRevision keys the store's
change detection on it. 522 KB -> 332 KB, now 84% real user content.
Also deletes `siblingTasks`, which existed to carry the full task list to
TimelineTaskItem — where it was declared as a prop and never destructured. Five
call sites were threading a conversation's entire task history into a component
that ignored it.
Left alone deliberately: primaryCompany (75 KB across ~50 enrichment columns —
trimming it needs a store guard so a list refetch cannot blank the panel's
company card, which is a poor trade for 6%), and the event cap, which is a
product dial rather than waste.
Co-Authored-By: Claude Opus 5 <<email>>Sep 2, 2026, 11:42 PM