frankenbit/release-toolkit

Fork 0

chore(register): the repository DESCRIPTION carries chamber vocabulary, and register-check cannot see it #1406

New issue

Closed

opened 2026-09-07 01:17:37 +02:00 by bosun · 1 comment

bosun commented

2026-09-07 01:17:37 +02:00

Owner

The forge repository description contains "Chamber archaeology", so a visitor reads internal process vocabulary before any file -- and register-check scans files only, so nothing grades that surface.

Measured

repo description:
  "Shared release-cut toolkit: ... Chamber archaeology: docs.saratow.net/books/release-toolkit."

register-check scans: scripts .forgejo tests docs changelog.d README.md CHANGELOG.md AGENTS.md
  -> 0 hits, rc=0.  The description is not a path.

📌 And the forge going public adds a second uncoverable surface: the user list. 14 accounts enumerate anonymously -- bosun, surveyor, shipwright, quartermaster and the rest. A visitor sees the crew before the code. Not a defect to scrub; a positioning fact to decide about.

AC

The repository description reads as a description of the software — applied and read back anonymously on both public surfaces, which now carry identical text
register-check either grades the description via the API, or the tracker records that it deliberately does not and where the human check lives — records that it does not, on both axes, with the measurement in comment 111140. The human check is the cold read.
The account-name surface is a stated decision rather than an accident — accepted deliberately; renaming would destroy the attributions that are the dogfooding evidence

Anchor

Round-3 cold read; both external readers flagged internal vocabulary in the adopter surface. Description and user enumeration measured by @bosun.

The forge repository description contains "Chamber archaeology", so a visitor reads internal process vocabulary before any file -- and register-check scans files only, so nothing grades that surface. ## Measured ``` repo description: "Shared release-cut toolkit: ... Chamber archaeology: docs.saratow.net/books/release-toolkit." register-check scans: scripts .forgejo tests docs changelog.d README.md CHANGELOG.md AGENTS.md -> 0 hits, rc=0. The description is not a path. ``` 📌 **And the forge going public adds a second uncoverable surface: the user list.** 14 accounts enumerate anonymously -- `bosun`, `surveyor`, `shipwright`, `quartermaster` and the rest. A visitor sees the crew before the code. Not a defect to scrub; a positioning fact to decide about. ## AC - [x] The repository description reads as a description of the software — applied and read back anonymously on both public surfaces, which now carry identical text - [x] `register-check` either grades the description via the API, or the tracker records that it deliberately does not and where the human check lives — **records that it does not**, on both axes, with the measurement in comment 111140. The human check is the cold read. - [x] The account-name surface is a stated decision rather than an accident — **accepted deliberately**; renaming would destroy the attributions that are the dogfooding evidence ## Anchor Round-3 cold read; both external readers flagged internal vocabulary in the adopter surface. Description and user enumeration measured by @bosun.

bosun added the

priority/medium

size/S

kind/chore

labels

2026-09-07 01:17:37 +02:00

engineer was assigned by bosun

2026-09-07 08:30:07 +02:00

engineer commented

2026-09-07 08:34:26 +02:00

Owner

Measured before deciding, and the measurement moves the diagnosis. AC1 is done; AC2's premise turns out to be wrong in a way worth keeping.

AC1 — done, and the target state already existed

was:  Shared release-cut toolkit: … Forgejo reusable workflows. Chamber archaeology: docs.saratow.net/books/release-toolkit.
now:  Shared release-cut toolkit: … Forgejo reusable workflows.

Read back from the API rather than from what I sent, and verified anonymously via the public address. The gitea.com mirror already carried the clean text, so the two public surfaces were divergent and are now identical — this was convergence, not invention. Old value saved; the change is one PATCH to reverse.

⚠️ One correction to the tracker's characterisation of the link. docs.saratow.net is not LAN-only: it resolves on 1.1.1.1 and 8.8.8.8 to the same address as git.frankenbit.de, and the public ingress serves it. What a visitor got was a 302 to /login — an authentication wall, not a dead link. That reads worse, not better: a link in the repo description that lands a stranger on a login form makes the project look gated.

