From 57dae70a07be8fec4fef27a7382034709fe3807c Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Wed, 5 Aug 2026 17:49:17 -0500 Subject: docs(triage): mark the Gmail date-slice walk as a floor, not a complete read The walk bottoms out at day resolution, so a single day over the 100 cap still truncates with nothing to signal it. Three slices reported about 250 messages where REST pagination found 291. A routine sweep tolerates that, because the next one re-reads live unread state. A backlog inventory can't. No tool ships here for real pagination, so a count taken through this MCP has to be reported as a floor. --- .ai/workflows/triage-intake.personal-gmail.org | 4 ++++ 1 file changed, 4 insertions(+) (limited to '.ai') diff --git a/.ai/workflows/triage-intake.personal-gmail.org b/.ai/workflows/triage-intake.personal-gmail.org index 7fb1231..0bc94fc 100644 --- a/.ai/workflows/triage-intake.personal-gmail.org +++ b/.ai/workflows/triage-intake.personal-gmail.org @@ -30,6 +30,10 @@ The rule binds the *anchor* windows only. The date-slice walk below deliberately ⚠ *The MCP caps at =maxResults=100= and exposes NO =pageToken= parameter.* The response carries a =nextPageToken=, but the tool can't consume it, so a pile over 100 is silently truncated — the tail below the cap never gets classified, and every later anchored sweep skips it (it predates the new anchor). This is exactly how a 300+ backlog accumulated invisibly by 2026-07-08. Two consequences: - *Never treat a 100-row result as complete.* When a scan returns exactly 100, walk the tail in *date slices*: re-query with =before:= (day resolution), repeat until a page returns fewer than 100, dedupe by message id across slices (the day-resolution boundary overlaps). + + ⚠ *The date-slice walk is a floor, not a complete read.* It bottoms out at day resolution, so any single day carrying more than the cap still truncates — and nothing in the response signals it. Measured 2026-08-01: three slices through the MCP reported about 250 messages where the REST API, paginated properly, found 291. The walk narrows the gap; it doesn't close it. + + So pick by what the number is for. A *routine sweep* tolerates the floor, because the next sweep re-reads live unread state and picks up what was missed. A *backlog inventory* does not, and neither does any count reported to Craig as complete — go to the Gmail REST API with real =pageToken= pagination instead. No tool ships for that here, so reaching it means stepping outside this MCP; until one does, an inventory taken through the MCP must be reported as a floor ("at least N"), never as a total. - *Never report =resultSizeEstimate= as a count.* It's unreliable — observed stuck at "201" across three different queries whose real union exceeded 300. *** Backlog-residue check (every sweep — cheap, mandatory) -- cgit v1.2.3