nixos-config/docs/review/blunix-remove-ripgrep-global.md

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