This is the record of an abcd-managed repository

abcdBetav0.16.2 · 2026-11-06

Development record

On a fresh PUBLIC repo the committed banned-names layer cannot be created, and the window in which it cannot is exactly the window in which a repo is being set up to ban a name.

issueopenmajoriss-2609100506269348

On a fresh PUBLIC repo the committed banned-names layer cannot be created, and the window in which it cannot is exactly the window in which a repo is being set up to ban a name.

The mechanism, which abcd states clearly once you are in it. For visibility public, ahoy install writes a .gitignore fence of /.abcd/ — the whole namespace. banlist add --public then refuses, because .abcd/docs-lint.json would be ignored and "a config written there would reach no CI run". The fence narrows to .abcd/.work.local/ only once .abcd/ already holds TRACKED files, because narrowing "needs positive evidence". A brand-new repo has none, so the fence stays wide, so the public layer cannot be written.

The escape exists and is not discoverable: commit the record tiers first with git add -f against the tool's own fence, then re-run ahoy install, which narrows the fence and only then writes the store. Three steps, one of them forcing past a gitignore the tool just wrote, none of them named by the refusal. The fix hint points at iss-176 and offers "commit the path explicitly, or ban the name on the private layer instead"; the second silently drops CI enforcement, which is the whole point of the public layer.

Why this is worse than an ordering wrinkle: the reason a repo reaches for the public banlist on day one is that it has a name it must never publish. That is precisely a rename or an extraction, which is precisely a new repo with nothing tracked under .abcd/ yet. The guarantee is unavailable at its own moment of need, and a maintainer who takes the offered second option gets a ratchet that CI never enforces without being told that is what changed.

Needed: let ahoy install write the public store and narrow the fence in one pass on a repo it is adopting (it is writing both files anyway), or refuse the public fence entirely for the record tiers, which abcd's own repository already does by committing .abcd/ and fencing only the local tier.

Adjacent to iss-223, which reports the same fence hiding already-committed records on a public repo; this is the other end of it, the fence preventing a record tier from ever becoming committed.

Grounds

  • pursued: the bootstrap paradox closes on a committed DECLARATION rather than on detected evidence — narrowing the fence waits on tracked files under the record namespace and the fence is what stops them existing, while a declaration is evidence a repository can give on its first commit — and the second half closes on scope: the names a person must never publish belong to that person and their machine rather than to any one repository, so a machine-global private list in the user-level home bans them everywhere at once. What would show it wrong: a fresh public repository that still cannot create its committed list with the declaration present; a machine-global entry that fails to ban a name in a second repository on the same machine; or either layer crossing the other's boundary — the home list read by CI, or any of its patterns reaching a committed file.

Deferral 2026-09-29

Deferred past v0.11.1: planning owed (re-deferred at v0.11.1 by run A's major-triage lane): the fix is itd-2609151516525843, which ruling M27 (2026-09-23) folds into draft itd-159 to be planned as one intent; both are still in drafts. That planning interview owes one ruling: is the committed-record declaration a switch value or an exception to the public-visibility fence?

Remedy grounds (2026-09-29)

  • Why: M27 is answered (one intent) and leaves one question for the planning interview, so both of its answers are written with the shared proof; the Grounds section above already names a committed declaration as the evidence that breaks the bootstrap paradox.
  • Rejected: pointing the refusal at the git add -f escape, which documents a way past the tool's own fence instead of closing the gap.

Deferral lapsed 2026-10-23

The deferral past v0.11.1 lapsed long ago and is withdrawn, on the old-majors triage of 2026-10-23. It stays open until itd-159 ships. The reason it carried stays in the body above.

Frontmatter

idiss-2609100506269348
typeissue
lifecycleopen
severitymajor

References2

mentions4