The launch payload's `local_username` identity rule takes the username from the last segment of HOME and hard-fails every case-insensitive occurrence of it in the payload. On a machine whose account name is an ordinary word that is also product vocabulary (an account named with the same three-letter word as the `ahoy install` track-latest flag and the "-shim" install mode it names, which appears in commands/ahoy.md, commands/update.md, commands/launch.md and docs/reference/cli/commands.md), `TestPayloadTreeImplementationsResolveIdentically` and `TestRenderPayloadLeavesSourceTreeUnversioned` fail on a pristine main (9 hard-fail findings at e6efe28f), and with them `make preflight` and the pre-push hook, so the v0.6.8 release branch could not be pushed from that machine until HOME was pointed at a symlink alias of the real home directory for the push. CI, which runs under a different account name, passes.

Frontmatter

.abcd/work/issues/wontfix/iss-2608291444328326-local-username-scan-collides-with.md
open on GitHub ↗ · commit history ↗

mentions5

• dcn-26082900000000012026-08-29 — v0.6.8 semantic gates: two maintainer judgements recorded so they are not re-litigated. (a) The iss35 cross-check was RE-RUN against the final content commit (00f1509d) rather than accepting an earlier full-tier run whose tree was amended in flight: a receipt attests one sha and the earlier run could not honestly name one; at ~13 minutes wall and ~1.7M tokens a re-run is cheaper than the ambiguity. (b) PROMOTE with a disposition on every finding (60, all independently re-verified, 0 refuted) rather than HOLD: the findings are the design brief lagging the shipped surface (iss-2608231346137587, whose corpus rule forbids hand-fixing ahead of the mining intent), not something the release introduced or ships, and a HOLD would block a correct changelog behind debt the record already owns. Also noted: the local_username payload rule collides with product vocabulary on a machine whose account name is a common word (iss-2608291444328326); the release push used a HOME symlink alias so the pre-push preflight could run in full, never --no-verify, and CI re-ran every gate under its own account.
• iss-236launch --dry-run hard-fails on a local_username false positive: the scan matches the maintainer's short username against the documented '--dev' CLI flag text, so the release preview reports 5 hard fails on a clean tree. The matcher needs a word-boundary/flag-context exemption.
• iss-2608301715040589an interactive cp prompt stalls an agent silently and has now cost three sessions time in one day
• iss-2609061504302157The capture-time scanner redacts an ordinary word when the local account name happens to be that word. On a machine whose account name is a common three-letter abbreviation for development, a capture containing the phrase 'the source checkout's <that word> build' came back with the word replaced by [redacted-user] and redacted: 1 in the JSON. The private-names layer is doing what it was told, but a banned name that is also a dictionary word or a conventional abbreviation needs a word-boundary and context rule, or at least a diagnostic naming which layer and which entry fired, so the author can tell a real leak from a false positive without reopening the file.
• iss-2609090951282192The memory write boundary refuses a page filename carrying a hard-fail span, and the ruling that ordered it asked for a bar narrow enough that an ordinary slug is not refused: secrets only. The delivered bar selects on the scanner hard-fail severity, and the scanner puts three kinds there rather than one, a secret pattern, a banned real name, and the caller's own local machine account name. The function comment says so plainly, so the width is disclosed rather than hidden, but it is wider than the ruling. The consequence is a refusal the author cannot act on: on a machine whose account name is an ordinary word, an ordinary page whose slug carries that word at a hyphen boundary is refused at ingest with a message telling the author to repair the slug at the source, when what matched was the machine account rather than anything in the page. That collision is already recorded against another surface as iss-2608291444328326, where the same rule turned the release payload gate red on a pristine tree until the home directory was pointed at an alias. It matters because a memory write is the one path here with no workaround: the page cannot be written under the name the distiller chose, and the remedy the message names is not the remedy. Fix direction: hold the filename to the secret patterns alone, as the ruling asked, or keep the identity kinds and make the refusal name which kind matched so an author can tell a collision from a leak. Detector: with the caller account name set to an ordinary word, an ordinary page whose slug contains that word must still write, while a page name carrying a token body is still refused.