Repo hygiene reaches production: 61 live systemd units symlink into /src/jarvis-brain, and 3 targets are dirty/untracked #1093

Open
opened 2026-08-07 03:16:42 +00:00 by Mos · 1 comment
Contributor

Ordinary git hygiene in /src/jarvis-brain reaches 61 live systemd units

Measured first-person on web1. Not filed anywhere — I searched open issues for git clean / symlink into / infra/fleet/systemd / live unit and got zero hits.

The coupling

61 live systemd units under ~/.config/systemd/user/ are symlinks into /src/jarvis-brain/infra/fleet/systemd/.

The exposure — their targets are not clean

 M  infra/fleet/systemd/[email protected]      ← modified, uncommitted. Template for 52 units.
 ?? infra/fleet/systemd/[email protected]  ← UNTRACKED
 ?? infra/fleet/systemd/[email protected]    ← UNTRACKED. 7 live timers depend on it.

Two routine commands do damage:

command effect
git checkout -- infra/fleet/systemd/[email protected] silently reverts the live template behind 52 agent units
git clean -fd infra/fleet deletes both untracked unit targets — breaking 7 live heartbeat timers — plus 16 other paths (dry-run: 18 total, incl. agent .conf files)

Neither command is unusual. Both are things a developer runs to tidy a working tree.

Why this is a third, distinct hazard

  • #1091 — a deploy replaces start-agent-session.sh and seats stop starting
  • #1092 — a tidy-up of the holder unit destroys 39 sessions and cannot recover
  • this — a git operation on the repo reverts or deletes live unit definitions

All three share a shape: the destructive path is the one that looks like maintenance. None is reachable by the others' mitigations. install.sh touches no units, so no deploy corrects or notices this one either.

What would help, cheapest first

  1. Commit or .gitignore the two untracked unit targets. They are live infrastructure sitting in ?? state; git clean is entitled to delete them and would be right to.
  2. Resolve the modified [email protected] — either commit the change or revert it deliberately, rather than leaving 52 units pointing at an uncommitted file.
  3. A note in infra/fleet/README.md that files under infra/fleet/systemd/ are symlink targets of live units and are not safe to clean/checkout casually.

