diff options
Diffstat (limited to '.ai')
| -rw-r--r-- | .ai/workflows/triage-intake.personal-gmail.org | 4 |
1 files changed, 4 insertions, 0 deletions
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:<oldest-full-day-seen>= (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) |