[BUG] The reconcile sweep cannot see two issues claiming the same sidekick

[TaekeK]

What's wrong? (one or two sentences)

Two open issues can carry the same sk: label at once, and nothing notices. The sweep's zombie check (🧟) only fires for a claim with no open PR, so when both claimants have an open PR — which is the normal state for a built issue awaiting acceptance — the collision is invisible.

Steps to reproduce

Currently live on the Feature/Bug boards:

sk:sk3: 370
sk:sk6: 943
sk:sk7: 819, 665   <-- both open, both with an open PR
sk:sk9: 758

1. gh issue list --state open --json number,labels and group the open issues by their sk: label.
2. sk7 is claimed by both [BUG]Excel powerqueries only works while ignoring privacy labels #819 (PR [BUG]Excel powerqueries only works while ignoring privacy labels #1000 open) and [Refactor] Dedup the test-file db-mock boilerplate (~20 jscpd clone pairs) via a __mocks__ manual mock #665 (PR [Refactor] Dedup the test-file db-mock boilerplate (~20 jscpd clone pairs) via a __mocks__ manual mock #1007 open).
3. Run the sweep. Neither is reported.

✅ What did you expect to happen?

A box can hold exactly one issue. Two open issues claiming one sidekick means at least one claim is stale, and the sweep is the component whose job is to notice that the recorded state and the real state have diverged.

❌ What actually happened?

Nothing is reported, and the consequence is silent. dor-acceptance loop E resolves the sidekick from the issue's sk: label and dispatches the run to that box, where the job asks "Am I the holder of issue #N?" against the box's own reservation. For the stale claimant that answers no, the job sets holder=false and exits — no comment, no board move, no error. The requestor asked for a change and gets silence, which is the exact failure mode the flow's own comments say it was built to avoid.

Root cause

.github/scripts/dor_reconcile.sh, the 🧟 arm of the per-issue walk:

if [ -n "$sk_label" ] && [ "$status" != "Building" ]; then
  if open_pr="$(gh pr list … --head "dor/issue-${num}" --state open …)"; then
    [ -z "$open_pr" ] && add_ex "🧟 #${num} still claims \`${sk_label}\` with no open PR — …"
  fi
fi

The check tests one issue at a time and treats "has an open PR" as proof the claim is legitimate. It has no notion of a claim being exclusive, so it cannot compare claims against each other.

There is a structural obstacle: the walk is now per-board, and a collision can span both pipelines — which is exactly the live case, #819 on the Bug board and #665 on the Feature board. A per-board walk can never see it.

Suggested direction

Collect the sk: claims repo-wide, once per sweep, independently of the per-board walk, and flag any box claimed by more than one open issue. That is a single gh issue list --state open plus a group-by, and it is the only formulation that catches a cross-board collision.

Worth considering alongside it: have the build side drop the previous holder's sk: label when it reserves a box, so the collision cannot persist in the first place. The sweep would then be a backstop rather than the only detector.

Also adjacent, and cheaper to fix at the same time: §3b (closed issues still claiming a sidekick) queries --label "$LABEL", so a closed issue without the gate label is missed there for the same class of reason.

Does it reproduce on the demo data?

Not applicable — pipeline automation, not product code. It reproduces against this repo's own boards, shown above.

Where does it happen? (optional)

.github/scripts/dor_reconcile.sh — the 🧟 checks in the per-issue walk and in §3b.

Did it work before? (optional)

No indication it ever did. The 🧟 check was written to catch an abandoned reservation, and a collision is a different shape of the same problem that it was never asked about.

[github-actions]

