fix(attention): audit the replied stamps the broad resolver wrote

[lilyshen0722]

Corrective pass for the mention rows stamped resolvedBy: 'replied' by the pre-#1573 resolver, requested in the pod before PR 3 renders them as per-kind inbox rows.

What it does

auditRepliedMentionAttention in attentionItemService.ts sits beside sweepResolvedMentionAttention and runs its test in reverse: for each row already stamped replied, re-read the source and reopen it only if the source contradicts the stamp.

npm run audit:replied-attention-stamps
npm run audit:replied-attention-stamps -- --resolved-before=2026-09-06T00:00:00Z
npm run audit:replied-attention-stamps -- --apply

Dry run is the default and prints { scanned, kept, contradicted, reopened, undecidable, unavailable }.

Three outcomes, not two

recipientRepliedAfterMention only has reply and thread edges for a PostgreSQL source. For a Mongo-fallback source it returns false unconditionally — so a two-way kept/reopen split would reopen every Mongo-sourced row, including the ones that were correctly resolved, re-raising attention a user has already dealt with. Those are counted as undecidable and left untouched. A test pins that they are never written and that hasReplyByUserAfter is not even called for them.

--resolved-before bounds the scan to the stamps the broad resolver could have written. An unparsable value throws rather than silently widening the audit to every stamp ever written.

The reopen re-states status: 'resolved', resolvedBy: 'replied' in the update filter, so a row acknowledged between the read and the write is not reopened underneath the operator.

Tests

Five new cases in backend/__tests__/unit/services/attentionItemService.test.js; suite is 21/21.

Each was mutated against the diff:

mutation	result
Mongo-source guard removed (if (false))	1 red
recipientRepliedAfterMention polarity inverted	2 red
if (!apply) continue deleted	1 red
resolvedAt: { $lt: before } dropped from the filter	1 red

tsc --noEmit reports no errors in either changed file (the 51 it does report are pre-existing, in cleanup-test-data.ts and test-discord-*.ts). eslint could not run locally — @typescript-eslint/parser is not installed in this workspace — so the backend TS lint gate is unverified here and left to CI.

Note for the reviewer: attentionItemService.ts ends with an explicit export default {...} and module.exports = {...} enumeration. A new export is invisible to every CommonJS consumer until it is added to both; the first test run failed with is not a function for exactly that reason.

🤖 Generated with Claude Code

[lilyshen0722]

CODE GATE: clear at acf4638a — one non-blocking gap, and it is the same shape as the three this stack has already produced.

I mutated rather than read. Four deciding lines in auditRepliedMentionAttention, each one red on its own:

mutation	result
drop resolvedAt: { $lt: before }	1 red
drop if (!apply) continue (dry run writes)	1 red
reopen Mongo-sourced rows instead of counting undecidable	1 red
reduce the update filter to { _id } (drop the re-stamp guard)	1 red

30 tests green across the service and PG model suites at this head, 21 in the service file.

The design reads right to me on the two things that matter most. Three outcomes rather than two is the correct call: a Mongo-fallback source carries no reply edges, so undecidable is an honest answer where reopened would be a fabricated one, and the audit reopening rows on absent evidence would be the same overreach in the other direction as the stamps it is auditing. And repeating the stamp in the updateOne filter closes the read-write window against an operator acknowledging a row mid-run.

The gap: the script's own argument parsing has no test

backend/scripts/audit-replied-attention-stamps.ts:29-33 carries the guard AND names the hazard in its comment: "An unparsable bound would silently widen the audit to every stamp ever written, which is the opposite of what the flag was passed to do." That is correct, and nothing pins it — no test references the script, so deleting the Number.isNaN throw leaves everything green.

The chain I verified rather than assumed: new Date('garbage') → Invalid Date → validDate returns null → before is falsy → the resolvedAt clause is spread away → the audit scans every replied stamp ever written. With --apply, that is an unbounded reopen from a typo'd flag.

There is precedent for pinning this in-repo (__tests__/unit/scripts/migrate-connector-gates.test.js), so it is a small ask: one test that imports the script with a bad --resolved-before and expects a throw, plus one that confirms a valid bound reaches the service.

Not blocking — the guard exists and is correct, and this is a maintenance script an operator runs deliberately. But it is the producer half of exactly the pattern you have now caught three times on this stack (#1579's manifest, #1582's reveal branch, #1582's collapsed PUT): the value's consumer is covered, the code that computes it is bare. I would rather name it on your PR than only on mine.

I did not run the audit against production; the dry run is yours to call or Sam's.