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.

2 files changed, 8 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)
diff --git a/claude-templates/.ai/workflows/triage-intake.personal-gmail.org b/claude-templates/.ai/workflows/triage-intake.personal-gmail.org
index 7fb1231..0bc94fc 100644
--- a/claude-templates/.ai/workflows/triage-intake.personal-gmail.org
+++ b/claude-templates/.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)