Ducklab

Ein vollzyklisches Software-Entwicklungs-Harness, das standardmäßig Multi-LLM ist und von Konstruktion her ehrlich.

In einem Block: selbstgehostetes Entwicklungs-Harness (Go-Engine + CLI + Desktop, Linux zuerst) · Brief → Anforderungen → Spezifikation → Plan → Build → Review → Release · Urteile sind Exit-Codes, keine Modellmeinungen · lokale Modelle zuerst (llama.cpp, vLLM) neben jedem OpenAI-kompatiblen oder Anthropic-Endpunkt · bedienbar von Menschen oder anderen Agenten über MCP mit aufgezeichneten, zugeordneten Entscheidungen · Apache-2.0 · entwickelt sich selbst (die Laufaufzeichnungen in .ducklab/ sind die Belege). Agenten: Start bei AGENTS.md und llms.txt.

Du gibst ihm einen Brief. Es schreibt Anforderungen, eine Spezifikation und einen Plan; baut Aufgaben mit einem Modell oder mehreren, die argumentieren; führt dein echtes Test-Gate des Projekts aus; und stoppt für dich, bevor irgendetwas committet wird. Jeder Modellaufruf wird protokolliert. Kein Modell entscheidet jemals ein Urteil.

Es wurde für lokale Modelle zuerst gebaut – die beiden, die den größten Teil davon gebaut haben, sind eine vLLM-Box im LAN und ein llama.cpp-Server auf localhost, beide zum Preis von null – und gehostete Modelle sitzen neben ihnen in derselben Liste, gemessen an derselben Evidenz.

Warum es das gibt

Die meisten agentischen Coding-Tools nehmen ein starkes Modell an und vertrauen ihm. Ducklab nimmt mehrere billige Modelle an und vertraut keinem von ihnen:

• Das Gate entscheidet, nie ein Modell. Ein Urteil ist der Exit-Code eines Befehls. Ein test-first-Lauf misst eine grüne Basislinie, bevor irgendein Test geschrieben wird, das rote über dem neuen Test danach, und jede Annahme reproduziert das Gate aus einem sauberen Checkout des committeten SHA – nichts landet, das nicht reproduziert hat, und eine Annahme, deren Reproduktion fehlschlägt, nimmt ihren eigenen Commit zurück.

• Dekorrelation überall. Ein anderes Modell reviewt; ein Reviewer erfährt nie, wer den Code geschrieben hat (abwesend im Payload, nicht in der UI versteckt); Turnierrichter wählen blind; Council-Kritiker lesen den Entwurf, nicht einander.

• Arbeit ist ein Vertrag. Die Liefergegenstände einer Aufgabe sind die nummerierte Checkliste des Implementierers; er berichtet über jeden nach Nummer, der Reviewer prüft jeden gegen den Diff, und ein nicht geliefertes Element ruft die Gummiente – einen Beraterplatz, der nur bei gemessener Not aufwacht (Bremsverweigerungen, Fehlerserien, rote Gates) und none antwortet, eine Notiz, die den Implementierer direkt zurück an die Arbeit schickt, oder stop.

• Plätze werden auf Evidenz gewählt. Jedes Entlein trägt eine Scorecard – Bestehensquote im Sitz aus deinen eigenen Läufen, Kosten pro Lauf, Coding-Index – und das Roster-Board schlägt Plätze daraus vor, wobei die Ranking-Kriterien dir zur Neuanordnung überlassen sind. Vorschläge sind selten und gerechtfertigt: Bestehensquoten ranken nach ihrer Wilson-Untergrenze, mindestens drei Läufe, Lokale gewinnen nie bei einem Preis von 0 $.

• Nichts ist unbegrenzt. Züge, Token, Kosten, Wanduhr, Tool-Ausgabe, Shell-Befehle – jede Obergrenze sichtbar und mittendrin anhebbar, auf dem Rekord.

