Builds a full dev workstation from a bare Arch Linux install. https://git.cjennings.net/archsetup/atom?h=main 2026-07-25T19:59:21+00:00 2026-07-25T19:59:21+00:00 Craig Jennings c@cjennings.net 2026-07-25T19:59:21+00:00 urn:sha1:d25711a61172ffb7b622a6a834ed17fdf52a54de 2026-07-12T14:14:47+00:00 Craig Jennings c@cjennings.net 2026-07-12T14:14:47+00:00 urn:sha1:110da0401d9ea91c83602bee4229f88b9f5b7725 All v1 phases of both specs shipped on dotfiles main in the 2026-07-11 build run (net: 21ca3ff, d73eba6, c9f8604, be15a81, 12e3e76; bt: d19fdca, f05a9b4, d7d859f), fake-verified green. The live halves stay on the VM live-verification task and the manual-testing checklist. vNext items from both specs are now logged as [#D] tasks. 2026-07-11T07:19:26+00:00 Craig Jennings c@cjennings.net 2026-07-11T07:19:26+00:00 urn:sha1:1e18c55b2ae3723456552dcabd1ce75fa95f4458 I ran spec-response Phase 6 on both READY specs. Each gets a SPEC_ID-bound parent task in todo.org with one child per implementation phase. Both specs flip from READY to DOING. Only the read-only detection phases are buildable now, so they're marked solo: net Phase 0 (the control-plane probe) and bt Phases 0-1 (the two probes plus the firmware-hint Guide verdict). The privileged phases stay lower priority and carry a note: they're gated on the shared cross-panel run-time privilege model that doesn't exist yet. Shipping them before the Confirm floor would let --fix run root ops via passwordless sudo ungated. I held off writing the manual-testing checklists. The phases that need live or reboot verification are the blocked ones, so their checklists would be planning work that can't start yet. 2026-07-11T06:59:56+00:00 Craig Jennings c@cjennings.net 2026-07-11T06:59:56+00:00 urn:sha1:102ed0925e0eb04d238aaf571836350258e3cbd9 I ran spec-response on both, then two more skeptical review rounds until each reached Ready with caveats, no blocking findings. I verified every current-behavior claim against the live engine before each response. The skeptical passes earned their place by catching real blockers the first round missed. Net: my round-1 "redaction copy/--json surface" was invented. That surface doesn't exist: SSID redaction is event-log-only and --json is raw. I re-resolved it as parity with the existing link-step behavior, plus a separate task for the systemic gap. I also made all three control-plane verdicts fixable, since a terminal outcome would never run its own fix (doctor.py:181). And I repointed the auth classifier at the profile key-mgmt and scan-security signals that carry the SAE/hidden distinction. Bt: the AutoEnable default is true, not false (bluez 5.87), so round 1 had the "dead every boot" premise backwards and would false-positive on healthy machines. The fault now fires only on an explicit AutoEnable=false, a disabled service, or a TLP entry. The verdict "code" is an additive schema.step key, not one that exists today. Both specs carry one caveat: Phases 1-2 need the shared cross-panel run-time privilege model, which doesn't exist yet. A hard ordering gate now sits on each: shipping the Privileged verdicts before the Confirm floor would let --fix run root ops via passwordless sudo ungated. Only Phase 0 is buildable today. 2026-07-11T06:20:56+00:00 Craig Jennings c@cjennings.net 2026-07-11T06:20:56+00:00 urn:sha1:b56d14690e69bc304ab4bb4d8ef176b67874edec Reviewed both DRAFT expansion specs against the live engines. Both stay Not ready: three open decisions apiece plus one blocking finding each. Net: the Security dimension claims connection names are already redacted, but redact.py covers only SSID, MAC, IP, secret-keys, and portal_url, so the new keyfile-perms and rival-manager verdicts would leak a connection name into the wall and --json. Four non-blocking fixes alongside it: nm-restart's scope was overstated, is-enabled isn't used yet, some message text was listed as classifier verdicts, and the priv.py dispatch integration wants naming. Bt: the doctor has no named-verdict layer to hang the proposed no-adapter-firmware and powered-off-persistent verdicts on. A step carries a pass/fail/warn/info status and the run an ok/warn/fail overall, nothing more. How each new verdict is represented has to be settled before Phase 1. Three non-blocking notes cover the widening sudoers surface, the real diagnostic surface, and the bounded journalctl precedent. Both designs are sound and target verified-real gaps: neither engine reads the config or logs the specs propose to add. 2026-07-11T05:54:56+00:00 Craig Jennings c@cjennings.net 2026-07-11T05:54:56+00:00 urn:sha1:0f7c166e1383286ee4117d16b5810814266ca02b I ran the audio doctor's design arc for the net and bluetooth doctors: a blind by-layer research catalogue of failure modes, a symptom-cluster triage, then a spec per doctor. The taxonomy holds ~74 network and ~55 bluetooth distinct root causes, each sourced to a forum or issue-tracker report, sorted into eight network and five bluetooth symptom clusters. The clusters are keyed to each doctor's existing probe ladder, so the fix-versus-guide boundary falls along the tiers the doctor already walks. Every entry carries a remedy class (auto, privileged, reboot-tail, or guide), reusing the audio doctor's four-class run-time privilege model. The two specs are expansions, not rewrites. The net doctor is already the most mature of the three: its classifier reaches six of the eight clusters today, so its spec adds only the control-plane cluster (a rival network manager, a masked NetworkManager, a bad keyfile) and sharper auth naming. The bt doctor's chain is structurally right but blind at both ends, so its spec adds a probe that names the firmware blob the kernel already logged and a probe that catches an adapter that power-on won't keep on across reboots. Both stay DRAFT with three open decisions each, headed for spec-review.