@TaekeK — confirmed, every claim in the report checks out against the code — and the backlog snapshot this run received corroborates the live collision (#819 carries bug + sk:sk7, #665 carries enhancement + sk:sk7, both open). But this is the pipeline's own supervisory tooling, not product code — as you noted yourself under "reproduces on demo data". Per the process (and the precedent of #997, #721, #716), it routes out of pipeline: the fix lands via the normal dev flow, since the DoR build machinery (demo-data deploy, sidekick acceptance) has nothing meaningful to run for a change to its own reconcile script. Everything a fixer needs is batched below.

Reproduction (static — verified against the real scripts)

1. The 🧟 arm is per-issue and treats "has an open PR" as legitimacy. .github/scripts/dor_reconcile.sh:293-297: sk_label set + status ≠ Building + gh pr list --head "dor/issue-${num}" non-empty → silent. [BUG]Excel powerqueries only works while ignoring privacy labels #819 and [Refactor] Dedup the test-file db-mock boilerplate (~20 jscpd clone pairs) via a __mocks__ manual mock #665 each individually pass that test, so the sk7 collision produces no line. Nothing anywhere in the script groups claims by sk: value — the exclusivity invariant is simply not expressed.
2. The cross-board case is structurally invisible. The walk is driven by board membership plus the per-$LABEL query (dor_reconcile.sh:177-195), and the workflow runs the script once per board (.github/workflows/dor-reconcile.yml:50-59). [BUG]Excel powerqueries only works while ignoring privacy labels #819 is only ever walked by the Bug sweep, [Refactor] Dedup the test-file db-mock boilerplate (~20 jscpd clone pairs) via a __mocks__ manual mock #665 only by the Feature sweep; no single invocation holds both claims, so even a per-sweep group-by inside the walk could not catch the live case.
3. §3b has the same gate-label blindness the open walk was already cured of. dor_reconcile.sh:316 queries closed issues with --label "$LABEL"; a closed issue that lost its gate label but kept sk: is invisible — the exact failure class documented at dor_reconcile.sh:168-176 (42 of 74 Feature-board items had no gate label) and pinned by test 7 of the harness, surviving in this one query.
4. The silent consequence is real. dor-acceptance.yml loop E resolves the box from the issue's sk: label (dor-acceptance.yml:202) and the landing job answers "am I the holder?" from the box's own ~/.dor-reservation; a non-holder sets holder=false and exits 0 (dor-acceptance.yml:228). For the stale claimant, requestor feedback is dispatched and dropped with no comment — silence being precisely what dor-acceptance.yml:333 says is "the worst outcome we have".

Root cause — two layers

• Detector (this issue): the 🧟 check answers "is this claim justified?" per issue and cannot answer "is this claim exclusive?" across issues. A repo-wide invariant is being checked from a per-board, per-issue walk. Layer: pipeline tooling, .github/scripts/dor_reconcile.sh.
• Origin (why a collision can exist at all — worth fixing in the same PR): claim_sidekick in .github/scripts/dor_build_lib.sh:200-212 enforces exclusivity in only one direction. It drops this issue's other sk:* labels ("one issue holds ≤ 1 box") but never drops another issue's claim on the same box ("one box held by ≤ 1 issue"). When a build landed [Refactor] Dedup the test-file db-mock boilerplate (~20 jscpd clone pairs) via a __mocks__ manual mock #665 on sk7 while [BUG]Excel powerqueries only works while ignoring privacy labels #819 still wore sk:sk7, ~/.dor-reservation was overwritten and [BUG]Excel powerqueries only works while ignoring privacy labels #819's label went stale with nothing to notice. Your "have the build side drop the previous holder" suggestion is exactly the missing other half of the exclusivity comment already at dor_build_lib.sh:203-206 — and with it in place, the sweep check becomes the backstop it should be.

Blast radius

• .github/scripts/dor_reconcile.sh — new repo-wide collision section; §3b query widened.
• test/ci-scripts/test-dor-reconcile-liveness.sh — two new stub arms + fixtures (runs in CI via pr.yml:878, so the regression test is enforced).
• .github/scripts/dor_build_lib.sh (claim_sidekick) if the prevention half is taken — safe: once this box's reservation file says "me", any other issue's claim on this box is stale by definition, and the label edit is already fault-tolerant (|| warning, dor_reconcile.sh-style).
• Health-issue consumers: a new exception line changes the fingerprint → exactly one notification comment; nothing else parses the exception text.
• No product code, schema, API, or UI is touched; no new token scopes needed (the repo-wide query is Issues-read, already used).

Implementer notes (the three sharp edges):

1. The collision scan must run outside the per-issue walk, from one gh issue list --state open --json number,labels with no label filter — the only formulation that sees both boards.
2. The script runs twice per sweep (once per board), so the same collision line would land in both health issues — either accept that or gate the scan to one invocation (e.g. only when LABEL != bug).
3. add_ex's fingerprint keys off the marker plus the first #N in the line (dor_reconcile.sh:50-56). A collision line naming two issues should key off all claimants, else sk7: #819+#665 changing to sk7: #819+#943 is not "news" and never notifies.

Drafted regression test (red today, green with the fix)

For test/ci-scripts/test-dor-reconcile-liveness.sh, in the harness's own style. Two stub changes in make_stub — replace the "pr list"* arm and add a repo-wide arm after the label-filtered issue list arms (first match wins):

  # Repo-wide sk:-collision scan — every open issue, NO label filter (the fix's new query).
  # Must sit BELOW the --label-filtered arms so those still match first.
  *"issue list"*"--state open"*"--json number,labels"*)  serve open_all.json "$@" ;;
  # An open PR per claimant when the fixture provides one — the shape that makes 🧟 silent.
  "pr list"*)  [ -f "$FIX/open_pr.txt" ] && cat "$FIX/open_pr.txt" || : ;;