• Deine Dokumentation ist nicht durch das Fenster des Modells begrenzt. Hänge ein Wiki an eine Stufe und ein großes Modell liest es ganz; ein kleines Modell bekommt jedes Dokument passend verdaut, der volle Text ist einen ref_read-Aufruf entfernt, und das Gate nennt jedes Dokument, das niemand geöffnet hat. Ein 32k-lokales Modell kann von einer Viertelmillion Zeichen Referenzmaterial gebrieft werden – das Harness trägt das Arbeitsgedächtnis.

Und der Existenzbeweis: ducklab wird in ducklab entwickelt. Der Plan, die Bugs, die Releases und die letzten neunzig-plus akzeptierten Aufgaben gingen durch seine eigene Schleife, angetrieben von denselben lokalen und gehosteten Modellen, die es misst – die meisten jüngsten Funktionen (der multimodale Chat, der Beraterplatz, die Laufhistorie der Führungsschiene) wurden von der Ente gebaut, von einer Person gegated.

Related MCP server: Loki Mode

Status

v0.6.1+, bewegt sich schnell. Sieben Stufen, fünf Modi, das Roster-Board mit Evidenz und Vorschlägen, Referenzdokumente mit automatischer Verdauung, Fähigkeiten, die vom Desktop verwaltet werden, ein sitzender Berater, mit dem du chatten kannst (Bilder inklusive, Vision vor dem Senden verifiziert), Bugs mit Screenshot-Evidenz, Releases, Autopilot, eine CLI, eine Desktop-App und ein MCP-Server, der einem anderen Modell erlaubt, die ganze Schleife mit aufgezeichneten, zugeordneten Entscheidungen zu bedienen.

docs/status.md verfolgt alle Akzeptanzkriterien und rundet nicht auf. Wo Code und Spezifikation abweichen, wird die Abweichung in docs/decisions/ aufgezeichnet.

Installation

Benötigt Go 1.25+, Node 22+ für den Desktop und git.

Linux

Die CLI und die Engine sind reines Go. Der Desktop ist eine Wails-v3-App und benötigt die GTK/WebKit-Entwicklungspakete:

sudo apt install libgtk-3-dev libwebkit2gtk-4.1-dev   # Debian/Ubuntu names
make desktop && make install

Auf Ubuntu 24.04+ benötigt der Desktop auch ein AppArmor-Profil – siehe Entscheidung 0003 und packaging/apparmor/.

macOS

xcode-select --install    # the desktop build links against WebKit
brew install go node
make desktop && make install

Ehrlichkeitshinweis: ducklab wird täglich auf Linux entwickelt und ausgeführt. Die CLI und die Engine werden bei jedem make cross für darwin/arm64 kompiliergeprüft, aber es wurde noch kein Desktop-Build auf einem Mac verifiziert – die erste Person, die es versucht, ist der Test, und make install gibt dir die CLI und die Engine in jedem Fall. Bitte melde, was auch immer bricht.

Beide

make install installiert nach ~/.local/bin – stelle sicher, dass es auf deinem PATH ist. Es warnt, wenn das Desktop-Binary älter als frontend/src ist, weil es sonst bereitwillig ein veraltetes installiert.

Drei Binaries

Provider-Schlüssel kommen aus der Umgebung der Engine zum Aufrufzeitpunkt – exportiere sie, bevor sie startet, oder starte den Desktop über einen Wrapper, der sie aus deinem Schlüsselbund lädt. Die App sagt dir, wenn der Engine, die sie übernommen hat, ein Schlüssel fehlt, den diese App hat, mit dem Neustart-Button neben den Worten.

Ein Zyklus, Ende zu Ende

Vom Desktop: Projekte → Neues Projekt, dann Zyklus → Entwurf. Von einem Terminal:

cd ~/dev/myproject
git init                                    # ducklab needs a git repo
ducklab project init --name MyProject       # auto-starts the engine if none is running

