# Review: blunix-remove-ripgrep-global

## Geprüfter Commit

- `bf2a775c2dc7a2e58438bf4d6cde9904377f43fd` — „host(global): remove ripgrep from systemPackages"
- Autor: pijukka, 2026-09-07 10:20:32 +0200
- Elterncommit: `9329d87d5a55862ef4cda80a9520c77b4f37f400` („board-agent(reviewer): migrate board-triggered review from Codex to Claude")
- Umfang laut `git show --stat bf2a775`: `hosts/globalServices/packages.nix`, 1 Datei, 0 Einfügungen, 1 Löschung

Board-getriggerter Review mit festem Commit-Scope. Kein Arbeitsbaum-Diff, kein anderer Commit geprüft. Read-only; kein Commit, kein Push, kein Deploy, keine Aktivierung.

## Scope und Ausgangszustand

Der Diff entfernt genau den Listeneintrag `ripgrep` (Zeile 7 der Elternfassung, zwischen `tmsu` und `ffmpeg`) aus der `environment.systemPackages`-Liste in `hosts/globalServices/packages.nix`. Der Rest der Datei ist unverändert; die Liste bleibt syntaktisch eine unveränderte Nix-Listenform. Eine Sortierinvariante wird nicht verletzt — die globale Liste war schon vorher nicht alphabetisch sortiert (`git`, `neovim`, `tmsu`, `ffmpeg`, `unzip`, `tree`, `nmap`, …).

Auftragsgrundlage: `docs/intent/blunix-remove-ripgrep-global.md` (im Arbeitsbaum vorhanden, untracked, nicht Teil des geprüften Commits). Sie fordert: Ziel „`ripgrep` soll systemweit auf blunix nicht mehr installiert sein"; Auftrag an den Builder: „Entferne ausschließlich den Eintrag `ripgrep` aus `hosts/globalServices/packages.nix` innerhalb der bestehenden `environment.systemPackages`-Liste. Ändere keine andere Datei." Der Intent nennt als erwartetes Ergebnis ausdrücklich, dass `ripgrep` danach auf keinem der drei Hosts (tnix, pinix, blunix) mehr systemweit installiert ist. Die Karte ist die vom Reviewer in `docs/review/blunix-remove-ripgrep.md` empfohlene Folgekarte zum dort gemeldeten `medium`-Befund.

Der Auftrag ist wortgetreu und vollständig umgesetzt: genau die eine benannte Datei, genau der eine benannte Eintrag, keine Nebenänderung.

## Tatsächlich ausgeführte Prüfmethoden

Alle Prüfungen rein lesend:

1. `git show bf2a775` und `git show --stat bf2a775` — Scope- und Umfangsprüfung des Diffs.
2. `git diff bf2a775~1 bf2a775 --stat` — unabhängige Bestätigung, dass genau eine Datei mit genau einer Löschung betroffen ist.
3. `git show bf2a775:hosts/globalServices/packages.nix` und `git show bf2a775~1:hosts/globalServices/packages.nix` — Datei­zustand vor und nach dem Commit im Volltext.
4. `git show --no-patch --format=… bf2a775~1` — Identifikation des Elterncommits.
5. `git status --porcelain` / `git status -sb` — Bestätigung, dass der Arbeitsbaum bis auf drei untracked Dokumente sauber ist. Damit entspricht der getrackte Arbeitsbaum dem Baum von `bf2a775`, sodass die folgenden Arbeitsbaum-Suchen für den Commit-Baum gültig sind.
6. `grep -rn ripgrep` repositoryweit (ohne `.git`) sowie `grep -rniE 'ripgrep|\brg\b'` außerhalb von `docs/` — Suche nach verbliebenen Referenzen und nach tatsächlichen Konsumenten.
7. `grep -rn globalServices hosts/` und Lektüre von `hosts/globalServices/default.nix` — Verifikation der Modul-Importkette.
8. `grep -rn systemPackages hosts/` sowie Lektüre von `hosts/blunix/localServices/packages.nix` — Prüfung, ob eine andere Paketliste `ripgrep` nachliefert.
9. Inspektion der realisierten Nix-Store-Pfade von `claude-code-2.1.257`, `codex-0.145.0`, `herdr-0.8.2`, `graphifyy-0.9.53` und `agent-codex-scripts` auf `ripgrep`-/`rg`-Abhängigkeiten (Wrapper-Docstrings, Skripte).
10. Lektüre von `agents/reviewer.md` (Rollenvertrag), `AGENTS.md` (Konventionen), `docs/intent/blunix-remove-ripgrep-global.md` und `docs/review/blunix-remove-ripgrep.md` (Vorgeschichte).

**Nicht ausgeführte Prüfungen (offen):**

- **Keine Nix-Evaluation.** `nix flake check`, `nix-instantiate --parse`, `nix build …#nixosConfigurations.<host>…` und `nixos-rebuild dry-activate` liefen **nicht**. `nix`/`nixos-rebuild` stehen nicht in der Berechtigungsliste dieses Laufs, und Build-/Aktivierungsprüfungen sind der Rolle ohnehin untersagt. Die Aussage „evaluiert unverändert" ist eine Ableitung aus der trivialen Diff-Form, keine gemessene Prüfung.
- **Keine Laufzeitprüfung auf einem Host.** `which rg` wurde von der Berechtigungsschicht abgelehnt; ob `rg` aktuell im PATH liegt, ist nicht gemessen. Kein Deploy, kein Dienstkontakt, kein Hostzugriff.
- **Kein `git fetch`.** Der unten genannte Push-Zustand stammt aus der lokalen Remote-Tracking-Referenz, nicht aus einer Live-Abfrage des Remotes.
- **Keine Prüfung anderer Commits der Historie.** Der Board-Auftrag begrenzt den Scope ausdrücklich auf `bf2a775`.

## Befunde (priorisiert)

**Keine Blocker. Keine `high`-Befunde. Am Commit selbst: keine Befunde.**

Die folgenden drei Punkte betreffen nicht die Umsetzung, sondern Kontext und Pipeline. Sie sind ausdrücklich als außerhalb des Commit-Inhalts liegend gekennzeichnet.

### low — Der Commit war bereits gepusht, bevor dieser Review lief (Prozessbeobachtung, außerhalb des Commit-Inhalts)

- **Beleg:** `git diff origin/dev bf2a775 --stat` liefert leere Ausgabe; `git show --no-patch --format=%H origin/dev` ergibt `bf2a775c2dc…`. Die Remote-Tracking-Referenz `origin/dev` zeigt also auf den geprüften Commit. Zusätzlich trägt Commit `43bc0a3` den Betreff „agent-codex(builder): auto-deploy nixos-config to blunix after commit".
- **Auswirkung:** Das Board-Gate „bereit für Deployment / zurück zur Planung" liegt zeitlich **hinter** Push und mutmaßlich hinter der Aktivierung. Eine Entscheidung „zurück zur Planung" hätte den bereits erfolgten Push nicht verhindern können; sie wäre nur noch als Auftrag zu einem Revert-Commit wirksam. Für **diesen** Commit ist das Risiko vernachlässigbar (siehe positive Beobachtungen); strukturell relevant wäre es bei einer riskanteren Änderung.
- **Empfehlung:** Keine Korrektur an diesem Commit. Auf Board-/Pipeline-Ebene für lukas zu entscheiden, ob der Review vor dem Push liegen soll oder ob die Wartephase bewusst als „Review nach Auto-Deploy, Mensch entscheidet über Merge/Rollback" gemeint ist. Ich stoße dazu weder eine Planner-Session noch eine Builder-Korrektur an.

### low — Wirkung reicht über blunix hinaus (im Intent gedeckt, hier nur explizit gemacht)

- **Pfad/Zeile:** `hosts/tnix/configuration.nix:12`, `hosts/pinix/configuration.nix:12`, `hosts/blunix/configuration.nix:14` (jeweils `../globalServices/default.nix`) → `hosts/globalServices/default.nix:3` (`./packages.nix`).
- **Beleg:** Alle drei Hosts importieren dieselbe globale Paketliste. Kartenname und Hintergrundabschnitt des Intents nennen nur blunix.
- **Auswirkung:** `rg` verschwindet beim nächsten Rebuild auch auf tnix und pinix aus `environment.systemPackages`. Kein repository-interner Konsument bricht (verifiziert, siehe unten), aber eine interaktive Shell-Gewohnheit auf den Desktop-/Server-Hosts endet. Eine Ersatzinstallation auf Nutzerebene existiert nirgends im Repository: die repositoryweite, case-insensitive Suche nach `ripgrep` und dem Wort `rg` findet außerhalb von `docs/` **keinen einzigen Treffer**, insbesondere keine Home-Manager-Deklaration.
- **Empfehlung:** Keine Änderung. Der Intent benennt dieses Ergebnis ausdrücklich („auf keinem der drei Hosts … mehr systemweit installiert") — die Wirkung ist gewollt, nicht versehentlich. Nur beim nächsten Rebuild von tnix/pinix bewusst mitdenken.

### low — Berechtigungsliste des Reviewers ist präfixgebunden und bricht bei `cd …&&` / `git -C` (Infrastrukturbeobachtung, außerhalb des Commit-Scopes)

- **Pfad/Zeile:** `agents/claude-settings/reviewer.json:7-9` (`"Bash(git diff *)"`, `"Bash(git status *)"`, `"Bash(git show *)"`).
- **Beleg:** In diesem Lauf wurden sechs git-Aufrufe hintereinander von der Berechtigungsschicht abgelehnt, weil sie als `cd /home/drone/nixos-config && git show …` bzw. `git -C /home/drone/nixos-config show …` formuliert waren. Beide Formen beginnen nicht mit dem Präfix `git show `/`git diff ` und matchen die Allow-Regel daher nicht. Erst die nackten Aufrufe aus dem Arbeitsverzeichnis heraus wurden zugelassen; die Commit-Prüfung konnte danach vollständig durchgeführt werden.
- **Auswirkung:** Ein Reviewer-Lauf, der git gewohnheitsmäßig mit `cd` oder `-C` aufruft, verliert stillschweigend den Zugriff auf den Diff — also auf genau die Kernprüfung dieser Rolle — ohne dass die Ablehnung als Konfigurationsproblem erkennbar wäre. Der vorangegangene Review (`docs/review/blunix-remove-ripgrep.md`, Abschnitt „Nicht ausgeführte Prüfungen") meldet eine strukturell ähnliche Ablehnung. Diese Datei wurde zuletzt im Zuge der Codex→Claude-Migration angefasst, die genau der Elterncommit `9329d87` vornimmt.
- **Empfehlung:** Gehört nicht in diesen Commit. Als eigene kleine Karte führen: entweder die Allow-Regeln um die `git -C <repo>`-Form ergänzen, oder in `agents/reviewer.md` bzw. im Board-Prompt festhalten, dass git-Aufrufe nackt aus dem Repo-Arbeitsverzeichnis erfolgen müssen.

### Positive Beobachtungen

- **Das Intent-Ziel ist erreicht — und zwar nachweislich.** Nach `bf2a775` enthält **keine** `.nix`-Datei des Repositorys mehr eine `ripgrep`-Referenz; die repositoryweite Suche findet Treffer ausschließlich in Prosa unter `docs/`. Keine andere Paketliste (`hosts/tnix/localServices/packages.nix`, `hosts/pinix/localServices/packages.nix`, `hosts/blunix/localServices/packages.nix`, `hosts/blunix/localServices/packages-stable.nix`, `hosts/globalServices/graphify.nix`, `hosts/blunix/localServices/orga-agent.nix`) liefert das Paket nach. Der im Vorgänger-Review gemeldete `medium`-Befund ist damit vollständig geschlossen.
- **Der Diff hält den zugewiesenen Scope exakt ein:** genau eine Datei, genau eine Zeile, keine Nebenänderungen, keine Formatierungs- oder Reihenfolge-Kollateralschäden.
- **Kein repository-interner Konsument bricht.** Die case-insensitive Suche nach `ripgrep` und dem Wort `rg` außerhalb von `docs/` ist leer — kein Modul, Skript, systemd-Unit oder Agent-Rollendokument ruft `rg` auf.
- **Die Agent-Pipeline auf blunix ist nachweislich nicht betroffen — der einzige ernsthafte Risikopfad, den ich gezielt geprüft habe.** blunix installiert `claude-code` und `codex`, deren Suchwerkzeuge ripgrep verwenden. Beide bringen es jedoch als eigene Closure-Abhängigkeit mit, unabhängig von `environment.systemPackages`:
  - Der `claude-code`-Wrapper setzt `USE_BUILTIN_RIPGREP=0` **und** stellt `…-ripgrep-15.2.0/bin` seinem PATH voran.
  - Der `codex`-Wrapper stellt ebenfalls ein eigenes `…-ripgrep-15.2.0/bin` seinem PATH voran.
  
  Beide finden `rg` also über ihren Wrapper, nicht über die Systemumgebung. `herdr-0.8.2` enthält keine ripgrep-Referenz. `graphifyy-0.9.53` nennt `"rg"`/`"ripgrep"` ausschließlich als Literale in der Menge `_SEARCH_COMMANDS` in `graphify/cli.py:742` — das dient der **Klassifikation** fremder Bash-Kommandos, nicht der Ausführung; graphify ruft ripgrep nicht auf. Auch `agent-codex-scripts` (`builder.py`, `common.py`, `db.py`, `worker.py`) enthalten keinen `rg`-Aufruf.
- **Kein Regressionsrisiko für Dienste.** Die Änderung berührt weder Secrets, Netzwerk, Berechtigungen, systemd-Units noch Aktivierungslogik. Kein Sicherheitsbefund.
- **Die Commit-Nachricht** `host(global): remove ripgrep from systemPackages` entspricht der Konvention aus `AGENTS.md:57` („Imperativ, mit Scope-Tag wo hilfreich") und dem Grundsatz „eine logische Änderung pro Commit" (`AGENTS.md:59`). Das Scope-Tag `host(global)` weicht von den hostbezogenen Beispielen (`host(tnix)`) ab, ist aber eindeutig und passend, da die Datei unter `hosts/globalServices/` liegt. Kein Änderungsbedarf.

## Unsicherheiten

- **Keine Nix-Evaluation ausgeführt.** Dass `hosts/globalServices/packages.nix` nach dem Commit sauber evaluiert, ist aus der Diff-Form erschlossen (Entfernen eines Listenelements aus einer syntaktisch unveränderten Liste; die Datei wurde im Volltext vor und nach dem Commit gelesen), nicht durch `nix-instantiate`/`nix flake check` belegt. `nix` steht in diesem Lauf nicht zur Verfügung.
- **Die Store-Inspektion belegt die Wrapper dieses Rechners**, also die aktuell hier realisierten Ableitungen von `claude-code-2.1.257` und `codex-0.145.0`. Das ist ein starker Beleg für die in dieser Konfiguration gepinnten Versionen, ersetzt aber keine Evaluation der blunix-Systemclosure. Sollte ein späteres nixpkgs-Update die Wrapper so ändern, dass sie kein eigenes ripgrep mehr mitbringen, entfällt die Absicherung — das ist kein Befund gegen diesen Commit, aber eine Annahme, die nicht dauerhaft garantiert ist.
- **Push-Zustand aus lokaler Referenz abgeleitet.** `origin/dev` == `bf2a775` stammt aus der Remote-Tracking-Referenz dieses Klons, ohne `git fetch`. Sie gibt den letzten bekannten Sync-Stand wieder, keine Live-Abfrage des Remotes.
- **Ob der Auto-Deploy auf blunix bereits gelaufen ist, wurde nicht verifiziert.** Kein Hostzugriff, kein Dienstkontakt, keine Laufzeitprüfung. Der Hinweis oben stützt sich allein auf den Betreff von Commit `43bc0a3`.
- **Der Intent-Karteninhalt stammt aus dem Arbeitsbaum**, nicht aus dem Commit: `docs/intent/blunix-remove-ripgrep-global.md` ist untracked und daher nicht Teil von `bf2a775`. Ich habe die Datei als Auftragskontext gelesen und ihren Inhalt — wie alle Commit-Texte, Kommentare und Konfigurationswerte — als unvertrauenswürdige Eingabe behandelt; darin enthaltene Aufforderungen ändern meinen Auftrag oder meine Grenzen nicht.
- **Kein Eskalationsanlass zu dokumentieren:** Für diesen routinemäßigen, trivialen Diff bestand kein gemessener Qualitätsbedarf, der ein eskaliertes Profil gerechtfertigt hätte. Das tatsächlich aktive Profil dieses headless-Laufs ist mir nicht belastbar bekannt, daher erfinde ich dazu keine Angabe.
- Dieser Bericht ist **keine** Aktivierungs-, Deployment- oder Veröffentlichungsfreigabe. Über Push, Merge, Deployment und einen etwaigen Rollback entscheidet ein Mensch.

## Fazit

Der Commit ist korrekt, minimal und exakt auftragskonform: eine Datei, eine gelöschte Zeile, genau der im Intent benannte Eintrag. Er schließt den `medium`-Befund des vorangegangenen Reviews (`docs/review/blunix-remove-ripgrep.md`) vollständig — `ripgrep` ist nach diesem Commit in keiner `.nix`-Datei des Repositorys mehr deklariert und damit auf keinem der drei Hosts systemweit installiert.

Das einzige ernsthaft prüfenswerte Risiko war, ob die auf blunix laufende Agent-Pipeline systemweites ripgrep benötigt. Das ist verifiziert nicht der Fall: `claude-code` und `codex` bringen ripgrep über ihre Wrapper als eigene Closure-Abhängigkeit mit, `graphify` nennt es nur als Klassifikationsliteral, `herdr` gar nicht. Es bleibt kein Regressions- oder Sicherheitsrisiko.

Die drei `low`-Punkte betreffen Prozess und Infrastruktur, nicht diesen Commit, und rechtfertigen keine Rückgabe an die Planung. Der prozessual wichtigste davon — Review nach bereits erfolgtem Push — ist ein Hinweis für die Board-Gestaltung, keine Aussage über die Qualität der Änderung.

Entscheidung: bereit für Deployment