#+TITLE: From archsetup — hardcoded machine identity in CLAUDE.md (consider fleet-wide)
#+DATE: 2026-06-21

* What we did

Built a Super+F Dirvish popup in the archsetup/dotfiles + .emacs.d projects,
modeled on the existing Super+Shift+N org-capture popup (launcher script names an
emacsclient frame, Hyprland window rules float it, an Emacs command runs in the
frame and q closes it). Cross-project: dotfiles half committed from archsetup,
Emacs half handed off to .emacs.d's inbox.

* The bug it surfaced

While stowing on this machine, =make stow hyprland= pulled the *velox* host tier,
and =uname -n= returned =velox=. But archsetup's CLAUDE.md asserted, as a fixed
fact, "This machine is **ratio**." It was simply wrong on velox — a stale
identity baked into a per-project doc that travels to every machine via git.

I'd been reasoning from that line all session (e.g. "the touchpad-auto reminder
is velox-only, and we're on ratio, so skip it") — exactly backwards. A hardcoded
"this machine is X" in a synced/tracked project file is a latent trap on any
multi-machine setup: the file is identical on every host, so the claim is false
on every host but one.

* The fix (this project)

Replaced the fixed identity with a runtime instruction. The attached CLAUDE.md
now reads, in the Notes section:

  Never assume which machine this is — always run =uname -n= to find the hostname
  (the =hostname= binary is absent, so =uname -n= is the source of truth;
  =uname -r= is the kernel release, not the host). The fleet is ratio
  (workstation) and velox (laptop), both Hyprland (Wayland)...

(Craig initially said =uname -r=; that's the kernel release. =uname -n= is the
nodename/hostname, which is what the stow host-tier logic already keys on.)

* Why this is a rulesets concern

This isn't an archsetup-only quirk. Any project whose CLAUDE.md / notes get
synced or cloned across machines can hardcode environment identity — current
host, current OS, "the laptop", an IP, a display name — and be wrong everywhere
the doc lands but the origin. rulesets governs how every project's CLAUDE.md and
rules are shaped, so it's the right layer to consider a general guard:

- A rule (claude-rules) along the lines of: don't assert mutable
  environment/host identity as a fixed fact in a tracked/synced project file;
  derive it at runtime (=uname -n= for host, etc.) and name the command.
- Possibly a startup or codify-time lint that flags "this machine is <name>" /
  "the current host is" style claims in CLAUDE.md.

Sending the edited CLAUDE.md (attached separately) plus this note so the rulesets
session can decide whether to codify the broader pattern. Proposal, not a
directive — your value gate applies.