ducklab intake --from brief.txt             # brief        → requirements
ducklab spec                                # requirements → spec
ducklab plan                                # spec         → milestones and tasks

ducklab run T-001                           # build it
ducklab run accept r-20260729-...           # commit it

ducklab review T-001                        # read the commit
ducklab release plan --bump minor           # what shipped

Jede Stufe schreibt zuerst eine .proposed-Datei und wartet auf dich. accept befördert sie; reject stellt genau das wieder her, was der Lauf geschrieben hat, und nichts anderes; „Änderungen anfordern“ schickt jeden Entwurf – Spezifikation, Plan, Release-Notizen – mit deiner Notiz zurück. Nichts wird ohne dich committet (oder ohne die Autonomiestufe, die du explizit gewährt hast).

Referenzdokumente reiten jede Stufe: --ref ~/wiki/product/ (oder die Anhänge-Tür im Desktop) lädt Dateien oder ganze Verzeichnisse als Hintergrund für den Architekten – verankert durch zwei Regeln, die der Prompt offen ausspricht: die genehmigten Anforderungen besitzen den Umfang, und wo eine Referenz und der Code uneins sind, ist der Code die Wahrheit. Wenn das Korpus den Kontext des Sitzes übersteigt, wird jedes Dokument einmal verdaut (per Inhalts-Hash gecacht), der volle Text bleibt über das ref_read-Tool erreichbar, und die Vorschlagskarte listet jedes Dokument auf, das kein Sitz je geöffnet hat.

Übernahme einer bestehenden Codebasis funktioniert genauso: Intake liest den Code und schreibt Ist-Anforderungen, die Spezifikation markiert ihre Abschnitte als as-built, und der Plan bleibt bewusst leer – neue Arbeit kommt dann über Bug-Reports und Planänderungen herein, so wird ducklab selbst entwickelt.

Dein Projekt erklärt seine eigene Wahrheit in .ducklab/project.toml: das Gate ([verify] – mit link_deps und setup für das, was ein sauberer Checkout braucht), wie die App startet ([run] mit einem Preflight) und wie die eigenen Binaries des Projekts neu gebaut werden ([install]), sodass die ganze Schleife läuft, ohne ducklab zu verlassen.

Ein Modell hinzufügen

ducklab provider set openrouter --url https://openrouter.ai/api/v1 \
                                --key-env OPENROUTER_API_KEY
ducklab duckling set pato-sonnet --provider openrouter \
                                 --model anthropic/claude-sonnet-4.5 \
                                 --roles reviewer,judge --context 200000 \
                                 --cost-in 3.0 --cost-out 15.0
ducklab duckling test pato-sonnet --prompt "say OK"

--key-env ist der Name einer Umgebungsvariable, nie ein Schlüssel. Kein Schlüssel wird in die Konfiguration geschrieben, über die API gesendet oder in der Shell-Historie behalten.

Die Roster-Ansicht des Desktops ist, wo Plätze zugewiesen werden: ziehe aus dem Flock auf einen Platz eines Modus, global oder pro Projekt, mit der Evidenz jedes Entleins auf der Karte und den Vorschlägen der Engine neben den Plätzen. Coding-/Intelligenz-/Agentic-Indizes kommen vom Benchmarks-Endpunkt von OpenRouter, wenn ein Entlein dort lebt; deine eigenen Läufe liefern den Rest.

Die fünf Modi

ducklab run T-001 --mode <modus>

Was es nicht tun wird

Diese sind tragend, keine Vorlieben.

• Ein Modell entscheidet nie ein Urteil. Ein Gate ist der Exit-Code eines Befehls.

• Ein grüner Kandidat wird byte-für-byte angewendet. Nichts wird nach dem Bestehen neu generiert.

• Ein Reviewer erfährt nie, wer den Code geschrieben hat.

• Nichts landet, das nicht reproduziert hat aus einem sauberen Checkout.

