> internal/processes/danic-deployment-scenarios.md · DEPLOYMENT · 9 MIN

danic.ai-os · Distribution & Team-Modell

Wie Firmen & Teams
danic.ai-os einsetzen

Ein Modell, vier Szenarien: Auslieferung an die Firma, neues Projekt, bestehendes Projekt und mehrere Entwickler:innen parallel — ohne dass sie sich in die Quere kommen.

00 — KERNPRINZIP

Das Zwei-Schichten-Modell

Der entscheidende Punkt vorweg: das „danic Setup" ist nicht an ein Repo gebunden. Es zerfällt in zwei sauber getrennte Schichten — eine globale Engine pro Entwickler:in und eine dünne Konfigurations-Schicht pro Projekt. Genau diese Trennung macht jedes der folgenden Szenarien möglich.

Schicht 1
User-Global

`~/.claude/` — die danic-Engine

111 Agents, 95 Commands, 22 Rules, 22 Hooks, 59 Skills. Einmal via install.sh installiert — danach in jedem Repo aktiv, das die Person mit Claude Code öffnet.

agents/ · commands/ · rules/common/ · hooks/ · skills/ · settings.json

▼ die Engine liest pro Projekt ▼

Schicht 2
Repo-lokal

`CLAUDE.md` + `project-management/` — der Projekt-Kontext

Pro Projekt: Tech-Stack, Domain, Constraints (CLAUDE.md) plus Feature-/Bug-Tracking, ID-Registry und Metrics. Stack-Routing liest tech-stack.md und aktiviert automatisch die passenden Specialist-Agents.

CLAUDE.md · project-management/feature-index.md · tech-stack.md · metrics/

Folgerung: Neue und bestehende Projekte nutzen dieselbe globale Engine. Der Unterschied liegt nur darin, wie Schicht 2 entsteht — von Grund auf generiert (neu) oder über die Bestandsstruktur gelegt (bestehend).

01 — AUSLIEFERUNG AN DIE FIRMA

Zwei Distributionsmodelle

So kommt danic.ai-os in die Firma. Heute ausgeliefert wird Modell A (versioniertes ZIP, Managed Delivery). Modell B (GitHub-Template) ist das Zielbild für technische Kunden — im Repo aktuell als „zukünftig" markiert. Beide teilen sich dieselbe Engine.

Modell A · IST · empfohlen

Managed ZIP-Package

build-customer-package.sh [kunde] exportiert einen sauberen, versionierten Stand (ohne Git-History, ohne DANIC-Internals), injiziert die Kunden-Config und erzeugt ein ZIP. DANIC liefert aktiv aus.

Kein Repo-Zugang nötig — Übergabe als ZIP / geteilter Ordner
Saubere Trennung — Validierung blockt interne Referenzen
Updates = neues Package + Delivery-Checklist

Modell B · ZIEL · GitHub-Template

„Use this template" → Fork

Die Firma erzeugt ein eigenes Repo aus dem danic-Template, klont es und führt install.sh aus. Updates kommen per git fetch + git checkout v1.x.

Self-Service — Firma updatet eigenständig auf Tags
Versions-Disziplin — CHANGELOG + Semantic Versioning
Voraussetzung — Kunden-Config sauber von Core getrennt

Migrationspfad: Beide Modelle liefern identische Inhalte. Der Wechsel A → B ist rein eine Frage der Übergabeform (ZIP vs. Git-Remote) — die Engine, Commands und Agents bleiben unverändert.

02 — SZENARIO A

Neues Projekt von Grund auf

Der gradlinige Fall: die Engine generiert Schicht 2 vollständig selbst. Von der Idee bis zum ausgelieferten Feature durch alle Quality Gates.

FLOW · green field — der Pulse läuft von links nach rechts; jede Box blinkt, sobald sie aktiv wird

Repo aus Template

Leeres Repo aus ZIP entpackt oder aus GitHub-Template erzeugt.

install.sh

Engine nach ~/.claude/ — einmalig pro Entwickler:in.

/init-product-system

Erzeugt PRD, ADRs & Baselines aus der Produktidee.

/ship-feature-auto

Feature end-to-end durch alle Phasen & Gates.

03 — SZENARIO B

Bestehendes Projekt nachrüsten

Die eigentliche Frage. Kein Rewrite, keine Migration des Codes. Weil die Engine user-global liegt, ist sie im Bestandsrepo sofort verfügbar — es wird nur Schicht 2 über die vorhandene Struktur gelegt. Stack-Routing erkennt den vorhandenen Tech-Stack und aktiviert die richtigen Specialist-Agents.

FLOW · brown field — die Engine ist bereits installiert; nur der Projekt-Kontext kommt hinzu

Engine vorhanden

install.sh lief einmal — gilt auch fürs Bestandsrepo.

CLAUDE.md anlegen

Tech-Stack, Domain, Constraints des Bestandscodes erfassen.

/init-feature-foundation

Mappt vorhandene CI, Tests & Struktur in die danic-Foundation.

/ship-feature-auto

Neue Features auf der Bestands-Codebase — Gates & ADRs ab jetzt.

Warum das funktioniert: danic ändert keinen bestehenden Code an. Es legt eine Prozess- und Wissensschicht darüber (CLAUDE.md + project-management/). Der Bestandscode wird ab dem ersten /ship-feature-auto nach denselben Quality Gates weiterentwickelt wie ein Greenfield-Projekt — schrittweise, ohne Big-Bang.

04 — SZENARIO C

Mehrere Entwickler:innen parallel

Zwei Achsen. Verschiedene Apps ist trivial: jede Person ein eigenes Repo, dieselbe globale Engine, null Konflikt. Dieselbe App ist der harte Fall — und danic löst ihn über vier ineinandergreifende Isolationsebenen.

FLOW · same app, parallel — so läuft ein Feature isoliert bis zum sicheren Merge

feature/* Branch

GitHub Flow — main bleibt immer stabil.

git worktree

Isolierter Arbeits-Ordner pro Feature — keine geteilte Working-Copy.

Headless / parallel

Conductor liefert autonom; mehrere Features gleichzeitig „in flight".

PR + Quality Gate

Review & Gate vor dem Merge zurück nach main.

Dateisystem

Worktrees

Jedes Feature in eigenem Ordner. Parallele Entwicklung, ohne sich die Arbeitskopie zu zerschießen.

Git

Branches

feature/*, fix/* isolieren Änderungen. main ist immer deliverbar.

Namensraum

ID-Registry

FEAT-/BUG-/ADR-IDs sind permanent und werden nie recycelt — keine Kollision zwischen Teams.

Merge

Quality Gates

PR-Review + Gate-Dokumentation vor jedem Merge. Kein Feature überholt die Stabilität von main.

Verschiedene Apps, ein Team: Hier braucht es keine Sonderlogik. Die Engine ist pro Entwickler:in installiert, jedes Projekt trägt seine eigene Schicht 2. Zwei Personen an zwei Apps teilen sich nichts außer der gemeinsamen danic-Version — Updates laufen über Tags, nicht über geteilten State.