[Birfy]

Fixes #641 — a Bot-to-Bot line that repeats what the same sender already delivered to that Session within the last minute now makes one turn instead of two, and the drop is written to the host log. One host change, its tests, the subsystem doc, one changelog fragment and the regenerated patch series.

Reproduce

deliver() had no memory of what it had just handed a Session, so every message_bot call made a turn of its own, even when the text was the same conclusion relayed twice:

• A specialist answers its lead, the lead relays the conclusion up, and the same line reaches the coordinator's Session a second time inside the same minute. The queue shows it twice and the Bot answers it twice.
• Only the exact absence of routing matters here: there was no window, no key and no journal. Whatever arrived was delivered and recorded as an exchange.
• core/test/repeated-delivery.test.js reproduces it through the public message_bot tool with three Bots and a fake clock: the same text twice from one sender to one recipient produced ['steer', 'steer'] instead of ['steer'].

What changed

• core/src/host/delivery.js
  • duplicateDelivery(fromId, sessionId, text) keeps the last minute of Bot-to-Bot text keyed by sender + recipient Session + the text with its whitespace collapsed (DEDUPE_MS = 60_000, dedupeText). A repeat inside the window returns true; the map is trimmed and capped at 500 entries (DEDUPE_KEPT), so a long-lived host cannot grow it without bound.
  • deliver() judges a line right after it resolves targetSessionId and before the exchange is recorded, firstContact is stamped and the message is handed to the Session. A drop returns the exchange id unchanged, records no exchange, and journals ds-bot: delivery: dedupe <sender> -> <session> through rt.warn, because a silent drop is how a real report goes missing.
  • Only a fresh Bot-to-Bot line is judged: fromId === undefined (the user, a group round) is untouched, remote?.handle (a friend's line) is untouched, and deferred / resumed / retried / resent carry on a message the Session already has, so dropping one of those would lose it rather than deduplicate it.
• core/test/repeated-delivery.test.js — four cases: the repeat collapses and is journalled; the same text 61 s later is news again; two senders with identical text are both delivered; the key includes the Session, so another recipient still gets it.
• core/test/connector-access.test.js — that test relays the literal 'hi' several times in a row to check whose request a relay is, which a one-minute dedupe would swallow; each relay now sends its own text, so the origin assertions still test origin.
• docs/subsystems/core-host.md — the dedupe rule, its key, what it deliberately skips, and the cap.
• changelog.d/641-repeated-bot-message.fixed.md — the user-visible change.
• patches/ds-bot/ — regenerated (generate, then check) because core/ changed.

What I ran

Tip SHA: 7fde6604b22bec9647608ccfff0d85ce614642aa (Node 22.23.3, TZ=UTC, base 9393d558):

• core, full suite: 1216/1216 pass (node --import ./test/harness-resolve.mjs --test --test-concurrency=4 "test/*.test.js", no cancellations).
• core/test/repeated-delivery.test.js on its own: 4/4 pass.
• core/test/connector-access.test.js + repeated-delivery.test.js: 20/20 pass.
• node scripts/ds-bot-patches.mjs check after generate → pin matches Fei2411/DeepSeek-Bot@2b10c70, 10 patches apply cleanly in order, core/ equals ds-bot/ + patches/ds-bot/.
• node core/scripts/lint.mjs (with DSH_HARNESS) → 0 errors, 43 pre-existing warnings; it also prints arch-docs: OK (6 changed file(s)).
• node .github/scripts/changelog.mjs check → 10 fragments well formed; node --test ".github/scripts/*.test.mjs" → 153/153.
• node core/scripts/build-client.mjs --check → exit 0.
• git diff --shortstat 9393d558...7fde6604 → 8 files, +360/−7.

Red without the source change

With core/src/host/delivery.js at main 9393d558 and the new tests kept:

• #641: the same conclusion sent twice within a minute makes one turn, and the drop is journalled → fail, one turn, not two: actual ['steer', 'steer'], expected ['steer'] — the defect itself, one line becoming two turns.
• The other three stay green: 61 s later is a new line, two senders are two deliveries, another recipient is another delivery. They are the guard against an over-eager dedupe, and they are red-proof only in the sense that a dedupe that dropped them would fail them.
• 1 failed, 3 passed; restoring the source makes all four green again.

Not run

• Two-Bot end-to-end over a real Bot Social link: this box has one home and no reachable server, so the report was reproduced at the deliver() boundary rather than over the wire.
• Full npm run verify (it also runs the three plugin suites; no plugin file is in the diff) and the smoke bench (dev/bench.sh needs pnpm, which this box does not have). tests-ok at the tip covers the rest.
• No load or soak run: the 500-entry cap is asserted by construction, not measured under a long session.

Risk

• T3 by the repo's own risk-gate.mjs (core/src/host/delivery.js is a T3 path; 178 changed lines in 5 files once the generated patch mirror is excluded): it needs a PASS at this tip plus green tests-ok, and the gating agent merges it itself after that.
• Behaviour change worth naming: a repeated Bot-to-Bot line within 60 s now produces one turn and no second exchange. Nothing else changes — routing, the unread-queue refusal, group copies, another Bot, the user's own messages and a friend's line are all delivered exactly as before.
• Deliberate narrowness: the window is per sender and per Session and the text must match after whitespace collapsing, so a genuinely re-sent but reworded line still arrives; deferred / resumed / retried / resent are never judged.
• A drop is visible in the host log, not in the chat. If a report ever does go missing this way, the log line names the sender and the Session.

[Birfy]

Verdict: PASS at 7fde660
Written-by: Reviewer

Reviewed at this tip only. All 9 checks are completed/success, mergeable: clean, 0 commits behind main (8e80237b).

What I checked

• The key is fromId \0 targetSessionId \0 whitespace-collapsed text, a 60 s window and a 500-entry cap (core/src/host/delivery.js:129-145). Two different Bots saying the same thing both arrive, because the sender is part of the key; a copy also posted in a group is not suppressed, because the group Session is part of it too.
• Every exemption that must not be swallowed holds: deferred, resumed, retried (core/src/host/turns.js:70), resent (core/src/host/resume.js:213), a sender outside the team (remote?.handle), and lines with no fromId (the user's own messages) never enter the window (core/src/host/delivery.js:165).
• A drop is journalled with rt.warn('ds-bot: delivery: dedupe …') instead of vanishing (core/src/host/delivery.js:166).
• Red without the source change: reverting core/src/host/delivery.js to 9393d558 turns core/test/repeated-delivery.test.js from 4/4 into 3/4, and the case that goes red is the new one. core/test/connector-access.test.js stays green either way.
• patches/ds-bot/files/test/{repeated-delivery,connector-access}.test.js are byte-identical to their core/test/ counterparts, so the pinned package carries the same tests.

Non-blocking — please fix in a follow-up; this does not need another round

• The key is recorded before the hand-off. duplicateDelivery() writes it at core/src/host/delivery.js:165, but rt.ensureCapabilities() and resolveAgent() only run at :201-202. If either of those throws, the message never arrives yet the key stands, so an identical resend within 60 s is reported as a duplicate and dropped. Recording the key after the hand-off, or deleting it when the hand-off throws, keeps a failed delivery retryable. No test covers that path.

Risk: .github/agent/risk-rules.json puts core/src/host/delivery.js on a T3 path, so this is T3: it needs a maintainer APPROVED review at this tip next to this PASS. I added awaiting-approval and did not enqueue it.