fix(email-classifier): require a standalone OTP code, not a tracking-link fragment by KrisBraun · Pull Request #235 · plotday/plot

KrisBraun · 2026-06-26T14:13:52Z

Problem

Two production threads were misclassified as OTPs and fired immediate, gate-bypassing OTP pushes:

Thread	Bogus "code"	Real source
`CcRuoq3tNqLxdMEYHVYLh` (Reclaim "Weekly Report")	`39378156`	UUID-ish tracking token `…f76e-39378156-bc8f…` on a "Sign in…" line
`CcRquZiM1Uy9ri8GsPk7r` (Walmart "Thank you for shopping")	`750993`	a fragment inside a `clickTracker` URL; the mail also carries `Order number: 600000097650390`

Both are reach: direct automated mail, so the existing reach/promotion gate (#221) doesn't catch them. The haystack handed to extractCta is the connector's raw note content (raw HTML for Gmail), so tracking-URL tokens are in scope, and the old \b(…|\d{4,8})\b matcher happily spliced a 4–8 digit run out of the middle of a longer token.

Fix

A genuine one-time code is a small standalone token, never a slice of a longer number, URL, or UUID-like identifier. extractOtp now:

scans each keyword line word-by-word and only accepts a whole token matching CODE_CORE (anchored ^…$);
strips only sentence/markdown wrapper punctuation — the strip excludes- / + = % . so URL/decimal-glued tokens (…+750993/…, 1234.56) fail;
keeps the anchored \d{4,8}, so a 15-digit order number can't satisfy it even as a slice;
adds an ID_LABEL guard rejecting numbers introduced by "…number[:#]" (order/account/reference number).

Tests

Two new false-positive tests reproduce the exact prod codes (39378156, 750993). All genuine-OTP cases still pass: 482913, G-557812, 224466, all-same-digit placeholder, bare year, order total.

email-classifier: 48 pass
gmail facets: 4 pass
outlook facets: 6 pass
tsc --noEmit clean

No changeset — @plotday/email-classifier is private (not published to npm).

🤖 Generated with Claude Code

…link fragment The reach/promotion gate left a residual false-positive class: direct, automated transactional mail (a Reclaim "Weekly Report", a Walmart order confirmation) where the old `\b…\d{4,8}\b` token matcher spliced a digit fragment out of a tracking-link token sitting on a line that merely carried a code keyword — e.g. `…f76e-39378156-bc8f…` → "39378156", `…+750993/…` → "750993". These fire an immediate, gate-bypassing OTP push. A genuine one-time code is a small STANDALONE token, never a slice of a longer number, URL, or UUID-like identifier. `extractOtp` now scans each keyword line word-by-word and only accepts a whole token that matches `CODE_CORE` (anchored ^…$). The wrapper-strip deliberately excludes `- / + = % .` so URL/decimal-glued tokens fail, and an anchored `\d{4,8}` means a 15-digit order number can't satisfy it even as a slice. An ID_LABEL guard also rejects numbers introduced by "…number[:#]" (order/account number). Two new FP tests reproduce the exact prod codes (threads CcRuoq3tNqLxdMEYHVYLh / CcRquZiM1Uy9ri8GsPk7r). All genuine-OTP cases (482913, G-557812, 224466, all-same-digit placeholder, year, order total) still pass — 48 email-classifier + 4 gmail + 6 outlook facet tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-26T14:13:52Z

Problem

Two production threads were misclassified as OTPs and fired immediate, gate-bypassing OTP pushes:

Thread	Bogus "code"	Real source
`CcRuoq3tNqLxdMEYHVYLh` (Reclaim "Weekly Report")	`39378156`	UUID-ish tracking token `…f76e-39378156-bc8f…` on a "Sign in…" line
`CcRquZiM1Uy9ri8GsPk7r` (Walmart "Thank you for shopping")	`750993`	a fragment inside a `clickTracker` URL; the mail also carries `Order number: 600000097650390`

Both are reach: direct automated mail, so the existing reach/promotion gate (#221) doesn't catch them. The haystack handed to extractCta is the connector's raw note content (raw HTML for Gmail), so tracking-URL tokens are in scope, and the old \b(…|\d{4,8})\b matcher happily spliced a 4–8 digit run out of the middle of a longer token.

Fix

A genuine one-time code is a small standalone token, never a slice of a longer number, URL, or UUID-like identifier. extractOtp now:

scans each keyword line word-by-word and only accepts a whole token matching CODE_CORE (anchored ^…$);
strips only sentence/markdown wrapper punctuation — the strip excludes- / + = % . so URL/decimal-glued tokens (…+750993/…, 1234.56) fail;
keeps the anchored \d{4,8}, so a 15-digit order number can't satisfy it even as a slice;
adds an ID_LABEL guard rejecting numbers introduced by "…number[:#]" (order/account/reference number).

Tests

Two new false-positive tests reproduce the exact prod codes (39378156, 750993). All genuine-OTP cases still pass: 482913, G-557812, 224466, all-same-digit placeholder, bare year, order total.

email-classifier: 48 pass
gmail facets: 4 pass
outlook facets: 6 pass
tsc --noEmit clean

No changeset — @plotday/email-classifier is private (not published to npm).

🤖 Generated with Claude Code

…link fragment The reach/promotion gate left a residual false-positive class: direct, automated transactional mail (a Reclaim "Weekly Report", a Walmart order confirmation) where the old `\b…\d{4,8}\b` token matcher spliced a digit fragment out of a tracking-link token sitting on a line that merely carried a code keyword — e.g. `…f76e-39378156-bc8f…` → "39378156", `…+750993/…` → "750993". These fire an immediate, gate-bypassing OTP push. A genuine one-time code is a small STANDALONE token, never a slice of a longer number, URL, or UUID-like identifier. `extractOtp` now scans each keyword line word-by-word and only accepts a whole token that matches `CODE_CORE` (anchored ^…$). The wrapper-strip deliberately excludes `- / + = % .` so URL/decimal-glued tokens fail, and an anchored `\d{4,8}` means a 15-digit order number can't satisfy it even as a slice. An ID_LABEL guard also rejects numbers introduced by "…number[:#]" (order/account number). Two new FP tests reproduce the exact prod codes (threads CcRuoq3tNqLxdMEYHVYLh / CcRquZiM1Uy9ri8GsPk7r). All genuine-OTP cases (482913, G-557812, 224466, all-same-digit placeholder, year, order total) still pass — 48 email-classifier + 4 gmail + 6 outlook facet tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-26T14:13:52Z

Problem

Two production threads were misclassified as OTPs and fired immediate, gate-bypassing OTP pushes:

Thread	Bogus "code"	Real source
`CcRuoq3tNqLxdMEYHVYLh` (Reclaim "Weekly Report")	`39378156`	UUID-ish tracking token `…f76e-39378156-bc8f…` on a "Sign in…" line
`CcRquZiM1Uy9ri8GsPk7r` (Walmart "Thank you for shopping")	`750993`	a fragment inside a `clickTracker` URL; the mail also carries `Order number: 600000097650390`

Both are reach: direct automated mail, so the existing reach/promotion gate (#221) doesn't catch them. The haystack handed to extractCta is the connector's raw note content (raw HTML for Gmail), so tracking-URL tokens are in scope, and the old \b(…|\d{4,8})\b matcher happily spliced a 4–8 digit run out of the middle of a longer token.

Fix

A genuine one-time code is a small standalone token, never a slice of a longer number, URL, or UUID-like identifier. extractOtp now:

scans each keyword line word-by-word and only accepts a whole token matching CODE_CORE (anchored ^…$);
strips only sentence/markdown wrapper punctuation — the strip excludes- / + = % . so URL/decimal-glued tokens (…+750993/…, 1234.56) fail;
keeps the anchored \d{4,8}, so a 15-digit order number can't satisfy it even as a slice;
adds an ID_LABEL guard rejecting numbers introduced by "…number[:#]" (order/account/reference number).

Tests

Two new false-positive tests reproduce the exact prod codes (39378156, 750993). All genuine-OTP cases still pass: 482913, G-557812, 224466, all-same-digit placeholder, bare year, order total.

email-classifier: 48 pass
gmail facets: 4 pass
outlook facets: 6 pass
tsc --noEmit clean

No changeset — @plotday/email-classifier is private (not published to npm).

🤖 Generated with Claude Code

…link fragment The reach/promotion gate left a residual false-positive class: direct, automated transactional mail (a Reclaim "Weekly Report", a Walmart order confirmation) where the old `\b…\d{4,8}\b` token matcher spliced a digit fragment out of a tracking-link token sitting on a line that merely carried a code keyword — e.g. `…f76e-39378156-bc8f…` → "39378156", `…+750993/…` → "750993". These fire an immediate, gate-bypassing OTP push. A genuine one-time code is a small STANDALONE token, never a slice of a longer number, URL, or UUID-like identifier. `extractOtp` now scans each keyword line word-by-word and only accepts a whole token that matches `CODE_CORE` (anchored ^…$). The wrapper-strip deliberately excludes `- / + = % .` so URL/decimal-glued tokens fail, and an anchored `\d{4,8}` means a 15-digit order number can't satisfy it even as a slice. An ID_LABEL guard also rejects numbers introduced by "…number[:#]" (order/account number). Two new FP tests reproduce the exact prod codes (threads CcRuoq3tNqLxdMEYHVYLh / CcRquZiM1Uy9ri8GsPk7r). All genuine-OTP cases (482913, G-557812, 224466, all-same-digit placeholder, year, order total) still pass — 48 email-classifier + 4 gmail + 6 outlook facet tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-26T14:13:52Z

Problem

Two production threads were misclassified as OTPs and fired immediate, gate-bypassing OTP pushes:

Thread	Bogus "code"	Real source
`CcRuoq3tNqLxdMEYHVYLh` (Reclaim "Weekly Report")	`39378156`	UUID-ish tracking token `…f76e-39378156-bc8f…` on a "Sign in…" line
`CcRquZiM1Uy9ri8GsPk7r` (Walmart "Thank you for shopping")	`750993`	a fragment inside a `clickTracker` URL; the mail also carries `Order number: 600000097650390`

Both are reach: direct automated mail, so the existing reach/promotion gate (#221) doesn't catch them. The haystack handed to extractCta is the connector's raw note content (raw HTML for Gmail), so tracking-URL tokens are in scope, and the old \b(…|\d{4,8})\b matcher happily spliced a 4–8 digit run out of the middle of a longer token.

Fix

A genuine one-time code is a small standalone token, never a slice of a longer number, URL, or UUID-like identifier. extractOtp now:

scans each keyword line word-by-word and only accepts a whole token matching CODE_CORE (anchored ^…$);
strips only sentence/markdown wrapper punctuation — the strip excludes- / + = % . so URL/decimal-glued tokens (…+750993/…, 1234.56) fail;
keeps the anchored \d{4,8}, so a 15-digit order number can't satisfy it even as a slice;
adds an ID_LABEL guard rejecting numbers introduced by "…number[:#]" (order/account/reference number).

Tests

Two new false-positive tests reproduce the exact prod codes (39378156, 750993). All genuine-OTP cases still pass: 482913, G-557812, 224466, all-same-digit placeholder, bare year, order total.

email-classifier: 48 pass
gmail facets: 4 pass
outlook facets: 6 pass
tsc --noEmit clean

No changeset — @plotday/email-classifier is private (not published to npm).

🤖 Generated with Claude Code

…link fragment The reach/promotion gate left a residual false-positive class: direct, automated transactional mail (a Reclaim "Weekly Report", a Walmart order confirmation) where the old `\b…\d{4,8}\b` token matcher spliced a digit fragment out of a tracking-link token sitting on a line that merely carried a code keyword — e.g. `…f76e-39378156-bc8f…` → "39378156", `…+750993/…` → "750993". These fire an immediate, gate-bypassing OTP push. A genuine one-time code is a small STANDALONE token, never a slice of a longer number, URL, or UUID-like identifier. `extractOtp` now scans each keyword line word-by-word and only accepts a whole token that matches `CODE_CORE` (anchored ^…$). The wrapper-strip deliberately excludes `- / + = % .` so URL/decimal-glued tokens fail, and an anchored `\d{4,8}` means a 15-digit order number can't satisfy it even as a slice. An ID_LABEL guard also rejects numbers introduced by "…number[:#]" (order/account number). Two new FP tests reproduce the exact prod codes (threads CcRuoq3tNqLxdMEYHVYLh / CcRquZiM1Uy9ri8GsPk7r). All genuine-OTP cases (482913, G-557812, 224466, all-same-digit placeholder, year, order total) still pass — 48 email-classifier + 4 gmail + 6 outlook facet tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-26T14:13:52Z

Problem

Two production threads were misclassified as OTPs and fired immediate, gate-bypassing OTP pushes:

Thread	Bogus "code"	Real source
`CcRuoq3tNqLxdMEYHVYLh` (Reclaim "Weekly Report")	`39378156`	UUID-ish tracking token `…f76e-39378156-bc8f…` on a "Sign in…" line
`CcRquZiM1Uy9ri8GsPk7r` (Walmart "Thank you for shopping")	`750993`	a fragment inside a `clickTracker` URL; the mail also carries `Order number: 600000097650390`

Both are reach: direct automated mail, so the existing reach/promotion gate (#221) doesn't catch them. The haystack handed to extractCta is the connector's raw note content (raw HTML for Gmail), so tracking-URL tokens are in scope, and the old \b(…|\d{4,8})\b matcher happily spliced a 4–8 digit run out of the middle of a longer token.

Fix

A genuine one-time code is a small standalone token, never a slice of a longer number, URL, or UUID-like identifier. extractOtp now:

scans each keyword line word-by-word and only accepts a whole token matching CODE_CORE (anchored ^…$);
strips only sentence/markdown wrapper punctuation — the strip excludes- / + = % . so URL/decimal-glued tokens (…+750993/…, 1234.56) fail;
keeps the anchored \d{4,8}, so a 15-digit order number can't satisfy it even as a slice;
adds an ID_LABEL guard rejecting numbers introduced by "…number[:#]" (order/account/reference number).

Tests

Two new false-positive tests reproduce the exact prod codes (39378156, 750993). All genuine-OTP cases still pass: 482913, G-557812, 224466, all-same-digit placeholder, bare year, order total.

email-classifier: 48 pass
gmail facets: 4 pass
outlook facets: 6 pass
tsc --noEmit clean

No changeset — @plotday/email-classifier is private (not published to npm).

🤖 Generated with Claude Code

…link fragment The reach/promotion gate left a residual false-positive class: direct, automated transactional mail (a Reclaim "Weekly Report", a Walmart order confirmation) where the old `\b…\d{4,8}\b` token matcher spliced a digit fragment out of a tracking-link token sitting on a line that merely carried a code keyword — e.g. `…f76e-39378156-bc8f…` → "39378156", `…+750993/…` → "750993". These fire an immediate, gate-bypassing OTP push. A genuine one-time code is a small STANDALONE token, never a slice of a longer number, URL, or UUID-like identifier. `extractOtp` now scans each keyword line word-by-word and only accepts a whole token that matches `CODE_CORE` (anchored ^…$). The wrapper-strip deliberately excludes `- / + = % .` so URL/decimal-glued tokens fail, and an anchored `\d{4,8}` means a 15-digit order number can't satisfy it even as a slice. An ID_LABEL guard also rejects numbers introduced by "…number[:#]" (order/account number). Two new FP tests reproduce the exact prod codes (threads CcRuoq3tNqLxdMEYHVYLh / CcRquZiM1Uy9ri8GsPk7r). All genuine-OTP cases (482913, G-557812, 224466, all-same-digit placeholder, year, order total) still pass — 48 email-classifier + 4 gmail + 6 outlook facet tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-26T14:13:52Z

Problem

Two production threads were misclassified as OTPs and fired immediate, gate-bypassing OTP pushes:

Thread	Bogus "code"	Real source
`CcRuoq3tNqLxdMEYHVYLh` (Reclaim "Weekly Report")	`39378156`	UUID-ish tracking token `…f76e-39378156-bc8f…` on a "Sign in…" line
`CcRquZiM1Uy9ri8GsPk7r` (Walmart "Thank you for shopping")	`750993`	a fragment inside a `clickTracker` URL; the mail also carries `Order number: 600000097650390`

Both are reach: direct automated mail, so the existing reach/promotion gate (#221) doesn't catch them. The haystack handed to extractCta is the connector's raw note content (raw HTML for Gmail), so tracking-URL tokens are in scope, and the old \b(…|\d{4,8})\b matcher happily spliced a 4–8 digit run out of the middle of a longer token.

Fix

A genuine one-time code is a small standalone token, never a slice of a longer number, URL, or UUID-like identifier. extractOtp now:

scans each keyword line word-by-word and only accepts a whole token matching CODE_CORE (anchored ^…$);
strips only sentence/markdown wrapper punctuation — the strip excludes- / + = % . so URL/decimal-glued tokens (…+750993/…, 1234.56) fail;
keeps the anchored \d{4,8}, so a 15-digit order number can't satisfy it even as a slice;
adds an ID_LABEL guard rejecting numbers introduced by "…number[:#]" (order/account/reference number).

Tests

Two new false-positive tests reproduce the exact prod codes (39378156, 750993). All genuine-OTP cases still pass: 482913, G-557812, 224466, all-same-digit placeholder, bare year, order total.

email-classifier: 48 pass
gmail facets: 4 pass
outlook facets: 6 pass
tsc --noEmit clean

No changeset — @plotday/email-classifier is private (not published to npm).

🤖 Generated with Claude Code

…link fragment The reach/promotion gate left a residual false-positive class: direct, automated transactional mail (a Reclaim "Weekly Report", a Walmart order confirmation) where the old `\b…\d{4,8}\b` token matcher spliced a digit fragment out of a tracking-link token sitting on a line that merely carried a code keyword — e.g. `…f76e-39378156-bc8f…` → "39378156", `…+750993/…` → "750993". These fire an immediate, gate-bypassing OTP push. A genuine one-time code is a small STANDALONE token, never a slice of a longer number, URL, or UUID-like identifier. `extractOtp` now scans each keyword line word-by-word and only accepts a whole token that matches `CODE_CORE` (anchored ^…$). The wrapper-strip deliberately excludes `- / + = % .` so URL/decimal-glued tokens fail, and an anchored `\d{4,8}` means a 15-digit order number can't satisfy it even as a slice. An ID_LABEL guard also rejects numbers introduced by "…number[:#]" (order/account number). Two new FP tests reproduce the exact prod codes (threads CcRuoq3tNqLxdMEYHVYLh / CcRquZiM1Uy9ri8GsPk7r). All genuine-OTP cases (482913, G-557812, 224466, all-same-digit placeholder, year, order total) still pass — 48 email-classifier + 4 gmail + 6 outlook facet tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-26T14:13:52Z

Problem

Two production threads were misclassified as OTPs and fired immediate, gate-bypassing OTP pushes:

Thread	Bogus "code"	Real source
`CcRuoq3tNqLxdMEYHVYLh` (Reclaim "Weekly Report")	`39378156`	UUID-ish tracking token `…f76e-39378156-bc8f…` on a "Sign in…" line
`CcRquZiM1Uy9ri8GsPk7r` (Walmart "Thank you for shopping")	`750993`	a fragment inside a `clickTracker` URL; the mail also carries `Order number: 600000097650390`

Both are reach: direct automated mail, so the existing reach/promotion gate (#221) doesn't catch them. The haystack handed to extractCta is the connector's raw note content (raw HTML for Gmail), so tracking-URL tokens are in scope, and the old \b(…|\d{4,8})\b matcher happily spliced a 4–8 digit run out of the middle of a longer token.

Fix

A genuine one-time code is a small standalone token, never a slice of a longer number, URL, or UUID-like identifier. extractOtp now:

scans each keyword line word-by-word and only accepts a whole token matching CODE_CORE (anchored ^…$);
strips only sentence/markdown wrapper punctuation — the strip excludes- / + = % . so URL/decimal-glued tokens (…+750993/…, 1234.56) fail;
keeps the anchored \d{4,8}, so a 15-digit order number can't satisfy it even as a slice;
adds an ID_LABEL guard rejecting numbers introduced by "…number[:#]" (order/account/reference number).

Tests

Two new false-positive tests reproduce the exact prod codes (39378156, 750993). All genuine-OTP cases still pass: 482913, G-557812, 224466, all-same-digit placeholder, bare year, order total.

email-classifier: 48 pass
gmail facets: 4 pass
outlook facets: 6 pass
tsc --noEmit clean

No changeset — @plotday/email-classifier is private (not published to npm).

🤖 Generated with Claude Code

…link fragment The reach/promotion gate left a residual false-positive class: direct, automated transactional mail (a Reclaim "Weekly Report", a Walmart order confirmation) where the old `\b…\d{4,8}\b` token matcher spliced a digit fragment out of a tracking-link token sitting on a line that merely carried a code keyword — e.g. `…f76e-39378156-bc8f…` → "39378156", `…+750993/…` → "750993". These fire an immediate, gate-bypassing OTP push. A genuine one-time code is a small STANDALONE token, never a slice of a longer number, URL, or UUID-like identifier. `extractOtp` now scans each keyword line word-by-word and only accepts a whole token that matches `CODE_CORE` (anchored ^…$). The wrapper-strip deliberately excludes `- / + = % .` so URL/decimal-glued tokens fail, and an anchored `\d{4,8}` means a 15-digit order number can't satisfy it even as a slice. An ID_LABEL guard also rejects numbers introduced by "…number[:#]" (order/account number). Two new FP tests reproduce the exact prod codes (threads CcRuoq3tNqLxdMEYHVYLh / CcRquZiM1Uy9ri8GsPk7r). All genuine-OTP cases (482913, G-557812, 224466, all-same-digit placeholder, year, order total) still pass — 48 email-classifier + 4 gmail + 6 outlook facet tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun · 2026-06-26T14:13:52Z

Problem

Two production threads were misclassified as OTPs and fired immediate, gate-bypassing OTP pushes:

Thread	Bogus "code"	Real source
`CcRuoq3tNqLxdMEYHVYLh` (Reclaim "Weekly Report")	`39378156`	UUID-ish tracking token `…f76e-39378156-bc8f…` on a "Sign in…" line
`CcRquZiM1Uy9ri8GsPk7r` (Walmart "Thank you for shopping")	`750993`	a fragment inside a `clickTracker` URL; the mail also carries `Order number: 600000097650390`

Both are reach: direct automated mail, so the existing reach/promotion gate (#221) doesn't catch them. The haystack handed to extractCta is the connector's raw note content (raw HTML for Gmail), so tracking-URL tokens are in scope, and the old \b(…|\d{4,8})\b matcher happily spliced a 4–8 digit run out of the middle of a longer token.

Fix

A genuine one-time code is a small standalone token, never a slice of a longer number, URL, or UUID-like identifier. extractOtp now:

scans each keyword line word-by-word and only accepts a whole token matching CODE_CORE (anchored ^…$);
strips only sentence/markdown wrapper punctuation — the strip excludes- / + = % . so URL/decimal-glued tokens (…+750993/…, 1234.56) fail;
keeps the anchored \d{4,8}, so a 15-digit order number can't satisfy it even as a slice;
adds an ID_LABEL guard rejecting numbers introduced by "…number[:#]" (order/account/reference number).

Tests

Two new false-positive tests reproduce the exact prod codes (39378156, 750993). All genuine-OTP cases still pass: 482913, G-557812, 224466, all-same-digit placeholder, bare year, order total.

email-classifier: 48 pass
gmail facets: 4 pass
outlook facets: 6 pass
tsc --noEmit clean

No changeset — @plotday/email-classifier is private (not published to npm).

🤖 Generated with Claude Code

…link fragment The reach/promotion gate left a residual false-positive class: direct, automated transactional mail (a Reclaim "Weekly Report", a Walmart order confirmation) where the old `\b…\d{4,8}\b` token matcher spliced a digit fragment out of a tracking-link token sitting on a line that merely carried a code keyword — e.g. `…f76e-39378156-bc8f…` → "39378156", `…+750993/…` → "750993". These fire an immediate, gate-bypassing OTP push. A genuine one-time code is a small STANDALONE token, never a slice of a longer number, URL, or UUID-like identifier. `extractOtp` now scans each keyword line word-by-word and only accepts a whole token that matches `CODE_CORE` (anchored ^…$). The wrapper-strip deliberately excludes `- / + = % .` so URL/decimal-glued tokens fail, and an anchored `\d{4,8}` means a 15-digit order number can't satisfy it even as a slice. An ID_LABEL guard also rejects numbers introduced by "…number[:#]" (order/account number). Two new FP tests reproduce the exact prod codes (threads CcRuoq3tNqLxdMEYHVYLh / CcRquZiM1Uy9ri8GsPk7r). All genuine-OTP cases (482913, G-557812, 224466, all-same-digit placeholder, year, order total) still pass — 48 email-classifier + 4 gmail + 6 outlook facet tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

KrisBraun merged commit 968d757 into mainJun 26, 2026
1 check passed

KrisBraun deleted the fix/otp-fp-standalone-code branch June 26, 2026 14:56