Dev-Modus — das Setup aus einem Checkout fahren

Der Dev-Modus fährt deinen lokalen onedot-devkit-Checkout als aktives Setup statt des signierten Release. Nutze ihn, wenn du einen Skill, eine Rule, einen Hook, ein Script oder die CLI änderst und das Ergebnis in einer echten Session sehen willst, bevor ein Release existiert.

Die Runtime bleibt dieselbe: ~/.onedot-devkit/current zeigt auf ein Versionsverzeichnis, und jede Session löst Skills, Hooks und Scripts über diesen Link auf. Der Dev-Modus ändert nur, woher diese Version kommt.

Einmal einrichten

1. Repository klonen: git clone git@github.com:onedot-digital-crew/onedot-devkit.git ~/Sites/onedot-devkit
2. Quelle darauf zeigen lassen: devkit config source-local ~/Sites/onedot-devkit — oder aus dem Klon heraus mit DEVKIT_SOURCE_LOCAL=1 bash install.sh installieren; das behält die lokale Quelle, statt auf den signierten Endpunkt zu wechseln.
3. Erste Dev-Version bauen: devkit maint dev-sync
4. Neue Claude-Session starten. Die Statuszeile zeigt die Version als <base>-dev@<sha7>.

devkit status nennt die Quelle, ein Rechner, der unerwartet auf einem Checkout läuft, ist dort sichtbar.

Täglicher Loop

bash

devkit maint dev-sync              # committeter HEAD, der Default
devkit maint dev-sync --worktree   # Arbeitsbaum, inklusive uncommitteter Edits

Eine Dev-Version wirkt in der nächsten Session. Eine laufende Session behält die Pfade, die sie beim Start aufgelöst hat, unter ihr ändert sich nichts.

devkit maint dev-sync baut den committeten Stand, kompiliert das Rust-Binary (cargo build --release -p devkit) und liefert es als bin/devkit der Version aus, genau wie ein Release.

Ist eine Payload-Datei (content/, hooks/, keys/) oder eine Rust-Quelle (rust/) nicht committet, stoppt der Lauf mit Exit 2 und nennt die Dateien, statt Erfolg zu melden — eine Warnung neben einer grünen Zeile liest sich als Notiz, und du würdest die vorherige Version testen im Glauben, es sei die neue. Committe die Dateien, oder nimm --worktree für den schnellen Selbst-Edit-Loop. --worktree nimmt jeden Edit im Checkout mit, auch die unfertige Arbeit einer parallelen Session.

Im devkit-Repository selbst läuft der Loop automatisch: ein SessionStart-Hook meldet, welche Version die Session fährt und ob sie HEAD entspricht, ein Stop-Hook baut nach jedem Turn im Hintergrund neu, und ein gescheiterter Neubau wird beim nächsten Session-Start mit seinem Log-Pfad gemeldet.

Was darunter passiert

Versionen sind unveränderlich und an ihren Namen gebunden. Ein bloßes devkit sync verweigert deshalb eine geänderte Payload unter unveränderter VERSION. devkit maint dev-sync leitet stattdessen einen eigenen Versionsnamen ab — <nächster Patch>-dev.<UTC-Epoch>.<sha8> — sodass jede eigene Payload ihr eigenes Verzeichnis bekommt und die Invariante hält. Die Epoch sorgt dafür, dass ein neuerer Build über dem aktiven sortiert.

Alte Dev-Versionen werden aufgeräumt; die letzten drei bleiben (DEVKIT_DEV_SYNC_KEEP ändert die Zahl). Ein Verzeichnis, aus dem noch ein Prozess läuft, wird nie entfernt.

Dev-Modus verlassen

1. devkit config source-http https://devkit.one-dot.io
2. devkit rollback <Release-Version> — eine Dev-Version sortiert über jedem Release, ein bloßes devkit sync würde den Schritt zurück als Downgrade verweigern. devkit version listet die installierten Versionen.
3. Neue Session starten.

Symptome

Symptom	Ursache	Fix
devkit maint dev-sync verlangt eine lokale Quelle	Die Quelle ist der signierte Endpunkt oder Git	devkit config source-local <checkout>
Exit 2 mit einer Dateiliste	Payload-Dateien sind nicht committet	Committen, oder devkit maint dev-sync --worktree
Session-Start meldet, die Session laufe nicht auf HEAD	Du hast nach dem letzten Neubau committet	Der Neubau läuft bereits; neue Session starten, sobald er fertig ist
Letzter Dev-Sync gescheitert, Log-Pfad gezeigt	Build oder Sync ist abgebrochen	Log lesen, Ursache beheben, devkit maint dev-sync
Die Änderung ist nicht sichtbar	Die Session startete vor dem Neubau	Neue Session starten; devkit status zeigt die aktive Version