pr-issue-linkage gate conflicts with deliberately unlinked PRs, making them permanently red and rung-ineligible

[kyle-sexton]

Filed by the autonomous babysit merge lane (AI-generated) after hitting it twice in one session on two unrelated PRs.

The conflict

The pr-issue-linkage check fails any PR without a close-linked issue. But the repo has at least two legitimate, documented workflows that deliberately produce PRs with no close-link — and for those, the gate is not catching a mistake, it is fighting a decision the author made on purpose and explained in the PR body.

Case 1 — topic-tracked lane work. PR #1349:

No linked issue — this PR is lane L3 of the context-engineering-rightsizing topic effort, which is tracked in docs/topics/context-engineering-rightsizing/ rather than as a filed GitHub issue.

Case 2 — deliberately-not-closed refs. PR #1264:

Refs #787 — the originating report. Deliberately not closed. Its causal premise is falsified [...] and its substantive ask [...] is not delivered by this PR.

Case 2 is the sharper one: the author did the right thing. They found the originating issue's premise was falsified, re-scoped the PR to what it actually delivers, split the remainder into #1387, and refused to auto-close an issue the PR does not resolve. The gate punishes exactly that diligence.

Why it matters beyond a red check

For any lane running the loop-lane autonomy ladder, the close-link is not cosmetic — it is what carries the work-class classification. The rung partition reads the close-linked item's work-class: label to decide merge eligibility. No close-link means no class, which means not eligible at any rung, including full-autonomy.

So these PRs are in a permanent double bind:

1. CI is red forever, on a check that will never pass without changing the authoring decision.
2. No autonomous lane can ever merge them, at any autonomy level.

They can only ever be merged by a human, and the red check makes that human's job harder by looking like a real failure.

There is also a trap for autonomous lanes here, which is why this lane stopped rather than "fixing" it: adding a close-link to clear the check would mean the lane choosing the work item for the PR, and thereby manufacturing its own merge eligibility. That is exactly the thing the merge lane must never do, so the correct behavior is to leave both PRs permanently red — which is not a good steady state for the repo.

Possible directions (not a decision)

• Let a PR declare an intentional exemption the gate honors — an explicit body marker or a label — so the decision is machine-readable instead of prose the gate cannot read.
• Teach the gate to accept a docs/topics/<slug>/ tracking reference as a valid linkage target, covering case 1.
• Distinguish "closes" from "refs" in the gate: require some issue relationship, but do not require it be a closing one. This covers case 2 without weakening the check.
• Decide, separately and explicitly, how the autonomy ladder should classify work that is legitimately not issue-tracked — today the answer is "never merges autonomously", which may be intended, but is currently an emergent side effect rather than a stated policy.

Notes

Both PRs were left untouched and report-only. Nothing was merged, no link was added, no label was changed.

Deliberately filed without a work-class label; that classification belongs to triage.

[kyle-sexton]

This was generated by AI during triage.

Partially verified — one claim held up, the other no longer reproduces on the cited PRs, but the underlying design gap is real.

Role-label resolution note: .work-item-tracker.json has no config.role_labels entry; defaults (agent-ready / needs-human) are used, per the taxonomy's loud-warning requirement.

Claim 1 — "these PRs are permanently red" — does not currently hold. Checking pr-issue-linkage / pr-issue-linkage on the current heads of both cited PRs:

• PR feat(claude-config): extend the audit-instructions catalog with checks I12-I14 #1349: success (latest run, after an earlier failure on a prior push).
• PR fix(source-control): emit a readiness verdict on the gate's silent failure paths #1264: success (latest run at 21:24:54Z, after a failure at 21:22:32Z — both after this issue was filed at 20:42:59Z).

Both PRs now pass using the PR template's existing documented escape hatch — a No linked issue (or Refs #N) line plus a non-empty ## Related section — after body edits landed post-filing. So the two concrete examples are not currently stuck; the check is not permanently red on them today. This session made no changes to either PR.

Claim 2 — the rung/work-class coupling — is confirmed real and still open. plugins/source-control/skills/babysit-loop/SKILL.md (merge-eligibility partition) states directly: it resolves each open PR's close-linked work item and reads "that item's recorded work-class classification," and "a PR with no close-linked item, or an item with no recorded classification, is NOT [merge-eligible]" at any rung, including full-autonomy. So the structural bind described in this issue is accurate as a standing policy gap, independent of whether any specific PR's CI check happens to be green: a PR with no close-linked issue can never be classified into a rung and so can never be picked up by an autonomous merge lane, only by a human — exactly as described.

Routing — human-gated. This is a genuinely open, cross-repo design/policy question, not a bug with a clear fix:

• The pr-issue-linkage check itself is a reusable workflow owned by melodic-software/ci-workflows, outside this repo's control.
• The rung-classification coupling lives in this repo's source-control plugin and is deliberate policy, not an oversight — changing it means deciding, as this issue itself lays out (not deciding), whether/how legitimately-untracked work (topic-tracked lanes, deliberately-unlinked refs) should ever be autonomously mergeable, and if so how the gate or the lane should recognize that intent machine-readably.
• The issue explicitly declines to pick a direction and was filed without a work-class label for this reason.

Given the mechanism is real but not urgent (a documented escape hatch already exists and both example PRs now pass; only the always red framing was overstated), this is normal backlog flow rather than blocking.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned for this drain wave.

The conflict between deliberate no-issue PR workflows and the pr-issue-linkage gate is real but blocked on the standing convention carrier #1164 (required-PR-section loop). Until that carrier lands, authors continue documenting intentional unlinks in the PR body; the gate stays red-by-design for those workflows.

Re-open trigger: #1164 closes with a gate exemption or alternate linkage contract for topic-tracked and maintenance PRs.