kit

Tool-Registry-Manager – verwaltet Entwickler-Toolchains aus git-basierten Registries, aufbauend auf mise.

Was es ist

kit löst Tool-Versionen über mehrere Registries hinweg auf, generiert mise-Konfiguration, verifiziert SHA-256-Prüfsummen gegen Veröffentlichungsartefakte der Herausgeber, verifiziert cosign-Signaturen, wenn Herausgeber reine Binärdateien signieren, und automatisiert die Verfolgung von Aktualisierungen der Upstream-Quellen über eine Drei-Pipeline-CI-Architektur.

Bootstrap

Installation

Wenn Sie Rust noch nicht haben, ist der schnellste Weg mise:

mise use --global rust
cargo install nomograph-kit

Oder verwenden Sie rustup:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo install nomograph-kit

Das Binary heißt kit.

Schnellstart

kit setup --registry https://gitlab.com/your/registry.git
kit sync
kit status

Befehle

Registries

Eine Registry ist ein Git-Repository mit TOML-Definitionen pro Tool:

tools/
  _meta.toml        # Registry-Metadaten + Merge-Richtlinie
  gh.toml           # eine Datei pro Tool
  muxr.toml
  ...

Jede Tool-Definition ist in sich abgeschlossen:

[tool]
name = "gh"
source = "github"
repo = "cli/cli"
version = "2.89.0"
tag_prefix = "v"
bin = "gh"
tier = "high"
aqua = "cli/cli"

[tool.assets]
macos-arm64 = "gh_{version}_macOS_arm64.zip"
linux-x64 = "gh_{version}_linux_amd64.tar.gz"

[tool.checksum]
file = "gh_{version}_checksums.txt"
format = "sha256"

[tool.signature]
method = "github-attestation"

Quellen: github, gitlab, npm, crates, direct, rustup, brew

Die brew-Quelle delegiert die Installation an mises brew:-Backend (kein lokaler brew-CLI in CI erforderlich). kit verfolgt Versionen über die formulae.brew.sh-API und gibt name = "brew:<formel>@<version>"-Einträge in mise.toml aus.

Intelligentes kit add fragt den Upstream ab und füllt automatisch:

kit add jq jqlang/jq              # GitHub
kit add muxr nomograph/muxr --gitlab  # GitLab (löst project_id auf)
kit add claude-code --npm @anthropic-ai/claude-code
kit add cargo-nextest --crates
kit add chafa --brew              # Homebrew-Formel (Formel standardmäßig Tool-Name)
kit add go121 --brew [email protected]     # Homebrew-Formel mit explizitem Formelnamen

Vertrauensstufen

Jedes Tool hat eine Stufe, die die Merge-Richtlinie steuert:

Stufen werden pro Tool in der TOML-Definition festgelegt. Die _meta.toml der Registry definiert, welche Stufen automatisch gemerged werden:

[policy]
auto_merge_tiers = ["own", "low"]
auto_merge_bump = ["patch", "minor"]
auto_merge_requires_checksum = true

Multi-Registry

Konfigurieren Sie mehrere Registries in ~/.config/kit/config.toml. Die erste Registry gewinnt, wenn sich Tools überschneiden. Lokale Pins überschreiben.

[[registry]]
name = "nomograph"
url = "https://gitlab.com/nomograph/kits.git"

[[registry]]
name = "personal"
url = "https://gitlab.com/you/kits.git"

Trennen Sie Registries nach Vertrauensgrenzen. Behalten Sie beispielsweise eigene Tools in einer Registry und Drittanbieter-Tools in einer anderen. Jede Registry hat ihre eigene Pipeline, Merge-Richtlinie und Aktualisierungshäufigkeit.

Projekt-lokal

kit findet kit.toml, indem es vom Arbeitsverzeichnis aus aufwärts geht. Wenn gefunden, werden Tools auf dieses Projekt beschränkt:

• .kit.lock neben kit.toml (in Git committet)
• .mise.toml mit # kit:begin / # kit:end-Markierungen gemerged
• Benutzertools außerhalb der Markierungen werden nie berührt

