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.
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
| id | iss-2609100506269348 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | major |
.abcd/work/issues/open/iss-2609100506269348-the-public-banlist-cannot-exist-when-a.md
open on GitHub ↗ · commit history ↗
References2
- itd-159the managed .gitignore visibility table has no mode for a public repo that commits its record: on abcd-cli (public, single-repo-curated-release, .abcd/** deliberately in-tree) ahoy install applied the public policy and fenced /.abcd/ and /memory/, contradicting the repo's own boundary that the record is present in every checkout. The visibility table needs a committed-record declaration (config or marker) that suppresses the fencerelated
- itd-2609151516525843A Repository Can Ban A Name On Its First Commit, And A Machine Can Ban One Everywhererelated
mentions4
- dcn-26091500000000032026-09-15 — Banned names get both halves (product thinker, ruling on iss-2609100506269348, choosing "both" once told a home list is invisible to CI): a committed declaration lifts the public visibility fence so a fresh public repository can create its committed banned-names layer on its first commit, and a machine-global private list in the user-level home bans a name in every repository on the machine. CI never reads the home list and nothing from it reaches a committed file. Filed as itd-2609151516525843 (`builds_on` itd-74, `refines` adr-56); whether the home is one macOS user's or shared across users stays the product thinker's separate open question. Rejected: move the banlist config out of the hidden directory; make the public list private-visibility only.
- iss-176The public banned-names family lives at .abcd/docs-lint.json, which the installed .gitignore fence ignores under visibility public, so the layer that claims to be committed and CI-enforced is untracked exactly where public exposure is the risk
- iss-223the managed .gitignore visibility table has no mode for a public repo that commits its record: on abcd-cli (public, single-repo-curated-release, .abcd/** deliberately in-tree) ahoy install applied the public policy and fenced /.abcd/ and /memory/, contradicting the repo's own boundary that the record is present in every checkout. The visibility table needs a committed-record declaration (config or marker) that suppresses the fence
- iss-2609261457353277itd-74 ac-5 promises the public family present after ahoy scaffolding; where the docs-lint config path is gitignored (TestPublicFamilyUnderPublicVisibility) install writes no public family and reports the gap as unresolvable, leaving that repo with no CI-enforced banned-names family