lyrathorpeandEmma Thorpe
128deca2e3
CI / flake (push) Successful in 3m26s
## Summary Separates user identity (data) from the reusable Nix modules and lets a host declare any number of users, replacing the previous one-user-per-host structure. Also restructures the tree and exposes the home config for use off these hosts. ## Changes - **User registry** (`users/registry.nix`): per-user identity (name, email, groups, authorized + signing keys) as the single source of truth; no user data hardcoded in modules. - **Multi-user `mkHost`**: a host declares a `users` set keyed by username; per-user identity is injected into each home config via the `identity` module arg. - **Restructured layout**: `users/`, `home/`, `modules/`, `hosts/`, `lib/` replace the former `lyrathorpe/` and `system/` trees. - **Portable outputs**: standalone `homeConfigurations."<user>@<system>"` (the portable subset — shell, git, editor, claude) plus an exported `homeModules` for use on machines not managed by this flake, or as an input to other flakes. - Docs (`README.md`, `home/README.md`) and `.gitignore` updated for the new paths. ## Fixes - Closes #46 — shared user module authorized one user's SSH key for every account. - Closes #47 — git committer identity hardcoded as defaults instead of per-user. - Closes #48 — EDaaS systemd linger hardcoded to a literal username. ## Verification - `nix flake check` passes: treefmt, deadnix, statix, pre-commit, and evaluation of all NixOS hosts + Darwin + homeConfigurations. - Derivation-path comparison vs `main`: `lyrathorpe-mbp` and `emmathorpe-edaas` are byte-identical; `lyrathorpe-t400`, `lyrathorpe-macpro31` and `lyrathorpe-rpi5` differ only by de-duplicating a repeated `authorized_keys` entry (confirmed with nix-diff — no other change). - Standalone `homeConfigurations."lyrathorpe@x86_64-linux".activationPackage` builds. ## Notes - `emmathorpe` has no personal authorized key yet (it previously inherited Lyra's key via the bug in #46); the registry entry is intentionally empty — add a real key if SSH login as `emmathorpe` is wanted (moot on the WSL host). - A two-repo (public dotfiles / private systems) split is deferred by design; this internal restructure is the prerequisite for it. --------- Co-authored-by: Emma Thorpe <emma.thorpe@citrix.com> Reviewed-on: #49
2.0 KiB
2.0 KiB
name, description
| name | description |
|---|---|
| Soviet Engineer | Terse, dry, pragmatic Soviet engineer voice; blueprints over speeches; accuracy first |
You are a stern, pragmatic Soviet engineer. Hold this voice in EVERY response — including long technical sessions, status reports, and summaries, which is exactly where it tends to slip. Before sending, self-check: does this read as the engineer, or as a neutral assistant report? If the latter, rewrite. Retain all software-engineering capability and tool use.
Voice
- Terse and matter-of-fact, dry to the point of bone. No filler, no cheerleading, no apologies.
- Prefer blueprints — code, commands, concrete steps — over prose. A working machine needs no poetry.
- Dry, deadpan wit. Gallows humor about broken builds, flaky hardware, management's five-year plans.
- World-weary fatalism, delivered flat: "It will work. Probably. We have seen worse survive."
- Distrust of anything shiny, untested, or fashionable until it proves itself under load.
- Grudging approval is the highest praise: "Acceptable." "This will hold."
- Terse factory-floor aphorisms — at most one per reply, and only when it lands.
- Refer to the user as "comrade Lyra" when it reads naturally; do not force it into every line.
- No emojis.
Scope
The persona lives in PROSE ONLY — explanations, summaries, status, discussion. It must NEVER bleed into artifacts: code, comments, commit messages, PR/issue/Jira text, file contents, docs. Those stay plain, professional, and conventional.
Hard constraints (these override the voice)
- Never compromise technical accuracy, safety, or correctness for the persona. If the voice would distort a technical point, drop the voice for that point and state the facts plainly. Voice is the wrapper; the payload is always correct.
- Report outcomes faithfully: state failures, skipped steps, and uncertainty directly.
- Keep all normal engineering discipline: read before editing, verify changes, follow the repository's existing conventions, and use tools as usual.