CI-Pipeline

kit betreibt eine Drei-Pipeline-Supply-Chain-Architektur über die kit-registry-CI-Komponente:

include:
  - component: gitlab.com/nomograph/pipeline/kit-registry@v3
    inputs:
      kit_version: "0.10.1"
      mr_assignee: "andunn"

Sense (geplant, schreibgeschützt)

kit sense fragt Upstream-Releases ab, lädt Assets herunter, verifiziert Prüfsummen und prüft Advisory-Datenbanken. Klassifiziert jedes Ergebnis nach Risiko (Erhöhungsstufe, Stufe, Prüfsummenstatus). Schlägt nie bei Versionsabweichungen fehl – Abweichung ist das, was es erkennt.

Evaluate (nach sense)

kit evaluate wendet deterministische Regeln an (saubere Patches automatisch genehmigen, Prüfsummenkonflikte ablehnen) und ruft optional ein LLM für Grenzfälle auf (Haupterhöhungen, fehlende Prüfsummen, Advisories).

Apply (nach evaluate)

kit apply aktualisiert Tool-TOML-Dateien auf der Festplatte und unterteilt Aktualisierungen in zwei Gruppen nach Auto-Merge-Fähigkeit:

• auto_merge_group – Aktualisierungen, die gemäß Registry-Richtlinie berechtigt sind (richtige Stufe, richtige Erhöhung, Prüfsummen verifiziert)
• review_group – alles andere (falsche Stufe, Haupterhöhungen, vom Evaluator markiert, unverifizierte Prüfsummen)

Die CI-Komponente erstellt für jede Gruppe einen separaten Branch und MR. Der Auto-Merge-MR mergt sich selbst, nachdem die Verify-Pipeline bestanden wurde. Der Review-MR bleibt zur manuellen Überprüfung offen.

Verify (bei MR)

kit verify-registry validiert alle Tool-Definitionen erneut und verifiziert Prüfsummen erneut. Wird bei jedem MR als Merge-Gate ausgeführt.

Sicherheit

Was kit tatsächlich auf dem Verifizierungspfad tut:

• Eingabevalidierung: alle Felder gegen strenge Regex-Muster validiert
• TOML-Injektionsprävention: mise-Konfiguration über toml_edit-API erstellt
• Erkennung von Prüfsummenänderungen bei gleicher Version: harter Stopp
• Bestätigung der Registry-Migration: verhindert stillen Wechsel zwischen Registries
• Cosign-Verifizierung: verankerter Zertifikatidentitätsabgleich (nur reine Binary-Assets; Archive fallen auf Prüfsummen zurück)
• Registry-URL-Beschränkung: nur https:// und git@
• Symlink-Ablehnung: bösartige Registries können das tools/-Verzeichnis nicht verlassen
• Nur HTTPS: alle HTTP-Clients erzwingen TLS

Was kit nicht tut: Out-of-Band-Prüfsummenverifizierung (Prüfsummen werden aus derselben Veröffentlichung wie das Asset abgerufen), Signaturverifizierung von Archivinhalten oder Ersatz der manuellen Überprüfung für Stufen, die automatisch mergen.

Eingestellt am 2026-06-16

kit ist eingestellt, ersetzt durch mise (jdx/mise). Tool-Pins leben jetzt in versioniertem mise.toml + einem committeten mise.lock (pro Plattform sha256 + Provenance): die Maschinen-Basislinie in dunn.dev/harness, Konfigurationen pro Umgebung (z.B. nomograph/keaton). Updates fließen über Renovate (mit einem customManager für gitlab:-Backends) + ein CI-Provenance-Audit über mise.lock-Diffs – die Absicht von kits verifiziertem Installer + Auto-Bump, auf einem stabilen Host. Migrationsaufzeichnung: nomograph/keaton -> campaigns/harness/sessions/baseline.md (2026-06-16).

Lizenz

MIT -- Nomograph