onedot-devkit — Zielbild und User-Flows

Diese Seite definiert Nutzererlebnis, Workflows und Produktumfang. Maintainer entscheiden damit; Entwickler folgen den Flows ohne Lernpflicht.

Ziel

Maximaler KI-Hebel bei minimalem Onboarding. Nach einmaliger Installation arbeitet der Entwickler normal weiter; Routing, Qualität, Sicherheit und Token-Effizienz greifen standardmäßig.

Die 6 Säulen

#	Säule	Bedeutung
1	Autopilot	Nutzen ohne Kenntnis jedes Skills, jeder Regel oder jedes Hooks.
2	Sicherheit	Secrets, Sandbox-Grenzen, destruktive Aktionen und Push-Gates sind standardmäßig sicher.
3	Qualität by default	Wiederverwendung, Verifikation, Tests und Review sind Teil des Routings.
4	Selbst-Skepsis	Tragende Entscheidungen erhalten eine unabhängige Gegenprüfung.
5	Token-Effizienz	Werkzeuge und begrenzter Kontext erledigen Arbeit ohne LLM.
6	Stack-Fit	Das Setup dient Laravel, Nuxt, Shopify Liquid, Shopware/Twig und Python.

User-Flows

Jeder Flow endet in ausführbarer Evidenz statt in einem Prosa-Versprechen.

Flow	Anlass und Route
0 — Onboarding	devkit installieren → devkit sync → devkit init und /index im Projekt → .agents/context/ ist bereit. Spätere Sessions prüfen automatisch auf Updates.
1 — Rücknehmbare Tagesarbeit	Wenn die Rücknahme kostenlos ist und deterministische Verifikation existiert: Ergebnis beschreiben → inline arbeiten → gezieltes /test → /review → /commit. Bewusst kein Spec-Overhead; die Dateizahl beeinflusst den Aufwand, nicht das Routing.
2 — Vertragsarbeit	Bei teurer Rücknahme oder noch unmöglicher deterministischer Verifikation: /spec → /spec-work → /commit → Pull Request. Standard ist der kompakte Vertrag; die Full-Route gilt bei hohem Risiko, irreversibler Migration, Sicherheits- oder Public-Contract-Grenze, repoübergreifendem Release, mindestens drei unabhängigen Subsystemen, neuer Architektur oder neuem mutierenden Schritt einer geordneten Pipeline. /review --spec bleibt optional. Gates: Spec-Validierung → Step-Verifikation → Tests und Qualitätsprüfungen → unabhängiges Review.
3 — Vorhaben	Bei mindestens drei Specs, externem Provider oder Transformation über Systemgrenzen: optional /brainstorm → kleinsten nächsten Slice mit /spec definieren → /spec-work → erst dann weiterplanen. /delegate prüft tragende Provider- oder Slice-Entscheidungen unabhängig. /wave plant freigegebene Specs hinter Preflight-, Kosten- und Abnahme-Gates; der Skill wählt keinen Slice.
4 — Wissen und Kontext	Gotcha, Konvention oder Entscheidung → /capture → .agents/context/. Fragen zur Vergangenheit nutzen Memory-Recall. Drift mit devkit context-drift-check prüfen.
5 — Wartung	SessionStart aktiviert ein gestagtes Update und holt das nächste im Hintergrund. devkit sync startet den sofortigen manuellen Pfad; devkit doctor diagnostiziert die Installation; devkit rollback kehrt zu einer früheren Version zurück.

Produkt-Entscheidungsprinzipien

Eine Funktion gehört ins Setup, wenn sie einen Flow und eine Säule unterstützt, ohne Autopilot oder Token-Effizienz zu schwächen. Ein Sonderritual verfehlt das Ziel; Sicherheit und Qualität sollen nicht nur an Modell-Prosa hängen, sondern an ausführbaren Prüfungen.

Prinzip	Entscheidungsregel
Standards first	Natives Laufzeitverhalten bevorzugen. Nur fehlendes Routing, gemeinsame Policy oder Verifikation ergänzen; eingebaute Funktionen nicht hinter einer Schicht verstecken.
Reference first	Externe Projekte sind Kandidaten, keine Autorität. Ansätze vergleichen und an repräsentativer Arbeit testen; Vertrautheit ist keine Evidenz.
Ergebnisse entscheiden	Schleifen, Zeit, Token, Fehler und Ausgabe messen. Größe allein urteilt nicht: Eine große Abhängigkeit kann helfen, eine kleine Always-on-Regel zu teuer sein.

Adoption und Ownership

Eine gepflegte Fähigkeit wird übernommen, wenn sie besser ist; eigener Ersatz ist die Ausnahme. Verhaltenskonflikte sind Migrationskosten, keine automatische Ablehnung.

• Evidenz: README-Aussagen und Benchmarks sind Hypothesen. Trials nutzen echte Payloads und repräsentative Aufgaben; Bibliothek, Proxy, Dienst und andere Oberflächen werden getrennt bewertet.
• Rücknehmbarkeit: Version pinnen, Installationsfolgen prüfen, veränderbare Konfiguration sichern und Rollback statt Backup-Meldungen verifizieren. Fehlende Messwerte ohne erfundene Genauigkeit benennen.
• Vereinfachung: Benennen, was entfällt. Eine überlappende Route ist Akkretion; kann nichts entfallen, bleibt dieser Preis sichtbar.

Drei Ownership-Formen passen:

1. Ein versionsgepinntes externes Tool mit expliziter Upgrade-Prüfung.
2. Fremde Ideen, die mit Attribution in eigenen Text und eigenes Verhalten übernommen werden.
3. Ein wörtlicher Snapshot, auf einen Upstream-Commit gepinnt und bis zur Anpassung als Referenzdaten behandelt.

Fließende fremde Anweisungen ohne Versionsgrenze oder eigene Ownership passen nicht. Externes Material bleibt bis zu Prüfung, Pinning und Anpassung nicht vertrauenswürdig; es kann jede Antwort ohne Update-Gate steuern.

Die Policy ist widerlegbar. Liefert ein gepinnter fremder Kanon repräsentativ dauerhaft bessere Qualität bei geringeren Lebenszykluskosten, verlangt Reference-first seine Übernahme; Herkunft rechtfertigt keine schwächere eigene Version.

Architekturgrenze

Updater, Signaturprüfung, atomare Aktivierung, Kollisionsschutz und Rollback bilden einen Supply-Chain-Vertrag. Externe Ideen dürfen ihn verbessern; direkte Vorlagen brauchen gleichwertige Ownership und Verifikation.

Regeln, Skills und Agenten sind selektiver übernehmbar, da jedes Element gegen Flow und Token-Budget gemessen wird. Beide Ebenen stammen aus einer Quell-Payload; Adapter bilden keine eigenen Policy-Kanons.

Wiederholte Prosa-Pflichten durch deterministische Mechanik ersetzen, wenn Verhalten beobachtbar ist. Das stärkt Autopilot, Qualität und Token-Effizienz; Prosa hält Absicht und Abwägungen fest.

Selbst-Skepsis im Produkt

• /challenge wendet adversariale Frames auf eine Entscheidung an.
• /spec erweitert Challenge und Authoring-Review bei hohem Risiko oder neuer Architektur.
• /spec-work bindet unabhängige Review-Evidenz an die geprüfte Änderung im vereinbarten Umfang.
• Qualitäts- und Debugging-Regeln verlangen Gegenhypothese und Stop-Bedingung für tragende Untersuchungen.
• /delegate liefert eine Cross-Model-Zweitmeinung, wenn ein unabhängiges Modell nützlich ist.