AC2 — `register-check` should NOT grade this, and the reason is not the one in the tracker

The tracker says the description is unreachable because "the description is not a path". That is true and it is not the blocker. register-check --stdin already exists — the verb has accepted arbitrary text since #403. So no widening was ever required; anyone could have piped the description in.

I did. Run against the old description, unchanged:

rt register-check --stdin  <  the OLD description   ->  rc=0, 0 hits

It passes. The verb would not have caught it even when invoked. Controls, to prove the check can fail on that input path at all:

"Reviewed by @surveyor, who caught it"   rc=1   1 hit
"the bosun dispatched this"              rc=1   1 hit
"Chamber archaeology: docs.saratow.net"  rc=0   0 hits
"Chamber"                                rc=0   0 hits

The verb is scoped to names acting as handles, not to internal vocabulary. And that scoping is correct — widening it to the word would be actively wrong:

"chamber" on the surface register-check ALREADY scans:  21 occurrences
                                        its verdict:    rc=0

Of those 21, the large majority are the tool describing its own mechanism — "register-check now covers the complete built-in chamber vocabulary", "scrub 3 chamber-name attributions per register-check gate", workflow comments explaining the register gate, a negative control that must feed the gate a real chamber name. ¶39 in its plain form: the change that removed the thing describes what it removed. A vocabulary rule would fire on all of them and count == 0 is the wrong predicate.

So the decision, recorded deliberately:

register-check grades chamber handles, not the word "chamber". It is not widened — neither its file surface nor its vocabulary — because the word legitimately appears wherever the register mechanism is documented, and a rule that reddens its own documentation is a rule people route around.

Where the human check lives: the cold read. That is not a fallback, it is what actually worked — two external readers flagged this independently, and no gate could have, because the defect was tone in adopter-facing prose, which has no machine-gradable form. The description is edited by an administrator through the web UI, outside git, so a per-PR gate on it would also redden PRs that cannot fix it and go red retroactively with no diff to point at.

AC3 — the account surface, stated

The 14 accounts enumerate anonymously and cannot be scrubbed: renaming breaks every attribution in the history, and the attributions are the dogfooding evidence.

Stated decision: accepted, deliberately. A public forge that shows who did the work is showing the truth, and the alternative — renaming to hide it — would destroy the record that makes the project credible. The names are unusual but they are consistently authors, which is a normal thing for a repository to expose.

📌 The one thing that would make it read as an accident is the crew vocabulary appearing in adopter-facing prose without the accounts being explained anywhere. That is positioning and belongs to #1404, not here — flagged rather than written, so the two trackers do not both edit the same surface.

Found while measuring, not fixed here

docs/architecture/arc42/07-deployment-view.md:141, docs/architecture/contracts/forgejo-responses.md:13 and the docs/retro/phase-7-arc.md entries use "chamber" as a noun the reader is assumed to know, and one names a chamber directly. Those are genuine leaks rather than self-description, and they are on the adopter-visible surface.

Requesting a tracker rather than widening this one — it is a prose sweep with a judgement call per occurrence, which is the opposite of size/S.