• Ein Reject macht rückgängig, was der Lauf geschrieben hat, und niemandes andere Arbeit.

• Nichts ist unbegrenzt.

• Geheimnisse berühren nie den Projektzustand.

• Die Engine ist nur Loopback. Es gibt keinen Remote-Modus.

Fähigkeiten

Eine Fähigkeit ist ein Verzeichnis mit einer SKILL.md – unter .ducklab/skills/ für ein Projekt oder im maschinenweiten Fähigkeiten-Verzeichnis, um jedem Projekt zu dienen (Projekt überschattet global bei Namenskollision). Die dokumentationsnur-Form hat kein Skript und ist der Standard: ein Rezept, das ein Modell liest und befolgt. Der Architekt liest Umfrage-Guides vor einer Übernahme (skill_list ist in seinem Prompt), der Berater liest sie im Chat, und nur der Implementierer kann skill_run eine ausführbare ausführen.

Fähigkeiten werden vom Desktop verwaltet (Zahnrad → Fähigkeiten): Liste mit Umfangs-Badges und Validierungsproblemen, lesen, die gesamte SKILL.md bearbeiten, mit Argumenten ausführen, löschen. Eine Fähigkeit, die ein Entlein während eines Laufs schreibt, erscheint dort grau als pending acceptance, bis ihr Lauf akzeptiert ist – eine Fähigkeit vorzuschlagen geht durch dasselbe Gate wie Code vorzuschlagen.

ducklab skill new house-style
ducklab skill run changelog-entry --arg summary="..."

Der Berater

Jedes Projekt besetzt einen Consultant (einen Common-Sitz auf dem Roster-Board): das Modell hinter den „chat about this“-Türen und dem Freitext-Chat in der Führungsschiene. Es liest den Code, die Runs, die Boards und die Skills — schreibt nie — und nimmt Bilder entgegen: Füge einen Screenshot einer defekten Ansicht ein und frage. Vision wird verifiziert, nicht angenommen: Ein Sitz mit deklarierter Vision wird einmal mit einer echten Bildanfrage getestet, und ein reiner Text-Sitz verweigert das Einfügen mit Worten, statt eine Antwort zu halluzinieren.

Ducklab über ein anderes Modell betreiben

ducklab mcp serve stellt die gesamte Schleife über stdio als MCP-Server bereit: Ein externes Modell liest jedes Ergebnis, entscheidet über Gates (mit einem erforderlichen, protokollierten Grund — Entscheidungen landen als approved_by: mcp:<client>, nie als „human“), beantwortet Fragen, meldet Bugs, ändert Pläne und startet Arbeit. Die next-Listen der Engine sind das Gesetz: Ein Operator kann keine Aktion ausführen, die eine Person nicht könnte.

Mitwirken

Siehe CONTRIBUTING.md — wie man baut, wie die Tests die Architektur schützen, wie Arbeit durch ducklabs eigene Schleife fließt und wo man anfängt. Die Kurzfassung:

make            # vet, test, build the frontend
go test ./...   # 38 packages
cd frontend && npx vitest run

Lizenz: Apache-2.0. Beiträge werden unter denselben Bedingungen akzeptiert (§5 der Lizenz — kein CLA). Der Name Ducklab und die Ente gehören dem Maintainer (§6).

Spezifikation

Der Code implementiert eine schriftliche Spezifikation in diesem Repository: docs/spec/ (00-VISION bis 08-DESKTOP-UI) ist die normative Ebene — Vision, Invarianten, Protokollverträge, Abnahmekriterien. Was das System HEUTE ist, lebt in .ducklab/docs/ — die Ist-Anforderungen, Spezifikation und der Plan, den die Schleife selbst pflegt, jede Version an einem menschlichen Gate signiert. Wo sich die beiden bewusst unterscheiden, wird der Unterschied in docs/decisions/ festgehalten; der Diff zwischen ihnen ist die Roadmap, und die Abgleichsstufe berechnet ihn.