And the test:

echo
echo "DoR reconcile — a box claimed by two open issues"
echo

# ── 17. Two OPEN issues claiming the same sidekick must be flagged ──────────
# Live case (2026-08): #819 (Bug board) and #665 (Feature board) both carried `sk:sk7`,
# both with an open PR, and neither sweep said a word. The 🧟 arm treats "has an open PR"
# as proof the claim is legitimate and has no notion of exclusivity, and the per-board
# walk can never see a claimant that lives on the other board.
collision_scenario() {
  local dir="$1" now
  now="$(date -u +%s)"
  rm -rf "$dir"; mkdir -p "$dir"; make_stub "$dir"
  : > "$dir/writes.log"; : > "$dir/live_runs.txt"; : > "$dir/titles.tsv"
  printf '[]\n' > "$dir/health_list.json"; printf '[]\n' > "$dir/marked.json"
  # Every claimant has an open PR, so the existing 🧟 arm stays silent — the live shape.
  printf '1007\n' > "$dir/open_pr.txt"
  # This (Feature) board carries only #665 — healthy by every existing per-issue check.
  board_doc "$(board_node 665 OPEN 'Awaiting functional acceptance' "$now" "$now" 'enhancement,sk:sk7')" \
    > "$dir/board.json"
  issue_node 665 "$now" "$now" 'enhancement,sk:sk7' | jq -s . > "$dir/issues.json"
  # The other claimant is a bug — only a REPO-WIDE open-issue query can see both.
  { issue_node 665 "$now" "$now" 'enhancement,sk:sk7'
    issue_node 819 "$now" "$now" 'bug,build-done,sk:sk7'; } | jq -s . > "$dir/open_all.json"
  printf '%s' "$dir"
}

out="$(run_sweep "$(collision_scenario "$TMP/collision")")"
assert_contains "a box claimed by two open issues is flagged" 'sk:sk7' "$out"
assert_contains "…naming the claimant on this board"          "#665"   "$out"
assert_contains "…and the claimant on the other board"        "#819"   "$out"
assert_lacks    "…without mis-flagging either as a zombie"    "🧟"     "$out"

Today this is red: with both PRs open no existing check fires, so no health report is published at all and the first three assertions fail. The §3b half gets its own small case — a closed_scenario row keeping sk:sk3 but no gate label, asserting the CLOSED-🧟 line — once the query drops the label filter (splitting board ownership by the bug label the way §3c's belongs_here already does).

Duplicates / related

No duplicate in the open backlog. #886 is the health issue this sweep writes into, not a report of this gap. No other open issue shares the root cause.

Route: state:out-of-pipeline — real, reproducible, root-caused, but pipeline tooling; fix it through the normal dev flow with the test above (bash tooling, so the coverage ratchet doesn't apply, but the CI harness does).