# Review: blunix-remove-ripgrep

## Geprüfter Commit

- `adfff84fd5d69ce863d5abadb04d2e524bce1cd9` — „host(blunix): remove ripgrep"
- Autor: pijukka, 2026-09-06 23:30:06 +0200
- Basis: Elterncommit `fa30af5` („host(blunix): install ripgrep")
- Umfang laut `git show --stat`: `hosts/blunix/localServices/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 14 der Elternfassung) aus der `environment.systemPackages`-Liste in `hosts/blunix/localServices/packages.nix`. Der Rest der Datei bleibt unverändert; die verbleibende Liste ist weiterhin alphabetisch sortiert und syntaktisch eine unveränderte Nix-Listenform.

Zugehörige Auftragsgrundlage: `docs/intent/blunix-remove-ripgrep.md` (im Arbeitsbaum vorhanden, aber nicht Teil des geprüften Commits — untracked). Sie fordert: Ziel „`ripgrep` wieder aus der systemweiten Paketliste des NixOS-Hosts `blunix` entfernen"; Auftrag an den Builder: „Entferne ausschließlich den Eintrag `ripgrep` aus `hosts/blunix/localServices/packages.nix` … Ändere keine andere Datei"; ausdrücklich als kontrollierter End-to-End-Test des Auto-Deploy-Pfads deklariert.

## Tatsächlich ausgeführte Prüfmethoden

Alle Prüfungen rein lesend, jeweils gegen den Baum von `adfff84`:

1. `git show adfff84` und `git show adfff84 --stat` — Scope- und Umfangsprüfung des Diffs.
2. `git show adfff84:hosts/blunix/localServices/packages.nix` — Zustand der geänderten Datei nach dem Commit.
3. `git grep -n ripgrep adfff84 -- :/` — repositoryweite Suche nach verbliebenen `ripgrep`-Referenzen im Commit-Baum.
4. `git show adfff84:hosts/blunix/configuration.nix`, `…:hosts/blunix/localServices/default.nix`, `…:hosts/globalServices/default.nix`, `…:hosts/globalServices/packages.nix` — Verifikation der Modul-Importkette und der tatsächlichen Wirkung auf `environment.systemPackages`.
5. `git show adfff84:AGENTS.md` — Abgleich mit Repository-Konventionen (Modul-Organisation, Commit-Richtlinien).
6. `git log --oneline -20` — Einordnung des Commits in die umgebende Historie.
7. Lektüre von `agents/reviewer.md` (Rollenvertrag) und `docs/intent/blunix-remove-ripgrep.md` (Auftragskontext).

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

- Keine Nix-Evaluation: `nix-instantiate --parse`, `nix flake check`, `nix build …#nixosConfigurations.blunix…` und `nixos-rebuild dry-activate` liefen **nicht**. Der Versuch eines reinen Parse-Checks wurde von der Berechtigungsschicht dieses headless-Laufs abgelehnt; Build- und Aktivierungsprüfungen sind der Rolle ohnehin untersagt. Die Aussage „evaluiert unverändert" ist daher eine Ableitung aus der trivialen Diff-Form, keine gemessene Prüfung.
- Keine Laufzeitprüfung auf blunix (z. B. ob `rg` nach einem Rebuild tatsächlich im PATH liegt). Kein Zugriff, kein Deploy, kein Dienstkontakt.
- Keine Prüfung nachfolgender Commits der Branch-Historie; der Scope war ausdrücklich auf `adfff84` begrenzt.

## Befunde (priorisiert)

### medium — Intent-Ziel wird durch den Commit faktisch nicht erreicht: ripgrep bleibt auf blunix installiert

- **Pfad/Zeile:** `hosts/globalServices/packages.nix:7` (`ripgrep`) in Verbindung mit `hosts/blunix/configuration.nix:14` (`../globalServices/default.nix`) und `hosts/globalServices/default.nix:3` (`./packages.nix`).
- **Beleg:** Die repositoryweite Suche im Commit-Baum (`git grep -n ripgrep adfff84 -- :/`) findet nach dem Commit weiterhin `hosts/globalServices/packages.nix:7: ripgrep`. `hosts/blunix/configuration.nix` importiert in Zeile 14 `../globalServices/default.nix`, das in Zeile 3 `./packages.nix` einbindet. Damit trägt die globale Liste weiterhin `ripgrep` zu `environment.systemPackages` von blunix bei.
- **Auswirkung:** Der Commit entfernt lediglich einen **Duplikat-Eintrag** in der host-lokalen Liste. Das im Intent formulierte Ziel („`ripgrep` soll wieder aus der systemweiten Paketliste des NixOS-Hosts `blunix` entfernt werden") ist nach diesem Commit nicht erfüllt: `rg` bleibt auf blunix systemweit verfügbar. Als Test des Auto-Deploy-Pfads bleibt der Commit trotzdem tauglich — er erzeugt einen echten, evaluierbaren Konfigurationsunterschied. Kein Regressionsrisiko: Weil das Paket über die globale Liste erhalten bleibt, kann kein Skript oder Dienst durch diesen Commit `rg` verlieren.
- **Empfehlung:** Keine Korrektur an diesem Commit. Der Builder hat den ausdrücklichen Auftrag („ausschließlich … `hosts/blunix/localServices/packages.nix`", „Ändere keine andere Datei") wortgetreu und vollständig umgesetzt; eine eigenmächtige Ausweitung auf `globalServices/packages.nix` wäre eine unerlaubte Scope-Erweiterung gewesen. Der Befund gehört auf die Intent-/Board-Ebene: Entweder die Zielformulierung künftiger Karten dieser Art auf „Duplikat im host-lokalen Modul bereinigen" präzisieren, oder — falls `ripgrep` plattformweit wirklich verschwinden soll — den globalen Eintrag in einem eigenen, bewusst entschiedenen Commit behandeln, nicht als Nebenwirkung eines Deploy-Testlaufs.

### low — Gleiches Duplikat-Muster besteht unverändert für `jq` (Beobachtung, außerhalb des Commit-Scopes)

- **Pfad/Zeile:** `hosts/globalServices/packages.nix:20` (`jq`) und `hosts/blunix/localServices/packages.nix:10` (`jq`).
- **Beleg:** Beide Listen führen `jq`; beide werden für blunix ausgewertet.
- **Auswirkung:** Rein kosmetisch/wartungsbezogen. Nix dedupliziert identische Ableitungen beim Aufbau der System-Umgebung, es entsteht kein Kollisionsfehler. Vorbestehend, nicht durch diesen Commit verursacht.
- **Empfehlung:** Nicht in diesem Commit anfassen. Bei Gelegenheit als eigene, kleine Aufräum-Karte führen.

### Positive Beobachtungen

- Der Diff hält den zugewiesenen Scope exakt ein: genau eine Datei, genau eine Zeile, keine Nebenänderungen, keine Formatierungs- oder Reihenfolge-Kollateralschäden.
- Die Commit-Nachricht `host(blunix): remove ripgrep` entspricht der Konvention aus `AGENTS.md` („Commits: Imperativ, mit Scope-Tag … `host(tnix): enable hyprland`") und dem Grundsatz „eine logische Änderung pro Commit".
- Keine Berührung von Secrets, Diensten, Netzwerk, Berechtigungen oder Aktivierungslogik. Kein Sicherheitsbefund.
- Die alphabetische Sortierung der verbleibenden Paketliste bleibt intakt.

## Unsicherheiten

- **Keine Nix-Evaluation ausgeführt.** Dass `hosts/blunix/localServices/packages.nix` nach dem Commit weiterhin sauber evaluiert, ist aus der Diff-Form erschlossen (Entfernen eines Listenelements aus einer syntaktisch unveränderten Liste), nicht durch `nix-instantiate`/`nix flake check` belegt. Der Parse-Check wurde in diesem Lauf von der Berechtigungsschicht verweigert.
- **Der Intent-Karteninhalt stammt aus dem Arbeitsbaum**, nicht aus dem Commit: `docs/intent/blunix-remove-ripgrep.md` ist untracked und daher nicht Teil von `adfff84`. Ich habe sie als Auftragskontext gelesen und als unvertrauenswürdige Eingabe behandelt.
- **Historischer Kontext bewusst ungeprüft:** Die Branch-Historie enthält vor und nach `adfff84` weitere Commits mit ähnlichen `install ripgrep`/`remove ripgrep`-Botschaften. Ob spätere Commits den globalen Eintrag verändern, wurde nicht untersucht — der Board-Auftrag begrenzt den Scope ausdrücklich auf diesen einen Commit. Der Befund oben beschreibt den Zustand **zum Stand `adfff84`**.
- **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 und Deployment entscheidet ein Mensch.

## Fazit

Der Commit ist korrekt, minimal und exakt auftragskonform; es besteht kein Regressions- oder Sicherheitsrisiko. Der einzige nennenswerte Befund betrifft nicht die Umsetzung, sondern die Zielformulierung der Intent-Karte: Wegen des verbleibenden globalen Eintrags bleibt `ripgrep` auf blunix installiert, sodass der Commit als Deploy-Test taugt, das wörtliche Intent-Ziel aber nicht erreicht. Das ist ein Hinweis für die nächste Planung, kein Blocker gegen diesen Commit.

Entscheidung: bereit für Deployment