Plain `bd show <rig-id>` answers from HQ and reports "never existed" for a live rig bead, with a hint that rules out the real cause #27

New issue

Open

opened 2026-09-09 22:32:18 +00:00 by forgejo-admin · 0 comments

forgejo-admin commented

2026-09-09 22:32:18 +00:00

Owner

What happens

bd show ce-j7fj from the city root prints:

Issue ce-j7fj not found
Hint: this ID may have never existed, or may reference a deleted/purged record with no trace left in the live database — try 'bd history ce-j7fj'

ce-j7fj exists. It is open, in_progress, assigned to celilo/gastown.furiosa, with a lease heartbeating. gc bd show ce-j7fj finds it immediately and prints gc bd: answering from the rig "celilo" store first.

Measured 2026-09-09 22:30Z.

gc bd show ce-j7fj              -> found, IN_PROGRESS, assignee celilo/gastown.furiosa
gc bd show ce-j7fj --rig celilo -> found, identical
bd show ce-j7fj                 -> "Issue ce-j7fj not found"

Why it matters more than a wrong store

The store scoping is already known: plain bd answers from HQ, and HQ holds no rig beads. CLAUDE.md documents that for bd ready.

The new part is the hint, which does not say "wrong store". It offers two explanations, "may have never existed" and "deleted/purged record", and both are false. A reader who takes the hint at face value concludes the bead was never filed or was destroyed, which is the opposite of the truth: the bead is live and someone is working it right now.

That is the empty-answer trap with an active push in the wrong direction. An operator hit exactly this today and reported the bead as non-existent. The next reasonable step after that conclusion is to re-file it, which produces the duplicate this repo has already seen several times.

bd history ce-j7fj, the command the hint recommends, also reads the HQ store, so following the hint confirms the wrong answer.

Suggested fix

When a lookup misses in the current store and the ID carries a known rig prefix (ce-, ga-, gs-), say so instead of guessing:

Issue ce-j7fj not found in the HQ store.
The `ce-` prefix belongs to the rig "celilo". Try: gc bd show ce-j7fj --rig celilo

Failing that, drop "may have never existed" from the hint whenever the ID's prefix does not match the store being queried. Saying nothing is better than ruling out the real cause.

Same family as the store/scope traps already recorded in gc-scratch CLAUDE.md under "Tool traps in this city": a reporting command answers about a smaller set than you asked for and says nothing about the difference. This one goes further by naming two causes that are both wrong.

## What happens `bd show ce-j7fj` from the city root prints: ``` Issue ce-j7fj not found Hint: this ID may have never existed, or may reference a deleted/purged record with no trace left in the live database — try 'bd history ce-j7fj' ``` `ce-j7fj` exists. It is open, `in_progress`, assigned to `celilo/gastown.furiosa`, with a lease heartbeating. `gc bd show ce-j7fj` finds it immediately and prints `gc bd: answering from the rig "celilo" store` first. Measured 2026-09-09 22:30Z. ``` gc bd show ce-j7fj -> found, IN_PROGRESS, assignee celilo/gastown.furiosa gc bd show ce-j7fj --rig celilo -> found, identical bd show ce-j7fj -> "Issue ce-j7fj not found" ``` ## Why it matters more than a wrong store The store scoping is already known: plain `bd` answers from HQ, and HQ holds no rig beads. CLAUDE.md documents that for `bd ready`. The new part is the **hint**, which does not say "wrong store". It offers two explanations, "may have never existed" and "deleted/purged record", and both are false. A reader who takes the hint at face value concludes the bead was never filed or was destroyed, which is the opposite of the truth: the bead is live and someone is working it right now. That is the empty-answer trap with an active push in the wrong direction. An operator hit exactly this today and reported the bead as non-existent. The next reasonable step after that conclusion is to re-file it, which produces the duplicate this repo has already seen several times. `bd history ce-j7fj`, the command the hint recommends, also reads the HQ store, so following the hint confirms the wrong answer. ## Suggested fix When a lookup misses in the current store and the ID carries a known rig prefix (`ce-`, `ga-`, `gs-`), say so instead of guessing: ``` Issue ce-j7fj not found in the HQ store. The `ce-` prefix belongs to the rig "celilo". Try: gc bd show ce-j7fj --rig celilo ``` Failing that, drop "may have never existed" from the hint whenever the ID's prefix does not match the store being queried. Saying nothing is better than ruling out the real cause. ## Related Same family as the store/scope traps already recorded in gc-scratch CLAUDE.md under "Tool traps in this city": a reporting command answers about a smaller set than you asked for and says nothing about the difference. This one goes further by naming two causes that are both wrong.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

celilo/gascity#27

No description provided.

Rows
Columns

Plain bd show <rig-id> answers from HQ and reports "never existed" for a live rig bead, with a hint that rules out the real cause #27

What happens

Why it matters more than a wrong store

Suggested fix

Related

Plain `bd show <rig-id>` answers from HQ and reports "never existed" for a live rig bead, with a hint that rules out the real cause #27