use-home-overview.tsfeat(home): the meetings widget owns one day, and the pipeline widget knows which one it counts
Two widgets in the home rail were quietly lying, in different ways.
The pipeline tile counted every crm_conversation the user owns. computePipelineStats
only filters by AOP when an aopId is passed, and nothing passed one — so on a real
account it read 788 "deals" against an actual pipeline of 124, with cold inbound,
vendors, recruiting and spam as stages. Worse, those carry no deal_value, so each
added 1 to the count and 0 to the ACV. It now defaults to the fuzzy-matched deals AOP
— the same match /statistics already used, extracted to modules/aop/utils/deals-aop
so the two surfaces cannot drift onto different pipelines — and a modal behind the
header's pencil carries the rest of the filters (which pipeline, whose, which stages).
The scope is resolved at the rail so it still feeds ONE getOverview call. An unscoped
count stays available, but only under a label that says what it is.
The meetings tile was a maze of its own making: when today ran out it drew TOMORROW
while the arrows still pointed at today, so Next went to tomorrow again (identical,
minus the now-line) and Back went to yesterday. The list now only ever renders the day
it is handed; it reports that today is spent and the widget moves the day, once,
ref-guarded so Back onto a spent today does not bounce straight forward again. It also
waits for the last meeting to END rather than to start, so the day cannot move out
from under the meeting you are in.
The rest is the shape those two changes exposed: the four stat tiles collapse into one
Statistics table (four bordered cards to say four numbers), meeting rows put the time
in a left-aligned gutter outside the colour rule so the times, the header icon and the
now-line dot all land on one edge, and per-tile remove gives way to one Edit widgets
button — adding and removing are the same act.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Aug 29, 2026, 3:45 PMuse-home-pipeline-filters.tsfeat(home): the meetings widget owns one day, and the pipeline widget knows which one it counts
Two widgets in the home rail were quietly lying, in different ways.
The pipeline tile counted every crm_conversation the user owns. computePipelineStats
only filters by AOP when an aopId is passed, and nothing passed one — so on a real
account it read 788 "deals" against an actual pipeline of 124, with cold inbound,
vendors, recruiting and spam as stages. Worse, those carry no deal_value, so each
added 1 to the count and 0 to the ACV. It now defaults to the fuzzy-matched deals AOP
— the same match /statistics already used, extracted to modules/aop/utils/deals-aop
so the two surfaces cannot drift onto different pipelines — and a modal behind the
header's pencil carries the rest of the filters (which pipeline, whose, which stages).
The scope is resolved at the rail so it still feeds ONE getOverview call. An unscoped
count stays available, but only under a label that says what it is.
The meetings tile was a maze of its own making: when today ran out it drew TOMORROW
while the arrows still pointed at today, so Next went to tomorrow again (identical,
minus the now-line) and Back went to yesterday. The list now only ever renders the day
it is handed; it reports that today is spent and the widget moves the day, once,
ref-guarded so Back onto a spent today does not bounce straight forward again. It also
waits for the last meeting to END rather than to start, so the day cannot move out
from under the meeting you are in.
The rest is the shape those two changes exposed: the four stat tiles collapse into one
Statistics table (four bordered cards to say four numbers), meeting rows put the time
in a left-aligned gutter outside the colour rule so the times, the header icon and the
now-line dot all land on one edge, and per-tile remove gives way to one Edit widgets
button — adding and removing are the same act.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Aug 29, 2026, 3:45 PMuse-home-setting-list.tsfeat(home): the meetings widget owns one day, and the pipeline widget knows which one it counts
Two widgets in the home rail were quietly lying, in different ways.
The pipeline tile counted every crm_conversation the user owns. computePipelineStats
only filters by AOP when an aopId is passed, and nothing passed one — so on a real
account it read 788 "deals" against an actual pipeline of 124, with cold inbound,
vendors, recruiting and spam as stages. Worse, those carry no deal_value, so each
added 1 to the count and 0 to the ACV. It now defaults to the fuzzy-matched deals AOP
— the same match /statistics already used, extracted to modules/aop/utils/deals-aop
so the two surfaces cannot drift onto different pipelines — and a modal behind the
header's pencil carries the rest of the filters (which pipeline, whose, which stages).
The scope is resolved at the rail so it still feeds ONE getOverview call. An unscoped
count stays available, but only under a label that says what it is.
The meetings tile was a maze of its own making: when today ran out it drew TOMORROW
while the arrows still pointed at today, so Next went to tomorrow again (identical,
minus the now-line) and Back went to yesterday. The list now only ever renders the day
it is handed; it reports that today is spent and the widget moves the day, once,
ref-guarded so Back onto a spent today does not bounce straight forward again. It also
waits for the last meeting to END rather than to start, so the day cannot move out
from under the meeting you are in.
The rest is the shape those two changes exposed: the four stat tiles collapse into one
Statistics table (four bordered cards to say four numbers), meeting rows put the time
in a left-aligned gutter outside the colour rule so the times, the header icon and the
now-line dot all land on one edge, and per-tile remove gives way to one Edit widgets
button — adding and removing are the same act.
Co-Authored-By: Claude Opus 5 (1M context) <<email>>Aug 29, 2026, 3:45 PM