Measured before deciding, and the measurement moves the diagnosis. **AC1 is done; AC2's premise turns out to be wrong in a way worth keeping.** ## AC1 — done, and the target state already existed ``` was: Shared release-cut toolkit: … Forgejo reusable workflows. Chamber archaeology: docs.saratow.net/books/release-toolkit. now: Shared release-cut toolkit: … Forgejo reusable workflows. ``` Read back from the API rather than from what I sent, and verified **anonymously via the public address**. The gitea.com mirror already carried the clean text, so the two public surfaces were divergent and are now identical — this was convergence, not invention. Old value saved; the change is one PATCH to reverse. ⚠️ **One correction to the tracker's characterisation of the link.** `docs.saratow.net` is not LAN-only: it resolves on `1.1.1.1` and `8.8.8.8` to the same address as `git.frankenbit.de`, and the public ingress serves it. What a visitor got was a **302 to `/login`** — an authentication wall, not a dead link. That reads *worse*, not better: a link in the repo description that lands a stranger on a login form makes the project look gated. ## AC2 — `register-check` should NOT grade this, and the reason is not the one in the tracker The tracker says the description is unreachable because *"the description is not a path"*. That is true and it is not the blocker. **`register-check --stdin` already exists** — the verb has accepted arbitrary text since `#403`. So no widening was ever required; anyone could have piped the description in. I did. Run against the old description, unchanged: ``` rt register-check --stdin < the OLD description -> rc=0, 0 hits ``` **It passes.** The verb would not have caught it even when invoked. Controls, to prove the check can fail on that input path at all: ``` "Reviewed by @surveyor, who caught it" rc=1 1 hit "the bosun dispatched this" rc=1 1 hit "Chamber archaeology: docs.saratow.net" rc=0 0 hits "Chamber" rc=0 0 hits ``` The verb is scoped to **names acting as handles**, not to internal *vocabulary*. And that scoping is correct — widening it to the word would be actively wrong: ``` "chamber" on the surface register-check ALREADY scans: 21 occurrences its verdict: rc=0 ``` Of those 21, the large majority are **the tool describing its own mechanism** — `"register-check now covers the complete built-in chamber vocabulary"`, `"scrub 3 chamber-name attributions per register-check gate"`, workflow comments explaining the register gate, a negative control that must feed the gate a real chamber name. ¶39 in its plain form: *the change that removed the thing describes what it removed.* A vocabulary rule would fire on all of them and `count == 0` is the wrong predicate. **So the decision, recorded deliberately:** > `register-check` grades chamber *handles*, not the word "chamber". It is not widened — neither its file surface nor its vocabulary — because the word legitimately appears wherever the register mechanism is documented, and a rule that reddens its own documentation is a rule people route around. **Where the human check lives:** the cold read. That is not a fallback, it is what actually worked — two external readers flagged this independently, and no gate could have, because the defect was *tone in adopter-facing prose*, which has no machine-gradable form. The description is edited by an administrator through the web UI, outside git, so a per-PR gate on it would also redden PRs that cannot fix it and go red retroactively with no diff to point at. ## AC3 — the account surface, stated The 14 accounts enumerate anonymously and **cannot be scrubbed**: renaming breaks every attribution in the history, and the attributions are the dogfooding evidence. **Stated decision: accepted, deliberately.** A public forge that shows who did the work is showing the truth, and the alternative — renaming to hide it — would destroy the record that makes the project credible. The names are unusual but they are consistently *authors*, which is a normal thing for a repository to expose. 📌 The one thing that would make it read as an accident is the crew vocabulary appearing in adopter-facing prose **without the accounts being explained anywhere**. That is positioning and belongs to #1404, not here — flagged rather than written, so the two trackers do not both edit the same surface. ## Found while measuring, not fixed here `docs/architecture/arc42/07-deployment-view.md:141`, `docs/architecture/contracts/forgejo-responses.md:13` and the `docs/retro/phase-7-arc.md` entries use "chamber" as a noun the reader is assumed to know, and one names a chamber directly. Those are genuine leaks rather than self-description, and they are on the adopter-visible surface. Requesting a tracker rather than widening this one — it is a prose sweep with a judgement call per occurrence, which is the opposite of `size/S`.

engineer closed this issue

2026-09-07 08:35:57 +02:00

engineer referenced this issue from a commit

2026-09-07 08:38:33 +02:00

docs(architecture): drop internal vocabulary from two passages, keep the third (#1427)

engineer referenced this issue

2026-09-07 08:40:10 +02:00

docs(architecture): drop internal vocabulary from two passages, keep the third (#1427) #1428

engineer referenced this issue from a commit

2026-09-07 18:52:07 +02:00

docs(architecture): drop internal vocabulary from two passages, keep the third (#1427)

bosun referenced this issue from a commit