Cdd Bootstrap

Scaffold a new greenfield project on the CDD workflow: `/cdd-bootstrap` (takes no argument).

Run this command from a CDD-repo session (it needs the CDD repo's `template/` and `bootstrap-cdd-project.sh`). This command exists only in the CDD repo; it deliberately has no counterpart in `template/.claude/commands/` (it operates *on* a new target project, so downstream projects have no use for it — see the process doc, Section 2.7). It is the greenfield sibling of `/cdd-retrofit`: `/cdd-retrofit` adapts an *existing* project, `/cdd-bootstrap` creates a *new* one.

This is a **guided** command, not a brief-to-files converter. The discovery conversation is part of the job: you walk the user through defining the project, then encode the result into the initial docs and roadmap, then scaffold the project in a single bootstrap invocation. The generated project starts with a real, filled-in overview, `CLAUDE.md`, and roadmap — not the template's pre-filled "survey the codebase" bootstrap phase, which is for files-only installs.

The command takes **no argument**: the project's name, directory, and location all emerge from the discovery conversation, so there is nothing meaningful to pass up front. The target path is proposed and confirmed in step 4, once the identifiers are settled.

**Checkpoint discipline:** confirm the project definition (step 1), then the draft roadmap (step 2), then the two identifiers and the target location (steps 3–4) — each before moving on. Nothing is rendered until all are approved. The scaffold commit is created only after the roadmap is approved. Outward-facing actions (creating a GitHub repo, editing `~/.bashrc`) are confirmed separately and never done silently.

## 1. Guided discovery

Have a conversation to define the project. Do not dump a rigid questionnaire; ask in natural batches, probe vague or one-word answers, and reflect back what you heard. Cover, at minimum:

- **What it is** — one paragraph, plain terms.
- **Goals** — why it exists; the problem it solves or outcome it produces; what success looks like.
- **What it does** — the high-level capabilities, coarse-grained.
- **What it explicitly does not do** — the non-goals. Push for these; they are load-bearing and easy to skip.
- **Constraints** — language/platform, hard technical limits, regulatory/business constraints, compatibility, deadlines.
- **Architecture intentions** — intended high-level shape: major components, how they relate, external boundaries, structural principles the project commits to.
- **Audience** — who consumes it (end users, other services, a team, future-you).

The user may not have firm answers for everything; capture intent and mark genuinely open areas rather than inventing detail. This material becomes the project overview (`doc/knowledge_base/project-overview.md`) and seeds `CLAUDE.md`.

**Off-ramp:** if discovery reveals this isn't really a project — a single self-contained artifact, finished in essentially one sitting, used as-is by future-you — apply the shared scope-triage heuristic (process doc, Section 6) and **offer to drop to `/cdd-quick-create`** instead of scaffolding the full substrate. Surface the signals; the human decides.

**Checkpoint:** present a structured summary of the captured definition (the seven headings above). Get explicit confirmation or corrections before writing anything.

## 2. Draft the initial roadmap

From the discovery, propose a thin but real roadmap: three to five phases, a handful of tasks each, every phase ending in a milestone statement. Slot in the template's suggested infrastructure tasks (CI, linting, tests, README, dependency pinning, release/versioning) where they fit the early phases.

Do **not** include the template's pre-filled "Phase 1: CDD bootstrap" survey phase. That phase exists for files-only starts where the docs haven't been written; here you are writing the docs through this conversation, so the roadmap starts at the project's real first phase.

Keep the roadmap's "Annotation conventions" and "Key principles" scaffolding from the template (adapt the principles to the project, or leave a short placeholder).

**Checkpoint:** show the drafted roadmap; the user approves or edits it. It is approved *now*, before the scaffold, because it will be committed as part of the initial scaffold commit (step 6) — there is no separate post-commit edit pass.

## 3. Confirm the two identifiers

Propose, then confirm with the user before rendering (never pick silently — see the two-identifier model, process doc Section 2.9):

- `<PROJECT_NAME>` — the display name from discovery; free text, may contain spaces.
- `<PROJECT_DIR>` — the directory / repo slug, matching `^[A-Za-z][A-Za-z0-9_-]*$`. This is the working tree's directory name and the handoff-directory namespace.

**Checkpoint:** confirm both before proceeding.

## 4. Confirm the target location

The path is derived, not passed in. Propose the CDD convention `$HOME/Code/<PROJECT_DIR>` as the default and let the user override (the basename should match `<PROJECT_DIR>`, since the worktree helper and handoff paths assume it).

The bootstrap script refuses a path that already exists and is non-empty, so check before staging:

```bash
[[ -e "<target>" && -n "$(ls -A "<target>" 2>/dev/null)" ]] && echo "exists and non-empty"

If it exists and is non-empty, stop and ask for a different location — /cdd-bootstrap is for greenfield. (Suggest /cdd-retrofit if the user actually meant to install CDD into an existing project.) An absent path or an empty directory is fine.

Checkpoint: confirm the target path before staging the overlay.

5. Stage the overlay

Build a staging directory that mirrors the template layout and holds the filled-in artifacts. The bootstrap script applies it over the template before substitution, so these files override the template stubs:

OVERLAY=$(mktemp -d)
mkdir -p "$OVERLAY/doc/knowledge_base"

Write, into $OVERLAY:

• `doc/knowledge_base/pr