diff options
| author | Craig Jennings <c@cjennings.net> | 2026-07-16 10:43:37 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-07-16 10:43:37 -0500 |
| commit | cf3eadc5dfeff5145feb891a2e61d1ada9a94df0 (patch) | |
| tree | 21cd1d64022b1c4a5c24804501e5697e91436518 /.ai/workflows/triage-intake.github-prs.org | |
| parent | f14dd8798842dda026d2613791d77f44c258ade7 (diff) | |
| download | rulesets-cf3eadc5dfeff5145feb891a2e61d1ada9a94df0.tar.gz rulesets-cf3eadc5dfeff5145feb891a2e61d1ada9a94df0.zip | |
fix(triage-intake): anchor the gmail residue probe to the epoch
The residue probe cut off at before:<anchor-YYYY/MM/DD> while the scan started at after:<anchor-epoch>. Gmail's before:<date> excludes the named day, so the anchor day fell between the two queries. Each sweep then advanced the anchor past that window and never looked back, so an evening anchor hid most of a day for good. That's the exact failure the probe was added on 2026-07-08 to prevent.
The probe now cuts off at the epoch, matching the scan. I hoisted the epoch rule to cover both anchored queries once rather than twice. I scoped it to the anchor windows so the date-slice walk's deliberate day resolution doesn't read as a bug.
home caught it: after acting on 38 messages the probe reported zero while a plain is:unread in:inbox still returned two messages from the anchor day. personal-gmail is the only source pairing an anchored scan with a residue probe, so nothing else needed the fix.
Diffstat (limited to '.ai/workflows/triage-intake.github-prs.org')
0 files changed, 0 insertions, 0 deletions
