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

danic.ai-os · Distribution & Team Model

How Companies & Teams
Deploy danic.ai-os

One model, four scenarios: delivery to the company, a new project, an existing project, and multiple developers working in parallel — without getting in each other's way.

00 — CORE PRINCIPLE

The Two-Layer Model

The decisive point up front: the “danic setup” is not bound to a repo. It splits into two cleanly separated layers — a global engine per developer and a thin per-project configuration layer. Exactly this separation makes every one of the following scenarios possible.

Layer 1
User-Global

`~/.claude/` — the danic engine

111 Agents, 95 Commands, 22 Rules, 22 Hooks, 59 Skills. Installed once via install.sh — then active in every repo the person opens with Claude Code.

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

▼ the engine reads per project ▼

Layer 2
Repo-local

`CLAUDE.md` + `project-management/` — the project context

Per project: tech stack, domain, constraints (CLAUDE.md) plus feature/bug tracking, ID registry and metrics. Stack routing reads tech-stack.md and automatically activates the matching specialist agents.

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

Conclusion: New and existing projects use the same global engine. The only difference lies in how Layer 2 comes into being — generated from scratch (new) or layered over the existing structure (existing).

01 — DELIVERY TO THE COMPANY

Two Distribution Models

This is how danic.ai-os reaches the company. What ships today is Model A (versioned ZIP, managed delivery). Model B (GitHub template) is the target picture for technical customers — currently marked “future” in the repo. Both share the same engine.

Model A · CURRENT · recommended

Managed ZIP Package

build-customer-package.sh [customer] exports a clean, versioned state (without Git history, without DANIC internals), injects the customer config and produces a ZIP. DANIC actively delivers it.

No repo access required — handed over as a ZIP / shared folder
Clean separation — validation blocks internal references
Updates = new package + delivery checklist

Model B · TARGET · GitHub template

“Use this template” → Fork

The company creates its own repo from the danic template, clones it and runs install.sh. Updates arrive via git fetch + git checkout v1.x.

Self-service — the company updates to tags on its own
Version discipline — CHANGELOG + semantic versioning
Prerequisite — customer config cleanly separated from core

Migration path: Both models deliver identical content. The switch A → B is purely a question of handover form (ZIP vs. Git remote) — the engine, commands and agents stay unchanged.

02 — SCENARIO A

New Project from Scratch

The straightforward case: the engine generates Layer 2 entirely on its own. From the idea to the delivered feature through all quality gates.

FLOW · green field — the pulse travels left to right; each box flashes the moment it becomes active

Repo from template

Empty repo unpacked from a ZIP or created from a GitHub template.

install.sh

Engine into ~/.claude/ — once per developer.

/init-product-system

Generates PRD, ADRs & baselines from the product idea.

/ship-feature-auto

Feature end-to-end through all phases & gates.

03 — SCENARIO B

Retrofit an Existing Project

The real question. No rewrite, no migration of the code. Because the engine sits user-global, it is immediately available in the existing repo — only Layer 2 is layered over the existing structure. Stack routing recognizes the existing tech stack and activates the right specialist agents.

FLOW · brown field — the engine is already installed; only the project context is added

Engine in place

install.sh ran once — it applies to the existing repo too.

Create CLAUDE.md

Capture tech stack, domain and constraints of the existing code.

/init-feature-foundation

Maps existing CI, tests & structure into the danic foundation.

/ship-feature-auto

New features on the existing codebase — gates & ADRs from here on.

Why this works: danic does not touch any existing code. It places a process and knowledge layer on top (CLAUDE.md + project-management/). From the first /ship-feature-auto, the existing code evolves under the same quality gates as a greenfield project — incrementally, without a big bang.

04 — SCENARIO C

Multiple Developers in Parallel

Two axes. Different apps is trivial: each person their own repo, the same global engine, zero conflict. The same app is the hard case — and danic solves it through four interlocking isolation layers.

FLOW · same app, parallel — this is how a feature runs isolated up to a safe merge

feature/* branch

GitHub Flow — main always stays stable.

git worktree

Isolated working folder per feature — no shared working copy.

Headless / parallel

Conductor delivers autonomously; several features “in flight” at once.

PR + Quality Gate

Review & gate before merging back into main.

File system

Worktrees

Each feature in its own folder. Parallel development without wrecking the working copy.

Git

Branches

feature/*, fix/* isolate changes. main is always deliverable.

Namespace

ID Registry

FEAT/BUG/ADR IDs are permanent and never recycled — no collision between teams.

Merge

Quality Gates

PR review + gate documentation before every merge. No feature outruns the stability of main.

Different apps, one team: Here no special logic is needed. The engine is installed per developer, each project carries its own Layer 2. Two people on two apps share nothing but the common danic version — updates run over tags, not over shared state.