Audit + fix: post-push duplicate-nudge regression on PR #11428 (June 1) — add dedupe check before auto-nudge

Per LEARNINGS 2026-06-02 04:10 UTC Action Item #2. Context: On 2026-06-01 the Kai bot sent two redundant post-push nudges to Carson's DM (D0B0980TR88) on PR #11428: one at 07:10:18 UTC ("Quick next-morning nudge...") and one at 17:55:42 UTC ("Quick afternoon follow-up..."). Between them, no material PR change (state/mergeStateStatus/reviewDecision/CI all unchanged). This violated MEMORY.md Core Rule #11 (ping-once-then-back-off, 24h budget per PR/task/topic, material-change requirement) and the May 7 anti-spam discipline. First contact-discipline regression in ~25 days. MANDATORY first step: (0) eval "$(~/bin/gh-fleet-token.sh)" — QUOTED form. Verify GH_TOKEN length > 0. (0b) export LINEAR_API_KEY=$(cat /home/agent/agents/carson-engineer/.linear-token) — required for Linear issue creation. DoD steps: (a) Identify which runtime path produced the two June 1 #11428 nudges. Candidates to inspect: - ~/shared-knowledge/POST-PUSH-PROTOCOL.md and any scripts it references - ~/agents/carson-engineer/HEARTBEAT.md and any heartbeat scripts (~/bin/*, scripts/, hooks/) - ~/agents/carson-engineer/IDLE-PROTOCOL.md - cron entries (crontab -l) - Look for grep-able strings 'next-morning nudge', 'post-push follow-up', 'afternoon follow-up', 'just following the post-push' Document what was found in result.runtime_path_identified (file path + relevant line numbers, or 'not identified' if can't pinpoint). (b) cd /home/agent/agents/carson-engineer && git fetch origin main && git checkout -b kai/post-push-dedupe-check (c) Edit the appropriate doc(s) — at minimum AGENTS.md and/or HEARTBEAT.md — to add a 'Post-push nudge duplicate-suppression check' section. Required content: - Before any auto-DM to Carson on PR-status, READ last 25 messages in his DM channel. - GREP for the PR number / task id / topic keyword. - If a same-PR nudge was sent in the last 24h AND the PR's mergeStateStatus / reviewDecision / failing-checks count is unchanged since that nudge, NO_SEND. - Time-since-push alone is NOT sufficient to fire a follow-up nudge; only material change (CI status flipped, new review comment, mergeStateStatus changed, reviewDecision changed) justifies one. - 'Following the post-push protocol' is subordinate to MEMORY.md Core Rule #11; protocol-compliance is not a defense against ping-once violation. - Cite precedent: LEARNINGS 2026-06-02 (two duplicate #11428 nudges on 2026-06-01) and May 7 reflection (foundational anti-spam discipline). (d) If a script is identified as the responsible runtime path, queue a FOLLOW-UP fleet-task targeting that script with the dedupe-check baked in as code (do not fix the script in this same PR — keep this PR doc-only for reviewability). Record the follow-up task id in result.followup_task_id. (e) Create Linear issue (LINEAR_API_KEY set in step 0b): title 'Post-push duplicate-nudge dedupe check (LEARNINGS 2026-06-02 precedent)', team BOLT, link to fleet-task id + this LEARNINGS entry + PR #11428 nudge timestamps (Slack ts 1780297818.391849 and 1780336542.039489 in D0B0980TR88). (f) git add + commit with conventional commit message 'docs(agents): require duplicate-suppression check before auto-nudge to Carson (BOLT-XXXX)' and texture-coding-agent identity per TOOLS.md. (g) git push origin kai/post-push-dedupe-check (h) gh pr create --base main --head kai/post-push-dedupe-check --title 'docs(agents): require duplicate-suppression check before auto-nudge to Carson [BOLT-XXXX]' --body with: link to BOLT-XXXX, summary of June 1 regression with Slack timestamps, summary of the new dedupe gate, reference to MEMORY.md Core Rule #11 and the May 7 / June 2 LEARNINGS entries. (i) PATCH this task to completed with result.pr_url, result.linear_issue_id, result.runtime_path_identified, result.committed_sha, result.files_edited, result.followup_task_id (if applicable). No Slack DM to Carson. Doc-only PR; Carson sees the disclosure in the June 2 standup, which is the appropriate venue. Do NOT pre-fire any defensive suppression in production scripts as part of this task — write the doc fix and (if applicable) queue the code-fix follow-up; let the change propagate normally. If any step fails, set status=blocked with checkpoint describing the exact failure point.