Blockers live in a free-text board field, not GitHub's built-in blocked-by relationship: 73 edges on 29 cards, and the one built-in edge is invisible to /issue-check #1893

Blockers are recorded in a free-text project field (Blocked by) instead of GitHub's built-in issue relationship ("Blocked by" / "Blocking" on the issue sidebar, REST issues/{n}/dependencies/blocked_by). The owner assumed the built-in one was already in use (2026-10-05). It is not: across all 470 open issues, exactly one built-in edge exists, and the owner added it today.

Measured (2026-10-05, 36efdf54a)

$ gh api --paginate 'repos/jlaustill/c-next/issues?state=open&per_page=100' \
    --jq '.[] | select(.pull_request==null) | select(.issue_dependencies_summary.total_blocked_by > 0) | .number'
1428          # -> #1844, added by the owner 2026-10-05 instead of the text field

The board (642 items, --paginate) has a non-empty Blocked by text field on 29 cards: 8 open and 21 closed. Parsed with BlockedByField.parse, the leading-run rule that order-backlog already uses, they name 73 edges, 28 of them on open cards:

A bare #\d+ scan of the same text would invent edges, because much of it is commentary that cites issues which are not blockers. BlockedByField.ts's header measured five such edges on 2026-09-12. One card (#1489) has text but parses to no blockers.

Today the text field is the only blocker source for:

• Skills: .claude/skills/issue-check/SKILL.md (Phase 1d, 19 references) and .claude/skills/start-issue/SKILL.md (Phase 3 reads it, Phase 7c appends to it).
• Docs: CLAUDE.md § "A Card That Turns Out Blocked Is Paused" and docs/WORKFLOW.md § Blocked by.
• Backlog ordering: scripts/order-backlog.ts, scripts/backlog/{BlockedByField,BacklogOrder}.ts and scripts/utils/ProjectBoard.ts (BLOCKED_FIELD), run by .github/workflows/backlog-order.yml.
• Board setup: npm run project:setup, which creates the field.

Because nothing else reads the built-in relationship, the edge the owner added on #1428 is invisible to /issue-check. #1428 would still be recommended as unblocked.

The built-in relationship also bears on two open cards about the text field: #1665 (GitHub caps the field near 1 KB, so a required append eventually cannot be written) and #1419 (records destroyed by overwrites, since the field keeps no history).

Definition of done

• Every edge a Blocked by value still claims (all 29 cards, open and closed) exists as a built-in blocked-by relationship. An edge the same text withdraws is not created (An integer × float product is routed into the integer clamp helper: u32 3 × 2.5 evaluates to 6.0, exit 0 #1668's "ADR-052 was accepted and #111 closed, but nothing implemented it: i64 x <- -0x80000000 stores +2147483648 on the host #1780 no longer gates it"). The numbers re-measured at migration time match the edges created.

  Reworded 2026-10-06 by owner ruling 1 (was: "Every edge BlockedByField.parse finds in a Blocked by value …"). Taken literally, the old wording created an open An integer × float product is routed into the integer clamp helper: u32 3 × 2.5 evaluates to 6.0, exit 0 #1668 ← ADR-052 was accepted and #111 closed, but nothing implemented it: i64 x <- -0x80000000 stores +2147483648 on the host #1780 edge that An integer × float product is routed into the integer clamp helper: u32 3 × 2.5 evaluates to 6.0, exit 0 #1668's own text withdraws.

• Nothing in the text is lost. Commentary that the built-in relationship cannot hold (the reasons after each leading run, Release v0.3.1 #1324's "every open v0.3.1-milestone card", scripts/ typecheck skips its 4 JS files (91 errors under checkJs), and generate-cpp-snapshots.ts duplicates npm test -- <path> --update #1489's text) is preserved on its card.
• /issue-check, /start-issue and backlog ordering decide blocked-ness from the built-in relationship. Each is mutation-checked: an open built-in blocker that the reader ignores turns its test or gate red.
• CLAUDE.md, docs/WORKFLOW.md and both skills tell people to record a blocker as a built-in relationship. No instruction writes the text field any more.
• The text field's fate is an owner ruling, recorded here (retire it, or keep it read-only as an archive), along with what that means for Blocked by is append-only by rule, but GitHub caps the text field (~1 KB), so the required append eventually cannot be written #1665 and Two Blocked by records were already destroyed after their blockers closed; #1322's is recoverable from git #1419.
• npm run test:gate is green.

Open question for the owner

The current rule says Blocked by is a permanent record that is never cleared and only appended to. Does a built-in edge to a blocker that has closed satisfy that "record" requirement, or does the history also need a comment? This decides box 2.

Written by Devin