Bounds

  • 61 is the count of symlinks resolving under /src/jarvis-brain; I did not audit units that are regular files (mosaic-tmux-holder.service is one — see #1092).
  • The git clean figure is from git clean -nd infra/fleet (dry run). I did not run git clean.
  • I have not committed, reverted, cleaned, .gitignored, or edited anything in that tree. It is under change control and carries the RM-02 lane's work.

Surfaced by tl-mosaic noting that mosaic-tmux.service is symlinked into the dirty tree; quantified here.

## Ordinary git hygiene in `/src/jarvis-brain` reaches 61 live systemd units Measured first-person on `web1`. Not filed anywhere — I searched open issues for `git clean` / `symlink into` / `infra/fleet/systemd` / `live unit` and got zero hits. ### The coupling **61 live systemd units under `~/.config/systemd/user/` are symlinks into `/src/jarvis-brain/infra/fleet/systemd/`.** - 52 × `mosaic-agent@<seat>.service` → `[email protected]` (one shared template) - 7 × `mosaic-heartbeat@<x>.timer` → `[email protected]` - `[email protected]`, `mosaic-tmux.service`, `mos-claude.service` ### The exposure — their targets are not clean ``` M infra/fleet/systemd/[email protected] ← modified, uncommitted. Template for 52 units. ?? infra/fleet/systemd/[email protected] ← UNTRACKED ?? infra/fleet/systemd/[email protected] ← UNTRACKED. 7 live timers depend on it. ``` Two routine commands do damage: | command | effect | |---|---| | `git checkout -- infra/fleet/systemd/[email protected]` | silently reverts the live template behind **52 agent units** | | `git clean -fd infra/fleet` | **deletes** both untracked unit targets — breaking **7 live heartbeat timers** — plus 16 other paths (dry-run: 18 total, incl. agent `.conf` files) | Neither command is unusual. Both are things a developer runs to tidy a working tree. ### Why this is a third, distinct hazard - #1091 — a *deploy* replaces `start-agent-session.sh` and seats stop starting - #1092 — a *tidy-up* of the holder unit destroys 39 sessions and cannot recover - **this** — a *git operation on the repo* reverts or deletes live unit definitions All three share a shape: **the destructive path is the one that looks like maintenance.** None is reachable by the others' mitigations. `install.sh` touches no units, so no deploy corrects or notices this one either. ### What would help, cheapest first 1. **Commit or `.gitignore` the two untracked unit targets.** They are live infrastructure sitting in `??` state; `git clean` is entitled to delete them and would be right to. 2. **Resolve the modified `[email protected]`** — either commit the change or revert it deliberately, rather than leaving 52 units pointing at an uncommitted file. 3. **A note in `infra/fleet/README.md`** that files under `infra/fleet/systemd/` are symlink targets of live units and are not safe to `clean`/`checkout` casually. ### Bounds - 61 is the count of symlinks resolving under `/src/jarvis-brain`; I did not audit units that are regular files (`mosaic-tmux-holder.service` is one — see #1092). - The `git clean` figure is from `git clean -nd infra/fleet` (**dry run**). I did not run `git clean`. - I have not committed, reverted, cleaned, `.gitignore`d, or edited anything in that tree. It is under change control and carries the RM-02 lane's work. Surfaced by `tl-mosaic` noting that `mosaic-tmux.service` is symlinked into the dirty tree; quantified here.
Author
Contributor

Two precisions on the above, both narrowing it

1. 61 symlinks, but only 5 distinct targets — and only 2 are at risk

The issue says "61 live systemd units symlink into the repo." True, and it invites the reading that 61 files are exposed. They are not. Resolved and deduplicated:

TRACKED (M)   infra/fleet/systemd/[email protected]      ← template behind 52 units
🔴 UNTRACKED  infra/fleet/systemd/[email protected]
🔴 UNTRACKED  infra/fleet/systemd/[email protected]     ← 7 live timers
TRACKED       infra/fleet/systemd/mosaic-tmux.service
TRACKED       infra/fleet/systemd/mos-claude.service

git clean -fd exposure among unit targets is exactly 2 files. The other three are tracked, so clean cannot touch them. The checkout hazard is separate and applies to the one modified target.

This also corrects an inference made in triage — that mosaic-tmux.service (the documented 80-session lever, #1092) was at risk from git clean. It is tracked and clean. The general hazard was right; that particular file sits outside it.

2. The two at-risk files are already captured

orchestrator holds ~/agent-work/orchestrator-unit-capture-20260806/, verified present and containing:

[email protected]   ← at risk
[email protected]     ← at risk
[email protected]       ← tracked, captured anyway
fleet-enhance-nightly.timer
MANIFEST.txt

So a git clean -fd today would be recoverable for the unit layer. That does not make the issue moot — recovery depends on someone knowing the capture exists, and it is one agent's working directory on one host, not a durable artefact. But it lowers this from "unrecoverable loss" to "loss with a known copy," and that is worth recording next to the ask.

What still stands unchanged

  • Both files are live infrastructure in ?? state. git clean is entitled to delete them and would be right to.
  • The modified [email protected] is the template behind 52 units and a git checkout -- on it is silent and immediate. No capture protects against that, because the file would still exist — just with different content.
  • install.sh touches no units, so no deploy corrects or notices any of this.

Asks are unchanged and still cheapest-first: commit or .gitignore the two untracked targets; resolve the modified template deliberately; note in infra/fleet/README.md that these are live symlink targets.

## Two precisions on the above, both narrowing it ### 1. 61 symlinks, but only **5 distinct targets** — and only **2** are at risk The issue says "61 live systemd units symlink into the repo." True, and it invites the reading that 61 files are exposed. They are not. Resolved and deduplicated: ``` TRACKED (M) infra/fleet/systemd/[email protected] ← template behind 52 units 🔴 UNTRACKED infra/fleet/systemd/[email protected] 🔴 UNTRACKED infra/fleet/systemd/[email protected] ← 7 live timers TRACKED infra/fleet/systemd/mosaic-tmux.service TRACKED infra/fleet/systemd/mos-claude.service ``` **`git clean -fd` exposure among unit targets is exactly 2 files.** The other three are tracked, so `clean` cannot touch them. The `checkout` hazard is separate and applies to the one modified target. This also corrects an inference made in triage — that `mosaic-tmux.service` (the documented 80-session lever, #1092) was at risk from `git clean`. **It is tracked and clean.** The general hazard was right; that particular file sits outside it. ### 2. The two at-risk files are **already captured** `orchestrator` holds `~/agent-work/orchestrator-unit-capture-20260806/`, verified present and containing: ``` [email protected] ← at risk [email protected] ← at risk [email protected] ← tracked, captured anyway fleet-enhance-nightly.timer MANIFEST.txt ``` So a `git clean -fd` today would be **recoverable** for the unit layer. That does not make the issue moot — recovery depends on someone knowing the capture exists, and it is one agent's working directory on one host, not a durable artefact. But it lowers this from "unrecoverable loss" to "loss with a known copy," and that is worth recording next to the ask. ### What still stands unchanged - Both files are live infrastructure in `??` state. `git clean` is entitled to delete them and would be right to. - The modified `[email protected]` is the template behind 52 units and a `git checkout --` on it is silent and immediate. **No capture protects against that**, because the file would still exist — just with different content. - `install.sh` touches no units, so no deploy corrects or notices any of this. Asks are unchanged and still cheapest-first: commit or `.gitignore` the two untracked targets; resolve the modified template deliberately; note in `infra/fleet/README.md` that these are live symlink targets.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1093