---
name: a-bare-issue-number-collides-across-the-two-repos
description: In this project issues live on spt-bs-releases and code on spt-bs-core, so a bare "#N" names two unrelated things and a scope ruling can be argued about the wrong one.
metadata:
  type: feedback
---

**Measured 2026-09-10 (doyle), milestone #294 v0.69.0 golden intake.** Three agents
(deployah, hertz, todlando) spent several messages ruling on whether "#217" was an
unrecorded ninth member of the greenlit eight. It is not, but nobody had looked up
what the number named.

- `releases#217` = "wax-seal FIDO2 ceremony (fast-follow): enrolled platform
  authenticator mint path". `type: ADDITION`, `state: DONE`, CLOSED 2026-08-25,
  milestone null. Nothing to do with v0.69.0.
- core PR `#217` on `BigscreenVR/spt-bs-core` = "build(xtask): enforce bounded Brain
  read policy (#293 census)", branch `fix/293-brain-audit`. THIS is the thing in the
  assembly chain (`1ebd03dc` via merge `d9db9ff3`).

**Why:** this project's deliberate exception (issues on the *releases* repo, code on
*core*) means the two repos have INDEPENDENT `#N` sequences that both render as `#N`.
`gh` resolves a bare `#N` against whichever repo you pass, silently and successfully,
so the wrong lookup returns a real, plausible, closed request instead of an error.
Board membership is counted in RELEASES requests, so a core PR number cannot be a
member at all — the "is it a ninth member?" question is MALFORMED, not a close call.
That distinction matters: "not the kind of thing the count ranges over" needs no
reason comment and no relocation, whereas "an addition we are waving through" would
need both under the PR #135 @4669460 stipulation.

**How to apply:** write `releases#N` or `core PR #N` — never a bare `#N` — in any
scope, form, or golden-intake message. Before ruling on whether some `#N` is in or
out of a milestone, `gh issue view N --repo BigscreenVR/spt-bs-releases` AND
`gh pr view N --repo BigscreenVR/spt-bs-core`; if both resolve, the token was
ambiguous and the ruling was about to be argued against whichever one the reader
happened to assume. See [[a-filename-substring-grep-mints-a-repo-cite]] for the same
class one layer down.

**Second face, same session, same class:** I nearly sent deployah a correction saying
his "[impl->] and [unit->] tags" claim was wrong, because `1ebd03dc` alone adds only a
lone `[int->]` tag. He was describing the MERGE `d9db9ff3`, which carries FOUR commits
and all three tag kinds. Reading one commit of a four-commit merge and reporting it as
the merge is [[compare-at-one-layer-crlf-meter-class]] wearing a different hat: state
which OBJECT you measured (commit vs merge vs branch) before contradicting anyone.

**Loose end this surfaced:** core PR #217 is still OPEN with `mergeCommit` null while
its content rides in the assembly. It has to be closed as superseded at release close
or it dangles.