From 2bab52dc7103b231987fda49ba2022182ef34970 Mon Sep 17 00:00:00 2001
From: cndgrr <59120057+cndgrr@users.noreply.github.com>
Date: Mon, 3 Aug 2026 21:15:37 +0000
Subject: [PATCH] fix(issueflow): the echo's illustrative #9 is an
 illustration, not a reference
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The echo body wrote `no longer blocked by #9` unbackticked, twice in one
sentence. GitHub linkifies both, so every echo posted a pair of "mentioned in"
events onto this repo's issue #9 — an issue with nothing to do with the one
being echoed. On a 15-minute cron that is one pair per `blocked` issue on the
board, and the first sweep after merge would have written the whole board's
worth at once.

The file's own convention two branches down already avoids this: the
`blocked-unparseable` comment code-spans its `Blocked by #N` for exactly this
reason. The prose is unchanged, the rendered set is unchanged, and the marker
digests the parsed set rather than the comment body, so no marker moves.
---
 actions/issueflow-reconcile/issueflow-reconcile.sh | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/actions/issueflow-reconcile/issueflow-reconcile.sh b/actions/issueflow-reconcile/issueflow-reconcile.sh
index 99a323f..7c3bda2 100644
--- a/actions/issueflow-reconcile/issueflow-reconcile.sh
+++ b/actions/issueflow-reconcile/issueflow-reconcile.sh
@@ -625,6 +625,11 @@ The merge releases the claim; no builder owes a draft. Triage owes completion in
     # declaration; this catches the readable-but-wrong one, which no flag can
     # detect because the machine cannot judge what a human meant — only state
     # what it read, and let the human see the divergence in one sweep.
+    #
+    # The illustrative `#9` in the body below is code-spanned for the same
+    # reason `blocked-unparseable` code-spans its `Blocked by #N`: an
+    # unbackticked `#N` in a comment this sweep posts on a cron linkifies, and
+    # writes a "mentioned in" event onto an unrelated issue once per echo.
     parsed_set="$(blocked_parse_set "$refs" "$cross_refs")"
     parse_marker="$(blocked_parse_marker "$parsed_set")"
     if blocked_parse_echo_needed "$n" "$parse_marker"; then
@@ -633,8 +638,8 @@ This issue's \`Blocked by\` declarations parse to: $parsed_set
 
 That is the exact set this sweep gates on — what the machine read, never a
 judgment about whether it is what you meant. The parse unions every clause it
-finds, so a sentence like \"no longer blocked by #9\" contributes #9 like any
-other; over-retaining is the deliberate direction of error, because a stale
+finds, so a sentence like \`no longer blocked by #9\` contributes \`#9\` like
+any other; over-retaining is the deliberate direction of error, because a stale
 \`blocked\` is a triage comment away and a false \`ready\` sends a builder into
 work that cannot merge. If this set names something you did not declare, or
 omits something you did, edit the declaration — the next sweep echoes the