What’s new

GitHub now refuses a tag-pinned action in every Core-vendoring repo, and make fleet-protection goes red if one stops. sha_pinning_required was on in only dotfiles-core and dotfiles-MacBook. It is now on in all eleven repos the script audits, which makes GitHub enforce rule 3 of the CI floor server-side: on sibling repos' own workflows, and on anything that reaches main without the text gate. The moving major survives. GitHub exempts reusable workflows ("can still be referenced by tag"), and a re-run of dotfiles-Alpine's lint-call.yml@v7 passed under enforcement. The new --require-sha-pin mode turns it on idempotently, keeps each repo's allowed_actions, and re-reads the server before it reports success. The admin report now fails a repo whose setting is off or cannot be read. It also reports allowed_actions and the count of Actions execution-protection policies, without gating either. CI's --rulesets-only run still skips the block, because it has no repo admin. Composite actions are not exempt, so dotfiles-nvim first SHA-pinned its setup-core-tools@v7 references (dotgibson/dotfiles-nvim#9) and then turned the setting on too (#1226).

A Core PR is checked against the real sibling repos before it merges. The new fleet-gates job in ci.yml clones the fleet beside Core and runs the audit's fleet-wide gates (§5f, §9m-§9p, theme and desktop-parity drift) that every other leg skips because it checks out Core alone. That gap let #1210 merge green and then refuse the v7.14.0 fan-out on dotfiles-Debian's stale TOOLS_OPTIN (#1239). The job is meant to be a required check, so it judges a delta: scripts/fleet-gate-delta.sh audits the PR's base and head against the same clones and fails only on a failure the PR adds. A sibling that drifts on its own therefore cannot block unrelated Core PRs. A failure already on main is a warning. A red means the sibling fix lands first, which is the fleet ratchets' existing order. The job holds no token, because the gates run sibling code (#1240).

/release-readiness actually checks the editor pin. The scheduled job allows ./scripts/check-nvim-freshness.sh as a literal command, but the routine only named the script loosely. The first run (#1245) ran neither form: it reached for gh release list, was refused, and reported a current nvim.lock as unverified. Step 4 now lists the three fleet-state commands exactly as the job grants them, says no other tool is needed for the editor row, and spells out the exit codes. Exit 0 with ✓ means current, exit 0 with a SKIP means unverified, exit 2 means behind, and exit 1 means the lock is broken.

/release-readiness checks the fleet-wide gates against the sibling repos before a tag. A Core PR's CI checks out Core alone, so every gate that reads a sibling (§9m-§9p, theme and desktop-parity drift) skips there. Until now the first run that could see a sibling break was sync-fanout's pre-fan-out audit, after the tag was cut. That is how #1210's correct Kali matrix cells merged green and then redded the v7.14.0 fan-out on dotfiles-Debian's stale TOOLS_OPTIN (#1239). The weekly job now checks Core out beside the fleet and runs audit-core.sh --scope none before the routine, with both tokens withheld from that step because the gates run sibling code. Any ✗ there is a HOLD, and a gate that could not see its sibling is reported as unverified, not as a pass. This is the fallback half of #1240. The PR-time check is still open there.

RELEASE-STRATEGY.md no longer lists making audit-arch and audit-alpine required checks as future work. The main ruleset already requires both, alongside the Ubuntu and macOS audit legs, and it binds admins too. The "Still worth doing" item still pointed at the classic branch-protection settings page that the fleet retired. The CI bullet now says what the ruleset enforces.

CI refuses a pull_request_target trigger. That trigger runs a fork's pull request with this repo's secrets and a write-capable token. The new ci-floor.yml workflow checks out dotfiles-core@v7 and runs its check-modern.sh --banned-triggers over this repo's workflows, the same rule the OS repos get through Core's lint-call.yml (dotgibson/dotfiles-core#1215). Nothing here uses the trigger today. The check passes with a warning until the Core release that ships the mode moves the v7 tag.

Engagement-data write guard. note, logshell, bhce and nmapsweep used to fall back to $PWD when $ENGAGEMENT was unset, so running them inside a checkout wrote client data into that repo. They now resolve their root through _eng_writeroot, which refuses any $PWD inside a git work tree.

The core_branch fallback in the two core.lock readers. core_branch was renamed core_ref in dotfiles-core#453, and reading both names was correct while it shipped: this repo vendors Core on its own schedule, so locks of both vintages existed in the wild and reading only the new name would have killed sync-core.sh on any repo that had not yet synced. That window is closed — Core declares the field gone as of v5 in VENDORING.md, and no core.lock in the fleet carries it, this repo's included. Gone with it: migrate_branch_to_ref, which rewrote the old key in place so set_field (which replaces, never inserts) would have a line to hit. Nothing needs that any more — sync-core.sh now dies naming core_ref alone, before the pull, if the lock has no such line, which is what licenses the never-insert rule downstream. test/check-core-freshness.sh keeps its soft branch=main default: it is a watcher, not a writer. The CORE_BRANCH env override is untouched — it is that script's own knob, not a lock field (#271).

aliases.md now gives an override location that works (#348). It told you to override $ENGAGEMENTS_DIR and the other data paths in 99-local.zsh. But this stage applies their := defaults at band 85, and 99-local.zsh loads at band 95, so the override came too late for anything the stage had already used. The doc now names ~/.zshenv or the environment. It also offered hethttp as its example of an unguarded helper, yet hethttp checks for python3 and refuses to serve from inside a git work tree unless HETHTTP_FORCE=1 is set. Its row now says so, and the example is lhost/ttyup. CLAUDE.md says twelve repos, not eleven.

The packages workflow contradicted the manifest about rustscan. .github/workflows/packages.yml's #260 paragraph explains why the job emits ::warning:: annotations, citing rustscan as an example of "an apt name that resolves in NO Kali component". That was true when written, but #315 restored rustscan to a real apt line after it migrated to kali-rolling on 2026-08-31 — so the repo shipped a workflow comment calling a name unresolvable while the manifest beside it installs that same name. The paragraph is now marked as the history of why annotations exist, with the current status of both examples it cites (rustscan resolves again; snmp-check was a package/binary split all along — the apt name is snmpcheck). Comment only; no job behaviour changes.

bootstrap.sh's PATH is not the shell's PATH — adopt blib_user_bindirs_on_path (dotgibson/dotfiles-core#748). Replaces the hand-rolled export PATH="$HOME/.local/bin:$HOME/.cargo/bin:$PATH" prelude, which also moves it below the source core/lib/bootstrap-lib.sh line. ~/.local/bin, ~/.cargo/bin and $GOBIN reach PATH only through the zsh layer, i.e. only inside a Core shell — which does not exist while bootstrap.sh runs. So every command -v <tool> guard here was answered by the PATH of whatever shell launched the bootstrap: on a fresh box, bash, with none of them. That is wasted work when the guard picks whether to reinstall, and a wrong answer when it picks a branch — dotfiles-openSUSE probed command -v mise for a mise mise.run had written to ~/.local/bin moments earlier, both arms of its Go fallback missed, and the run exited 2 on every bootstrap. No stubbed CI leg can see that: a stub installs nothing, so "is the tool present afterwards" can never fail under one. Core has shipped blib_user_bindirs_on_path for exactly this since dotgibson/dotfiles-core#425 — it resolves CARGO_HOME and GOBIN/GOPATH rather than hard-coding them, and adds only directories that exist, so it is called again after an installer creates one. The directory --install writes into is mkdir -p'd before the helper runs: the helper adds only directories that already exist, so a straight swap for the old unconditional export would have dropped ~/.local/bin for the whole first run and sent the probe/report phase back to reporting a tool it watched get installed as missing. audit-core.sh used to exempt the Role repos from this helper on the reasoning that a role layer installs no packages; that was never true of an --install that does pipx and go install into ~/.local/bin, which is why the prelude was hand-rolled here in the first place. The exemption is gone.

sync-core.sh --help printed set -euo pipefail. The header is rendered with sed -n '2,35p' "$0", and the comment block it means to print ends at line 33 — so every --help run trailed the closing ─── rule with the first two lines of actual code. Pre-existing, and found by the --help render check while retiring the core_branch fallback above; the range now stops at the rule.

Two more targets had the same guard defect, found by the new gate rather than by eye. make shellcheck and make secrets each announced a skip and then ran the missing tool, exiting 127 — the same shape as markdown below, in targets nobody had thought to check. Both collapsed into one recipe line. _core_make_gate_hits (dotgibson/dotfiles-core#775) found them the first time it was pointed at this repo, having been written from the markdown case alone.

make markdown announced a skip and then ran anyway. Each make recipe line runs in its own shell, so the guard's exit 0 only ended that line: without npx it printed "npx not available — skipping markdown" and then ran npx, exiting 127. Collapsed into one recipe line, so the skip is a real skip (dotgibson/dotfiles-core#775 — the same defect in six other fleet repos). MD_FILES was already correct here, including the offensive/companion exclude that matches the gate's, so only the guard needed fixing. An unreadable MARKDOWNLINT_VERSION now fails rather than silently linting unpinned — "same version as CI" is this target's whole claim.

.markdownlint.jsonc's header claimed this config was "the local check for the README" and that "CI here gates this repo's own code, not its Markdown". Both were true when written; dotgibson/dotfiles-core#592 made the markdown leg blocking and it covers all 17 repo-owned files, not just the README.

kubectl is outside Kubernetes' documented support skew, which the line did not say. Its provenance note was correct; its silence on currency was the problem. kali-rolling is 1.33.4+ds-1 (imported 2025-10-02) against upstream stable v1.37.0. kubectl is supported within ±1 minor of the apiserver, so a 1.33 client is unsupported against 1.35/1.36/1.37 — a documented window, not a version-number aesthetic, and it degrades the corpus' k8s-* entries sitting under peirates. The line now points at pkgs.k8s.io when a cluster's version matters, the same shape as the google-cloud-cli/gh/vault pointers in the same block. #275 item 3.

The covert-egress header excepted ptunnel-ng as "the CURRENT upstream" — an annotation this changelog added two entries below, wrong within three weeks. Its *version* claim holds (kali 1.43-2 is upstream v1.43); its *vitality* claim did not. v1.43's own release note says "due to time constraints, there will be no further publications in the near future" (tagged 2024-11-27) and master has not moved since 2024-04-07. It froze at a version apt happens to have. All five tools in that block are frozen, dead, or behind — which is the honest state of covert-channel egress and more useful than implying one live option exists. ptunnel-ng is still the right choice of the two ptunnels; it is the maintained-*er* fork, not a live project. #275 item 4.

dnsenum's name lands you on the wrong repo. The line carried no upstream pointer, and fwaeytens/dnsenum — what you find searching the name, 702 stars — has not moved since 2019-10-08. Kali ships 1.3.2-1, whose Homepage names SparrowOchon/dnsenum2 ("officially mainlined in Kali"). Same use-the-fork trap the kwp-vs-iphelix/pack and ConfuserEx-vs-mkaring notes exist to prevent — and the same shape as the pack fix above, where apt's Homepage also named a fork the note did not know about. Honest status: frozen fork, and apt is on it. dnsrecon is the maintained analogue and is in apt, but no doc or corpus entry names it, so it stays out on this file's membership rule. #275 item 5.

PowerUpSQL was named in the payload-build block's "absent" list but was the one member of six with no status line. Verified: not archived, but no release has ever been cut and the last functional commits are Aug 2024 — quiet, not dead, the sRDI shape. Recorded as low impact here, because the Linux-native half is already on the box: impacket-mssqlclient (enum_links/use_link) and nxc mssql cover linked-server hopping and are both already listed. skahwah/SQLRecon is named as the maintained analogue with no pointer of its own — the pretender treatment. The block's reference to that tool in offensive/evasion had also drifted, and is corrected from :124 to :126. #275 item 6.

sliver's note ran one release ahead of the facts. It said upstream "has kept releasing (past 1.7.6 by Aug 2026)"; v1.7.6 shipped 2026-08-28 and is the head, so "past" was wrong — now "through 1.7.6". The durable phrasing the last cycle introduced (check sliver-server version before an op, never a patch count) is unchanged and still right. What 1.7.6 contains sharpens it: it bounds mTLS/WireGuard envelope and pivot-frame allocation from the length prefix and fixes DNS varint boundary handling — memory exhaustion on network-facing paths, not cosmetic stability. #275 item 7.

proxychains4 carried no annotation, and the bare proxychains name is a live trap. apt is at upstream's head (4.17-3.1 = v4.17; rofl0r alive but slow to release — fixes landed 2026-08-27 against a 2024 tag). The addition is the trap: a real proxychains package exists in Kali and Debian sid at 3.1-9 — proxychains 3.1, from 2007. It escapes the usual apt-file search '/usr/bin/proxychains$' check because it ships /usr/bin/proxychains3, a third binary name, so apt install proxychains *succeeds* and silently hands you an 18-year-old tool. A sharper reason to name proxychains4 than "the bare name is only a virtual Provides:". #275 item 8.

redup's katana step would have inherited the nuclei miscount on migration. It ran katana -update unconditionally — the exact shape the nuclei engine step had before it was fixed below. katana 1.7.0-0kali1 landed in kali-dev on 2026-08-27 and has not migrated to kali-rolling; apt owning a binary is precisely when Kali patches its self-updater out, as it already did to nuclei. On the day katana migrates and is patched, the step would have started printing ✗ katana update failed and tallying it on every run of a healthy box. The flag is now probed before use, reusing the nuclei step's whole-token regex byte-for-byte — the match has to be whole-token here too, since katana's help carries -duc, -disable-update-check, which a bare grep -- -update would match on exactly the patched build the probe exists to catch. A flagless build now degrades to a skip that tallies nothing. Preventive: no behaviour change on today's go install build, where the probe passes. redup -h, the redup header comment, aliases.md and install/tools.lst all gave nuclei a build hedge and katana none; all four now match. #260 item 5.

The Cloud / SaaS / CI-CD block claimed Terraform Cloud entries are "pure REST — curl + a token, nothing to install." The tfc-agent entry lower in the same file already said the opposite — that it "corrects this file's older claim that the Terraform Cloud entries are pure REST" — so the correction was written at one end and never applied at the other, leaving the two halves of one file contradicting each other. tfc-agent-hijack creates the agent pool over REST and then runs tfc-agent, a HashiCorp release binary on infrastructure you control; only tfc-token-backdoor and tfc-var-injection are curl-only. Checking the rest of the sentence while correcting it found it loose for two more of the five services it named: Snowflake's three entries are SQL (``sql fences, which is why the corpus gate never sees a command in them) and slack-2fa-disable` is a console toggle with no command at all. "Nothing to install" still holds for both — "curl + a token" did not. Okta and GitLab were accurate as claimed.

katana's manifest pointer said "not in apt", which is no longer true. Initial Kali packaging (1.7.0-0kali1) was committed to kali-dev on 2026-08-27. It has not migrated, so go install is still the only route on any box today — but the pointer now states the kali-dev version and the "has not migrated" qualifier, mirroring the shape rustscan already carries in the same file, and names pkg.kali.org/pkg/katana as the re-check. It also records what a migration would bring: the kali-dev packaging carries no debian/patches directory yet, so -update survives there for now. #260 item 5.

mitm6's freeze note claimed "there is no maintained successor to move to." Too strong, and the near-miss has a name: RedTeamPentesting's pretender (Go, v1.4.1, Jul 2026) is maintained and does mitm6's exact DHCPv6/DNS takeover plus mDNS/LLMNR/NBT-NS. But it is a spoofer only — no listener, no capture, no relay — so it replaces neither mitm6 nor responder, and the note's conclusion (keep mitm6, frozen because finished) is unchanged. It gets no → UPSTREAM pointer of its own: no doc and no corpus entry invokes it. The same note now records a second axis the old text conflated with it — whether the coercion fires is not whether the relay yields. On fully-patched Server 2025 / Win11 24H2, SMB signing is required by default and LDAP channel binding ships Enabled-When-Supported (MSRC, Dec 2024): the trigger still fires, the SMB and plain-LDAP relay legs close, and value shifts toward krbrelayx and the AD CS / PKINIT path. #260 item 6.

redup counted every successful searchsploit -u as a failure. The step ran if searchsploit -u; then …, but searchsploit exits 6, not 0, after any successful update — its own header documents it ("Exit code '6' means updated packages (APT, brew or Git)") and its update routine ends in a bare exit 6 on every route (apt, brew and git alike). So a completely successful refresh printed ✗ searchsploit -u failed and was tallied, making the summary read red on a healthy box. This is the same miscount as the nuclei engine step below, one step further down the same function, and it survived that fix. The exit status is now captured and both 0 and 6 count as success; anything else still reports, and now prints the code. Found while correcting the step's prose for #260 item 8 — the report called this a comment-only fix.

redup's nuclei engine step could never succeed on Kali. It ran nuclei -update unconditionally, but Kali patches that flag out of its packaged nuclei — apt owns the binary, so self-updating it is not nuclei's job there. Kali's -h UPDATE section carries only -update-templates, -update-template-dir and -disable-update-check. So the step failed on every run on the primary target platform and tallied a failure, making the summary read red on a completely healthy box — the exact miscount the function's own comments exist to prevent. The engine step is now probed and the templates step (the daily-moving half) stays unconditional, so a go install-provided nuclei on non-Kali Debian still self-updates. The probe matches -update/-up as a whole TOKEN: a bare substring grep matches -update-templates, -update-template-dir and -disable-update-check, three hits on the very help text that proves the flag is absent.

Three apt names in install/offensive-packages.txt resolved against nothing. Verified against kali-rolling's own binary index, not a local box: - bbot is packaged in no Kali component and never has been (pkg.kali.org 404s) — now an UPSTREAM/pipx comment. The old line's "(pipx/upstream if the repo build lags)" hedge implied a repo build that does not exist. - snmp-check is the binary name; the package is snmpcheck, which ships /usr/bin/snmp-check. Same package/binary split the file already documents for httpx-toolkit and python3-ldapdomaindump. hacktheplanet's command was always right; only the manifest was wrong. - rustscan is absent from main, contrib and non-free alike — Kali's packaging sits in kali-dev at 2.4.1 and has not migrated. The line also claimed it "ships in kali-linux-default", whose Depends does not name it, so both halves were wrong. Now an UPSTREAM (cargo) comment. test/check-packages.sh had been reporting all three for weeks; see the packages.yml note under Changed for why nobody saw it.

Caldera was routed to Docker for nothing. install/offensive-packages.txt carried it as → UPSTREAM/docker and offensive/offensive.zsh justified the missing probe with "Caldera ships no caldera binary". Both false: kali-rolling ships caldera (5.3.0-0kali1) and it installs /usr/bin/caldera. Now a plain apt line, noting the ~70 MB Python chain and that no kali-linux-* metapackage carries it. The decision not to add HAVE_CALDERA stands, but for the real reason — nothing in offensive.zsh invokes it, which is install/tools.lst's actual membership rule.

The corpus-coverage counts went stale again, exactly as recorded below for the v2.10.0 sync. A later v2.10.1 sync added entries/blue/smb-enum-5145.md and projected the smb-enum pair into both views; no header moved. The version notes in those files now point at companion.lock for the exact revision instead of hardcoding a commit count, which rots the same way the counts do. Actual is 103 red / 102 blue with 19 and 24 blocks projected. Fixed in hacktheplanet, PURPLE-TEAM.md, OFFENSIVE-METHODOLOGY.md and — found while verifying, reported by neither audit — CONTRIBUTING.md and the Makefile. hacktheplanet also listed smb-enum-nxc among the entries "covered as richer prose below" while generating a block for it seven paragraphs later, so its own accounting summed to 102 rather than 103.

CLAUDE.md described --install as apt-only on Kali. _install_apt_absent pipx-installs ROADtools on both routes, which bootstrap.sh and install/offensive-packages.txt both state plainly. "Where things are" also documented 2 of the 4 install/ manifests; corpus-commands.lst and impacket-binaries.lst are now listed, the latter being the file whose entire purpose is making impacket-petitpotam fail (#208).

OFFENSIVE-METHODOLOGY.md dated Caldera's Apache move to "May 2026", contradicting the manifest's already-corrected 2025-12-19 donation date (#211 landed that fix in the manifest only).

Two red entries and their blue pairs are projected nowhere and belong to no category. bloodhound-collect and ldap-recon are both Active Directory — discovery, squarely inside the "richer prose here" subject area but absent from its list; their pairs bloodhound-collect-4662 / ldap-recon-4662 key off event 4662, which is PURPLE-TEAM.md's own criterion for projecting. hacktheplanet's claim that an unprojected entry is "not a gap in the generator" was therefore false. Both files now name the gap instead of implying it cannot exist.

**rdp-hijack-tscon was listed as "covered better below"; it is covered *equally*.** Its two commands are byte-identical to the prose ones. Noted rather than silently kept.

OFFENSIVE-METHODOLOGY.md's "roughly two-thirds of the corpus" replaced with the measured figure — 69/103 red (67%) and 76/101 blue (75%). All three files now carry the same caveat: these counts are hand-maintained, they go stale on every companion-sync, and the corpus is authoritative when they disagree.

kwp was attributed to the wrong project (#213). The manifest filed it under PACK (kwp, statsgen, maskgen) → github.com/iphelix/pack. PACK ships statsgen/maskgen/policygen/rulegen and no kwp — kwp is hashcat's kwprocessor, and hacktheplanet's invocation is verbatim kwprocessor. Following the old pointer landed you in a repo that does not contain the tool. Split onto its own UPSTREAM line.

exploitdev's Linux toolchain was unmanifested (#212, #213). gdb, nasm and objdump are invoked by that reference and appeared nowhere in the package list. Resolved by checking a real kali-rolling box rather than guessing: nasm (via metasploit-framework) and binutils are already pulled transitively, so they go in the accounting block, while gdb is genuinely absent — gcc only *suggests* it — so it joins the "Kali does NOT ship by default" block, whose stated test it meets exactly.

nc was named only inside another package's comment (#212). netcat is the primary command of the reverse-shell fold and was listed nowhere. Added as netcat-traditional, not netcat-openbsd as the audit suggested: Kali installs traditional and points the nc alternative at it, and the documented nc -lvnp form is a traditional idiom — OpenBSD's nc rejects -p alongside -l, so that variant could have flipped the alternative and broken the very line it was meant to support.

Four field-reference commands could not run as written (#213, #212). hacktheplanet invoked nmap --script=msrpc-dcom-interface-activation, which is not a script nmap ships — verified against nmap 7.99 on kali-rolling, where the only msrpc NSE is msrpc-enum (already the line directly above). Dropped rather than replaced: there is nothing to replace it with. exploitdev invoked !mona egghunter, which is not a mona command — egg is, and -c (NtAccessCheckAndAuditAlarm) is one of *its* options; the two lines collapse into one. hacktheplanet also credited --dc to impacket/certipy when it is kerbrute's idiom — impacket and certipy use -dc-ip, as every impacket line in that file already does. The same misattribution in this file's #187 entry is corrected with it.

Two hacktheplanet commands could not run as written (#187). rusthound-ce was invoked with --dc <ip_address>; RustHound-CE has no such flag — that is kerbrute's idiom (impacket/certipy use -dc-ip) — and takes -i/--ldapip for the DC IP or -f/--ldapfqdn for its FQDN. And two pivot lines invoked bare proxychains, which is not a binary on this layer's own box: the manifest ships proxychains4, that package installs only /usr/bin/proxychains4, and its Provides: proxychains is a virtual-package relation, so apt-file search '/usr/bin/proxychains$' matches nothing. The audit that filed this guessed the second one was "probably fine … one command -v settles it"; it was run, and it isn't. Both lines now carry the reasoning inline, since --dc is right for kerbrute two folds up and the next reader will otherwise "fix" it back.

cifs-utils was missing from the manifest (#187). hacktheplanet mounts a share with mount -t cifs twice — once in the SMB fold, once on SYSVOL inside the GPP-cpassword block — and nothing in offensive-packages.txt provided mount.cifs. smbclient *browses* a share; mounting one is a separate package. This was the only real gap of the six the audit alleged: samba-common-bin and gcc-mingw-w64-i686 were false (smbclient ships /usr/bin/rpcclient; mingw-w64 provides i686-w64-mingw32-gcc), and the rest had already landed with #186.

The manifest's own accounting claim was false again (#187). The target-dropped block claims it "accounts for every tool the DOCS *and* the COMPANION CORPUS name", and seven doc-named tools were unaccounted for. pspy joins the block properly — it is genuinely target-dropped, and ippsec names it in the same breath as linpeas. The other six (macro_pack, PowerUpSQL, and the Donut/sRDI/ConfuserEx/ScareCrow loaders from evasion) get a stated exclusion instead of a listing, because they are operator-side *payload-build* tooling that runs on Windows: not target-dropped, not in Kali apt, and not something a Linux apt list should imply it can install. Either a tool is listed or the manifest says in one line why it isn't — which is what makes the claim checkable.

ldapdomaindump was installed twice and invoked never (#187). It arrives by apt (python3-ldapdomaindump) *and* by pipx on the non-Kali route, and OFFENSIVE-METHODOLOGY.md lists it — but no command anywhere under offensive/ ran it, making it the only installed AD-enum tool with no copy-paste line. It now has one in the AD fold, writing to loot/ldd to match the methodology table. The manifest records the apt-name/binary-name split, the same dual-name trap already documented for impacket and certipy. Not acted on from #187: the bloodhound-python finding was already fixed at HEAD (the audit ran against a pre-b294258 tree — every line number in it is stale by 11–15, and it cites os/kali.conf, deleted 2026-08-18). The -M wmi-event finding is real but worse than filed — that NetExec module does not exist in *either* spelling — and lives in generated content, so it was fixed upstream in htpx#73 and arrives here on the next companion sync.

Seven packages, behind eight commands hacktheplanet invokes, had no manifest line (#186) — ftp, showmount, dig, nslookup, mysql, psql, redis-cli and i686-w64-mingw32-gcc. The Service-enumeration block states its own rule — *every fold's primary command in PATH* — and five folds were not honouring it. ftp, nfs-common and bind9-dnsutils join that block; the other four get a new block of their own, because checking kali-meta's debian/control showed the audit's framing was too generous: no Kali metapackage names mariadb-client, postgresql-client, redis-tools or mingw-w64, so those four lines in hacktheplanet fail on a stock box, not just a slim one. mingw-w64 is the sharpest — build-essential gives you native gcc only, so nothing else on the box covers the cross-compile. - Note the DNS name: it is bind9-dnsutils, not the dnsutils the audit proposed. dnsutils is a transitional binary off the same bind9 source, gone from trixie and back only in sid; the sole Kali metapackage still naming it is kali-linux-wsl. Since test/check-packages.sh resolves every name against kali-rolling, the durable name is the only safe one to pin. - No install/tools.lst change: that file's header restricts it to commands offensive/offensive.zsh probes or invokes by bare name, and none of these are. Adding them would make bootstrap's report cry wolf.

PrintSpoofer64.exe and GodPotato were the target-dropped block's one blind spot (#186). That block promises to account for *every* tool the docs and the corpus name; these two arrive from the corpus inside hacktheplanet's companion:gen potato-seimpersonate block, which is how they slipped it. Two UPSTREAM → lines now, matching the linpeas/winPEAS treatment.

redup's help advertised a step that always no-ops (#186). Both help strings and aliases.md promised a refresh of "the go-installed tools", but go_fast_movers has been () since kerbrute was dropped as upstream-frozen. The strings now describe what the function does; the block comment still records why the array is empty and how to re-populate it. aliases.md also gains katana, which it had missed since redup started driving it.

doggo, carapace and sesh never installed on a fresh box. mise lands in ~/.local/bin, which is not on PATH during bootstrap, so the go install fallback's command -v mise always missed. A PATH prelude fixes this and the related re-install-every-run behaviour of atuin.

A symlink cycle in the .zshrc wiring. bootstrap.sh re-did a link the library already makes, bypassing the ELOOP guard in _blib_seed_zdotdir_rc.

bootstrap.sh no longer silently installs nothing when install/packages.txt is missing.

apt_install's per-package retry keeps --no-install-recommends.

The bootstrap workflow's path filter omitted install/ and wsl/, so package-list edits never re-ran the bootstrap test. Filters removed.

dotsync hardcoded ~/dotfiles-Offense; it now resolves this checkout.

The offensive tmux binding shipped even when its script was not linked, and hardcoded ~/.config against an XDG-aware bootstrap.

@batt_enable was unconditionally off "because WSL has no battery" — now detected, so bare-metal laptops keep the widget.

ssh/config pinned modern-only crypto on Host *, which refuses to negotiate with the legacy targets an offensive box exists to reach. Scoped to your own infrastructure.

pseudo-shell.py proxied through Burp by default, so every request failed opaquely when Burp was not running; now opt-in. Its requests dependency documents a PEP 668-compatible install path.

redup printed "go not installed" for an intentionally empty tool list, and ran searchsploit -u without the privilege its root-owned checkout needs.

core-verify asks the integrity question again, and core-check gets the freshness one back (dotgibson/dotfiles-core#691). Adopting the fleet vocabulary pointed the canonical core-verify at test/check-core-freshness.sh and demoted core-check to an alias of it. Those are two different questions: freshness is *is there a NEWER Core upstream?*, integrity is *is THIS core/ the tree core.lock pins?* — and Core's scripts/make-vocabulary.txt defines the canonical verb as the second. So the register read green on a target answering something else, while this repo still had no local integrity check at all: core-integrity.yml ran one in CI and nothing ran one here. core-check is a real target again, with help text naming its question, and core-verify delegates to Core's own scripts/core-integrity.sh from a CORE_REPO checkout — the same invocation CI uses, and the only implementation that knows how the fan-out filters the vendored subtree. Verified both ways against a sibling clone at core v6.1.0: core-verify reports pristine, core-check reports current.

Three tool decisions recorded so the next scout cycle doesn't re-raise them. All three were proposed by #260 and all three were declined, on stated grounds rather than by omission: - gh in redup's go_fast_movers (item 9). It has the profile the machinery was kept for — go-only, apt-absent since kali-rolling dropped 2.46.0-3 on 2025-12-10, and genuinely fast — but upstream supports the release binary and GitHub's own apt repo, not go install, and a bare go install build reports an unset/dev version string. The entry would replace a correct build with one that cannot report its own version. Recorded in the comment beside the katana rejection already there, so the array is now empty for two stated reasons rather than one. - trufflehog. In kali apt (3.94.3-0kali1) and a good fit for what the Cloud / SaaS / CI-CD block is for — "find the leaked key" is the missing first step of most of the gh-*/npm-*/pypi-* supply-chain entries. Held out on this file's own membership rule, not on merit: no doc and no corpus entry invokes it. The doc edit is the prerequisite; the note says so, and says it becomes a plain apt line once one does. - PrivescCheck — same rule, same note, beside the PowerUp.ps1 entry it would complement. The report conceded the prerequisite for this one and not for trufflehog; the rule applies to both identically.

make view-counts / test/check-view-counts.sh — a gate on the hand-typed corpus counts in hacktheplanet, PURPLE-TEAM.md and OFFENSIVE-METHODOLOGY.md. Two of those files already carried a caveat saying the numbers go stale on every companion-sync; this executes it. It exists because the drift above is a repeat — the same fix is recorded for the v2.10.0 sync — and nothing could see it: gen-views.sh --check byte-compares block *contents* and has no opinion on how many blocks exist, and markdownlint cannot tell 101 from 102. It is repo-owned rather than an extension of gen-views.sh because offensive/companion/ is a vendored subtree and an edit there is lost on the next sync. It checks only what is mechanically derivable (entry totals, projected-block counts, and the sums of those); the semantic buckets — 56 cloud/SaaS/ CI-CD, 13 C2-egress/Impact, 7 Linux, 69/76, the percentages — are deliberately ungated, because nothing in entries/*.md marks an entry "cloud". Exit 2 means a stale count; exit 1 means an anchored sentence was rewritten and needs re-anchoring — two different failures, so a maintainer is never told the wrong one.

The SMB enum fold and its detection are now entry-backed. companion.lock bumps to htpx b80741f, which pairs smb-enum-nxc with a new smb-enum-5145 blue entry (htpx#97), and both sides are wrapped in companion:gen markers: the nxc commands in hacktheplanet's SMB fold, and the detection in PURPLE-TEAM.md's recon section. The hacktheplanet block is the notable half. Those five nxc smb lines have been hand-written since the file existed, and the entry upstream carried only three of them — so wrapping them would have silently deleted --loggedon-users and the /24 spray. htpx#100 widened the entry to the full fold with its inline comments matched, which makes render_red reproduce the existing lines byte for byte: the diff to hacktheplanet here is the two marker lines and nothing else. That is the bar for putting a marker around prose that was already good — the tempting shortcut, wrap it and let the generator win, loses content nobody notices for months. This sync also brings pair_note: (htpx#98), which the vendored copy predated: an entry carrying pair: null must now say why, and upstream CI rejects one that does not.

ROADtools is now installed by --install, on every route (#231). Entra/M365 tooling in this layer was entirely Windows-side (AADInternals, TeamFiltration, MSOLSpray); the corpus even cited dirkjanm's ROADtools as device-code-phish's source: while handing you Windows-only PowerShell. bootstrap.sh grew an _install_apt_absent step — a THIRD install category for tools no route can apt-install — that pipx-installs roadrecon and roadtx on the Kali path too, not just the portable subset, so the Entra corpus entries finally run from the attacker box. hacktheplanet's M365 fold documents the Linux commands and install/offensive-packages.txt carries the annotation. The corpus entry's own platform:/source: fix lands upstream in dotgibson/htpx.

SCCM/MECM is now covered — it was a total blank (#230). grep -ri sccm over the repo used to return nothing, despite site-server takeover and Network Access Account extraction being mainstream AD attack surface. Added a SCCM / MECM fold to hacktheplanet (discovery -> NAA over the network or from a compromised client -> site takeover -> PXE boot-media creds), a Cred access row in the methodology map, and sccmhunter + pxethiefy UPSTREAM annotations in install/offensive-packages.txt (whose corpus-only block widened to admit doc-named operator tooling). sccmhunter is documented, not wired into --install: it is not on PyPI, its git install carries a Python 3.13 floor and an ldap3 fork pin pip drops silently, so a documented manual step beats a best-effort loop that fails quietly. Every command verified against upstream.

corpus commands resolve — a gate for the question nothing asked (#208). Two entries in coerce-petitpotam once invoked impacket-petitpotam and dfscoerce. Neither is a real command, both shipped in a released corpus, and a human reading the file found them — because every existing gate looks somewhere else: gen-views.sh --check byte-compares the 18 *projected* red blocks (85 of 103 are unprojected), check-packages.sh reads the manifest and never the corpus, companion-integrity checks provenance rather than content, and htpx's own CI checks pairing and slots rather than existence. test/check-corpus-commands.sh resolves the first token of every command line in every red entry against the manifest, an impacket-binaries.lst roster, and the classifications in install/corpus-commands.lst. Offline and deterministic, so unlike packages-check it can be required; wired into make test and its own workflow. - Its --self-test rebuilds the pre-v2.8.0 coerce-petitpotam at run time and asserts the gate still reddens on it — a regression guard for the gate itself, since one that quietly stopped catching its own motivating bug would pass forever. - install/corpus-commands.lst requires a line of prose on every classification, so "whatever the allowlist excuses, it says so" is enforced rather than hoped for. It also fails on a classification no entry uses any more, so a companion-sync that drops an entry surfaces its dead excuse. - The roster spans two packages: impacket-scripts (57 wrappers) and python3-impacket (5 more, including impacket-secretsdump and impacket-wmiexec). A roster built from impacket-scripts alone would have failed the two most-used commands in the corpus. packages.yml gained an advisory step that re-derives it from kali-rolling and diffs, so the checked-in copy cannot rot unnoticed.

Five tools the corpus invokes and nothing accounted for, all surfaced by the new gate on its first run: ldap-utils (ldapsearch, a real apt package, now installed), plus UPSTREAM entries for evilginx2, MSOLSpray and tfc-agent in a new "Corpus-only operator tooling" block. tfc-agent also corrects this file's older claim that the Terraform Cloud entries are pure REST. The legacy bloodhound-python binary is now named in the BloodHound block, with the warning that the entry invoking it is wrong for a CE stack — that fix routes upstream to htpx.

A gate against leaked RETURN traps (#198) — test/check-return-traps.sh, wired into make lint as make trap-guard and into CI as the return-traps job in checks.yml. A bash RETURN trap is a global slot, not a function-scoped one: armed inside a function it survives into the *caller's* frame and fires a second time when the caller returns, where the local it cleans up is out of scope and set -u makes that fatal. In dotfiles-Debian that aborted provision() after every package had installed but before wire_links ran — the whole stack on the box, and not one symlink. Nothing else can see it: the broken line is valid bash, so shellcheck and bash -n both pass it, and no CI job in this fleet exercises a real install path (every bootstrap run is --links-only). Hence a grep. The correct form is trap 'trap - RETURN; rm -rf "$tmp"' RETURN. This is prevention, not a fix. #198 reported the bug in this repo's verified_install(), but that function — and the entire SHA-pinned out-of-band install block around it — left in the layer split (6d641d2), which moved it to dotfiles-Debian; the trap went with it. No repo-owned shell here arms a RETURN trap today. The guard exists so none ever does again. zsh is out of scope: it has no RETURN signal at all.

Makefile — the entry point (make lint, test, core-sync, packages-check, …). Makes core.lock's make core-lock instruction true for the first time.

scripts/sync-core.sh, test/check-core-freshness.sh and a freshness workflow — the consumer-side core-sync line, which three files already referenced and none provided.

test/check-companion-integrity.sh — tamper detection for the second vendored subtree, mirroring core-integrity.

test/check-packages.sh + a packages workflow resolving every manifest name against kali-rolling.

markdownlint in CI, against the .markdownlint.jsonc that had been sitting unused.

bootstrap.sh --dry-run and --no-upgrade.

companion_version / companion_tag in companion.lock, for symmetry with core.lock.

bootstrap.sh --install runs on Core's escalation, sudo-keepalive and failure-tally helpers instead of bare sudo (dotgibson/dotfiles-core#973). The Kali apt route hard-coded sudo three times and primed it with a one-shot sudo -v whose own comment promised to "keep the timestamp warm" — one line before "go get coffee". It now resolves the escalator once with blib_resolve_su (root runs directly, else sudo, else doas, by absolute path), runs the three apt calls through blib_priv, and keeps the timestamp warm for real with blib_sudo_keepalive_start / _stop. Every best-effort install — the apt per-package fallback, each pipx install, each go install — now records a miss via blib_note_fail instead of an indented echo, blib_failures_report prints them together after the wiring, and a new --strict turns a non-empty tally into exit 1. Without it the exit code is unchanged: the offensive tools are optional; zsh is not. Closes this repo's rows in Core's audit-core.sh §5f ledger, including the keepalive row it had been exempt from on the theory that a role repo installs no long package sets — the apt route is that set.

BREAKING — make core-sync no longer pulls; Core arrives by fan-out (dotfiles-core#676). scripts/sync-core.sh is now report-only: it says how far behind core/ is and how Core actually gets here, and writes nothing. This repo was the fleet's one sanctioned second writer into core/. That sanction rested on a specific property, spelled out in VENDORING.md: the pull stamped core.lock from *what it actually pulled* — core_sha from the squash commit's git-subtree-split trailer, core_version from the tree on disk — so the lock could not describe a commit its own core/ did not contain. A filtered vendor removes exactly that property. Core stopped vendoring its whole tree: core/ is now core.manifest ∪ core.vendor, roughly two thirds of it. A git subtree pull merges the whole upstream tree and has no way to apply that filter, so "what it actually pulled" is by construction no longer what a vendored core/ should contain. The first pull after this repo's lock moved to a filtering commit would land every upstream file against an expectation of the subset, and core-integrity would report TAMPERED — correctly, with no hand-edit anywhere. Teaching it to filter was the alternative and is worse: it would make this repo a second producer of Core's format, which the sanction never extended to. Two implementations of one filter is the failure dotfiles-core#556 exists to prevent. In practice this changes nothing about how Core actually arrives. Every one of the last ten core.lock writes in this repo came from the fan-out, not from make core-sync. The independent cadence being given up was already not in use. make core-sync and make core-lock survive as the place that explains this — they are what someone types when asking "how do I move Core?", and that question still has an answer. --check is accepted and ignored, since every run is now what it meant.

offensive/companion/ is unaffected and still pulls. htpx vendors its whole tree and has no allowlist, so make companion-sync keeps working exactly as before. The asymmetry between the two subtrees is deliberate and is now stated in CONTRIBUTING.md, CLAUDE.md and the Makefile header — do not "fix" companion-sync to match.

ptunnel-ng added beside ptunnel, not instead of it. ptunnel-ng (utoni/ptunnel-ng, redirected from lnslbrty) is the maintained fork and kali's 1.43-2 *is* its latest upstream release, so it is the one to reach for. The original ptunnel line stays for one mechanical reason: the corpus entry entries/red/icmp-tunnel-c2.md invokes the bare ptunnel binary, and test/check-corpus-commands.sh — offline and required — resolves that name against the manifest, so dropping the line reds a blocking gate. ptunnel-ng cannot cover for it either: it ships only /usr/bin/ptunnel-ng, with no ptunnel binary and no alternatives symlink. Retargeting the entry is an upstream change in htpx — entries/ is a vendored subtree — and it is a rewrite, not a rename: the two are not flag-compatible, -lp/-da/-dp having become -l/-r/-R.

The covert-egress block now carries a status per tool. It read as though all four were current upstreams; not one is. iodine is a full release behind (kali 0.7.0-13 vs upstream v0.8.0); dnscat2 is frozen at its own last release (v0.07, 2016 — so apt is *not* behind, there is simply nothing newer); ptunnel is frozen at 0.72; icmpsh is dead (last push 2018, never released).

sliver's currency note no longer hardcodes a patch count. "TWO patches behind" was accurate when written and wrong within five months. It now states the shape — apt froze at 1.7.1-0kali4 while upstream kept releasing — and points at sliver-server version instead of a number that rots.

Freeze and archive statuses added where the file asserted none. PrintSpoofer (archived Sep 2024) was the last unmarked freeze in the target-dropped block; hashid is frozen at Jun 2022 while the line calls it "the cracking entrypoint"; the evasion payload-build paragraph carried no status for any of its five tools (macro_pack and ScareCrow archived, Donut alive, sRDI static since 2023). Each is kept — these target behaviours and formats that have not moved — with the reason stated.

The ConfuserEx pointer now names the mkaring fork. Canonical yck1509/ConfuserEx is archived and has not moved since 2019, so a bare "ConfuserEx" landed a reader in a dead repo — the failure the kwp-vs-iphelix/pack note already guards against elsewhere in the file.

ligolo-ng loses its "(upstream if repo build lags)" hedge. Kali tracks it closely (0.9.1-0kali1 within ~2 weeks of upstream v0.9.1), so the hedge invited a hand-built pivot that is almost never warranted.

The hexyl note's reason is narrower than it claimed. "There is no hexyl package in Kali at all" is false: the rust-hexyl source package, which builds a hexyl binary package, has been imported into and removed from kali-rolling repeatedly (0.4.0, 0.5.1, 0.7.0, 0.8.0, most recently 0.16.0-4), following Debian testing. It is out right now, so the conclusion — keep it out, it would hand check-packages.sh an unresolvable name — is unchanged, but it can return without warning.

rusthound-ce's version pair replaced with its cadence. The quoted v2.4.91 -> v2.5.2 in seven weeks had itself gone stale (seven releases shipped in the eight weeks to Aug 2026). The mechanical reason it stays out of redup — cargo, no self-updater, go_fast_movers is go-only — is unchanged.

redup's ffuf/gobuster note now separates ownership from currency. "apt-packaged ones (gobuster/ffuf) update via up" implied apt keeps them current. apt *owns* them, so up is the only correct route and neither belongs in go_fast_movers — but kali's ffuf is 2.1.0 (Jan 2024) against an upstream that resumed releasing at 2.2.x. The routing claim stands; the currency implication does not.

packages.yml now emits ::warning:: annotations as well as its job summary. It stays advisory — Kali is rolling, and a package that vanishes mid-migration must not red an unrelated PR — but summary-only proved to be the same as silent: three unresolvable apt names sat in the manifest while the job reported them into a page nobody opened and exited 0 every week. Annotations surface on the Checks and Files tabs without changing any exit code. Its header also claimed you could make the job blocking by dropping a || true that does not exist in the file; the real lever is the exit 0 at the end of the resolve step.

Five currency annotations corrected (#211). adaptixc2's said upstream publishes zero releases so there is "no tag to judge staleness by" and that it rolls on main — both false: v1.0/v1.1/v1.2 are tagged, main last moved 2026-03-04, and work is on version branches. That premise was load-bearing for the fingerprinted-default-profiles warning above it. sliver's apt lag is two patches, not "~a patch". caldera entered the Apache Incubator 2025-12-19, not May 2026. rusthound-ce's "collectors aren't daily-churn" reasoning is dead (v2.4.91 → v2.5.2 in seven weeks) — the conclusion survives for a mechanical reason instead: cargo, no self-updater, and redup's loop is go-only. And mitm6 finally gets the FROZEN note that kerbrute and havoc already carried.

Three of the four field references now point at the corpus. exploitdev, ippsec and evasion listed their sibling references but omitted ~/companion (htpx), which hacktheplanet has always carried. evasion was the sharpest case: its "Network-filter & egress bypass (C2 channels)" fold is prose-only by design, and the six entries holding the actual commands (dns-tunnel-c2, icmp-tunnel-c2, domain-fronting-cdn, https-beacon-sliver, mtls-c2-sliver, web-service-c2-telegram) live only in the corpus — with no route to them from the doc that needed them most. Its footer is also restyled to match the other three (~/name + alias, not offensive/name).

evasion opened with bare vim. It told you to run vim ~/evasion, bypassing the read-only opener that exists so an errant :w cannot publish engagement data — the one reference of the four that did. Now leads with evade, matching exploitdev.

hacktheplanet gained the two commands the corpus had and it did not (#212). The coercion fold described "many vectors" but never showed the MS-DFSNM one, and the pivot fold described ligolo-ng in prose with no command line at all. Both are now present, so the header's claim that these entries are "covered better below" holds again.

bootstrap.sh calls blib_link_role_layer instead of hand-rolling three links. The block it replaces had already drifted from dotfiles-Defense's copy of the same wiring: Defense honoured BLIB_DRY when dropping the stale pre-v4 link and this repo did not, so --dry-run mutated the box here and not there. One shared definition ends that class of drift.

Templates moved to $CONFIG/offensive/templates (from $CONFIG/kali/templates) — named for the role rather than the distro, matching Defense's $CONFIG/defense/. The two shipped docs that quote the path by hand, offensive/hacktheplanet and offensive/ippsec, are updated in the same change. Core deliberately declined a compat symlink, since it would preserve a ~/.config/kali/ on a repo no longer called Kali.

Bootstrap now cleans up after the old wiring. A box bootstrapped before this change carries $CONFIG/tmux/os.conf and $CONFIG/kali/templates pointing into this checkout; both dangle afterwards. Each is removed only when it is a symlink resolving inside this repo, so a box also running dotfiles-Debian never has that repo's live os.conf touched, and --dry-run only reports.

This repo is now a pure Role layer. It used to be both the OS-native layer for Kali *and* the offensive role on top. dotfiles-Debian now covers the Debian family properly and accepts ID=kali as a first-class target, so the OS half moved there and what is left here is the role. Concretely: - Removed: os/kali.zsh, os/kali.gitconfig, install/packages.txt, install/tool-versions.env, scripts/update-tool-checksums.sh, wsl/, ssh/config. Every one of them has an equivalent in dotfiles-Debian, whose package list carries the Kali tier as # only:kali annotations. - bootstrap.sh is distro-agnostic and installs nothing by default. The ID=kali gate, the apt base install, the full-upgrade, the SHA-pinned verified_install block, the carapace .deb, the 1Password repo and the /etc/wsl.conf write are all gone — they belong to the OS-native layer. What replaces them is a report: a three-state host-tool probe (on $PATH / present-but-unreachable / missing), modelled on dotfiles-Defense. - --install is the new opt-in. On Kali it apt-installs install/offensive-packages.txt as before. On any other Debian-family box it installs a small portable subset via pipx (impacket, certipy-ad, netexec, bloodyAD, ldapdomaindump) and go (nuclei, gobuster, ffuf, kerbrute). On anything else it refuses and says why rather than guessing at a package manager. - --no-offensive and --no-upgrade are accepted but inert, with a note — the behaviour they asked for is now the default, so aborting on them would be worse than honouring them. - --links-only with --install is refused: one wires symlinks only, the other installs packages.

install/tools.lst is new — the host-tool probe list, and the one place it is written. Twin of dotfiles-Defense's. A command belongs there only if offensive/offensive.zsh probes or invokes it by bare name.

offsync replaces this repo's half of dotsync. dotsync came from os/kali.zsh and now belongs to the OS-native layer (band 80). offensive.zsh exports $DOTFILES_OFFENSE and binds offsync to it — a distinct verb, because reusing dotsync at band 85 would silently shadow the OS layer's.

test/check-packages.sh and make packages-check now check one manifest (install/offensive-packages.txt); make tool-checksums is gone with the pins.

The gating workflows (lint, bootstrap, companion, routine-filter) no longer use trigger-level path filters: a paths:-skipped workflow produces no check run, so requiring one would hang every non-matching PR.

os/kali.gitconfig no longer duplicates Core's init.defaultBranch, and os/kali.zsh no longer duplicates Core's ~/.local/bin PATH prepend.

offensive/templates/engagement.md documents the layout mkengagement actually creates.

pipx installs different binary names than Kali does. PyPI's impacket ships secretsdump.py, not Kali's impacket-secretsdump wrapper; certipy-ad ships certipy. offensive.zsh probes the Kali names, so those HAVE_* flags do not fire on a pipx box. The bootstrap's probe recognises both names, so the report is honest; teaching the shell layer to resolve both is a separate change.

github_credential_backdoor now also selects personal_access_token.request_created (#348). This follows htpx's gh-cred-audit (htpx#139). GitHub logs the request only in orgs that require approval for fine-grained PATs. There it is the moment an attacker-minted token can still be denied, and a denied request never produces the access_granted the rule already selected. Neither PAT action had a fixture before. Each now has its own single-event TP row, because zircolite passes a TP file when any event in it matches, so a shared file would hide a typo in either action name.

Detection review 3, section C: the two findings that needed lab or estate data. - dpapi_backupkey_secret_read_4662 keeps SYSTEM in scope, on purpose. Running the extraction on the DC from a SYSTEM context (psexec to the DC, then mimikatz lsadump::backupkeys or SharpDPAPI backupkey) records S-1-5-18 as the subject, so excluding SYSTEM would hide common post-compromise tradecraft. A new TP covers that read. The rule says what to do if a lab capture shows BackuprKey servicing logging as SYSTEM: split it into a lower-level rule, don't exclude it. - The GPP User-preferences sweep threshold (10) is now DEPLOY-REQUIRED, with a README deploy-time row. The count is of distinct paths, and each path carries its GPO's GUID, so the threshold has to clear what one user reads across all their linked GPOs. The TP sweep now spans four GPOs, and a new logon TN reads six files from three.

Detection review, section C (1-7): seven rules with a dead term, an easy evasion, or an allowlist keyed on a name the attacker picks. Each fix carries a fixture that the old rule gets wrong: it misses the new TP or fires on the new TN. Host validation is 111/111 with 80 true negatives (was 77). - potato_seimpersonate_4688: 4688 renders NETWORK SERVICE as the computer account and an app pool as its bare pool name, so the NETWORK SERVICE term never matched and APPPOOL caught only pools with the word in their name. It now keys on SIDs (S-1-5-82-*, S-1-5-19, S-1-5-20) with name fallbacks. The fixture's IIS APPPOOL\DefaultAppPool SubjectUserName was not what Windows writes; it is now corrected, and a SYSTEM TN was added. - recovery_inhibition_process (test): it adds vssadmin resize shadowstorage, PowerShell Win32_ShadowCopy removal, and wbadmin delete systemstatebackup/backup, and recoveryenabled no longer requires the literal no. The old rule caught 1 of the 6 forms; the new rule catches all 6, and read-only near-misses stay silent. - suid_bit_set: /usr/bin/install (install -m 4755 /bin/bash /tmp/.x) was allowlisted, and every entry was a basename suffix, so /tmp/dpkg passed too. The allowlist is now full paths. - shadow_file_read, ssh_private_key_read: the allowlists keyed on comm, which a renamed copy or prctl sets. They now key on full exe paths, and cron is added to the shadow allowlist. The SSH rule no longer fires on *.pub. - lsass_handle_access, mass_file_read_4663: a dumper or collector renamed to MsMpEng.exe / SearchIndexer.exe anywhere on disk was filtered. They now use full paths, with Defender matched by its protected Platform directory. - data_destruction_wipe: diskpart never carries clean on its own command line. The branch now matches the shell that pipes it in; diskpart /s is deliberately left unmatched. - archive_staging_utility: it fired at high on extraction (7z x -p…, rar x -p-, tar -xf … -C %TEMP%). It now requires a create verb per archiver. Sigma's case-insensitive ' -c' also matched tar's -C <dir>, so tar uses its named create clusters. The Splunk precedence sign-off was re-traced for the new condition.

Detection review, section A: thirteen rules that could not fire (wholly or in one arm), or whose allowlist could never suppress, because rule and fixture shared a guess about the vendor's log. Every corrected name below was checked against a primary source (vendor docs or source code), and each fixture was rebuilt in that shape. Run against the new fixtures, the old rules fail ten validation cases; the new ones pass 44/44 cloud and 108/108 host. - GitHub: github_self_hosted_runner_registered keyed on self_hosted_runner.created, which GitHub does not emit; it now matches *.register_self_hosted_runner and *.configure_self_hosted_jit_runner. github_credential_backdoor's deploy-key arm used repo.create_deploy_key; GitHub logs a deploy key as public_key.create (github/docs audit-log data). - Slack: slack_external_shared_channel keyed on two action names Slack does not have; it now uses external_shared_channel_invite_created / _accepted / _approved / external_shared_channel_connected. - Harbor: a push is audited as operation: create (there is no push operation), and the actor is username, not operator. So harbor_image_pushed_trusted_tag never fired, and none of the three Harbor allowlists suppressed anything. The trusted-tag rule now also catches a tag re-pointed at an existing digest (create on tag). - PyPI: the collaborator rule missed the invite / accepted path (the takeover path) and now names project-creation's add Owner as a false positive. The token-upload rule's filter keyed on a publisher_type column that does not exist; it now reads project:release:add with additional.uploaded_via_trusted_publisher, so a trusted-publisher upload is finally suppressed. The trusted-publisher rule looked for a journal entry Warehouse never writes; it now keys on the project:oidc:publisher-added event. - Google Workspace: gws_admin_role_grant missed GRANT_ADMIN_PRIVILEGE, the actual super-admin grant, and mislabelled GRANT_DELEGATED_ADMIN_PRIVILEGES as one. - GCP: gcp_iam_policy_backdoor required a leading-dot, exact-case .SetIamPolicy, missing Resource Manager's …projects.setIamPolicy, bucket storage.setIamPermissions and the SetIAMPolicy spelling. Each casing is now listed. - AD: ldap_recon_property_reads_4662 used legacyExchangeDN's GUID for servicePrincipalName (now f3a64788-…, MS-ADA3), so its Kerberoast half never fired. ldap_recon_search_filter_1644 matched the bitwise-OID form a DC never logs (1644 rewrites it to userAccountControl&<bits>) and trustedForDelegation, which is a PowerShell pseudo-property rather than an LDAP attribute. - Jenkins: the Audit Trail plugin's default pattern logs neither /script nor generateNewToken. Both rules now carry a DEPLOY-REQUIRED note and a README deploy-time row, and jenkins_script_console drops to experimental. npm_publish_2fa_disabled (#149) and snowflake_network_policy_change also drop to experimental while their fields are unconfirmed. 17 fixtures move to vendor-documented, each citing its source.

The host validation gate now tests correlation timespan, and runs the current SQL backend. #333 pinned pysigma-backend-sqlite to 1.2.4 because 2.0.0 windows each correlation on the event time and the fixtures had none. The 34 correlation fixtures now carry Event.System.TimeCreated (one second apart, inside the shortest 5m window), and each of the 16 correlation rules gains an -outside-window case: the same TP events re-timed so no window holds the threshold (a burst that is simply too slow). Those 16 cases fail on 1.2.4, which ignores the window, and pass on 2.0.0, so the pin moves to ==2.0.0 rather than floating: the backend version decides whether half of every correlation rule is tested. 108/108 on a fresh install.

The host validation plane went red overnight with nothing in the repo changed: every correlation rule stopped firing. zircolite 3.7.6 floats pysigma-backend-sqlite>=0.1.1, and 2.0.0 (2026-09-26) started enforcing correlation timespan on a timestamp column that the synthetic fixtures do not carry, where 1.2.x compiled a bare GROUP BY/HAVING and ignored the window. All 20 value_count/event_count cases went silent (72/92), bisected to that one package. zircolite 4.1.0, which requires sqlite >=2.0.0, fails the same 20, so the fix is a pin, not an engine bump: zircolite-constraints.txt now holds pysigma-backend-sqlite==1.2.4 (92/92), reversing its old "backends stay zircolite's business" line with the reason. Lifting the pin means timestamp-aware fixtures, so the gate exercises the windows it currently never tested.

detections/README.md's tables had drifted from the corpus (#314). Adds the ten missing substitution rows — aws_snapshot_share_external, azure_vm_run_command, azure_keyvault_bulk_secret_read, both remaining gcp_* rules, host_enum_srvsvc_wkssvc_5145, local_group_enum_sweep_4798_4799, gws_illicit_oauth_grant, k8s_pod_exec_attach, harbor_image_pushed_trusted_tag — and the three missing rule-table rows: gcp_iam_policy_backdoor, gcp_audit_log_sink_deleted, asrep_roast_4768. The last of those is easy to miss because a differently-named sibling is listed (asrep_roast_probing_4771, the correlation); they are separate rules. Two of the twelve markers were not substitutions at all, which is why they had no home and is recorded as its own finding rather than papered over. k8s_privileged_pod_created's marker is about how your backend expands JSON arrays; slack_2fa_enforcement_disabled's is about writing a collector mapping so the rule can tell an enable from a disable. Neither has a placeholder to replace, so neither fits a table headed *Substitutions* with Substitute / Until you do columns. They get a second table — Deploy-time backend work — rather than a marker of their own, because deploy-required.sh is the one checklist an operator runs before deploying and both belong on it: skip either and the rule ships subtly wrong rather than merely noisy, which is the harder failure to notice.

entra_directory_role_grant allowlisted a display name (#306). filter_iga keyed on Identity, the AuditLogs actor display-name column — mutable and non-unique, so the allowlist stops matching the day IGA renames the service principal. It fails *open* here, which means noise rather than a miss, and that is the direction that ends in a mute. Its two Azure siblings go out of their way to warn against precisely this (azure_keyvault_bulk_secret_read: "The value is an object id (oid), NOT a name"; azure_vm_run_command: a name-shaped entry for a service principal "matches nothing and leaves the rule as noisy as an empty allowlist, while looking filled in"); this was the one rule in the set that had not had that treatment. Now matches the actor object id with InitiatedBy|contains. The path is not the same for every actor — InitiatedBy.user.id for a human, InitiatedBy.app.servicePrincipalId for an app, never both, which is why this repo's own hand-written Sentinel queries coalesce the two arms. Sigma cannot coalesce, so a single dotted key would silently cover only one kind of actor, and automation — the case the filter exists for — is the kind it would miss. Matching the column covers both, and keeps the field flat, which is what lets the rule stay in the EVTX validation plane instead of being rewritten into the cloud one. The comment now also warns against InitiatedBy.app.appId: that is the *application*, so allowlisting it exempts every principal using it. The fixtures carry one arm each — user on the TP, app on the TN — and the TN's appId is deliberately a different guid from its servicePrincipalId so the pair shows the two are not interchangeable. Finding 3 of #302 (okta_mfa_factor_reset missing a filter_helpdesk scaffold) stays declined: every Okta sibling is filter-free, as is the cross-platform twin gws_admin_role_grant, so the absence is the SaaS-audit convention rather than an outlier.

DEFENSE-METHODOLOGY.md claimed GCP had reached its resource plane. It had not (#305). The plane-axis passage read "AWS and GCP both reached their resource planes" — written while the Azure gap was being closed, with GCP asserted rather than checked. The error was load-bearing rather than cosmetic: a ledger saying a plane is covered is a reason for the weekly /coverage-gap sweep not to look there, so the false sentence hid the gap it described, which is why correcting it is listed as the prerequisite on the issue and would have been worth doing even with no rule attached. CHANGELOG.md's own #280 entry carries the same claim; that entry is left as the historical record it is, and this line is the correction. T1530 on GCS is declined in the same pass, with its reopen condition: storage.objects.get is Data Access telemetry, off by default, so a GCS twin of aws_s3_bulk_exfil would be inert on most estates — the argument already used to decline T1526/T1580/T1069.003. It carries no known-absent marker id, and both the methodology and detections/README.md now say why: the marker gate reads the corpus, not the corpus per provider, and aws_s3_bulk_exfil already covers T1530, so listing the id would fail the build in the other direction. A decline scoped to a provider rather than a technique can only live in prose.

systemd_unit_persistence allowlisted the binary an attacker writes units with (#302). filter_provisioning carried /systemd and /systemctl by exe|endswith under a comment claiming it was the "same list as cron_persistence, same reason" — and cron's list has neither. The claim was false and the two entries were an evasion: systemctl edit --force --full evil.service and systemctl link /tmp/evil.service both attribute the unit-file write to /systemctl, so the rule was silent on two first-class variants of the T1543.002 it exists to catch. Neither entry was justified anywhere — #210 folded them into the package-manager list without a measured reason. Dropping them outright would have reintroduced the systemctl enable symlink noise they were presumably there for, so the suppression is now scoped by path instead of by binary: filter_systemctl_wants matches only the <target>.wants/ symlink farm that carries the volume, and filter_systemd_runtime only PID 1 writing under /run. A unit written at the top level of a watched directory alerts again, whoever wrote it. filter_provisioning is now cron's eleven entries exactly, so the comment is true. Proved rather than asserted: the two new manifest rows (linux-systemd-persist-systemctl-edit, linux-systemd-persist-runtime-generated) fail on the pre-change rule and pass on this one, and each carries the near-miss true negative showing the narrowed suppression still suppresses. The transient-unit path (systemd-run, StartTransientUnit) is written by PID 1 under /run and is therefore still suppressed — recorded in the rule as the accepted cost of not muting it on every reboot's generator output.

core-verify asks the integrity question again, and core-check gets the freshness one back (dotgibson/dotfiles-core#691). Adopting the fleet vocabulary pointed the canonical core-verify at this repo's upstream-tag query and demoted core-check to an alias of it. Those are two different questions: freshness is *is there a NEWER Core upstream?*, integrity is *is THIS core/ the tree core.lock pins?* — and Core's scripts/make-vocabulary.txt defines the canonical verb as the second. So the register read green on a target answering something else, while this repo still had no local integrity check at all: core-integrity.yml ran one in CI and nothing ran one here. core-check is a real target again, with help text naming its question, and core-verify delegates to Core's own scripts/core-integrity.sh from a CORE_REPO checkout — the same invocation CI uses, and the only implementation that knows how the fan-out filters the vendored subtree. It probes with -f plus bash … rather than -x, so a checkout that lost the exec bit does not fail it spuriously. Verified both ways against a sibling clone at core v6.1.0: core-verify reports pristine, core-check reports current.

The SUID tripwire tested the wrong argument for the one chmod that matters, and the history rule watched a syscall that could never be recorded. Both are documented auditd rules rather than Sigma logic, which is why neither fixture nor gate could see them. suid_bit_set shipped -S chmod,fchmod,fchmodat -F a1&04000, but the mode is a1 only for chmod(path, mode) and fchmod(fd, mode); fchmodat(dirfd, path, mode, flags) carries it in a2, so for every fchmodat the kernel ANDed a pathname pointer against 04000 and recorded or dropped the event depending on where the string happened to sit in memory. That is not a corner case: fchmodat is what coreutils and glibc's -at paths call, and it is the only path-based chmod that exists on arm64, which has no chmod syscall at all — so on an arm64 host the whole rule rested on the broken predicate. Now split by argument position, four lines instead of two, with the arm64 load failure and fchmodat2 both written down. history_clearing had the twin defect one layer along: it listed ftruncate, which takes a descriptor and emits no PATH record, so under -F dir= it was never recorded — dead in the list rather than merely noisy — while : > ~/.bash_history, the canonical clear, is an open with O_TRUNC and was not in the list at all. Replaced with open/openat O_TRUNC lines (flags in a1 and a2 respectively, the same split), and coreutils truncate -s0 is now named as genuinely unreached from the file plane rather than silently missed. Neither rule's Sigma changed; both descriptions now predict what a lab run must show, including the truncate -s0 non-result.

Three auditd rules assumed an ingestion model nothing stated. ssh_authorized_keys_write, ssh_private_key_read and history_clearing match key (SYSCALL record) and name (PATH record) in one selection, which only works where the pipeline coalesces the records of one auditd event into a single document — auditbeat/Elastic and the Splunk auditd TA do, a raw line parser does not, and there the three are inert while the key-only rules beside them keep working. Stated in each rule and in detections/README.md, alongside a note that syscall argument positions are per syscall rather than per family.

The potato rules cited the pre-re-measurement figures, and one of them argued the opposite of the record it cites. 2026-08-token-mismatch-sysmon-1.md was re-measured over the full corpus on 2026-08-30 — 147 Sysmon-1 records became 1491, and four recognised potato captures became six — but the rules reading it were not updated with it. Seven hand-written locations still said 147 / four captures / 4-of-4, across token_theft_parent_child_mismatch_sysmon_1.yml, potato_seimpersonate_sysmon_1.yml, DEFENSE-METHODOLOGY.md, fixture-provenance.tsv and docker/LAB-VALIDATION-PLAN.md. Corrected to 5 of 6 over 1491, with the sixth (PrintSpoofer) named and explained rather than absorbed into a count: its operator was already an interactive admin, so no service identity appears on that event and neither rule can reach it. The count of payloads the pair's Image list drops was also stale at two — it is three (notepad.exe, whoami.exe, nc64.exe), which is a third of the rule's own detections rather than a quarter. The ParentUser-availability note in both rules said "only the one from a 2022 host carries ParentUser"; four of the 1491 do, two of them the - placeholder. The one that mattered beyond bookkeeping is the rejected negated-filter variant. The rule defended rejecting it on the premise that it "finds the same 4 of 4 on this corpus and nothing more, so it buys no coverage here" — i.e. rejected *despite* being equivalent, purely on the Splunk NOT-on-missing-field conversion hazard. The record says the opposite: over 1491 records it matches 8, not 5, and two of the three extra are arguably wanted, so the decisive objection is the third — a ParentUser of -, which does not contain SYSTEM and so passes a negated filter, in a corpus where 401 of 1491 records resolve no parent at all. The rule now makes both arguments instead of the weaker one. No detection logic changed; the Splunk deploy form is regenerated.

**potato_security_4688.jsonl was a three-key skeleton, and token_theft_4688_* were never checked against a real event. The 4688 potato fixture carried NewProcessName, SubjectUserName and SubjectUserSid and omitted the twelve other fields every real 4688 carries; it is rebuilt on the captured event-version-2 key set and field order, with the Target Subject block left null on purpose so it does not pre-judge #230. The token_theft 4688 fixtures needed no change — their key set proved identical to six captured 4688s — and that rule fired on real telemetry for the first time**, on a genuine token swap. Its pre-Windows-10 falsepositives note is measured now too: captured event-version-1 4688s carry no Target Subject block at all and the rule is correctly silent on them. One observation recorded rather than fixed — a captured 4688 can populate TargetUserName/TargetDomainName/ TargetLogonId while TargetUserSid reads the null SID, and TargetUserSid is the only one of the four that rule can see. Five provenance rows move to vendor-documented; none reaches captured, because none of this is first-party.

The "a rule naming both channels' fields nulls under either pipeline" claim was false, in all six places it appeared. Repeated by the potato_seimpersonate pair, the T1486 mass_file_encryption pair, host_recon_command_burst, and twice in detections/README.md — where it is cited as precedent — the claim was that a pysigma pipeline unable to resolve a field drops the whole rule. Measured with the CI pins (sigma-cli 3.0.2, pysigma 1.5.0): it does not. Such a rule compiles under both pipelines with the unresolvable field passed through unmapped, and an OR of the two field sets fires correctly on each channel. What actually makes one rule insufficient is that the logsource resolves to one EventID per pipeline — category: process_creation becomes EventID=1 under sysmon and 4688 under windows-audit, whichever rule you compile — so a single compiled search covers a single channel regardless of the fields it names. The per-channel split is still correct; only the stated reason was wrong, and the corrected reason is now what each rule gives.

check-fixture-provenance.sh no longer claims every fixture is unverified. Stale since aa02c28; the ledger has carried vendor-documented rows since. Rewritten to describe why the distribution is deliberately not gated, without a count that goes stale again.

potato_seimpersonate_sysmon_1 was keyed on the wrong field and had never fired on a potato (#239). The rule and detections/README.md described it as the Sysmon half of a per-channel pair with potato_seimpersonate_4688, one shape on two channels. It was not. 4688's SubjectUserName is the account that *created* the process; Sysmon 1's User is the account of the *new* process. The two agree on an ordinary service-spawns-shell event, which is why the pair looked like a twin and why its fixture passed — and they diverge on a successful potato, which is the entire technique. So the rule went silent at exactly the moment its twin fired, and a host forwarding only Sysmon read as covered for T1134.001 in both detections/README.md and detections/navigator/COVERAGE.md while seeing nothing. Measured rather than argued: replayed against four real potato captures on three hosts (RogueWinRM, NetworkServiceExploit, RottenPotato from an IIS webshell, EfsPotato) from the pinned EVTX corpus, the shipped rule fired on none of them. The selection moves to ParentUser, which is SubjectUserName's actual counterpart, and the corrected rule fires on the two captures whose payload is a named shell. The pairing claim in both rules and in detections/README.md is now true rather than merely stated. ParentUser needs Sysmon 13.00+, which is a real ingestion constraint and is written into the rule instead of assumed — on an older build the field is absent and the selection is silently unsatisfiable rather than noisy. Full measurement, and what it does not settle, in docker/validation/labruns/2026-08-potato-sysmon1-user-semantics.md. The 4688 half is untouched and still unconfirmed on a real potato; the first-party run is tracked as dotgibson/dotfiles-Defense#246. Fixture corrected to the measured shape (it carried no ParentUser key at all) and renamed to potato_sysmon1_tp.jsonl, and the pair gains its first true negative.

make core-check reported fleet drift from an empty variable. It printed "gh not installed — cannot query upstream tags" and then queried anyway; gh failing left upstream_ver empty, which is never equal to local_ver, so it announced • vendored core is 5.4.1, upstream is — a sync from dotfiles-core is owed. A confidently wrong answer about drift, which is worse than the 127 the same defect causes elsewhere. The guard and the query are now one recipe line, and an empty upstream is its own branch: it reports drift UNKNOWN, not current and exits 1, rather than guessing. Found by _core_make_gate_hits (dotgibson/dotfiles-core#775), not by eye.

make markdown announced a skip and then ran anyway. Each make recipe line runs in its own shell, so the guard's exit 0 only ended that line: without npx it printed "npx not available — skipping markdown" and then ran npx, exiting 127. Collapsed into one recipe line, so the skip is a real skip (dotgibson/dotfiles-core#775 — the same defect in six other fleet repos). MD_FILES was already correct here, so only the guard needed fixing, not the scope. An unreadable MARKDOWNLINT_VERSION now fails rather than silently linting unpinned — "same version as CI" is this target's whole claim.

.markdownlint.jsonc's header claimed this config was "the local README check" and that "CI in this repo gates its own code, not its Markdown". Both were true when written; dotgibson/dotfiles-core#592 made the markdown leg blocking and it covers all 21 repo-owned files, not just the README.

The Sigma toolchain pins moved where Renovate can see them (#322). pySigma, pyparsing, sigma-cli and the three backends were strings inside sigma.yml's run: line, so nothing noticed when they aged. They now live in detections/requirements.txt, which the sigma gate installs with -r, the cloud validation plane with -c, and the README's local block with -r. check-readme-gates.sh gains a fourth assertion that the block reads the same file as CI, because the block no longer shows versions inline. renovate.json also watches docker/validation/zircolite-constraints.txt and groups every bump into one ci(deps) PR, since the packages are coupled. A bump that turns the hard gate red is that PR's intended outcome.

bootstrap.sh is the fleet's pilot of Core's bootstrap driver, blib_main (dotgibson/dotfiles-core#976). The shared half of every bootstrap — the flag loop, the escalator, the Core symlink surface, the band-85 role stage, the managed ~/.zshrc, the closing report — now runs from one definition in core/lib/bootstrap-lib.sh; this file declares what it is (BOOTSTRAP_ROLE=defense, BOOTSTRAP_LOGIN_SHELL=0) and keeps only what is genuinely Defense's: the forensics host-tool probe (bootstrap_check, behind --no-check via bootstrap_flag) and the closing case-data note plus the login-shell guard, which is now Core's blib_login_shell_hint (Offense carried the same one). The hand-rolled band-85 stage is gone — blib_link_role_layer wires 85-defense.zsh and defense/templates and drops the stale pre-v4 link, exactly as before. Three things the driver gives this repo for free: --only zsh,git in the space form (the old for a in "$@" loop could only parse --only=zsh,git), -n for --dry-run, and the local core/ pre-commit guard on a fresh clone. One convention change: an unknown flag exits 2 (usage error), not 1, which stays for real failures. Everything else on the box is byte-identical: same links, same loader, same closing lines, same exit codes.

bootstrap.sh closes on Core's failure tally instead of over it (dotgibson/dotfiles-core#973). This bootstrap installs nothing and escalates nothing, so it had no failure ledger — and none of its own steps needs one; the tool probe is report-only by design. But the shared scaffold it calls records *its* failures (a tpm clone behind a proxy) into the lib's array as it goes, and this script then printed "Defense bootstrap complete" regardless. The closing block now runs blib_failures_report, says "finished WITH the misses above" when there were any, and a new --strict turns that into exit 1; without it the exit code is unchanged, as befits a report-only script. Core's §5f ledger exempts this repo from blib_note_fail and blib_resolve_su with those reasons, so this is the last row the fleet ratchet had open.

The Kubernetes escape rule's hostPath branch matched only the literal /. A mount of /var/run/docker.sock, /run/containerd, /proc, /etc, /root or /var/lib/kubelet is a node takeover on its own and produced no alert. Now the root mount plus a prefix list, with hostIPC added as a scalar branch beside hostPID. hostNetwork was considered and declined in the rule: it is not an escape by itself and it is precisely the CNI/node-agent request the rule's own false positives name. The documented array-traversal caveat is unchanged and still governs the two array-keyed branches.

snowflake_network_policy_change fired on statements that read a policy. It excluded SHOW but not DESCRIBE/DESC. filter_show is now filter_readonly and covers both. GRANT ... ON NETWORK POLICY stays selected on purpose — it changes no allowlist, but a GRANT OWNERSHIP on the enforced policy is the step before an attacker can alter it.

Four proposals from the same review were declined, in the rules themselves. A decline that lives only in an issue gets re-proposed next cycle. sudo_root_shell keeps comm and its interpreter list: exe resolves symlinks, so an exe|endswith list silently loses hosts where /bin/sh is dash or python3 is python3.14, and dropping the list turns a detection into a log of every command run through sudo — the GTFOBins escapes it is accused of missing exec a listed shell as a child and are caught there. k8s_clusteradmin_binding does not gain verb: [escalate, bind]: those are RBAC authorization verbs, never the verb of an audit event, so the selection would match nothing while reading as coverage. jenkins_job_backdoor does not add config.xml: the Audit Trail plugin's default pattern does not log it, and the logged line carries no HTTP method, so the branch could not separate the malicious POST from the routine GET. jenkins_api_token_created keeps no filter block: this corpus has no verified Jenkins actor field, and inventing one produces a filter that passes its own fixture and matches nothing in production — the hazard fixture-provenance.tsv exists to expose.

check-readme-tables.sh — the README's rule and deploy-time tables are now gated (#314). Same argument check-readme-gates.sh makes about the other half of the file: *"the README is load-bearing documentation, so it gets a gate like the rest of the load-bearing artifacts."* Nothing tied these tables to detections/sigma/, so they drifted — twelve rules carried a DEPLOY-REQUIRED marker with no row in the deploy-time table, and three had no row in any per-directory table. Four assertions, both directions on both tables. The deploy direction is the expensive one: the table's own preamble says the marker *"isn't enforcement, so this is the discoverable checklist instead"*, so a rule missing from it ships with an unfilled placeholder nobody was told about — the failure half those rules' comments describe at length. A phantom row is worse, sending an operator to fill a placeholder that is not there. The rule-table direction is about honesty of scale: the cloud/ table listed one of three GCP rules, so GCP read as a third of what shipped. It locates the tables by heading text and fails rather than passing if a heading moves, because a silent pass would report a clean bill for a table it never read — the same posture as keying splunk-precedence-allowlist.tsv on stanza title. Each of the four assertions plus the heading guard was verified to fire by mutating the README, so the gate is demonstrated rather than assumed. Wired into make methodology, make sigma and sigma.yml (thirteen hard checks become fourteen), and check-readme-gates.sh required it to document itself.

Targeted LDAP recon has a detection (#284). T1087.002 / T1069.002 read as covered, but only through sharphound_ldap_sweep_4662.yml, a fan-out detector — a handful of revealing filters (servicePrincipalName=*, the userAccountControl bitfield match, adminCount=1) never trips it, and ldap-recon-4662 was the one htpx blue entry nothing here claimed and nothing in the methodology declined. Two rules close it: detections/sigma/discovery/ldap_recon_search_filter_1644.yml keys on the search-filter content, which only 1644 carries, and says that 1644 is off by default; ldap_recon_property_reads_4662.yml is the fallback where it is not collected, counting the SPN / UAC property GUIDs those filters read. They are two files because the Sentinel / Elastic deploy forms mark a whole file unsupported when it holds a correlation, which would have dropped the primary arm with the fallback. Both fire on their fixtures under zircolite, the 4662 arm with a true negative past its threshold.

T1537 Transfer Data to Cloud Account — detections/sigma/cloud/aws_snapshot_share_external.yml (#262). The corpus had no detection for exfil that never crosses an egress boundary. An attacker snapshots a volume, grants restore rights to an account they control, and copies it from there; the bytes move inside AWS's own address space over AWS's own APIs, so the wire plane, DLP, and aws_s3_bulk_exfil's object-read volume signal all stay quiet. Both existing Exfiltration rules key on crossing an external boundary — slack_external_shared_channel on an invite out, snowflake_data_unload on COPY INTO an external location — and T1537 is definitionally the case that does not, so this is the one exfil family that had no representative at all rather than thin coverage of a covered one. It is the inverse of the two CloudTrail rules beside it. ModifySnapshotAttribute, ModifyImageAttribute and the RDS pair are MANAGEMENT events, in every trail by default, where aws_s3_bulk_exfil and aws_data_destruction both go half-blind without S3 data-event logging. So it needs no new telemetry — which is why it was authorable at all, and what separates it from every entry in the declined ledger, each of which is blocked on telemetry the estate lacks. Two tiers, because only one needs tuning. A grant to group: all is public, fires with no allowlist, and is correct on day one; a grant to a named account is a finding only once filter_own_accounts holds your own account IDs. The condition puts the public arm OUTSIDE the filter deliberately, which is recorded in detections/siem/splunk-precedence-allowlist.tsv because the compiled SPL relies on search-command precedence to bind it — traced, not assumed. Keyed on the .add. path rather than the bare verb, which scopes out two non-events at once: ModifySnapshotAttribute also sets a description, and the remove half of the same call is the attacker's cleanup. Both are proven inert by the true-negative fixture, alongside a share to an allowlisted account. Its blind spot is stated in the rule: the attacker's CopySnapshot runs in THEIR account and never reaches the victim's trail — the same geometry that keeps CopyObject out of the S3 rule — and a share -> copy -> un-share sequence leaves a clean permission list, so a posture sweep over currently-shared snapshots is not a substitute for the event stream.

Two backend-typing fixes on the T1537 rule, and the gate divergence they exposed (review feedback on #268). The allowlist's AWS account IDs were unquoted, which is the convention every EventID in this corpus follows — but an account ID is a STRING that happens to be all digits, so the Sentinel form compiled == 111122223333 against a string field and the allowlist silently suppressed nothing. Splunk and Lucene are untyped and were unaffected, which is what made it easy to miss. They are quoted now, and the number_as_string validator that objects is excluded for this one rule id in detections/sigma-validation-config.yml rather than corpus-wide, so a genuinely mis-typed EventID elsewhere still fails. The '*' wildcard standing in for "field is present" was the second: it compiles to startswith "" in KQL, a tautology for any string and wrong against valuesToAdd, which CloudTrail emits as a JSON array. |exists: true gives each backend its real existence test — isnotempty(), exists:, =*. docker/validation/sigma_eval.py gained SigmaExists support to match, since it raised rather than guessing. Both were invisible to the rule's own true-negative fixture, because that fixture runs through the Python evaluator and not through a backend — precisely the hazard fixture-provenance.tsv's header describes, reached from a new direction. detections/check-attack-tags.sh ran sigma check with NO config, so it enabled every validator and honoured no exclusions. A per-rule exclusion therefore passed the hermetic lint and failed here, reported as an ATT&CK-tag error it was not. It now reuses sigma-validation-config.yml with only the -attacktag line stripped — that line exists to keep the hermetic lint off the network, and this gate has the pinned bundle injected already. Verified the tag validator still fires by tagging a rule attack.t9999.

detections/htpx.pin -> v3.1.0 (7ea71779365c). Carries the aws-snapshot-share-exfil <-> aws-snapshot-share-cloudtrail pair the rule above names. Authored red-first upstream (dotgibson/htpx#115) so the purple loop closed before the rule existed, rather than shipping the corpus's only unpaired rule.

Seven rules that named a benign false positive in prose now carry the filter block to suppress it. Each documented the noise and left the reader to hand-edit the rule: shadow_credentials_keycredentiallink_5136 (filter_whfb — the rule prescribed a Windows Hello allowlist its detection never implemented, so in any WHfB tenant this high rule fired on every legitimate key enrollment; the on-prem key-trust self-write, where Subject equals the object, is named as needing a SIEM-side comparison Sigma cannot express), gcp_service_account_key_created (filter_iac, for parity with its GCP siblings), harbor_robot_account_created (filter_provisioning), entra_directory_role_grant (filter_iga — PIM/IGA automation, with a note NOT to allowlist the PIM service whose operations the rule deliberately selects), bitlocker_abuse_encryption (filter_provisioning on the imaging task-sequence parent), ldap_recon_explicit_creds_4648 (filter_sweep_principals, present in its sibling discovery rules but not here — the correlation's threshold is no substitute, a scanner clears it every cycle), and github_self_hosted_runner_registered (filter_runner_provisioning). Every one is a DEPLOY-REQUIRED stub with a true-negative fixture proving the exclusion works, so the validation advisory that listed rules with a filter and no true negative is now empty. The BitLocker rule's generated Splunk form mixes a top-level OR with the new NOT; the binding was traced and recorded in splunk-precedence-allowlist.tsv rather than left to precedence.

\pipe\srvsvc and \pipe\epmapper are read at last; EfsPotato and RoguePotato are watched on the mechanism plane. srvsvc_epmapper_pipe_impersonation_sysmon_17.yml (id 563f2958-0d44-4138-884f-14d338d37cd9) selects EventType: CreatePipe on a PipeName whose name NESTS either endpoint, closing the telemetry-ahead-of-detection hole #225 closed for spoolss and #229 for atsvc/svcctl/efsrpc. Two names, one rule: they share the invariant, the EventType pin, the absence of an Image key, the technique and both its tactics, and the false-positive story, which is the svcctl/atsvc case rather than the efsrpc one, where the split existed because the invariant genuinely differed. With this, every name the shipped config collects is either read or declined in writing. The three questions #240 carried were re-derived, not inherited, and the sweep was re-run from scratch because the original figures lived only in a config comment — a rule resting on a number recorded nowhere a reader could check is the circularity fixture-provenance.tsv exists to make visible. docker/validation/labruns/2026-08-srvsvc-epmapper-pipe-creation.md is the record: all 278 EVTX of sbousseaden/EVTX-ATTACK-SAMPLES @4ceed2f4, chainsaw 2.16.4, 61 PipeEvent records — the figure reproduces exactly. *Creation, not connection*, and for a third distinct reason, so neither sibling's argument carries across. Every nested pipe in the corpus produces exactly one 17 and one 18, tens of milliseconds apart: the 17 carries the tool's own Image, the 18 is the coerced service binding back as Image=System ProcessId=4, naming the victim. Dropping the pin takes the rule from 2 matches to 4 and adds no attack it did not already see — only a misattributed second copy of each. So the pin buys deduplication and attribution and costs no coverage, where coercion_efsrpc_pipe_sysmon_18's identical-looking pin is load-bearing against *volume* because lsass creates \efsrpc every boot. Both siblings now say so in their own descriptions. *The generic \<x>\pipe\<y> shape is rejected*, and the decisive objection turned out to be measured rather than argued. It is expressible without regex (PipeName|contains: '\pipe\', since Sysmon renders one leading backslash and no \Device\NamedPipe\ prefix) and on the create half it matches 3 of 61, all attacks — but the third is PrintSpoofer's nested spoolss pipe, which spoolss_pipe_impersonation_sysmon_17 already fires on, so its marginal coverage over this corpus is zero. The ingestion objection stands separately: it needs unfiltered PipeEvent collection, so under the shipped onmatch="include" baseline it would see only the seven collected names — a much larger decision than a rule may make on the config's behalf. And 3-of-3 measures an attack-sample corpus, not an estate. It still misses GodPotato. Reopen condition recorded in the rule: if collection is ever widened past an include list, the generic form should *replace* this rule rather than sit beside it. For the same reason spoolss is deliberately absent from the name list — that rule's contains: 'spoolss' already matches the nested form, verified against the record, so adding it here would double-alert one attack. *No filter_* block, and the omission is the argument.* The legitimate creators make the bare \srvsvc and \epmapper, which the selection does not contain, so the narrowing does the work an exclusion would. #240's proposed filter_legit: Image|endswith: '\svchost.exe' is confirmed dead: the one legitimate \epmapper record is Image=System. A cosmetic filter would be that defect written twice. Consequently no check-splunk-precedence.sh row is needed — the compiled Splunk form is EventType="CreatePipe" PipeName IN ("*\\pipe\\srvsvc*", "*\\pipe\\epmapper*"), an OR list with no NOT beside it. The fixtures are a provenance first for this repo. srvsvc_epmapper_pipe_17_tp.jsonl is the two real create records transcribed verbatim from the corpus — the first pipe fixtures here whose *values*, not merely whose key set, come from the provider. They stay vendor-documented, not captured: labruns/README.md reserves that for first-party capture, and these are 2020–2021 third-party builds. A true negative ships despite the rule having no filter_* — not required by any gate, but the \pipe\ narrowing is the rule's entire thesis and nothing else would prove it discriminates; it changes exactly one value per line, PipeName nested to bare, holding Image at the TP's so the nesting is isolated as the sole discriminator. Validation: sigma efficacy 84/84 passed (42 with a true-negative), run against the pinned zircolite v3.7.6 — the new row fires on the transcribed EfsPotato and RoguePotato records and stays silent on the near-miss. Two claims this repo was making are corrected. The bare-srvsvc traffic was described as "five … ordinary share enumeration … from Image=System" — four of the five are Image=System and the fifth is wmiprvse.exe, and they come from three different capture types plus a kekeo capture. And "3 of 61 records" for the nested shape counts *pipes*; it is 6 records over 3 pipes. The load-bearing half — that no legitimate bind takes the nested form — holds exactly. Drive-by: docker/validation/README.md said 81 manifest rows / 38 true negatives against a real 84 / 42, and runbook-sysmon18-remote-pipe.md said "two things still need a host" while listing three. What is not settled: volume on a live host, in either direction. No legitimate *create* of either name appears anywhere in the corpus and none of the captures spans a boot, so the claim that a legitimate create would carry the bare name is inference. That half carries to #235, whose runbook gains it as item 4 with a pre-committed prediction and EfsPotato/RoguePotato rows in its firing table. Closes dotgibson/dotfiles-Defense#248. Ledger: corpus 110 -> 111 rules, 128 -> 129 documents, techniques unchanged at 81. Privilege Escalation TA0004 9 | 14 -> 9 | 15, Stealth TA0005 3 | 5 -> 3 | 6, T1134.001 5 -> 6 rules. No new technique or tactic row, and no new Splunk precedence allowlist row.

\pipe\srvsvc and \pipe\epmapper join the PipeEvent include list; EfsPotato and RoguePotato stop being unwatched on the mechanism plane. Measured while gathering evidence for #240: every potato in the pinned sbousseaden/EVTX-ATTACK-SAMPLES corpus that stands up its own pipe uses the nested \<something>\pipe\<endpoint> shape, and two of the three do it on names nothing collected — EfsPotato on \dd4c18dc-…\pipe\srvsvc, RoguePotato on \RoguePotato\pipe\epmapper, both carrying their own Image on the create. detections/sysmon/sysmonconfig-detection-lab.xml dropped both events before Sigma ever saw them, which is the blocking constraint #240 records. The entries are deliberately \pipe\srvsvc and \pipe\epmapper rather than the bare names, and the measurement is the same shape twice: 7 of the 61 PipeEvent records match bare srvsvc and five are ordinary share enumeration (NetShareEnum, NetSessionEnum) arriving as \srvsvc from Image=System; 3 match bare epmapper and one is the legitimate endpoint mapper arriving as \epmapper. The narrow forms collect 2 apiece and leave the routine traffic out. Wanting that traffic is a separate decision and a separate rule. Worth recording on the epmapper side: that legitimate record is Image=System, not svchost.exe, so the filter_legit: Image|endswith: '\svchost.exe' #240 proposed would not have filtered it. Narrowing the collection is what does the job the Image filter was expected to do. No rule reads either name yet, which is the telemetry-ahead-of-detection hole #225 and #229 each closed one name at a time. Both are filed with the collection rather than after it, as dotgibson/dotfiles-Defense#248, and the config's comment block — which tracks which rule reads which name and why any name is unread — now distinguishes the two kinds of unread name: lsarpc because a rule there would be unfilterable volume and that is a decision, \pipe\srvsvc and \pipe\epmapper because the rule is owed. Closes dotgibson/dotfiles-Defense#240, whose three open questions carry to #248 — the volume one in particular, since no legitimate *create* of either name was observed and none of these captures spans a boot. Ledger: unchanged — collection only, no rule, no tactic or technique count moves.

A Sysmon-plane rule for the token swap itself, and the Stealth row widens a third time (follow-on to #239). #239 established that Sysmon 1's User is the new process and ParentUser the creator, then used only the creator half to repair potato_seimpersonate_sysmon_1. token_theft_parent_child_mismatch_sysmon_1.yml (id b7f135f0-c066-4b0b-ac45-3f6bb433be38) uses both: a child running as SYSTEM whose creator was an app-pool / NETWORK SERVICE / LOCAL SERVICE identity. That is token theft stated as two fields on one event — a service identity cannot spawn SYSTEM without holding a token it did not start with — so unlike the potato pair it observes the outcome rather than the shape before it, and it takes the TA0005 half of T1134.001 on the reopen condition #223 wrote. Stealth TA0005 goes 3 | 4 → 3 | 5; the technique count, which is what measures the gap, does not move. It carries no Image constraint on purpose: measured against the four real potato captures in the pinned corpus it fires 4/4 where the potato pair fires 2/4, the difference being payloads (notepad.exe, whoami.exe) that no shell list catches, and the shell list removes no noise — its only matches across all 147 Sysmon-1 records swept are those four swaps. The tidier variant mirroring the 4688 rule's filter_same_context was rejected on evidence: it compiles to Splunk as NOT ParentUser="*SYSTEM*", where NOT on an absent field matches, so on a pre-Sysmon-13 host it would fire on every SYSTEM process creation while the zircolite backend the gate runs stays silent — a defect the gate is structurally unable to see. Measurement in docker/validation/labruns/2026-08-token-mismatch-sysmon-1.md, including what it does not settle: ParentUser was still never observed on a real potato (all four captures predate Sysmon 13, so it was derived by ProcessGuid linkage), the corpus contains no EDR or RMM agent so the zero-false-positive result is "not yet met" rather than "does not occur", and the locale exposure is reasoned rather than measured.

The rest of the Sysmon PipeEvent block gets read (#229). #225 closed one of the five pipe names detections/sysmon/sysmonconfig-detection-lab.xml collects and left four collected-and-unread — the same telemetry-ahead-of-detection hole, one size smaller. Two rules close three of them: svcctl_atsvc_remote_pipe_sysmon_18 (Sysmon 18 / ConnectPipe on \svcctl and \atsvc with Image = System) and coercion_efsrpc_pipe_sysmon_18 (Sysmon 18 / ConnectPipe on \efsrpc). This is corroboration, not new coverage, and the ledger should not be read as wider than it is. The service smbexec/psexec installs over svcctl is already caught by service_creation_psexec_7045; the task atexec schedules over atsvc by scheduled_task_suspicious_4698; efsrpc coercion by coercion_named_pipes_5145 and the Suricata coercion.rules. What the pair adds is a second, independent plane: the bind is visible on the host where those audit subcategories are never forwarded, and it is the request rather than the result, so it fires earlier in the chain. Only T1021.002 is a genuinely new technique row, and only because nothing here previously named the admin-share access itself. The invariant was re-derived, not copied. #225's shape was ownership on pipe *creation*, and it transfers to none of these: svcctl, atsvc, efsrpc and lsarpc are all created once at boot by the OS, and every tool in scope *connects* to a pipe already there — so the creation half detects nothing on those names and the new rules take the connect half, the opposite trade for the opposite reason. Origin replaces ownership: a remote SMB client's pipe open is serviced by the kernel SMB server, so Image reads System rather than a local sc.exe/schtasks.exe, and that is what separates impacket from administration. lsarpc deliberately ships no rule. Sysmon PipeEvent carries no authenticating principal, so coercion_named_pipes_5145's filter_machine — the block that makes that pipe survivable on 5145 — has no counterpart here, and a coercion bind and a routine domain bind arrive as byte-identical events. The decline is argued in DEFENSE-METHODOLOGY.md and recorded in a form that runs: the efsrpc rule's true negative *is* an lsarpc bind. The cost is stated rather than buried — PetitPotam's default endpoint is lsarpc, so 5145 stays the primary for coercion. Both rules ship with unverified fixture provenance on purpose. That Sysmon emits an 18 for a remote SMB pipe open, attributed to System, is derived from where the kernel services that open rather than observed — the purple-team run that would confirm it has not been done, and until it has, the rules' silence means nothing.

spoolss_pipe_impersonation_sysmon_17 — the one hole where the telemetry was already enabled and no rule consumed it (#225). detections/sysmon/sysmonconfig-detection-lab.xml has collected Sysmon PipeEvent 17/18 on five pipe names since it was written, with a comment saying it exists to corroborate potato_seimpersonate — and no Sigma rule selected it. Both potato rules told the analyst to "confirm the SYSTEM outcome with Sysmon 17/18 on the spoolss/DCOM named pipe", which was an instruction to go read telemetry the corpus collected and had no detection for. The ingestion was done ahead of the detection and the detection never followed. The new rule closes that. Its invariant is ownership rather than content: legitimate spoolss pipes are created by the print spooler, and PrintSpoofer-class tools stand up their *own* pipe and coerce the spooler into connecting to it, so a non-spooler process creating one is the anomaly. That is a shape, not an IOC — it survives renaming the binary. It is pinned to EventType: CreatePipe deliberately: category: pipe_created resolves to 17 *and* 18, but the only connect the attack generates is the spooler binding back, which the rule's own spoolsv.exe filter removes — so everything surviving the filter on 18 would be ordinary print traffic. Signal on 17, noise on 18.

This reverses the standing decision in #223/#224, on the terms that decision set. Those issues declined the TA0005 (Stealth) half of T1134.001 for the potato_seimpersonate pair because what the pair selects is a service identity spawning a shell — the shape *before* the token is stolen — and recorded a reopen condition: a rule that actually detects the impersonation "earns the TA0005 half on its own evidence, and should take it". This is that rule, and it takes both tactic tags. The pair still declines, and DEFENSE-METHODOLOGY.md now records the argument as settled rather than pending; the 4624/4672 token-context half of the reopen condition remains open. Ledger: Stealth TA0005 2 | 2 -> 3 | 3, Privilege Escalation TA0004 9 | 11 -> 9 | 12.

htpx-drift.yml — a weekly question about the pinned corpus, and a correction to what #202 claimed. Pinning htpx (detections/htpx.pin) is what makes check-htpx-pairing.sh reproducible, and it opens one specific hole: the gate reads the pinned sha, but the references: URLs the rules write point at /blob/main/. So if upstream removes or renames an entry this repo names, the link is a live 404 for anyone who clicks it while CI stays green. Nothing watched for that. This does, weekly, and the report leads with exactly those entries. The correction. #202's commit message and PR said bloodhound-sharphound "was renamed bloodhound-collect upstream". That is wrong, and the distinction matters. Checked against htpx's full history: bloodhound-sharphound, bloodhound-sharphound-4662, archive-staging-rar, local-data-collection and rogue-account have never existed in that repo — not as a file, not as an id:, in any commit. All eight dead references were ids written *here* that were never right, not upstream drift. The fix was the same either way, and check-htpx-pairing.sh catches that class permanently at author time. But the rename story would have made this workflow look like a response to something that had already happened, when the hole it covers has not bitten yet. It is a cheap weekly question, not a reaction. It reports on corpus changes, not commits. A pin behind by a README edit or a .gitignore commit is behind by nothing — only two gates read this corpus and both read entries/ alone. Verified against real history: two consecutive upstream commits that touched no entry produce no issue. Filing for those is the nagging core-drift.yml's header says it refuses to do, and a weekly nag becomes a weekly ignored issue. Report-only, like core-drift.yml: one deduplicated issue via the existing file-routine-issue.sh, nothing changed. Bumping the pin stays deliberate, because a bump moves HTPX-COVERAGE.md and that diff is the point. check-htpx-pairing.sh gained --list-claims, a data query printing every entry this repo names. The workflow uses it rather than re-implementing "what counts as a claim" in YAML — that definition already has two readers, and a third would be how they start disagreeing.

The Defense↔htpx link is checked, not just asserted — check-htpx-pairing.sh plus a drift-gated HTPX-COVERAGE.md. detections/README.md opens by promising that each rule names the exact Offense fold and htpx pair that reproduces it, "so the purple loop is closed in the file itself". Rules kept that promise in three places — ~84 references: URLs, an htpx pair <id> in each validation note, and 82 cells of the Validate with (Offense fold · htpx pair) tables — and nothing verified any of it. htpx is a separate repo on its own release cycle, so an entry renamed there left a rule here pointing at a 404, and the only way to find out was for someone to click the link. The split is the design decision #196 asked for, and it is deliberate: - Claims are a hard gate. Naming an entry is a factual assertion about another repo — it is true or it is false. check-htpx-pairing.sh resolves every named entry against the pinned corpus and checks the blue ones still pair back to a red entry that points at them. - Gaps are a report. HTPX-COVERAGE.md renders which blue entries this repo claims, which it does not, which techniques here the corpus has no attack for, and which entries htpx declares unpaired. It never fails on a gap and it is drift-gated, so a change in the shape of the boundary arrives as a reviewable diff. htpx spans Okta, Workspace, GitHub Actions, GitLab, Jenkins, Harbor, Vault, Terraform Cloud, Snowflake, Cloudflare, npm and PyPI; a bidirectional foreign key would be red forever and silenced within a week. The issue predicted exactly that. Declared holes are excluded by field, not by an allowlist. htpx now requires pair_note: on any entry carrying pair: null (htpx#98), so the report reads the upstream reason verbatim instead of keeping a local copy of someone else's decision — which is the thing that goes stale. The corpus comes from a pinned commit (detections/htpx.pin), fetched by htpx-corpus.sh. Same argument as attack-data.pin: a check whose answer depends on what upstream did this morning is not a gate. No sha256 field, because the pin names a git commit and git's own object hashing already binds it — verifying HEAD against the pin *is* the digest check. This repo deliberately does not vendor htpx as a subtree the way Offense does; two gates read it, and a ~200-file subtree plus a second sync obligation is a steep price for that. Adopted after fixing what it found, in the same PR — the standard check-rule-coverage and the Splunk precedence gate were held to. Eight dead names: - bloodhound-sharphound / bloodhound-sharphound-4662 were renamed bloodhound-collect upstream — a dead references: URL, a dead validation note, and a dead table cell. - archive-staging-rar, local-data-collection and rogue-account named entries htpx has never had — the corpus's Collection and Exfiltration entries are all SaaS-side and it has no account-creation entry at all. Those rules now say so in prose rather than naming a phantom, which reads as a working cross-reference. Half of those were in the README table, which is why the gate reads that column too and not just the rules.

host_enum_srvsvc_wkssvc_5145 now cites its htpx blue entry. The rule's validation note has named the red side (smb-enum-nxc) since it was written, but the corpus had no detection to put beside it — htpx#97 tracked that hole for exactly this rule. entries/blue/smb-enum-5145.md is now upstream, ported from this rule, and the rule references it. It is the first edge the new gate was built to verify, so the gate ships with a live cross-boundary link rather than an empty set.

dnf repoquery (43) had been red on every run since the version floors landed (#193), and never because of a floor. The version probe in test/check-packages.sh ended its options with --. dnf5 only treats -- as end-of-options from 5.4 onwards. The 5.2.x that fedora:43 ships rejects it as an unknown argument, and the probe hid that error (stderr went to /dev/null). So every floored name came back with no version, and the check reported neovim and tree-sitter-cli as "virtual capabilities" on F43 only. The -- is gone; manifest names never start with -. A floored name that resolves by name but yields no version now reports a probe failure instead of blaming the manifest entry. packages.yml's path filter now includes test/check-packages.sh, because a change to the probe is only exercised on that workflow's Fedora containers.

The tmux auto-attach honours DOTFILES_NO_AUTOTMUX, the fleet's one opt-out name (dotgibson/dotfiles-core#877). MacBook, openSUSE and Gentoo already read it; this layer attached unconditionally for any interactive TTY, which is how dotfiles-core's README hero render — a vhs session that sources this layer — typed its whole tour into a fresh main session. Core's gen-hero-tape.sh now refuses to render a hero on a layer that does not honour the knob. Export DOTFILES_NO_AUTOTMUX=1 for any harness that drives an interactive zsh and must not land in tmux.

make markdown probed for a global, unpinned markdownlint-cli2 — so on a normal box it never linted anything (dotgibson/dotfiles-core#873). Nothing in this repo's bootstrap installs markdownlint-cli2 globally; it is npm-only. So unless the operator had separately run npm i -g markdownlint-cli2, the guard fired on every invocation and the target skipped, cleanly and with exit 0, forever. That is a correct guard doing exactly what it says — and a local mirror of a blocking CI gate that has never mirrored anything. dotgibson/dotfiles-core#775 fixed this target's skip guard and its file scope; neither defect could bite while the target never ran at all. And where the binary *was* installed it was whatever version npm last put there, while lint-call.yml installs the pinned MARKDOWNLINT_VERSION — so a rule that changes across a bump reds a required check against a green local run. It now runs the pinned version through npx, reading the number from the vendored core/scripts/tool-versions.env rather than restating it, and refuses rather than guess if that pin is unreadable — a silently-unpinned lint being the thing this fixes. npx needs only node, which is far likelier present than a global markdownlint install, and still self-skips without it so make lint works on a bare box. Converges on the shape dotfiles-Offense and dotfiles-Defense already run.

bootstrap.sh's PATH is not the shell's PATH — adopt blib_user_bindirs_on_path (dotgibson/dotfiles-core#748). Replaces the hand-rolled export PATH="$HOME/.local/bin:$HOME/.cargo/bin:$HOME/.atuin/bin:$PATH" prelude. ~/.local/bin, ~/.cargo/bin and $GOBIN reach PATH only through the zsh layer, i.e. only inside a Core shell — which does not exist while bootstrap.sh runs. So every command -v <tool> guard here was answered by the PATH of whatever shell launched the bootstrap: on a fresh box, bash, with none of them. That is wasted work when the guard picks whether to reinstall, and a wrong answer when it picks a branch — dotfiles-openSUSE probed command -v mise for a mise mise.run had written to ~/.local/bin moments earlier, both arms of its Go fallback missed, and the run exited 2 on every bootstrap. No stubbed CI leg can see that: a stub installs nothing, so "is the tool present afterwards" can never fail under one. Core has shipped blib_user_bindirs_on_path for exactly this since dotgibson/dotfiles-core#425 — it resolves CARGO_HOME and GOBIN/GOPATH rather than hard-coding them, and adds only directories that exist, so it is called again after an installer creates one. The directory this script installs into is mkdir -p'd before the helper runs: the helper adds only directories that already exist, so a straight swap for the old unconditional export would have dropped ~/.local/bin for the whole first run and made command -v atuin miss the binary the atuin block had just linked there, skipping the systemd user unit. A second call now runs after the mise.run install, so _dotfiles_go_install's command -v mise arm sees the mise this script just installed.

make check was not hermetic, and wrote Core into your real config dir (dotgibson/dotfiles-core#852). The target promises "a hermetic --links-only run against a throwaway HOME" and redirected only HOME — but bootstrap.sh resolves its target as CONFIG="${XDG_CONFIG_HOME:-$HOME/.config}", and core/lib/bootstrap-lib.sh defaults XDG_CONFIG_HOME, XDG_STATE_HOME, XDG_CACHE_HOME, XDG_DATA_HOME and ZDOTDIR the same way. A :-/:= default applies only when the variable is unset, so for anyone who exports XDG_CONFIG_HOME the run wired Core into their live config tree and then failed its own assertions, which look under the temp dir bootstrap never touched. Reproduced on Fedora 44: zsh/, nvim, starship.toml, tmux, git, mise, lazygit, atuin, jj, sesh and tealdeer all landed in the exported XDG_CONFIG_HOME, while the target reported MISSING symlink on a clean checkout — a gate that mutates the box it was only supposed to inspect, then blames the tree. env -u for the five variables the bootstrap path actually consults fixes both halves; verified with XDG_CONFIG_HOME *and* ZDOTDIR pointed at a decoy, which now stays empty while the check passes. dotfiles-openSUSE had already reached the same fix locally.

make check's mktemp -d was unguarded, so a failure left $tmp empty and the next line ran mkdir -p "$tmp/.config/tmux/plugins/tpm" — /.config/… on the real filesystem. It now refuses, and a trap replaces the two hand-placed rm -rfs so an interrupted run cleans up too.

make check accepted a commented-out loader line. grep -q "source .*loader.zsh" matched # source ~/.config/zsh/loader.zsh, and its unescaped . also matched loaderXzsh. Now grep -qE '^[^#]*source .*loader\.zsh', and both ~/.zshrc greps are 2>/dev/null so a missing file reports once instead of twice.

make zsh-syntax and make markdown announced a skip and then ran anyway. Each make recipe line runs in its own shell, so each guard's exit 0 only ended that line: with zsh absent, zsh-syntax printed "zsh not installed — skipping" and then ran zsh -n (Error 1); with no global markdownlint-cli2, markdown printed its own skip and then ran the linter (Error 127). Both collapsed into one recipe line, so a skip is a real skip. This is the defect dotfiles-Debian recorded and fixed for its zsh-syntax, noting the shape survived in the other OS repos' Makefiles — this is that repo, and it had both (dotgibson/dotfiles-core#775).

make markdown also scanned the wrong files. It globbed '*.md', which is top-level only, while the reusable gate's markdown leg — blocking since dotgibson/dotfiles-core#592 — lints git ls-files '*.md' ':!:core/**', recursively. The three .github/ markdown files were therefore enforced by a required check and invisible locally, so this target could read green against a red PR. Now uses the same pathspec via a new MD_FILES. All nine files lint clean, so nothing was hiding.

.markdownlint.jsonc's header claimed the rules were "mirrored from Core rather than CI-enforced" and that "lint.yml skips **.md entirely". Both were true when written and neither survived dotgibson/dotfiles-core#592.

bootstrap.sh no longer fails on a machine without sudo. The escalator is now resolved once (BLIB_SU: empty as root, else sudo, else doas) and used everywhere, instead of a hard-coded sudo at a dozen call sites. A container, a WSL first boot, or a minimal Server image previously died at the first dnf line with sudo: command not found (exit 127) before doing anything.

bootstrap.sh can no longer stall on an invisible password prompt. The sudo timestamp is primed up front and refreshed in the background for the life of the run, and privileged calls no longer discard stderr. Previously, calls placed after the multi-minute cargo/go builds outlived the 5-minute timestamp and blocked on a prompt written to /dev/null — indistinguishable from a hang.

Re-running bootstrap.sh no longer rebuilds the Rust/Go tools from source. The presence guards probed PATH, but ~/.cargo/bin and ~/.local/bin are only added by os/fedora.zsh — i.e. only inside a Core *zsh* — so a run from bash rebuilt all six crates plus yazi every time. provision() now puts both bindirs on PATH first.

A failed step is now reported. Best-effort failures are collected and printed as a closing summary instead of being swallowed, so a box missing carapace, op, lazygit and every cargo tool no longer reports bootstrap complete. --strict exits non-zero.

/etc/wsl.conf is backed up before it is overwritten (.pre-dotfiles.<epoch>, matching every other managed file). It was the one destructive write with no backup.

**OS detection no longer matches Fedora-*like* distros by accident.** ID=/ID_LIKE= are parsed as keys; the old grep -qi fedora /etc/os-release also matched Rocky, Alma, CentOS Stream, Nobara, and any incidental substring such as a URL. Fedora-like distros are now an explicit --force-os opt-in.

--help no longer drifts. It was sed -n '2,17p' "$0", coupled to the header's line numbers — the exact trap core/scripts/sync-core.sh documents. It is a heredoc now.

.gitignore no longer ignores the tracked core/.claude/ files. The .claude/ pattern was unanchored, so it matched at any depth — a hazard for a vendored tree whose git tree SHA must match core.lock.

Three availability claims in bootstrap.sh that stopped being true. The section header, the dust spinner label and the viddy comment all said dust is not packaged on Fedora; du-dust has shipped continuously (F43 1.2.4-2, F44 1.2.4-5, rawhide 1.2.5-1.fc46). They now name only the tools that genuinely need a source build.

install/packages.txt dates the wget virtualisation to F40, not F42. Fedora's Wget2asWget change targeted Fedora Linux 40 — the note was two releases late. The rest of it (no package literally named wget, default provider wget2-wget, pin wget1-wget for classic semantics) was already correct.

jc is installed from dnf (dotgibson/dotfiles-core#1208). jc converts the output of common commands (ps, df, dig, ip, ...) to JSON for jq/yq. Fedora packages it on every supported release — jc 1.26.0 on F43, F44, F45 and rawhide (F46), shipping /usr/bin/jc and pulling python3-jc — so it is one line in install/packages.txt, and the atomic edition layers it from the same list with no change. This is the OS half of a fleet ratchet: Core's core-doctor probe and PORTING-MATRIX.md row land after the OS repos install it.

make lint stops warning about dnf on every package verb (dotgibson/dotfiles-core#1087, dotgibson/dotfiles-core#1104). Core's capability cross-check warns when a PKG_* verb's leading binary is absent from install/packages.txt. Both declarations here run base-system binaries the list deliberately does not name — that file records what this repo ADDS to a box — so the check fired on 8 verbs in each, burying the one case it exists to catch: a verb naming a tool nothing installs. PKG_UNLISTED_TOOLS declares the exceptions (dnf on the workstation edition, rpm-ostree dnf rpm systemctl on the atomic one) and both declarations now validate with zero warnings. Kept honest from both ends, so it cannot rot into a blanket silencer: a name no declared verb runs is a FAILURE, and so is a name packages.txt actually installs. Needs Core ≥ 7.10.0 vendored — an older validator rejects the key outright.

The atomic edition — Silverblue, Kinoite, any bootc host — as a variant of the same bootstrap (#186; runbook step 3 of dotgibson/dotfiles-core's NON-MUTABLE-HOST-PROPOSAL.md §4.6, the R4 patch measured end to end on a booted fedora-bootc:42 guest, runs 34893435585 and 34895922848). On a booted ostree image dnf install resolves the whole transaction and then refuses ("configured to be read-only"), rpm --import cannot lock the rpmdb, and nothing installed is live until a reboot — so the old script died at its first dnf line there. The marker is /run/ostree-booted, not VARIANT_ID (the bootc image reports ID=fedora and no variant), and everything hangs off that one flag: the RPM Fusion release RPMs, the package list, the lazygit COPR (a repo file into /etc/yum.repos.d — dnf copr needs a plugin that is not live until a reboot), the carapace RPM and 1password-cli all layer with rpm-ostree install --idempotent into the next deployment; the package list is filtered to the names dnf repoquery resolves and rpm -q does not already answer, because one base-provided name refuses the whole layer even under --idempotent (measured — it took the first 38-package layer down); 1Password's fingerprint-verified key is installed under /etc/pki/rpm-gpg and the repo's gpgkey points at it. A second declaration, os/fedora.atomic.capabilities (PROVISIONER=atomic, the rpm-ostree verbs, PKG_APPLY_PENDING=rpm-ostree status --pending-exit-77, PKG_APPLY=sudo systemctl reboot, no count verb — that question is root-only there), is relinked by bootstrap_wire_pre_loader the way dotfiles-openSUSE selects Leap's, so Core's up, nudge and maint runner (Core v7.6.0) see the staged host. The closing line says "N package(s) layered — reboot to apply, then re-run once": the cargo/go tools behind command -v cargo guards are skipped on the first run and picked up on the second, which is the edition's measured cost (a full second deployment plus the from-source builds). 118 code lines in bootstrap.sh, an 18-line declaration delta, no install/ fork and no os/*.zsh fork — the atomic edition's packages *are* Fedora's packages. BOOTSTRAP_PROVISIONER=atomic forces the marker, which is how a container reaches the staging path at all.

test/check-flavors.sh, on dotfiles-openSUSE's model, and make suite. Two hand-maintained declarations that are mostly identical by design are the most likely place for this variant to drift, and Core's schema validator checks each file alone. The test asserts the DELTA: PROVISIONER on the atomic file only; the five verbs dnf on one side and rpm-ostree on the other (--idempotent on the install, rpm-ostree upgrade — never bootc upgrade, which refuses a host with a layered package); the staged pair (PKG_APPLY_PENDING / _EXIT agreeing on 77, PKG_APPLY) present only there and the count keys present only on the dnf file; every other key identical both ways; and that the split is still reachable — the marker probe, the CI seam, the relink and the "reboot to apply" closing line survive in bootstrap.sh, and os/fedora.zsh keeps both dnfi arms. Runs anywhere (it reads the repo), so the new test workflow runs it on a plain runner on every PR; make test now runs the suite.

bootstrap.yml gains a fedora-bootc:42 leg with provisioner: atomic (Core v7.7.0's reusable input, dotgibson/dotfiles-core#1050). A container is not the host — the image has no /run/ostree-booted and a writable /usr — so without the seam every container leg walked the dnf branch and a green tick tested the wrong code (R6, measured). The forced run shims rpm-ostree, makes the rpm shim answer -q with 1 so the base-image filter keeps its names, and fails unless the run prints "reboot to apply"; packages_check runs the same dnf -q provides (38 of 38 in that image). It is not a required check, and the weekly unstubbed sweep skips it by design; .github/core-gates.txt declares real-bootstrap none … with the reason, so the coverage register says VM-only rather than reading green.

dnfi knows the edition. sudo dnf install resolves and then refuses on an atomic host; the alias now reads the declaration bootstrap.sh linked (_core_cap PROVISIONER, band 02 read it first) and expands to sudo rpm-ostree install --idempotent there. The other dnf aliases are unchanged: search / provides / history are read-only and answer on both editions, and upgrading is Core's up, which dispatches through the same declaration.

os/fedora.capabilities — this repo's Core v5 capability declaration (dotgibson/dotfiles-core#663, #667). Core's up, maint runner and core-doctor now dispatch through it rather than through package-manager branches inside portable Core modules. Fedora is the repo core/examples/os.capabilities.example was written from, so this is that example made real. MAINT_UNATTENDED_UPGRADE=1 — a versioned, non-rolling distro whose stable updates are what an unattended nightly is for, and what this box already did; the operator's MAINT_SYSTEM_UPGRADE=1 is still the first of the two gates.

make capabilities — validates os/*.capabilities against Core's schema via the vendored core/scripts/check-capabilities.sh, and runs as part of make lint.

bootstrap.sh --dry-run — previews the whole plan (packages *and* the symlink graph) and changes nothing, via the shared lib's BLIB_DRY; prints the wiring tally.

bootstrap.sh --strict and --force-os; a preflight that checks for the commands the script assumes and fails once with the full list.

bootstrap.sh now installs the core/ pre-commit guard on a fresh clone (blib_install_core_guard), which the shared lib always intended but was never called.

1Password's signing key is fingerprint-verified before rpm --import; a mismatch fails closed. The three upstream install scripts are downloaded, sanity-checked, then run — never curl | sh — and starship installs to ~/.local/bin, needing no root.

packages workflow — resolves every name in install/packages.txt against a matrix of supported Fedora releases, replacing hand-maintained availability prose with a check.

du-dust to install/packages.txt — dust is an RPM, not a from-source build. Fedora packages it under the same name Debian does (du-dust, binary /usr/bin/dust), and every fresh box was instead spending minutes on cargo install --locked du-dust for a tool dnf already had. The cargo block stays as a presence-guarded fallback: it is a no-op once the RPM is in, and it is what catches dnf --skip-unavailable silently dropping the name if du-dust ever follows sd/gron out of the repos.

bootstrap.sh runs on Core's bootstrap driver, blib_main (dotgibson/dotfiles-core#986). The shared half — the flag loop, the escalator, the sudo keepalive, the Core symlink surface, the OS overlays, the managed ~/.zshrc, the login shell, the closing report — now runs from one definition in core/lib/bootstrap-lib.sh (vendored since v7.4.0). This file declares what it is (BOOTSTRAP_OS=fedora) and keeps only what is Fedora's: the OS guard and preflight as bootstrap_guard, the dnf provisioning as bootstrap_provision (its body is unchanged), the dry-run preview as bootstrap_check, and --no-flatpak / --force-os through bootstrap_flag. 753 → 660 lines. What the driver gives for free: one --help (this repo's half, then the shared flags), and blib_user_bindirs_on_path running before anything probes rather than only inside provision(). One convention change: an unknown flag exits 2 (usage error), not 1, which stays for real failures. Same links, same loader, same exit codes otherwise; make check (the vendored links gate) ran green through the driver on a Fedora box, and a real --dry-run printed the provisioning plan and wrote nothing.

make check runs Core's vendored check-links.sh instead of its own copy of the hermetic --links-only gate (dotgibson/dotfiles-core#975, #852). The recipe carried one of four near-identical copies of that block across the fleet, and they drifted the way copies do: #852 found the same non-hermetic-HOME defect in three of them at once and had to fix it three times by hand. The script has been vendored as core/scripts/check-links.sh since then with its consumer named "as intent rather than as a file" — nine releases later no Makefile had followed. Now this one calls it: the Core graph is the script's own default, and --require adds the four things this repo's OS layer wires on top (80-os.zsh, os.capabilities, tmux os.conf, git os.gitconfig). Exit 2 is the drift signal, 1 means the check could not run.

bootstrap.sh runs on Core's escalation, sudo-keepalive and failure-tally helpers instead of private copies (dotgibson/dotfiles-core#867). blib_resolve_su replaces the hand-rolled root/sudo/doas probe — the same $EUID string compare, plus an absolute path for the escalator, and --require only when packages will actually be installed, so --dry-run no longer demands one. blib_sudo_keepalive_start / _stop replace the private refresher loop and its trap. note_fail is now a one-line shim over blib_note_fail, and the closing report comes from blib_failures_report — which means the failures the shared lib records itself (the tpm clone, blib_install_system_file) finally appear in it instead of being dropped. Output and --strict semantics are unchanged; the one visible difference is that hint lines print the escalator's full path (/usr/bin/sudo dnf remove …). Closes this repo's four rows in Core's audit-core.sh §5f ledger, which had read 1/9 (Gentoo only) since dotgibson/dotfiles-core#748.

A stale 4.5 MB orphaned worktree copy under .claude/worktrees/, and the obsolete zsh/local.zsh ignore entry (host overrides have lived at ~/.config/zsh/99-local.zsh since v4).

jc is installed (dotgibson/dotfiles-core#1208). extra/jc converts the output of ps, ss, dig and friends to JSON (ss -tlnp | jc --ss | jq), next to gron in install/packages.txt. This is the OS-first step of the fleet ratchet: Core adds the detection line, the core-doctor data / net row and the PORTING-MATRIX row once the OS repos install it.

make lint stops warning about pacman and checkupdates on every package verb (dotgibson/dotfiles-core#1087, dotgibson/dotfiles-core#1104). Core's capability cross-check warns when a PKG_* verb's leading binary is absent from install/packages.txt, and it fired on 7 verbs here for two different reasons. pacman is base-system, and that file records what this repo ADDS to a box. checkupdates is installed — just under another name, from pacman-contrib, which the list does carry; the check matches package names, not the binaries inside them. PKG_UNLISTED_TOOLS=pacman checkupdates declares both, and the declaration now validates with zero warnings. Kept honest from both ends: a name no declared verb runs is a FAILURE, and so is a name packages.txt actually installs. Needs Core ≥ 7.10.0 vendored — an older validator rejects the key outright.

The fleet make vocabulary, and a test/ suite (dotgibson/dotfiles-core#691, reported by dotgibson/dotfiles-core#846). Core declares one canonical set of verbs for every repo that vendors it — help, lint, check, dry-run, packages-check, core-verify, test — so the same word means the same thing in nine repos. This repo was missing three of them. - make dry-run is the canonical spelling of what was make bootstrap-dry. bootstrap-dry is kept as a .PHONY alias: the requirement is that the canonical name *exists*, not that the old one dies. - make check is the full local gate — lint + test + a bootstrap.sh --dry-run that proves the whole plan still builds, provision() included, which no workflow ever executes. Deliberately *not* the hermetic HOME=$(mktemp -d) --links-only run that Debian's and Fedora's check use: that is only hermetic in $HOME, since wire_links ends in blib_set_login_shell, which appends to /etc/shells and runs chsh under sudo. --dry-run reaches the same code with BLIB_DRY=1 and writes nothing. - make test runs test/*.sh, and refuses rather than passing when there is nothing to run — a test: that runs no suite renders as a no-op in the fleet register. - test/check-packages.sh is the suite, modelled on dotfiles-Debian/test/check-packages.sh. It is the old inline packages-check recipe promoted to a real script — same parser (blib_read_pkgs_into, so it reads exactly what bootstrap.sh feeds pacman), same pacman -Si resolution, now shellcheck-visible and invokable by path — plus a duplicate-name check, which needs no package manager and so runs off-Arch too, and a clean skip instead of a hard "pacman not found" failure. It carries no version floors: Debian needs them because a frozen archive resolves neovim at 0.9.5 and calls that healthy, while on a rolling release the repos carry current upstream by construction — the drift risk here is names *moving* (doggo went AUR→extra in 2025) or disappearing. - .github/workflows/packages.yml now runs make test rather than make packages-check, and its path filter gained test/**. The floor requires a workflow that runs the *suite*; a workflow pinned to one target inside it would silently skip the second script anyone adds. make packages-check still runs exactly that script for anyone who types the verb.

make markdown, wired into make lint. lint-call.yml's markdown leg has been blocking since dotgibson/dotfiles-core#592, but this repo had no local target for it — a required check nobody could run before pushing, and a .markdownlint.jsonc only CI ever read. MD_FILES uses the gate's own pathspec (git ls-files '*.md' ':!:core/**'), so the local run scans exactly what CI scans, recursively — a '*.md' glob would be top-level only and miss pull_request_template.md. All seven files already pass, so nothing rides along. It skips when markdownlint-cli2 is absent rather than failing like the shellcheck arm: shellcheck is a pacman package, so missing means a box to fix, while markdownlint-cli2 is npm-only. Part of the fleet sweep in dotgibson/dotfiles-core#775.

os/arch.capabilities — this repo's Core v5 capability declaration (dotgibson/dotfiles-core#663, #667). Core's up, maint runner and core-doctor now dispatch through it rather than through package-manager branches inside portable Core modules. PKG_COUNT_PENDING is checkupdates (from pacman-contrib, already in install/packages.txt), which syncs a copy of the database in user space and never touches the real sync DB. PKG_ASSUME_YES, PKG_UPGRADE_PARTIAL and MAINT_UNATTENDED_UPGRADE are deliberately absent: each omission is a safety statement Core honours exactly, so up -i refuses a partial upgrade and the scheduled runner refuses to upgrade this rolling distro unattended. Do not add them.

make capabilities — validates os/*.capabilities against Core's schema via the vendored core/scripts/check-capabilities.sh, and runs as part of make lint.

bootstrap.sh --dry-run — previews the entire run (package plan + symlink plan + /etc/wsl.conf handling) and changes nothing. The shared library has supported BLIB_DRY end-to-end all along; this layer simply never exposed it.

Root Makefile — lint, bootstrap-dry, packages-check, secrets, core-lock, core-verify. lint reproduces the CI gate exactly, so a failure is visible before pushing.

packages workflow — resolves every install/packages.txt name against the Arch repos on PR and weekly, without installing. Nothing previously checked the package list, on a rolling release where renames are routine.

Root .gitattributes, .editorconfig, .shellcheckrc — Core ships all three, but EditorConfig/shellcheck/gitattributes resolution is directory-scoped, so they governed core/** only and this repo's own files had no policy.

The tmux auto-attach honours DOTFILES_NO_AUTOTMUX, the fleet's one opt-out name (dotgibson/dotfiles-core#877). MacBook, openSUSE and Gentoo already read it; this layer attached unconditionally for any interactive TTY, which is how dotfiles-core's README hero render — a vhs session that sources this layer — typed its whole tour into a fresh main session. Core's gen-hero-tape.sh now refuses to render a hero on a layer that does not honour the knob. Export DOTFILES_NO_AUTOTMUX=1 for any harness that drives an interactive zsh and must not land in tmux.

make markdown probed for a global, unpinned markdownlint-cli2 — so on a normal box it never linted anything (dotgibson/dotfiles-core#873). Nothing in this repo's bootstrap installs markdownlint-cli2 globally; it is npm-only. So unless the operator had separately run npm i -g markdownlint-cli2, the guard fired on every invocation and the target skipped, cleanly and with exit 0, forever. That is a correct guard doing exactly what it says — and a local mirror of a blocking CI gate that has never mirrored anything. dotgibson/dotfiles-core#775 fixed this target's skip guard and its file scope; neither defect could bite while the target never ran at all. And where the binary *was* installed it was whatever version npm last put there, while lint-call.yml installs the pinned MARKDOWNLINT_VERSION — so a rule that changes across a bump reds a required check against a green local run. It now runs the pinned version through npx, reading the number from the vendored core/scripts/tool-versions.env rather than restating it, and refuses rather than guess if that pin is unreadable — a silently-unpinned lint being the thing this fixes. npx needs only node, which is far likelier present than a global markdownlint install, and still self-skips without it so make lint works on a bare box. Converges on the shape dotfiles-Offense and dotfiles-Defense already run.

bootstrap.sh's PATH is not the shell's PATH — adopt blib_user_bindirs_on_path (dotgibson/dotfiles-core#748). go install pins GOBIN to ~/.local/bin, and ~/.local/bin, ~/.cargo/bin and $GOBIN reach PATH only through the zsh layer, i.e. only inside a Core shell — which does not exist while bootstrap.sh runs. So every command -v <tool> guard here was answered by the PATH of whatever shell launched the bootstrap: on a fresh box, bash, with none of them. That is wasted work when the guard picks whether to reinstall, and a wrong answer when it picks a branch — dotfiles-openSUSE probed command -v mise for a mise mise.run had written to ~/.local/bin moments earlier, both arms of its Go fallback missed, and the run exited 2 on every bootstrap. No stubbed CI leg can see that: a stub installs nothing, so "is the tool present afterwards" can never fail under one. Core has shipped blib_user_bindirs_on_path for exactly this since dotgibson/dotfiles-core#425 — it resolves CARGO_HOME and GOBIN/GOPATH rather than hard-coding them, and adds only directories that exist, so it is called again after an installer creates one. Arch escapes the worse half of this by luck — pacman puts mise in /usr/bin, so the fallback arm resolves — but _dotfiles_go_install's presence guard could never see a tool an earlier run had installed, so every bootstrap re-ran every go install.

bootstrap.sh could exit 0 having installed nothing. blib_read_pkgs' exit status is lost inside the < <(…) process substitution, so a missing or empty install/packages.txt produced an empty array, a failed pacman -S, a zero-iteration fallback loop, and a success message. It now refuses to continue.

bootstrap.sh silently swallowed per-package install failures. The fallback loop discarded every error, so a handful of renamed packages yielded a green run and a half-provisioned machine. Failures are now collected, reported at the end, and produce a non-zero exit — after wiring completes, so the box is still usable.

bootstrap.sh clobbered an existing /etc/wsl.conf. Every other mutation in this system backs up first (blib_link → .pre-dotfiles.<epoch>); this one overwrote, losing any local [automount] / [boot] / [network] settings on a re-run of a script documented as idempotent. It now no-ops when already correct and backs up otherwise.

pacorphans passed all orphans to pacman as a single argument. zsh does not word-split unquoted parameters, so pacman -Rns $orphans handed over one newline-joined string; now ${(f)orphans}. zsh -n cannot catch this — the syntax is valid.

--help was coupled to the file's header line numbers (sed -n '2,17p' "$0"), so editing the banner silently drifted the help text. Replaced with a usage() heredoc, matching the fix core/scripts/sync-core.sh already documents.

bootstrap.sh runs on Core's bootstrap driver (dotgibson/dotfiles-core#976, #986; vendored here since v7.4.0). The file now declares what it is (BOOTSTRAP_OS=arch, BOOTSTRAP_STRICT_DEFAULT=1 — a package that did not install is exit 1, always, as before) and defines the hooks that are Arch's: the Arch check and the --only/--skip note as bootstrap_guard, the pacman phase as bootstrap_provision (body unchanged: -Syu first, bulk --needed then per-package, the Go builds, the AUR hints, wsl.conf, Flathub), the dry-run preview as bootstrap_check, --no-flatpak as bootstrap_flag, the rolling-release hints as bootstrap_closing. The flag loop, the escalator, the sudo keepalive, the symlink surface, the managed ~/.zshrc, the login shell and the closing report come from core/lib/bootstrap-lib.sh :: blib_main. The -E ERR trap stays and now steps aside for the driver's own return verdicts. 446 → 421 lines. Two visible changes: an unknown flag exits 2 (the driver's usage-error code; it was 1), and --strict is accepted as a no-op spelling of the default.

bootstrap.sh runs on Core's escalation, sudo-keepalive and failure-tally helpers (dotgibson/dotfiles-core#973). It had no root check at all — it leaned on the lib's default of sudo through _blib_priv, an underscore-private symbol — and its ledger held one kind of miss (a pacman package). Now blib_resolve_su pins the escalator up front (root runs directly, else sudo, else doas; an explicit BLIB_SU= still wins, which is what CI sets), every privileged line goes through the lib's public blib_priv, blib_sudo_keepalive_start / _stop keep the timestamp warm across the go builds, and blib_note_fail records the per-package misses, the go installs and the Flathub remote alongside what the shared lib records itself. blib_failures_report prints the tally and the exit code stays 1 when there was anything in it — Arch's contract, unchanged. The carapace / viddy / op lines stay as the deliberate manual-step hints they are. Closes this repo's four rows in Core's audit-core.sh §5f ledger.

make core-lock no longer regenerates core.lock; it explains why and points at the fan-out. (dotgibson/dotfiles-core#593) The target was added here to satisfy core.lock's own header instruction, “Regenerate … with: make core-lock”. That instruction was the bug — Core removed it in dotfiles-core#454, because core.lock is written by sync-core.sh in the same commit as the subtree pull and was never meant to have a second writer. Keeping the generator meant this repo owned a second definition of a format Core owns, and it had already drifted from it in three ways: it hardcoded core_branch=main, so regenerating a lock that had been pinned to a released commit silently replaced that provenance with a branch name; it re-emitted the removed header line, reintroducing the very instruction it existed to satisfy; and it predates dotfiles-core#453, which renamed the field to core_ref — so running it now would emit a lock the rest of the fleet disagrees with. core-verify is unchanged and remains the way to check this repo's vendored core/.

Privilege escalation goes through the library's _blib_priv, honouring BLIB_SU, instead of a hardcoded sudo. This makes bootstrap.sh work as root and on doas-only boxes — and makes provision() runnable in a container, which Arch base images (no sudo) previously prevented.

Arch derivatives are accepted with a warning rather than refused: the guard now falls back to ID_LIKE=…arch…, so EndeavourOS/Manjaro/CachyOS work.

go install for sesh logs its errors to a file instead of /dev/null, and the module version is overridable via SESH_VERSION (still defaulting to latest — see the note in provision()). carapace is a printed paru hint and takes no version override, per the analysis in #89: go install cannot work for any version of it. That error logging is what makes such a failure visible in the first place — the old /dev/null form is precisely why the carapace call could fail on every bootstrap without anyone noticing.

A failed run now says where it failed (ERR trap), and a successful one prints the wiring tally and points at core-doctor.

bootstrap.sh installs the local core/ pre-commit guard on a fresh clone (blib_install_core_guard), catching a hand-edit at commit time rather than waiting for core-integrity.yml at PR time.

jc joins the apt base stack (dotgibson/dotfiles-core#1208) — kellyjonbrazil's command-output-to-JSON converter, next to gron in install/packages.txt. Untiered, because every target resolves it: noble 1.25.1 (universe), 26.04 1.25.5 (universe), trixie 1.25.4 and kali-rolling 1.25.7 (main). This is the OS-repo half of the fleet ratchet; Core's detection line and core-doctor row follow once the fleet installs it. The name counts quoted in the packages and bootstrap workflow comments move to 33 untiered and 45 on Kali. The Kali figure had drifted: it read 47 while the list resolved 44 there.

make test and make core-verify — the two canonical fleet verbs this repo was missing (dotgibson/dotfiles-core#691, reported by dotgibson/dotfiles-core#846's register). Core now declares one make vocabulary for every repo that vendors it — help, lint, check, dry-run, packages-check, core-verify, test — after nine repos turned out to speak nine dialects, with "verify core" alone spelled five ways. test runs the repo's own suite, which today is exactly test/check-packages.sh, so packages-check is its only prerequisite rather than a copied command line; it is declared .PHONY because it names the test/ directory it runs and an undeclared test: would report "up to date" and run nothing. The requirement is that the canonical name exists, not that the old one dies, so integrity stays as a .PHONY alias of core-verify and muscle memory survives. Verify from a Core checkout beside this one with make fleet-vocabulary.

os/debian.capabilities and os/debian.kali.capabilities — this repo's Core v5 capability declarations (dotgibson/dotfiles-core#663, #667). Core's up, maint runner and core-doctor now dispatch through them. The apt verbs are identical on all three targets, so almost everything is shared; exactly one key differs, and it is why there are two files: Kali does not declare MAINT_UNATTENDED_UPGRADE, because engagement boxes are updated by hand between ops and a background full-upgrade mid-engagement destroys the reproducibility findings rest on. bootstrap.sh relinks the Kali file over the default, keyed on the same $OS_ID that scripts/pkg-filter.sh tiers install/packages.txt on — so the declaration and the package list agree by construction rather than by coincidence, and a future tier is one new file with no code change.

TOOLS_OPTIN declares jj and ast-grep opt-in on this family — they are — on noble and trixie and cargo-only on Kali. Core's single list could not say "opt-in there, expected here", so core-doctor reported them as missing-and-expected on every box (dotgibson/dotfiles-core#666). dust is deliberately not in that list: it is present here, just installed out of band under its plain name.

make capabilities — validates os/*.capabilities against Core's schema via the vendored core/scripts/check-capabilities.sh, and runs as part of make lint.

Initial dotfiles-Debian OS-native layer: the Debian-family repo the fleet had planned, cancelled, and left a note against in dotfiles-core/scripts/os-repos.txt. Targets Ubuntu 24.04 LTS on headless SSH-only machines; debian:trixie is a blocking CI lane because the repo is named for the family, not one distro.

install/tool-versions.env — version + SHA-256 pins for the twelve tools a frozen LTS cannot supply, with scripts/update-tool-checksums.sh to refresh them (--check to assert, --latest to report newer upstream releases).

verified_tree_install alongside verified_install in bootstrap.sh. Neovim ships a directory tree (bin/, lib/, share/nvim/runtime), not a lone binary — copying just bin/nvim yields an editor whose $VIMRUNTIME points at nothing.

verified_install handles all three shapes upstreams actually ship — .tar.gz, plain .gz (tree-sitter) and .zip (procs) — and takes an optional inner-binary name for assets whose executable is named differently from the command.

bootstrap.sh runs on Core's bootstrap driver, blib_main (dotgibson/dotfiles-core#986). The shared half — the flag loop, the escalator, the sudo keepalive, the Core symlink surface, the OS overlays, the managed ~/.zshrc, the login shell, the closing report — now runs from one definition in core/lib/bootstrap-lib.sh (vendored since v7.4.0). This file declares what it is (BOOTSTRAP_OS=debian) and keeps only what is Debian's: the three-distro OS guard and preflight as bootstrap_guard, the apt provisioning with its tiered package list and pinned out-of-band installs as bootstrap_provision (body unchanged), the dry-run preview as bootstrap_check, the distro tier's capability re-link as bootstrap_wire_pre_loader (the slot exists for exactly this: it must land before the managed ~/.zshrc is written), the shadowed-tools report as bootstrap_closing, and --no-upgrade / --no-unattended / --force-os through bootstrap_flag. 962 → 876 lines. One convention change: an unknown flag exits 2 (usage error), not 1, which stays for real failures. Same links, same loader, same exit codes otherwise.

make check runs Core's vendored check-links.sh instead of its own copy of the hermetic --links-only gate (dotgibson/dotfiles-core#975, #852). The recipe carried one of four near-identical copies of that block across the fleet, and they drifted the way copies do: #852 found the same non-hermetic-HOME defect in three of them at once and had to fix it three times by hand. The script has been vendored as core/scripts/check-links.sh since then with its consumer named "as intent rather than as a file" — nine releases later no Makefile had followed. Now this one calls it: the Core graph is the script's own default, and --require adds the four things this repo's OS layer wires on top (80-os.zsh, os.capabilities, tmux os.conf, git os.gitconfig). Exit 2 is the drift signal, 1 means the check could not run.

bootstrap.sh runs on Core's escalation, sudo-keepalive and failure-tally helpers instead of private copies (dotgibson/dotfiles-core#867). blib_resolve_su replaces the hand-rolled root/sudo/doas probe — the same $EUID string compare, plus an absolute path for the escalator, and --require only when packages will actually be installed, so --dry-run no longer demands one. blib_sudo_keepalive_start / _stop replace the private refresher loop and its trap. note_fail is now a one-line shim over blib_note_fail, and the closing report comes from blib_failures_report — which means the failures the shared lib records itself (the tpm clone, blib_install_system_file) finally appear in it instead of being dropped. Output and --strict semantics are unchanged; the one visible difference is that hint lines print the escalator's full path (/usr/bin/sudo apt-get purge …). Closes this repo's four rows in Core's audit-core.sh §5f ledger, which had read 1/9 (Gentoo only) since dotgibson/dotfiles-core#748.

neovim and tree-sitter-cli are not in install/packages.txt. Ubuntu 24.04 resolves both (0.9.5 and 0.20.8) and both are far below what Core requires (0.12 and 0.26.1) — which is exactly why the version-floor check exists; resolution alone would have called that box healthy.

yq in either spelling: noble's yq is kislyuk's Python tool, and the Go yq-go this stack means is sid-only. Installed via go install instead.

cargo, and therefore yazi/ast-grep/viddy: noble's rustc is 1.75, too old to build them. All are HAVE_*-guarded in Core, so the shell degrades cleanly.

wl-clipboard/xclip: no display on these headless ubuntu/debian boxes. Tiered in for Kali (# only:kali), which runs under WSL2 with WSLg. Copying still works regardless: Core's clip falls back to OSC 52 when it finds no local backend. Pasting does not, deliberately — see the README's *Headless clipboard* note.

PPAs, in any form. They are keyed to an Ubuntu series and would break the Debian lane; vendor-signed apt repos (Charm, 1Password) are used instead.

TOOLS_OPTIN opts yazi and viddy in on both editions (dotgibson/dotfiles-core#1239). dotgibson/dotfiles-core#1210 corrected PORTING-MATRIX.md's Kali cells for both tools from cargo³ to cargo²¹: this repo installs Kali's cargo but cargo-installs neither. That made them cell-level opt-ins, and without them core-doctor rendered a false ✗ for each on every Kali box. Core's fan-out audit caught the stale declaration and held the v7.14.0 sync back until this landed.

The tmux auto-attach honours DOTFILES_NO_AUTOTMUX, the fleet's one opt-out name (dotgibson/dotfiles-core#877). MacBook, openSUSE and Gentoo already read it; this layer attached unconditionally for any interactive TTY, which is how dotfiles-core's README hero render — a vhs session that sources this layer — typed its whole tour into a fresh main session. Core's gen-hero-tape.sh now refuses to render a hero on a layer that does not honour the knob. Export DOTFILES_NO_AUTOTMUX=1 for any harness that drives an interactive zsh and must not land in tmux. DEBIAN_NO_TMUX keeps working alongside it.

make markdown probed for a global, unpinned markdownlint-cli2 — so on a normal box it never linted anything (dotgibson/dotfiles-core#873). Nothing in this repo's bootstrap installs markdownlint-cli2 globally; it is npm-only. So unless the operator had separately run npm i -g markdownlint-cli2, the guard fired on every invocation and the target skipped, cleanly and with exit 0, forever. That is a correct guard doing exactly what it says — and a local mirror of a blocking CI gate that has never mirrored anything. dotgibson/dotfiles-core#775 fixed this target's skip guard and its file scope; neither defect could bite while the target never ran at all. And where the binary *was* installed it was whatever version npm last put there, while lint-call.yml installs the pinned MARKDOWNLINT_VERSION — so a rule that changes across a bump reds a required check against a green local run. It now runs the pinned version through npx, reading the number from the vendored core/scripts/tool-versions.env rather than restating it, and refuses rather than guess if that pin is unreadable — a silently-unpinned lint being the thing this fixes. npx needs only node, which is far likelier present than a global markdownlint install, and still self-skips without it so make lint works on a bare box. Converges on the shape dotfiles-Offense and dotfiles-Defense already run.

bootstrap.sh's PATH is not the shell's PATH — adopt blib_user_bindirs_on_path (dotgibson/dotfiles-core#748). Replaces the hand-rolled export PATH="$HOME/.local/bin:$HOME/.cargo/bin:$PATH" prelude. ~/.local/bin, ~/.cargo/bin and $GOBIN reach PATH only through the zsh layer, i.e. only inside a Core shell — which does not exist while bootstrap.sh runs. So every command -v <tool> guard here was answered by the PATH of whatever shell launched the bootstrap: on a fresh box, bash, with none of them. That is wasted work when the guard picks whether to reinstall, and a wrong answer when it picks a branch — dotfiles-openSUSE probed command -v mise for a mise mise.run had written to ~/.local/bin moments earlier, both arms of its Go fallback missed, and the run exited 2 on every bootstrap. No stubbed CI leg can see that: a stub installs nothing, so "is the tool present afterwards" can never fail under one. Core has shipped blib_user_bindirs_on_path for exactly this since dotgibson/dotfiles-core#425 — it resolves CARGO_HOME and GOBIN/GOPATH rather than hard-coding them, and adds only directories that exist, so it is called again after an installer creates one. The directory this script installs into is mkdir -p'd before the helper runs, and the second refresh sits immediately after the verified_install block: the helper adds only directories that already exist, so a straight swap for the old unconditional export would have dropped ~/.local/bin for the whole first run and made the command -v uv (ty route) and command -v atuin (daemon unit) probes miss binaries this script had just written. The literal list was a fork of Core's helper and was missing GOBIN — harmless only because this script sets it to ~/.local/bin itself. A second call now runs after the verified_install block, which on a first run is what creates ~/.local/bin.

make check was not hermetic, and wrote Core into your real config dir (dotgibson/dotfiles-core#852). The target promises "a hermetic --links-only run against a throwaway HOME" and redirected only HOME — but bootstrap.sh resolves its target as CONFIG="${XDG_CONFIG_HOME:-$HOME/.config}", and core/lib/bootstrap-lib.sh defaults XDG_CONFIG_HOME, XDG_STATE_HOME, XDG_CACHE_HOME, XDG_DATA_HOME and ZDOTDIR the same way. A :-/:= default applies only when the variable is unset, so for anyone who exports XDG_CONFIG_HOME the run wired Core into their live config tree and then failed its own assertions, which look under the temp dir bootstrap never touched — a gate that mutates the box it was only supposed to inspect, then blames the tree. Reproduced against the byte-identical recipe in dotfiles-Fedora (dotgibson/dotfiles-Fedora#153); only the package manager differs between the two repos here, and the --links-only path is the same Core code. Fixed with env -u for the five variables the bootstrap path consults — the fix dotfiles-openSUSE had already reached locally.

make check's mktemp -d was unguarded, so a failure left $tmp empty and the next line ran mkdir -p "$tmp/.config/tmux/plugins/tpm" — /.config/… on the real filesystem. It now refuses, and a trap replaces the two hand-placed rm -rfs so an interrupted run cleans up too.

make check accepted a commented-out loader line. grep -q "source .*loader.zsh" matched # source ~/.config/zsh/loader.zsh, and its unescaped . also matched loaderXzsh. Now grep -qE '^[^#]*source .*loader\.zsh', and both ~/.zshrc greps are 2>/dev/null so a missing file reports once instead of twice.

make zsh-syntax printed "zsh not installed — skipping" and then ran zsh -n anyway. Each make recipe line runs in its own shell, so the guard's exit 0 only ended that line. The same shape is still present in the other OS repos' Makefiles.

make markdown had the same defect, and it was still live here. Without a global markdownlint-cli2 it printed "not installed — skipping" and then ran the linter anyway, failing with Error 127. Collapsed into one recipe line, so the skip is a real skip. Of the fleet, dotfiles-Fedora carries this target byte-for-byte (also live); dotfiles-Offense and dotfiles-Defense have the same shape guarding npx instead (latent — it only bites where npx is absent); dotfiles-MacBook already fixed its copy; Alpine, Arch, Gentoo and openSUSE have no markdown target at all.

make markdown also scanned the wrong files. It globbed '*.md', which is top-level only, while the reusable gate's markdown leg — blocking since dotgibson/dotfiles-core#592 — lints git ls-files '*.md' ':!:core/**', recursively. The three .github/ markdown files were therefore enforced by a required check and invisible locally, so this target could read green against a red PR. It now uses the same pathspec via a new MD_FILES. All nine files lint clean, so nothing was hiding.

.markdownlint.jsonc's header claimed the rules were "mirrored from Core rather than CI-enforced" and that "lint.yml skips **.md entirely". Both were true when written and neither survived dotgibson/dotfiles-core#592.

The CI floor bans the pull_request_target trigger. It runs a fork's pull request in the base repo's context, with its secrets and a write-capable token, which is the precondition for a "pwn request". GitHub starts blocking it by default on 2026-11-02 for repos on the default policy, and rule 10 of scripts/modern-baseline.yml makes that permanent whatever a policy later allows. check-modern.sh reads the on: block itself: the scalar, flow and block forms, quoted or bare, and first-level entries only. A comment, a branch filter or an env: value that names the trigger does not fire. That is why it is not a banned_patterns entry, which would red the baseline's own rule 1 rationale. It was free to add: no repo in the org declared the trigger on its default branch (#1215).

The pull_request_target ban now reaches every repo that calls lint-call.yml@v7. The reusable workflow's actionlint job gains a step that runs check-modern.sh --banned-triggers caller: rule 10 alone, from the Core checkout, over the caller's own workflows, including ones not yet committed. It blocks from the start, because every caller was measured clean first. Rule 10's walker is now one function that both the floor and the new mode call, so the fleet check cannot drift from Core's. A caller that pins the workflow to a SHA newer than the v7 tag gets a warning, not a false red. dotfiles-Windows, dotfiles-web and htpx do not call lint-call.yml, so they are not covered yet. All three are clean today (#1215).

The openSUSE Tumbleweed tree-sitter-cli row moves to 0.27.0. Tumbleweed's tree-sitter went 0.26.8 → 0.27.0 (checked 2026-09-29; 0.26.8 has left the index), and both Leap 16.x lanes stay at 0.26.8. All three still clear the ≥ 0.26.1 floor. Footnote ⁵ also named the split-off library libtree-sitter0_26 for every openSUSE lane. That library is named for its soname, so Tumbleweed now ships libtree-sitter0_27. Reported by dotgibson/dotfiles-openSUSE#217.

The relink fix now names which checkout to run. core-doctor's relink row and the "relink pending" nudge used to say run ./bootstrap.sh --links-only. On a box with both an OS checkout and a role checkout, running the wrong one moved the whole Core surface onto that repo's vendored Core, possibly an older one, and the doctor then read current. The line now names the loaded checkout's own script, for example run ~/dotfiles-Offense/bootstrap.sh --links-only, quoted when the path needs it (#1213). The other state no longer stops at "last relinked from another checkout". It appears after a partial --only/--skip run of the other checkout, or a moved one. It now names both fixes, since either checkout's full --links-only run re-stamps the box. Which one should own Core stays an open question in #1211 (#1218).

make audit from a fleet shell no longer reds four cases CI calls green. The behavioral suite's host scrub now also drops BROWSER and every ATUIN_* variable. Core's own 00-tools.zsh exports BROWSER=w3m on a headless box (WSL included), and an operator who opted into the atuin daemon exports ATUIN_DAEMON__ENABLED=true. Both leaked into the cases that pin the unset state: the GUI and macOS browser cases, and the daemon guard's never-opted-in pair. That is how the v7.13.0 cut went red locally on a tree CI had passed. Every case that wants one of these variables sets it explicitly.

An operator who exports a Core knob no longer reds make audit either. Exporting CORE_SHADOW_CLASSICS=0 in ~/.zshenv, as the v7.13.0 notes suggest, failed the suite's "knob unset" shadow case. The host scrub now unsets every CORE_* variable that zsh/ reads, including one read arithmetically as ((CORE_X)) with no $. The list is derived from the sources, ignoring comments, so a new knob is covered without an edit. core-doctor's unknown relink row also drops its "live check" hint. That check proved the capability contract was live, not that this box had relinked, so a pass read as "you're fine" when it wasn't (#1204).

The weekly /freshness-triage routine can now check the CLI tool pins it reports on (#1203). Its "CLI tool pins" row asks for each scripts/tool-versions.env pin against upstream, but neither the routine's allowed-tools nor the job's mirrored --allowedTools granted a release lookup, so the row came back "not checked" (#1193). Both lists now grant the read-only gh release view and npm view, and the routine says which to use for which pin.

A bootstrap no longer downgrades Core on a box with two checkouts. An OS repo and a role repo stacked on it each vendor Core, and each bootstrap linked the whole Core surface from its own copy. So running the OS repo's bootstrap after the role repo's could quietly swap in an older Core, and core-doctor then read current. The shared driver now checks the Core already linked. If it comes from another checkout with a newer core.version, the run leaves every Core link alone, still wires its own layer, says why, and leaves the relink stamp as it was. --force-core overrides. An unreadable version or an equal one relinks as before (#1211).

The maintenance bots' Claude Code CLI pin rolls forward, 2.1.281 → 2.1.285. The weekly freshness review (#1193) found it the only scripts/tool-versions.env pin behind upstream that is not deliberately held. It is an npm install, so there is no *_SHA256 to refresh. shfmt stays held at 3.13.1 (#813).

The fleet's pinned shfmt moves 3.13.1 → 3.14.1, ending the #813 hold (#1217). The hold assumed the bump would add ::warning:: nags to consumer repos that pass today. Measured against every sibling's main, none of the ten lint-call.yml consumers passes today, and 3.14.1 leaves each one's count of drifting files unchanged. The one consumer where shfmt blocks is dotfiles-MacBook's make fmt-check, and it was rewritten first to a form both versions agree on (dotfiles-MacBook#275). SHFMT_SHA256 is refreshed, and the tool-versions.env note now says where the next output-changing bump can bite. Core's own scripts are unaffected, since Core does not run shfmt.

make fleet-protection now reports each repo's Actions execution settings. After the ruleset rows, the default run lists whether GitHub itself refuses a tag-pinned action (sha_pinning_required, the server-side twin of check-modern.sh rule 3) and the allowed_actions policy. The rows are reported, not gated: they never change the exit code until the fleet decides whether to enforce them. An unreadable setting prints as ?, not as "not required". They need repo admin, so --rulesets-only, the CI mode, skips them and says so. The first run shows SHA pinning required on 2 of the 11 repos it covers: dotfiles-core and dotfiles-MacBook. --help now prints the whole header instead of a fixed line range that had fallen out of date (#1226).

jc is part of the stack: it turns command output into JSON. ps aux | jc --ps, jc dig example.com and a few hundred other parsers hand jq something to transform. Before this, Core's JSON tools could transform, grep and explore JSON but could not produce it from ps, ss or dig. It is its own command with no alias, probed by zsh/00-tools.zsh and listed in core-doctor's data / net group. Every OS repo now installs it. PORTING-MATRIX.md gains a jc row and footnote ⁴⁰, which records the two exceptions: openSUSE Leap 16.x has no package, so it is declared opt-in there, and Gentoo's dev-python/jc is testing-keyworded only (#1208).

/modernize now re-checks its standing watches on every run. Some floor changes wait on an upstream event, so the routine gains a Standing watches list and reports each one as still watching or trigger met. It starts with two. One is workflow dependency locking (#1223), which would extend the SHA-pin rule to an action's transitive and composite uses: once GitHub ships a public preview. Rule 3 in scripts/modern-baseline.yml now names that gap. The other is the retirement of the macos-15 and windows-2022 runners (#1222).

The README's install steps now put the OS layer before a role repo. Offense used to be shown cloned and bootstrapped on its own, but it ships no OS layer: Kali needs dotfiles-Debian first, and Defense needs whichever OS repo the box runs. The WSL mirrored-networking note now points at dotfiles-Debian/wsl/windows.wslconfig.example, because Offense no longer carries that file.

PORTING-MATRIX.md no longer promises installs that don't happen. Kali's yazi and viddy cells read cargo²¹ (available, not installed): dotfiles-Debian installs Kali's cargo but cargo-builds nothing with it. Footnote ¹³ says Arch only hints the AUR 1password-cli, and that the vendor-repo setup is key-first rather than rolled back. Footnote ¹⁵ drops a go install fallback for glow/gum that never existed. Footnote ¹⁸ counts four openSUSE installers and two curl | sh routes now that yazi's is gone. The lineage notes name NixOS as its own lineage and Offense as a role layer on dotfiles-Debian. Found by the weekly doc-audit (#1192).

PORTING-MATRIX.md footnotes ⁵ and ³³ stop saying dotfiles-Fedora has no version floors (dotfiles-Fedora#203). dotfiles-Fedora#193 landed both floors on 2026-09-17: the # min: pair on neovim and tree-sitter-cli, a warn-only NEOVIM_FLOOR, a tree-sitter cargo fallback that runs only below TREESITTER_FLOOR, and a floor-agreement gate. Both footnotes now describe that, and ³³ drops its claim that Fedora was the last non-rolling target without a floor.

task.ps1 — the fleet's make verbs, for a host without make (dotfiles-core#855). dotfiles-core declares the seven canonical verbs once (help lint check dry-run packages-check core-verify test, its scripts/make-vocabulary.txt, dotfiles-core#691) so a contributor moving between repos re-learns nothing — and this repo was the one that still answered to none of them: no Makefile, no runner, only bare scripts, in the fleet's most-tested repo, where "reproduce the CI gate locally" has the most to offer. make is not a given on a Windows host and just would be a new dependency, so the verbs are spelled in the language the repo is written in: .\task.ps1 <verb>. It is a dispatcher, not a second implementation: lint is tests/Invoke-Validation.ps1 plus gen-theme.ps1 -Check (ci.yml's dependency-free legs), test is tests/Invoke-Tests.ps1 (the gated suite, exactly as CI runs it), dry-run is install.ps1 -DryRun, check is lint plus the links-only bootstrap previewed (Windows has no throwaway HOME to run it in), packages-check is packages/Check-PackageFreshness.ps1 and core-verify is the three tests/Assert-*Parity.ps1 gates over the mirrored assets. Each step runs in a child pwsh -File, so a script's exit ends its own process and the first failing step's code is the verb's. Anything after a single-step verb passes through (.\task.ps1 test -NoGate). Core's fleet-vocabulary.sh register reads the verb table statically — the quoted keys of Get-TaskVerbs, and whether test names the suite runner by path — so tests/Task.Tests.ps1 pins that shape, the exact verb set in the contract's order, and that every step names a script that exists.

remote-install runs the host sshd as a service that restarts itself (#266). The box's front door was a bare sshd.exe with nothing supervising it (sc.exe query sshd returned 1060), so every crash and every reboot needed a human. remote-install now registers sshd as an Automatic service with recovery actions (restart after 5s / 10s / 30s, failure count reset daily), and remote-status reports the same plan while changing nothing. Two traps the planner exists for: registration is not health — scoop's install-sshd.ps1 registers with "take no action" recovery, so recovery is probed separately via sc.exe qfailure — and the ImagePath goes through scoop's current junction, never its resolved target, because a version-pinned path dies silently on the next scoop update openssh (the Get-DotStablePwshPath trap). It also warns when openssh is not held, since a running service keeps the daily scoop update * from replacing its binaries. This narrows 34-remote.ps1's standing rule rather than reversing it: ports, keys, firewall rules and DefaultShell still belong to the runbook; only *supervision* moved into the verbs, which stay explicit and refuse without a token. (powershell/os/34-remote.ps1, powershell/Dotfiles/Remote.Helpers.ps1, tests/Remote.Tests.ps1, docs/REMOTE-ACCESS.md)

desktop/PARITY.md's generated block takes the canonical marker, and the marker now says who writes it (dotgibson/dotfiles-core#1129). The pair became <!-- core:desktop-parity:gen parity --> … <!-- core:desktop-parity:end parity -->, matching the core:<ns>:gen <id> grammar every other generated region in the fleet uses. Not a tidy-up. core: is *provenance* — it names the repo whose generator owns the region — and this file is precisely where that matters: nothing in this repo writes the block, nothing here gates it, and until now its only clue that dotfiles-core rewrites it was a marker that did not say so. The block id is the other half; the old pair carried none, so the file format could hold exactly one generated region, forever. The bytes between the markers did not move. Core renders whichever marker form the target file carries, echoed back verbatim, so this repo and dotfiles-MacBook can be renamed in separate commits without the weekly parity-check sweep reding in between — which is the whole reason Core learned to accept both forms first (dotgibson/dotfiles-core#1143) rather than changing the string in one place and breaking two others. Core drops the legacy arm once both copies carry the new pair. Nothing here reads these markers — no Pester test, no workflow, no gate — so this is a two-line change in one file.

notify-web.yml passes client-id, not the deprecated app-id, and reads the new FLEET_APP_CLIENT_ID org variable (#251, dotfiles-core #831). The pinned create-github-app-token (v3.2.0) deprecates app-id, and this repo's inline notifier — it does not consume Core's reusable — passed it. The variable is a new one because FLEET_APP_ID holds the App ID and the new input wants the Client ID, a different value; the if: guard and the ::warning:: that is this repo's only signal of a silently skipped refresh move in the same commit. Precondition: the org variable must exist before this merges, or the mint skips and the showcase stops refreshing with only that warning to say so.

remote-status / remote-install guard sshd's DefaultShell, which could lock you out of the box (#267). A healthy sshd refuses *every* login when HKLM\SOFTWARE\OpenSSH\DefaultShell names a shell it cannot launch, and it rejects before authentication completes, so the client sees only Permission denied (publickey,keyboard-interactive) — every symptom points at keys. It happened here when the Store pwsh moved 7.6.5.0 → 7.6.6.0 and Windows deleted the old package directory. This is the third consumer of a version-pinned pwsh, after scheduled tasks and the sshd ImagePath (#266). Get-DotSshdShellVerdict grades the value against two independent disqualifiers, because the obvious fix for one trips the other: - A version-pinned Store directory is graded fragile while it still exists. - The per-user app alias is version-stable, but it is a reparse point, which sshd (0x105 lineage) reports as "does not exist" exactly like the deleted directory. remote-status reports the value next to the service. remote-install repoints it at the first machine-wide real file it finds, preferring the MSI pwsh, and says so plainly when it has to fall back to Windows PowerShell 5.1. The docs note that winget's Microsoft.PowerShell manifest can be msix-only: the MSI has to come from the GitHub release, and installing it retires this failure for all three consumers. (powershell/os/34-remote.ps1, powershell/Dotfiles/Remote.Helpers.ps1, tests/Remote.Tests.ps1, docs/REMOTE-ACCESS.md)

The daily maintenance run reports a per-app scoop upgrade failure instead of logging ok (#263). scoop update * exits 0 even when one app fails, so the step's exit-code check could not see it. tailscale failed every day from 2026-08-20 to 2026-09-16, re-downloading a 36.6 MB MSI each time, while the log said ok scoop upgrade (apps). Get-DotScoopUpgradeOutcome reads the result per app out of the step's output. It keys on the *block*: an app has failed when its Updating '<app>' block never reaches "was installed successfully!", and an ERROR line inside the block is kept as the reason. The step sets $LASTEXITCODE itself, so the runner's existing "FAIL … — continuing" path makes one bad app visible without aborting the run. The root cause is not fixed here: tailscale's pre_uninstall needs admin and the daily task runs unelevated, so it needs a scoop hold or the elevated-task route. (powershell/Dotfiles/Maint.Helpers.ps1, tests/Maint.Tests.ps1)

The three sync bots open their PRs as the fleet App, so CI actually runs on them (#265). nvim-sync, starship-sync and theme-sync all pushed the branch and opened the PR with GH_TOKEN: ${{ github.token }}, and GitHub deliberately starts no workflow run from an event the default GITHUB_TOKEN created. So ci.yml's pull_request trigger never fired, not one of the six contexts the main ruleset requires ever arrived, and every sync PR sat BLOCKED indefinitely — #260 and #264 were each unblocked by a human closing and reopening them, which re-fires pull_request, and both merged minutes later. That manual step was being paid weekly, and it was not merely an annoyance: Core's fleet-drift.yml sweeps Mondays while these bots run Tue/Wed/Thu, so a sync PR waiting on a human reads as a Core drift red that is nothing of the kind (dotgibson/dotfiles-core#1058). Each bot now mints a short-lived, repo-scoped token from the dotgibson-fleet-sync App (actions/create-github-app-token, at the same SHA pin notify-web.yml already carries) and both pushes and opens the PR with it, so the PR is App-authored and its CI runs unattended — the same problem, and the same fix, as dotfiles-core's freshness.yml on its own self-PRs. Narrow on both axes: no owner:/repositories:, which is what scopes the token to *this* repository, and only contents + pull-requests: write — deliberately not workflows: write, so a bot that ever tried to rewrite CI fails loudly instead of having quietly been able to all along. It degrades rather than fails: with no App configured the mint is skipped and the bot falls back to GITHUB_TOKEN, so the PR still opens and merely needs the old manual nudge. GH_TOKEN moves from the job env: to the PR step's, because a job-level env: cannot read the steps context. The two App-free options weighed in #265 do not actually work — the recursion guard covers a push and a bot's own close+reopen exactly as it covers pull_request, so neither would have produced a single check. Depends on live infrastructure: the App is installed on this repo today, but Core's GITHUB-APP-AUTH.md still lists it under "does not need installing" and scripts/fleet-app-scope.sh reports it as an install nothing writes to; a Core-side issue moves it to a justified entry beside dotfiles-core's own. (.github/workflows/nvim-sync.yml, starship-sync.yml, theme-sync.yml)

**The package-freshness check now compares *directionally* — a lock that runs ahead of its source is no longer reported as behind (#234, #250). Check-PackageFreshness.ps1 gated every row on Test-PackageVersionMatch, which answers "same release?" and says nothing about which side is newer. So winget still advertising TranslucentTB 2026.1 under a 2026.2.0.0 lock filed as an update every week, and re-pinning (#241, #254) could never clear it. New pure helper Compare-PackageVersion in packages/PackageLock.ps1 orders the shapes the lock actually carries — dotted numerics, scoop's 8.22.0_1 / 25.0.2-10 / 10.0.0.0p2 suffixes, the 20260812 and 2026.08.19 date stamps, and pre-release words — and returns $null rather than guessing when it cannot. The checker's single verdict function (Get-FreshnessVerdict) routes each row: behind is the only finding; ahead becomes a one-line "lock ahead of source" note in the report, visible but not actionable; unordered** lands under "Skipped (could not compare)" with both versions and *still files a report*, so a shape the comparer does not read surfaces instead of vanishing into a green run. The padding tolerance (2.7.10.0 == 2.7.10) is unchanged. (packages/PackageLock.ps1, packages/Check-PackageFreshness.ps1, tests/Packages.Tests.ps1)

Each box now records which Core it last relinked against, and says when it is behind. core.lock records what a repo vendored, and nothing recorded what a box had relinked. So the fallback deletion in #763 had to guess when the fleet had re-bootstrapped, and the only check was a one-liner typed on each host. bootstrap.sh (via blib_main, or blib_write_relink_stamp for a bootstrap off the driver) now writes ${XDG_STATE_HOME:-~/.local/state}/dotfiles-core/bootstrap.lock, host state in core.lock's read-never-sourced shape. It holds core_sha, core_tag, the lib that ran, the mode and when. A dry run, an --only/--skip partial wiring or an aborted run leaves the previous stamp. An identical re-run touches nothing, so the scaffolded check-links.sh idempotency witness stays silent. core-doctor gains a relink row and a .relink key in --json, which print relinked at v7.11.0 — repo vendors v7.12.0, run ./bootstrap.sh --links-only. A "relink pending" line fires at shell start only on a real mismatch (CORE_RELINK_NUDGE=0 silences it). A box bootstrapped before this reads unknown, never red. bootstrap-test.yml's links-only leg asserts the stamp wherever the vendored lib knows it (#1154).

CORE_SHADOW_CLASSICS=0 stops Core taking over standard command names. An operator who works on other people's machines trains habits on Core that fail elsewhere. cd→z jumps by frecency where cd would have errored on a typo, and rm -i teaches you to expect a prompt that no foreign box gives. Exported before the shell loads Core (in ~/.zshenv), the knob skips every alias in zsh/20-aliases.zsh that takes over a standard name: ls, cat, cd, vim, diff, rm/cp/mv, mkdir, tree, du, ps, top/htop, watch, df, ping and help. The names that collide with nothing (ll, la, lt, llt, catp, cdi, bat) stay. It is unset by default, so nothing changes for anyone who does not set it. In aliases.md each governed row now has a Note that starts with shadow, and the suite reads the shadow set from those comments, so a new shadow without the gate fails. Removing the shadows outright was decided against until a real incident is recorded, the same bar as #692 (#1155).

The bash 3.2 floor stays, and PORTABILITY.md §1 now says why. Retiring it for lib/*.sh behind a re-exec stage-0 was costed first (#1153). It would shed about 30 lines of lib/. The injection guard stays because namerefs still expand a subscript, the §5k gate stays re-scoped, and a blib_main stage-0 misses dotfiles-MacBook, the only host on 3.2. RELEASE-STRATEGY.md §2 records it as a candidate declined before it reached the Breaking Backlog.

The CI floor's template-injection rule now covers push-trigger ref names and workflow inputs. Rule 7 of scripts/modern-baseline.yml bans an attacker-influenced ${{ }} expression inside a run: body, and it named github.head_ref — the fork branch on a pull request — but not github.ref_name, which on a push or tag event is the same attacker-chosen string by another trigger (git refnames allow $ ; & | ( ) { }). It now bans github.ref_name and, for uniformity, github.base_ref. And its inputs. exemption, earned by the composite setup-core-tools/action.yml, was applied to every gated file, which left bare inputs.* ungated in the workflows — where it is workflow_dispatch free text or a value a sibling repo feeds one of Core's *-call.yml@vN workflows. A new rule 7b (banned_run_interpolation_contexts_workflow_only) bans it under .github/workflows/ alone. Both were free: every occurrence in the tree was already routed through env: (#1160).

Two zsh plugin pins roll forward in zsh/45-plugins.zsh (#1156, the freshness bot): zsh-history-substring-search 14c8d2e0ffae → a0bdb0d47dba and zsh-syntax-highlighting 2fc57d63067c → 0bfcb582e71d. This is the one change in the release that reaches a host, so it is recorded here even though a bot landed it — CONTRIBUTING.md has no carve-out for automation. Both ranges were read against the upstream compare: the first is two commits touching only README.md (+2/-2, a zplug snippet fix), the second one commit adding an Arch install path to INSTALL.md (+8/-0). So the pins move and no plugin code does; the other six pins were already current.

The scaffold's README is now linted for real, and held to Core's. The suite drove the scaffolded repo's markdown leg through a shim that records argv and exits 0, so the README new-os-repo.sh writes was never judged by the .markdownlint.jsonc it writes beside it, and its hand-copied shield block could drift from Core's unnoticed (#1162). 35-new-os-repo.sh now runs the real markdownlint-cli2 on it wherever the tool is installed (CI's main leg installs the pinned one), and asserts the header and every shield link definition match Core's README.md with the repo name swapped. dotgibson-* (Core's release, on purpose) and ci-url (lint.yml, not ci.yml) are the stated exceptions.

new-os-repo.sh writes the fleet's shield row into the README it scaffolds. A checkup that fetched every badge and link target across the fifteen public READMEs found the two newest repos opening with no shield row at all — dotfiles-NixOS because this scaffold wrote none, and its generated .markdownlint.jsonc deliberately left out the MD033 allowance the row needs ("a fresh OS repo has no showcase page"). The scaffold now writes the eight-badge row above the title, the link definitions at the end, the CI badge pointing at the lint.yml it also writes, and the scoped MD033 allowed_elements stanza the siblings carry — so the next repo starts where dotfiles-NixOS had to be brought to by hand (dotfiles-NixOS#11). The same checkup fixed a dead bash link here (#1151), two logo slugs simple-icons no longer ships in each of dotfiles-Windows and dotfiles-Defense, and dotfiles-Offense's Python badge, which read CPython's GitHub releases — it publishes tags — and rendered "no releases or repo not found".

Two tool pins roll forward: markdownlint-cli2 0.23.2 → 0.23.3 and the maintenance bots' Claude Code CLI 2.1.273 → 2.1.281. The weekly freshness review (#1159) found them the only pins behind upstream that are not deliberately held. markdownlint-cli2 0.23.3 only updates dependencies, and both versions pin the markdownlint library at 0.41.1, so no rule is added, renamed or given a new default in Core or in the lint-call.yml consumers. The pre-commit hook's rev moves with it, because §9 keeps the two in step. Both are registry installs, so there is no *_SHA256 to refresh. shfmt stays held at 3.13.1 (#813).

Both atuin guard premises re-measured against 18.23.0; both VERIFIED_AGAINST anchors move (#1158, run 35956975589). Upstream released 18.23.0 on 2026-09-22, one minor past the 18.22.0 the anchors in zsh/00-tools.zsh carried. One atuin-guard-verify dispatch, checksum and build-provenance verified: silent discard holds (its report job skipped), and autostart self-healing is moved exactly as it was on 18.22.0. absent and stale spawn a daemon and land their row, and wedged blocks on the pidfile lock and loses it (upstream atuinsh/atuin#4114, still open). That is the shape #1102 already answers by probing and warning rather than standing down, so the auto-filed #1177 asks nothing new of Core. Editing an anchor is a claim that the premise was re-measured at that version, so this is that claim and not a version bump. 18.23.0 continues 18.22.0's direction, and the block now says so: an FTS index over captured command output and a sync engine replacing the event bus both sit behind the socket, with no client-side spool or direct-write fallback (the one PR that would have changed the client's connect shape, atuin #4168, closed unmerged). A dead socket still discards, and atuinsh/atuin#3382 (accept-but-silent) is still open, so the steer away from socket activation stays.

The test suite no longer writes to the developer's real ~/.config/zsh/.zshrc. Every fixture moves HOME into the sandbox, but an interactive fleet shell also exports ZDOTDIR=~/.config/zsh, and the driver defaults ZDOTDIR only when it is unset. So a make audit (or make release) run from such a shell had the driver and scaffold fixtures re-point the real $ZDOTDIR/.zshrc into a temp dir, deleted at exit, and the next shell started bare. The same inherited mise activation state made sandboxed shells error on an untrusted mise/config.toml, so the audit went red locally while CI stayed green. test-core.sh now unsets ZDOTDIR, the four XDG_*HOME dirs and every MISE*/__MISE_* variable before any fragment runs, and 05-suite-shape.sh asserts that none survive. The test/check-links.sh that new-os-repo.sh scaffolds clears the same variables itself.

The fan-out count gate no longer reads binary files. _core_fanout_count_hits ran its awk over every tracked file, assets/demo.gif included, so every make audit printed a gawk Invalid multibyte data detected warning under a UTF-8 locale. It now skips any file containing a NUL byte. It does not use grep -I, because BusyBox grep accepts that flag and ignores it. The verdict never changed (a GIF makes no fan-out claim); the audit's output is quieter.

new-os-repo.sh writes the LICENSE its README shield advertises. The shield row added above carries an MIT License badge linking blob/main/LICENSE, but nothing wrote that file (it is in neither core.manifest nor core.vendor), so a new repo's first push would show license | not identified and a link that 404s. The scaffold now writes Core's LICENSE (the whole fleet's, byte for byte) with the birth year, and the generated .markdownlint.jsonc names the real reason MD041 is off: the README opens with the back-to-top anchor and shield row, not an H1.

PORTING-MATRIX.md and the README stop contradicting the fleet (#1174, from the #1157 sweep). The sesh row's Arch cell asserted AUR⁹, but dotfiles-Arch go-installs sesh and says the AUR sesh-bin is not needed; it is now go⁹, and footnote ⁹ names Arch among the go-install consumers. Footnote ³³ gave Gentoo's ~arch neovim range two ways eleven lines apart (0.12.5 and 0.12.3); both now read 0.12.5, as the TSV does. Footnote ³⁴ said jq 1.8.2 reached "all three" supported Alpine stable branches; Alpine carries four, and 3.21 is still on 1.7.1. The README's install steps gain the Defense clone and name Debian and NixOS among the Linux distros, matching the "all ten bootstraps" line beneath them.

Every registered README hero is now filmed — the tenth, dotfiles-NixOS's, landed as dotfiles-NixOS#8, so the "still to be filmed" prose in CLAUDE.md, assets/hero-repos.txt and assets/README.md is retired. It was the one row no rootless chroot could film — its host guard asserts sudo nixos-rebuild switch --upgrade and up -n probes $PATH for it — so it was filmed on NixOS-WSL, and assets/README.md gains "Filming the NixOS hero": the two-rebuild install, nixpkgs' own render kit (vhs 0.11.0, not the 0.12.0 that writes no gif), the Adwaita Mono rejection the ❖ fallback needs, and the trap that is NixOS-WSL's alone — a nixos-rebuild switch resets the kernel-global binfmt_misc table, which every distro on the machine shares, so the distro you drive from loses wsl.exe until it is re-registered (the recipe is there). The install also surfaced dotfiles-NixOS#6: home.nix named two attributes nixpkgs does not have, invisible to that repo's parse-only gate. §9k's rule stands: a registered tape with no gif is a skip, so a re-render that has not landed never blocks the gate.

PORTING-MATRIX.md gains an eza fleet-version table (footnote ³⁹), against a 0.23.5 floor. 0.23.5 added --hyperlink=auto and lines-of-code counting, and an older eza rejects the flag outright. The /tool-scout scan in #1158 held it on a watch that ends only when every lane is at or above that version, and until now nothing recorded where the lanes sit. scripts/fleet-package-versions.tsv now carries seventeen rows, each read from the distro's own index. Seven are at or above; Alpine edge/3.24/3.23 and Gentoo stable are one patch short on 0.23.4; Ubuntu 24.04 (0.18.2), both Leap backports (0.20.4), Debian 13 (0.21.0) and Alpine 3.22/3.21 are further back. gen-porting-matrix.sh registers the block and marks the eza row. Core enforces no eza floor, and zsh/ passes no flag that needs one.

windows-terminal/settings.json's colour scheme is generated from theme/palette.toml (#230). The twenty hexes in the Tokyo Night scheme were the largest hand-typed colour block left after #228 — deliberately skipped that round, because the file is APP-OWNED: install.ps1 symlinks it into all three Windows Terminal flavours' LocalState, the app rewrites *this copy* on every settings change, and its JSON writer strips comments, so a // core:theme:gen marker would not survive the first toggle. gen-theme.ps1 therefore grew a second emitter kind. json-scheme finds the scheme object by its own "name" (the app re-sorts the array alphabetically, so an index is not stable), scoped to the schemes array so a profile sharing that name cannot be hit, and rewrites the hex values on the lines they already occupy — indentation, key order and trailing commas preserved byte for byte. Deliberately not a ConvertFrom-Json | ConvertTo-Json round trip, which would reformat all 227 lines every run and fight tests/Format-AppJson.ps1's no-re-indent rule. It emits UPPERCASE hex because the app does; lowercase would make every GUI round-trip a twenty-line colour diff. Registering the file also turns on the residual-hex scan over it for free, so a hex the palette does not define can no longer be dropped anywhere in that file.

The last two night-style hexes are gone. background was #1A1B26 and selectionBackground #28344A — tokyonight *night* values in a palette pinned to *storm*, and the same pair #229 had already replaced twice elsewhere (ListPredictionSelected, Get-DotAnsiSgr's Black). They now resolve to color_bg #24283B and color_bg_visual #2E3C64, so the terminal's selection highlight finally matches PSReadLine's prediction bar and its canvas matches psmux's @tn_bg. The other eighteen already agreed with Core and did not move.

The core front door reaches the second family: core update check and core maint <install|run|log|status|uninstall> (dotgibson/dotfiles-core#684). Core's zsh dispatcher grew the same arms in the same change, and its PARITY.md pins them as aligned rows enforced by parity-check.sh — so this lands FIRST, or Core's gate would assert a pwsh half that did not exist yet. Additive only: up, update-check and the five maint-* verbs keep working exactly as before, and core update -y still belongs to up — only the literal word check in first position is intercepted. A bare core maint (or -h/--help) prints the family's usage line rather than erroring, the way a bare core is the index; an unknown sub-verb gets its own did-you-mean (core maint stauts → status). Every arm is an explicit call, never & "maint-$v", because the load contract is derived from literal command names and an indirect call would hide the dependency. Core.Tests.ps1 stubs the six new leaves and asserts routing, arg forwarding, the bare-namespace usage, and that a typo dispatches nothing.

Get-DotAccentSpec — the accent half of theme parity, which this host simply did not have. Core's zsh/05-ui.zsh has _CORE_ACCENT_SPEC / _CORE_MUTED_SPEC, the one place $COLORTERM is interpreted, with a truecolor tier and a hand-picked 256-colour fallback. grep -rnE 'CORE_ACCENT|AccentSpec' powershell/ returned nothing here, so PARITY.md's accent row was a genuine gap rather than a drift. The pwsh twin lives in powershell/core/05-lib.ps1 beside Get-DotAnsiSgr and is generated from the same palette. The two fallback forms deliberately disagree (SGR 111/103 vs spec 75/244); both are carried verbatim and neither is derived from the other.

A drift gate on the maintenance runner's own step list. Maintenance.ps1 states its steps in three places — the file header, the -Help block, and the actual Step calls — and nothing kept them honest, so both prose copies had silently lost the scoop junction step (the header had also lost navi). tests/Maint.Tests.ps1 now discovers the steps from the AST and fails when one is not documented in both, with a bidirectional map assertion so a renamed or removed step cannot leave a stale entry that passes forever. Both prose blocks are corrected.

wsl-ssh-config — the client-side ssh_config for the distros behind this host. docs/REMOTE-ACCESS.md §4 told you to hand-write the Host <distro> block that Format-DotWslSshConfig could already generate: the renderer, the port allocator and the alias slug all shipped as tested module exports with nothing calling them. powershell/os/34-remote.ps1 is that caller. Ports are allocated from the sorted distro list, because wsl --list reorders on install / unregister / re-default and a port that moves is worse than no port — it is already baked into ssh_config, into firewall rules and into muscle memory. -HostPort reserves the port the Windows sshd actually answers on instead of assuming 22; assume otherwise and a distro is handed the host's port, a collision that stays invisible until that distro silently fails to bind. -JumpHost emits the ProxyJump shape — one LAN port, distro ports on the host's loopback — rather than a network-facing listener per distro. It prints and never writes: the file this output belongs in lives on the machine you ssh *from*, which by definition is not this one. Reading the distro list back out of wsl.exe is the one impure step, and it is impure in a way that bites — wsl --list --quiet emits UTF-16LE, which lands in PowerShell as a string with a NUL between every character, so a naive reader finds no distros on a box that has several. WSL_UTF8=1 is set on the child only (and restored, including the unset case, which must be removed rather than blanked), with the NUL strip as the belt for builds that ignore the variable. Still deliberately absent, and still a runbook rather than a script: standing sshd up. The service, the firewall rules, the HKLM DefaultShell key, the boot task and the power settings are machine-global state that varies per box.

Get-DotfilesStubContent and Test-StubIntoRepo (powershell/core/05-lib.ps1, exported from the Dotfiles module) — the stub body renderer and the "is this wired?" predicate for Kind='Stub' rows. Test-StubIntoRepo is a *reference* check, not an equality check, so a user's own added lines survive a re-install; it compares with forward slashes and uses String.Contains rather than -like, because it gates a delete in uninstall.ps1 and a [ read as a wildcard would be a false positive.

powershell/Dotfiles/Remote.Helpers.ps1 (+ tests/Remote.Tests.ps1) — pure logic for reaching this host and the distros behind it: Get-DotWslSshPlan (a stable distro->port map, sorted by name so a port never moves when you install or unregister a distro), Format-DotWslSshConfig (the client-side ssh_config, direct or via ProxyJump), ConvertTo-DotSshAlias, and Get-DotRemoteWiringResult — the triage that says whether a wired config survives an ssh session. Get-DotWslSshPlan takes the Windows sshd's port as a parameter rather than assuming 22. A host that moved sshd off 22 is common, and assuming otherwise produces a confident "port collision" diagnosis that is simply wrong. Deliberately absent: anything that touches the service, registry, firewall, scheduled tasks, or power settings. That is machine-global state which varies per box and is better done by hand with eyes on it — the runbook is in docs/REMOTE-ACCESS.md.

A Remote (ssh) configs row in dotfiles-doctor — probes whether Redirection Guard is enforced in the current session and reports any stub-kind config still wired as a symlink. Only the actionable rows are listed: plain symlinks are also unreadable over ssh under enforcement, but that has no fix at this layer, and listing all eleven every run would bury the one you can do something about.

docs/REMOTE-ACCESS.md — the full diagnosis, the one-command way to confirm Redirection Guard in a broken session, the list of fixes that do *not* work, the scoop limitation, and a corrected WSL section (banner-grabbing to identify which daemon is on which port; who rather than ss for per-distro attribution, since networkingMode=mirrored makes ss show the host's whole peer list).

desktop/PARITY.md's shared half is now generated and gated, and the "identical copy" claim in desktop/README.md is corrected (dotgibson/dotfiles-core#693). This file and dotfiles-MacBook/sketchybar/PARITY.md were an admitted verbatim pair held together by nothing but the sentence *"Edit both together"* — and they had drifted 3.5 KB apart. Most of that was a one-sided Markdown reformat with no semantic content; the real divergence was 947 bytes of Windows-only prose — the psmux battery-scale note — that had never been marked as a deliberate divergence. The shared contract now lives between the <!-- desktop-parity:gen --> and <!-- desktop-parity:end --> markers, rendered from dotfiles-core/desktop/PARITY.shared.md by make gen-desktop-parity; Core's scripts/gen-desktop-parity.sh --check fails the weekly parity-check run if either copy is edited alone. The psmux note is unchanged in substance and stays here, below the markers where the generator does not touch it, now labelled deliberate — so TERMINAL_WORKFLOW_GUIDE.md's pointer at the 40–60 % disagreement still resolves. Edit the Core source, not this file's generated block.

The module step no longer re-downloads modules it already has, which is what had module update: PSReadLine failing on every run. Save-Module -Force rewrites <Path>\<Name>\<Version> wholesale even when that exact version is already on disk, and for a module whose assemblies are mapped into a running PowerShell that overwrite cannot succeed — the files are locked and it fails with *"Access to the path … is denied"*. PSReadLine is loaded by every PowerShell session, so on any box with a shell open it failed every time. Confirmed on this host rather than guessed: Microsoft.PowerShell.PSReadLine.dll and its Polyfiller were held open, with six other pwsh processes running. The module was not out of date. Neither were the other three — all four already matched the gallery exactly, so the step was re-downloading four modules a day to achieve nothing, and failing on one of them for the privilege. It now looks up the gallery version and saves only when there is something newer. This removes the failure rather than hiding it: a genuinely new version installs into its own version directory and never touches the locked one, so the update path that matters is untouched. Find-Module failing (offline, gallery down) deliberately falls *through* to Save-Module rather than skipping — an unknown latest version must not read as "up to date", or the step would go quiet on exactly the days it cannot check. Test-DotModuleUpToDate (powershell/Dotfiles/Modules.Helpers.ps1) is the pure decision, conservative by construction: nothing installed, an unparseable version on either side, or an unknown gallery version all return "save anyway".

The theme is generated now, and three colours had already drifted. Core made theme/palette.toml the one place a colour is authored (dotfiles-core#679) and renders it into every consumer with scripts/gen-theme.sh. This repo was the last in the fleet still typing the numbers — and the hand-copied fzf block in powershell/core/10-tools.ps1 carried a comment claiming it was "kept byte-for-byte in step with Core's zsh fzf.zsh" while three of its fourteen values were wrong: border and scrollbar on #27a1b9 against Core's #29a4bd, and gutter on #16161e against #1d202f. Core's parity-check.sh stayed green throughout, because it only compares the query: colour. The palette is now vendored like nvim/ and starship/ — theme-sync.ps1 + theme/.core-ref, hash-gated against Core by tests/Assert-ThemeParity.ps1 — and gen-theme.ps1 renders it into nine marked # core:theme:gen <id> blocks across powershell/core/ and psmux/. gen-theme.ps1 -Check gates every PR. Four values changed, all of them corrections to Core's: the three fzf colours above, plus ListPredictionSelected and Get-DotAnsiSgr's Black, which were carrying #28344a and #1a1b26 — colours from a *different* tokyonight style that appear nowhere in the storm palette. Everything else regenerated byte-identical, which is the useful part of the diff: it shows the other 50-odd literals were already right.

-Check also rejects a hex the palette does not define. psmux.conf keeps seven colours outside its @tn_* table (pane borders, status style, the @vpn_fg and @pwr_fg seeds) that psmux cannot express as #{@tn_*} lookups, and wrapping each in its own marker pair would be more noise than gate. Instead the checker asserts every remaining hex in a registered file is still a value the palette defines. That is the check that would have caught #16161e and #27a1b9 years earlier, and it is what catches those seven the day Core flips style.

install.ps1 grows Write-StubItem, dispatching on the plan row's Kind. It mirrors Link-Item's contract deliberately — idempotent skip, back up before overwrite, honour -DryRun, same stats — and the install summary gains a stubbed line (emitted only when the caller tracks it, so an older stats bag renders unchanged).

uninstall.ps1 now treats *either* shape as ours (symlink into the repo, or a stub that references it), so it can no longer orphan the files install.ps1 wrote.

dotfiles-doctor is Kind-aware: a stub row reports stub -> repo, and a stub-kind row still wired as a symlink is flagged *"will not resolve over ssh"* with the re-install fix. A symlinked profile is a warn, not a fail — nothing is broken until you ssh in.

auto-tag.yml's Core pin moved from v4.12.0 to v5.0.2 — a major and eight minors in one step, because nothing advances it automatically. This repo vendors no core/, so it is absent from scripts/os-repos.txt: the fan-out never opens a PR here and make fleet-drift cannot see it. The pin advances when a human moves it, and between 2026-08-16 and 2026-08-26 nobody did. Behaviourally this is a no-op, and it is worth being precise about why. auto-tag-call.yml and scripts/auto-tag.sh are byte-identical at v4.12.0 and v5.0.2 (git rev-parse on both blobs agrees), and the workflow re-checks-out dotfiles-core at a moving alias for the scripts it runs — so this host was already executing the same code as every "current" repo. What changes is that the recorded pin now matches what actually runs, instead of reporting eighteen releases of drift that were not real. The genuine defect the audit surfaced is upstream and is being fixed there: the reusable workflows fetched their scripts from v4 while every caller ran at @v5 (dotgibson/dotfiles-core#672). The comment above the pin now records that a SHA pin freezes the workflow body but not the scripts it pulls, so the next reader does not over-trust it.

The navi repo update maintenance step, which was never a real command. navi repo takes only add / browse / help, so the step exited 2 with *"unrecognized subcommand 'update'"* on every run it has ever made — invisible until the exit-code fix above made it reportable. Nothing is lost: navi has no "refresh my repos" verb to re-point it at, and updating imported cheatsheets means git-pulling each one under navi info cheats-path by hand. On this host that path does not exist at all, so there was nothing to refresh either way. Worth adding back the day cheat repos are actually imported (navi repo add). Removed from all four places that named it — the runner, its file header, its -Help block, and TERMINAL_WORKFLOW_GUIDE.md — with the step-documentation gate in tests/Maint.Tests.ps1 keeping those honest. Separately, and on the host rather than in the repo: the scoop install of navi was broken — navi.exe was absent from the app directory, leaving only config.yaml, install.json and manifest.json, so the shim reported *"Could not create process"*. Not a Redirection Guard problem; the junction traverses fine. A reinstall of the same version (2.24.0, matching the bucket, and navi is unpinned) restored it with the persisted config.yaml intact. Two independent faults were stacked behind one silently-passing step.

Ctrl+←/→ word movement was never actually bound — it was PSReadLine's default showing through. 10-tools.ps1's # Ctrl+arrow word movement; Tab = menu complete comment sat above a line that bound only Tab, so the motion came from the built-in key table and no user would ever have noticed. It mattered to the parity contract: Core's PARITY.md marks the Word nav row aligned, but parity-check.sh had to give the pwsh half a - sentinel and report it as a SKIP — the only row in the table resting on a framework default rather than on something this repo states, and so the only one a future PSReadLine or -EditMode change could move without any config moving with it. The four new Set-PSReadLineKeyHandler lines are behaviour-preserving by construction: NextWord, not ForwardWord is both PSReadLine's own default under -EditMode Vi *and* Windows, and the match for zsh's forward-word — both land the cursor on the start of the next word, where ForwardWord lands on the end of the current one. Both Vi tables are pinned, since a bare -Key reaches the insert table only and Core's zsh/40-bindings.zsh binds viins and vicmd both. They are deliberately *not* column-aligned like the Tab/arrow lines above them: parity-check.sh matches its needles with grep -F, so padding here would make the Word nav row whitespace-brittle from another repo. (powershell/core/10-tools.ps1, tests/Repo.Tests.ps1, TERMINAL_WORKFLOW_GUIDE.md; #231 → #238. Follow-up: dotgibson/dotfiles-core#849)

psmux, jj and mise were all invisible over ssh too. The follow-up #225 named: every remaining config this repo wired was a symlink into the repo, and under Redirection Guard a Windows process cannot read any of them. Measured on this host before the change — jj config get ui.default-command answered *"Value not found"* and mise config ls outside a project listed nothing, so both tools had been silently running on their own defaults rather than erroring. Three different config systems needed three different answers, and finding out which was the actual work: - psmux turned out to already have an include directive. Its syntax is tmux-compatible, so source-file is the mechanism — the repo's own psmux.conf opens with one. Both psmux.conf and psmux.reset.conf become Kind = 'Stub', and the repo conf's existing source-file ~/.config/psmux/psmux.reset.conf line simply resolves to the second stub. No change to the config itself. - ~/.config/psmux/scripts is a *directory* of eight pwsh popup helpers, and a directory has no include form. New Kind = 'StubDir': a real directory of one-line forwarders, one per script, each &-invoking the repo copy with @args. That leaves psmux.conf's eight display-popup binds untouched — they still name ~/.config/psmux/scripts, which is real now — and & rather than dot-sourcing keeps $PSScriptRoot pointing at the repo, so a script that resolves a sibling still finds it. - jj and mise are TOML, which has no include directive at all. Neither can be stubbed, so they are not wired as files any more: Get-DotfilesEnvPlan sets JJ_CONFIG and MISE_GLOBAL_CONFIG_FILE as persistent User-scope variables pointing into the repo — both verified against the installed versions before being committed to. User scope is what reaches an ssh session and a scheduled task, the same mechanism DOTFILES_WIN already uses. A forwarder directory does not track the repo by itself, and the drift runs both ways. Checking only that every script has a forwarder let the other direction survive indefinitely: a script deleted upstream leaves a forwarder pointing at nothing, that forwarder is not *missing*, so install returned "already wired" and its own stale-sweep never ran — leaving a psmux bind that opens a popup and immediately errors. Test-StubDirIntoRepo now fails on both directions, which is what makes the sweep reachable. Two honesty problems came with the env-var mechanism, both handled rather than documented away. Nothing exists at ~/.config/mise/config.toml any more, so the wiring is invisible at the conventional path — hence explicit env: rows in dotfiles-doctor, because a variable that goes missing looks exactly like a tool with no config. And a shell already open when install.ps1 runs keeps the old environment block, so the doctor checks the process value as well as the registry and reports *"set for new sessions, but missing from THIS one"* instead of grading it ok — the same false-ok shape the nvim row taught us to look for. install.ps1 retires the superseded jj/mise symlinks (identified by Test-SymlinkCurrent against the plan's Target, so a link belonging to another checkout is left alone), and uninstall.ps1 clears the two variables — but only while they still point into this repo, and never DOTFILES_WIN, which is how bootstrap.ps1 finds an existing checkout. Still a symlink, and correctly so: .gitignore_global (global ignores reach ssh via the .gitconfig stub's core.excludesfile override) and the interactive-only desktop configs — Windows Terminal, GlazeWM, Zebar.

The maintenance tasks were pointing at a pwsh that Windows deletes. maint-install baked (Get-Command pwsh).Source into both scheduled tasks, and a Store-installed pwsh resolves to a *version-pinned* package directory (…\WindowsApps\Microsoft.PowerShell_<ver>_…\pwsh.exe). When Windows cleans up a superseded package the task fails with 0x80070002 — silently, because a task that never launches writes nothing to maint.log. Measured on this host: dotfiles-maint sat at 0x80070002 with no completed run between 2026-08-26 and 2026-08-29, which also meant the scoop junction sweep from #217/#221 was not happening. The feature was correct and simply never got to run. maint-install now prefers a version-stable path — MSI install, machine-wide app alias, per-user app alias, scoop shim — and only falls back to the resolved version-pinned path, warning when it does. The daily task runs as you and takes the per-user alias; the SYSTEM task cannot, since SYSTEM's %LOCALAPPDATA% is under config\systemprofile, so with a Store-only pwsh it stays pinned and says so. Installing the MSI build gives both a stable path. Get-DotStablePwshPath is the pure, unit-tested policy; the probing stays in the fragment. Detection, so this cannot rot silently again: maint-status now shows each task's Execute and attaches a verdict — a missing executable or a 0x80070002 last result is a fail, and the informational SCHED_S_* codes are not. dotfiles-doctor carries a Maint tasks row. Both are careful about what they can actually see: Task Scheduler ACLs a SYSTEM-principal registration to SYSTEM and BUILTIN\Administrators, so an unelevated shell cannot distinguish a broken junction task from a healthy one and reports not visible rather than guessing not installed. (A self-check inside the daily run was tried and removed for exactly this reason: it would have reported a confident false failure every day.)

hostip returned an address no other machine could reach. It took the first non-link-local IPv4 Windows reported, and on any box with a Hyper-V or WSL virtual switch that is vEthernet (Default Switch) — a Manual 172.x address that exists only inside the host. Measured here: hostip answered 172.26.80.1 while the LAN address was 10.0.50.90. Nothing about the address itself says which is which, so it read as correct right up until the connection timed out. What separates them is the routing table: the LAN interface carries a default route and a virtual switch has none. hostip now reads the default routes and the addresses and hands both to Select-DotHostAddress, a new pure module export that makes the choice — preferring a default-route interface in the caller's metric order, and falling back to the old SkipAsSource ordering on an offline box with no default route at all, rather than returning nothing. Surfaced by wsl-ssh-config above, which prints this address into a config you paste on another machine — the one place the wrong answer is guaranteed to bite.

.core-ref recorded tag = v4-19-g10ad221 — the moving major alias, not the release it describes. (#202) Every Core cut writes the specific vX.Y.Z and then force-repoints the major alias v4 onto the same commit (tag-release.sh, git tag -fa, alias second). Both tags are annotated and both sit on the release commit, so git describe breaks the tie by tagger time and picks the alias. That is a provenance field naming a target that is deliberately moved on the next release: the recorded string silently reinterprets itself, and re-running the same command against the same commit today returns v4.15.1-19-g10ad221. commit was always authoritative — only tag lied, and it lied in the direction that looks fine until you check. Both sync scripts now filter describe to the vX.Y.Z shape (--match 'v[0-9]*.[0-9]*.[0-9]*'), which excludes bare-major aliases by construction — the identical fix Core shipped for core.lock in dotgibson/dotfiles-core#515, so the Windows row and the Unix repos' core_tag agree on what a release name means. When only an alias exists, describe finds nothing and the tag line is omitted: an absent tag is honest where v4 was not, and the SHA stays the source of truth either way. nvim/.core-ref is corrected in place; starship/.core-ref already read v4.9.0 because its last sync was a pinned -Ref landing exactly on a release commit — the same latent bug, just not yet visible. The filter also immunizes -CoreLocal runs against a locally stale alias, since a plain git fetch never force-updates an existing tag (this box's own Core clone has v4 frozen at v4.7.0's commit). The describe call also moved above each script's *_LIBONLY hook as Get-CoreDescribeTag, which is the part that keeps it fixed: the old inline call sat below the hook and was structurally unreachable from Pester, which is exactly why a wrong value shipped unnoticed. The new fixture (New-DotCoreTagFixture in tests/_TestHelpers.ps1) tags one commit v9.9.9 then v9 in release order, and a companion assertion proves a bare describe --tags still gets that fixture *wrong* — so if the reproduction ever stops reproducing, the suite says so instead of going quietly green. (nvim-sync.ps1, starship-sync.ps1, nvim/.core-ref, tests/_TestHelpers.ps1, tests/NvimSync.Tests.ps1, tests/StarshipSync.Tests.ps1)

Why Mason can't install ruby-lsp on this host, written down where package decisions live. The winget package the box runs, RubyInstallerTeam.Ruby.4.0, ships no MSYS2 DevKit, so every gem with a C extension fails to build — ruby-lsp and rubocop both die on prism. The error names neither ruby nor the DevKit (No rule to make target '/C/Ruby40-x64/include/ruby-4.0.0/ruby.h'): with no msys64, gem falls back to scoop's mingw make, which has no rm and mangles the drive-letter path into an MSYS-style one. docs/PACKAGE-OWNERSHIP.md now carries the symptom, the mechanism, and the one-line elevated fix (ridk install 1 3), next to the existing ruby-ownership reasoning. Confirmed fixed on the reference host on 2026-08-24: ridk install 1 3 (elevated) populated C:\Ruby40-x64\msys64, and gem install ruby-lsp now builds both native extensions clean. That is host state, not repo state — a rebuilt box gets plain Ruby.4.0 again and needs the same command. It also records why ruby stays out of winget.json rather than being declared like node was: the lock-drift gate only accepts ids Update-PackageLock.ps1 can resolve to an installed version, so declaring RubyWithDevKit.4.0 on a box running plain Ruby.4.0 would sit permanently unlockable and red. (docs/PACKAGE-OWNERSHIP.md)

psmux power pill — the battery segment the macOS tmux bar has. New psmux/scripts/psmux-power.ps1, rendered right-most in status-right, which is where Core puts it too (its last slot is #{@status_right_os}, the hook each OS repo fills). It is the Windows port of Core's tmux/scripts/tmux-battery.sh and uses that scale, so the two terminal bars agree: green ≥60 / yellow ≥20 / red <20, with the level glyph swapped for a charging bolt on AC and the colour still tracking the level. One deliberate divergence — Core prints nothing when there's no battery, so its segment vanishes on a desktop; here it falls back to Zebar's AC placeholder, a lone green md-power-plug 󰚥, since an empty segment reads as a broken pill on a desktop-first host. Power state comes from SystemInformation.PowerStatus (one in-process GetSystemPowerStatus read), not Win32_Battery — a desktop returns nothing from the latter, so "no battery" and "the query failed" would be indistinguishable. Refreshed by the existing in-session timer alongside the VPN pill, so nothing new touches psmux's synchronous render path. psmux.conf seeds @pwr_pill with set -og (only-if-unset) so the desktop plug is right before the first tick, while a prefix + r reload can't clobber a live laptop reading. (psmux/, powershell/os/33-psmux-pill.ps1) Note this means the psmux bar and Zebar disagree between 40 and 60 % — deliberately. The bars are matched terminal-to-terminal (psmux ↔ Core tmux) and desktop-to-desktop (Zebar ↔ sketchybar), and those two references use different scales.

Test coverage for the power pill's every state. The dev box is a desktop, so the laptop branches would otherwise ship unexecuted. psmux-power.ps1 takes a -SimulateState testing seam (no host read, no poke) and tests/Repo.Tests.ps1 asserts each colour and glyph threshold — including that a charging 15 % battery stays red, which is the case a naive "on AC → blue" reading would silently hide.

The package-freshness check now validates its own inputs — a wedged scoop bucket is a finding, not a silent green. A bucket is a git clone, and a stuck clone keeps serving manifests from whatever commit it froze at. Those stale versions still parse and still compare as matching, so the check reported "everything's current" on data months old — wrong in the reassuring direction, the worst way for a check to fail. That is not hypothetical: on 2026-08-04 the local extras clone had been stuck mid-merge on an upstream rename (UD bucket/pycharm.json) since mid-July, so scoop status called lazygit and tailscale "latest version" while the CI bot correctly had them behind. The box contradicted CI and the box was wrong. Check-PackageFreshness.ps1 now checks every bucket it reads manifests from — present, a real clone, not stuck on a merge/rebase/cherry-pick, clean tree — and writes a report even when nothing looks outdated, since that silent-green case is the entire point. The warning leads the issue body, because it invalidates every row under it. Also catches a bucket the scoop bucket add loop failed to create (its catch is empty), which today degrades quietly into a "no manifest version" skip for every app in it. Unit-tested via a new DOTFILES_PKGFRESH_LIBONLY hook, matching the *_LIBONLY idiom the sync scripts use. (packages/Check-PackageFreshness.ps1, tests/Packages.Tests.ps1)

dotfiles-doctor now checks scoop bucket health too, because CI structurally can't. The guard above lives in a script whose CI runs on a fresh runner, where buckets are added moments earlier and are always clean — so it protects the local-run path but can never observe the box this actually happened on. The wedge was a local condition that made the machine disagree with the bot for three weeks, and the doctor is where "is this box healthy" belongs. New Scoop buckets row under Health & toolchain: 6 bucket(s) clean and pullable when fine, and on a fault it names the bucket, says why (stuck mid-merge (MERGE_HEAD), dirty tree, missing directory, not a clone) and hints the exact unwedge. warn, not fail — nothing is broken and no tool is missing; the box just can't be trusted to tell you what's current. The detector is reused from packages/Check-PackageFreshness.ps1 through its DOTFILES_PKGFRESH_LIBONLY hook rather than reimplemented, so there's one definition of "this bucket can't be trusted"; the dependency deliberately only points this way, since the freshness bot must stay self-contained for CI, where the Dotfiles module isn't installed. The whole probe is wrapped so a bucket check can never take down a doctor run. (powershell/Dotfiles/Doctor.Helpers.ps1, powershell/os/45-doctor.ps1, tests/Doctor.Tests.ps1)

A config reload repainted a live pill in the wrong colour. @vpn_fg was defaulted with a plain set -g, so every prefix + r overwrote whatever the refresher last poked. Because the pill's text is never defaulted, the two halves then disagreed until the next tick — up to a full refresh interval — and these pills encode their state in the colour: an active tunnel kept showing its address in the no-tunnel green, losing the orange that is the entire signal. Both colour options now use set -og (only-if-unset), which still guarantees a non-empty colour on first paint. Caught on review of the same mistake in @pwr_fg, where it would paint a 15 % battery healthy-green. psmux set -g @vpn_pill '', but an empty-string argument is dropped on the way to the exe and the set no-ops exactly like the splat above. Clearing now uses set -gu (unset). psmux-pill-disable clears the segment too, instead of only stopping the timer.

Holding the prefix key shoved the IP pill two columns right. The prefix/mode indicator sits between #S and the pill with each branch padded to the same width — but the idle branch was three literal spaces, which psmux's parser collapsed to one (see the next entry), against a prefix branch of space + glyph + space that survived as three. The branches are now spaced with #{p<n>:} and are five rendered cells each, verified in both directions on a real terminal. A test asserts the three branches stay equal width, since eyeballing this is exactly what failed before.

Multi-space gaps in the status bar were rendering as a single space. psmux parses option values as split_whitespace() + join(" "), so every run of spaces collapses to one, quoted or not — which means the twelve-space cwd→clock gap added in #163 had never actually widened anything. Bar gaps now use #{p<n>:}, which pads an empty body at render time — after the parser has had its way — and is the same idiom Core's tmux.conf already uses (#{p19:}), so the two configs now read the same. The session→IP gap is wider as a result, and a test forbids multi-space runs in status-left/status-right so this can't silently regress. Note #{p<n>:} only works written directly in the config: a format arriving via a user option is not re-expanded, which is the same rule that keeps a #[…] style run from working inside @vpn_pill.

Two stale psmux config tests. They asserted the pill was read via #(cmd /c type %LOCALAPPDATA%…) and passed only because that string still appeared in the comment block describing the retired transport — they had stopped testing anything real. Repointed at the live @vpn_pill / @pwr_pill segments, plus a static guard that every psmux set in the repo quotes its @option name, since the splatting bug above is invisible at runtime. (tests/Repo.Tests.ps1)