create-ccc-tutor 0.1.0

package/template/docs-harness/adoption-playbook.md

@@ -0,0 +1,373 @@
+# Harness Adoption Playbook
+
+Step-by-step guide for installing the harness in a project. Works for greenfield (new project) and brownfield (existing project) scenarios, via two installation paths.
+
+> **`/init` is the fast path.** Once the harness is on disk and the bootstrap has run, `/init` asks you the questions in Phase 1 here and fills the slots automatically. This playbook is the full manual flow — useful when `/init` doesn't fit your situation, or when you want to understand what `/init` is doing under the hood.
+
+## File layout overview
+
+CCC-MAGI ships TWO root-level "AI context" files plus the project constitution:
+
+| File | Read by | Contains |
+|---|---|---|
+| `AGENTS.md` | Codex / Cursor / Cline / Aider / Gemini CLI / Devin / etc. | Universal project context + auditor brief |
+| `CLAUDE.md` | Claude Code only (others ignore) | Claude-specific workflow, Bootstrap, Language Awareness |
+| `constitution.md` | Every AI agent (per § preamble) | Universal Core (5 invariants) + Project Identity + Red Lines + Slot Registry |
+
+If you use Claude Code, both `CLAUDE.md` and `AGENTS.md` are read by Claude — Claude Code natively reads `CLAUDE.md` and CCC's setup instructs it to also read `AGENTS.md` for project context.
+
+If you use Codex / Cursor / Cline / Aider, those tools read `AGENTS.md` natively. The `CLAUDE.md` file is also present but those tools ignore it.
+
+This dual setup means: any AI tool coming to the project gets the right context without manual configuration.
+
+## Two installation paths
+
+The harness supports two install paths. Pick whichever fits your setup:
+
+### Path A — Through CCC (desktop wrapper)
+
+If you use **CCC (Claude Code Controller)** as your desktop session manager:
+
+1. Open CCC, click "new session", pick your project folder.
+2. In the session view, click the "Harness" button.
+3. In the HarnessWizard window, click "Environment Detection".
+4. Confirm token usage warning → CCC opens a terminal at your session path with your AI CLI running.
+5. The AI walks you through:
+   - **Step 1** (Bootstrap): detect existing harness configs, present 3-option menu, archive/delete other configs, **pull CCC-MAGI from GitHub** to your project.
+   - **Step 2** (`/init`): fill 16 L0 questions, write `.harness/state/install.json`.
+6. CCC HarnessWizard shows ✅ Step 1 / ✅ Step 2 / ✅ All configuration complete.
+
+CCC users do NOT need to manually clone CCC-MAGI — Step 1 pulls it for you. See `CCC_harness_flow.md` (in this repo) for the full spec.
+
+### Path B — Standalone (no CCC)
+
+If you DON'T use CCC, or want full manual control:
+
+1. `git clone <CCC-MAGI-repo> .ccc-magi-temp` in your project (you do this yourself).
+2. Move contents into the right locations (see Step 1.1 below for the file mapping).
+3. Open your AI CLI (`claude` or `codex`) at the project root.
+4. The CLI reads `CLAUDE.md`, sees the **Bootstrap Status Check** block, sees `.harness/state/install.json` doesn't exist → AI reads `.harness/scripts/standalone-bootstrap.md` and walks you through:
+   - Detection + 3-option menu (same as CCC's Step 1, minus the git clone — you did that)
+   - If you pick 1/2: invoke `/init` for Step 2 (L0 filling)
+   - If you pick 3: AI continues working without harness this session; re-prompts next session
+
+This playbook below documents Path B in detail. Path A is the same flow but with CCC's GUI driving terminal spawning + monitoring.
+
+---
+
+## Phase 0 — Preconditions
+
+Before starting:
+
+- [ ] You have a project (or are about to create one) with a git repo initialized.
+- [ ] Working tree is clean (`git status` clean).
+- [ ] You have a CLI installed (Claude Code, Codex, or both — single-engine mode works with one).
+- [ ] You've decided whether this will be **greenfield** (new project, no existing code) or **brownfield** (existing code that the harness will wrap).
+- [ ] You've skimmed `constitution.md` and `CLAUDE.md` so you know what you're signing up for.
+
+### Recommended branch
+
+For brownfield adoption, work on a dedicated branch so it's easy to back out:
+
+```bash
+git checkout -b feat/install-harness
+```
+
+For greenfield, install directly on `main`.
+
+---
+
+## Phase 1 — Install harness templates + fill slots
+
+**Goal:** the harness's template files land in your project, and project-specific values get filled into the slot registry.
+
+### Step 1.1 — Copy the harness
+
+Copy the contents of `outcome/` from the harness package into your project root (or a known subdirectory; the convention is the project root):
+
+```
+your-project/
+├── constitution.md           ← from outcome/constitution.md
+├── CLAUDE.md                 ← from outcome/CLAUDE.md
+├── AGENTS.md                 ← from outcome/AGENTS.md
+├── skills/                   ← from outcome/skills/
+├── agents/                   ← from outcome/agents/
+└── .harness/                 ← created by the install (scripts/, state/)
+    └── scripts/              ← copy from outcome/cli-configs/scripts-template/
+```
+
+Plus CLI configs into their canonical locations:
+
+```
+.claude/settings.json         ← from outcome/cli-configs/claude/settings.json
+.codex/config.toml            ← from outcome/cli-configs/codex/config.toml
+.codex/hooks.json             ← from outcome/cli-configs/codex/hooks.json
+```
+
+### Step 1.2 — Fill the L0 slots
+
+Open `constitution.md` and the slot registry block at the top. Fill every L0 slot. The harness can't run with unfilled L0 slots — that's the entire point of L0.
+
+L0 slots, in plain language:
+
+| Slot | Question for you |
+|------|------------------|
+| `project_name` | What's this project called? |
+| `project_description` | One sentence, no jargon — what does this do? |
+| `project_stage` | early / beta / prod / scale — where are you now? |
+| `project_scale_target` | What scale are you building toward? |
+| `team_size` | solo / small / large |
+| `primary_concern` | What is this harness primarily protecting? (stability / speed / security / ...) |
+| `out_of_scope_items` | What should the harness NOT keep harping on? |
+| `auditor_model` | Display name of the second model (default Codex; None = single-engine) |
+| `language_mode` | plain (default) or professional — affects how prompts are phrased to you |
+| `spec_dir` | Where feature specs live (default `docs/features/`) |
+| `implementation_dir` | Where implementation notes live (default same as spec_dir) |
+
+Then the L0 constitution-identity slots (Section 2 of constitution.md):
+
+| Slot | Question |
+|------|----------|
+| `project_audience` | Who do we serve? (one sentence) |
+| `project_non_goals` | What do we deliberately NOT do? |
+| `project_compliance` | Compliance / legal floors (GDPR / HIPAA / PCI / none / other) |
+| `project_performance_floor` | Performance floors that can't be crossed |
+| `project_identity_other` | Other "if-violated-it's-not-this-project-anymore" statements |
+
+### Step 1.3 — Fill the L1 slots as you go
+
+L1 slots are answered at the appropriate stage. Some can be auto-detected from manifests (`package.json`, `pyproject.toml`, etc.):
+
+- `tech_stack` — auto-detect from manifests
+- `repo_structure` — auto-detect from filesystem, confirm with you
+- `test_framework` — auto-detect from dependencies, confirm
+- `test_runner_command` — auto-detect from scripts, confirm
+
+Other L1 slots need you to answer when relevant:
+
+- `release_lanes` — default `[git-push]`; you can add OTA / staged environments
+- `backend_db_type` — leave empty if no backend (db-schema skill skips entirely)
+- `error_tracker` — Sentry / Bugsnag / none / other
+- `test_required` — true (default) or false
+- `junior_reviewers` — which plugins to enable (see `outcome/agents/README.md`)
+- `dependency_flow` — optional; leave blank if no enforcement
+- `supported_locales` — default `["zh-Hans", "en", "ko"]`; adjust to your project
+- `high_trap_libraries` — libraries to force `context7` verification on
+- `feature_folder_pattern`, `client_code_paths`, `backend_code_paths` — per your repo layout
+
+L2 slots (anti-flag rules, project red lines) start empty and grow over time. Don't fill them now.
+
+### Step 1.4 — Customize the example agents
+
+The harness ships 4 example agents in `agents/` (`frontend-reviewer`, `backend-reviewer`, `security-reviewer`, `test-fixer`). Each has `example: true` in its frontmatter. Decide:
+
+- Keep `frontend-reviewer` if your project has client-side code
+- Keep `backend-reviewer` if `backend_db_type` is configured (it auto-skips otherwise)
+- Keep `security-reviewer` if your project touches PII or auth
+- Keep `test-fixer` if `test_required = true`
+
+Replace the project-specific checklist categories in each kept agent with rules from your `{{rule_sources}}`. The structure stays; the content swaps.
+
+Add your own junior reviewer plugins by copying `agents/_template/junior-agent-template.md`. Register the new agent in the `junior_reviewers` slot.
+
+### Step 1.5 — Customize the CLI hook scripts
+
+The harness's `claude/settings.json` and `codex/hooks.json` reference these scripts at `.harness/scripts/`:
+
+- `precommit-typecheck.sh` — your stack's typecheck (e.g., `tsc --noEmit`, `mypy`, `cargo check`)
+- `lint-bans.sh` — grep for your anti-flag patterns from `AGENTS.md`
+- `precommit-cycles.sh` — your dependency-cycle check (e.g., `madge --circular src/`); skip if `dependency_flow` is empty
+- `format-edit.sh` — your formatter (e.g., `prettier --write`, `black`, `gofmt`)
+- `post-migration.sh` — only if `backend_db_type` is configured (refresh schema cache + regenerate typed bindings)
+- `auditor-gate.sh` — invokes the auditor CLI with structured output; the harness ships a reference implementation in `outcome/cli-configs/scripts-template/`
+
+### Step 1.6 — Commit Phase 1
+
+```bash
+git add constitution.md CLAUDE.md AGENTS.md skills/ agents/ .claude/ .codex/ .harness/
+git commit -m "feat(harness): install workflow harness
+
+- Add constitution, workflow rules, agent definitions
+- Configure cross-model audit (auditor: {{auditor_model}})
+- Hook scripts at .harness/scripts/ customized for stack
+- Two-file feature spec model active
+
+See constitution.md and CLAUDE.md for design rationale."
+```
+
+---
+
+## Phase 2 — First feature as dogfood
+
+**Goal:** run a real feature through the harness end-to-end. The first run validates the install AND surfaces gaps before they compound.
+
+### Greenfield path
+
+1. Pick the simplest meaningful feature (e.g., "user can sign in").
+2. Run `/feature-draft <name>`.
+3. Walk Stage 1 with the harness paraphrasing your intent and running edge-case sweeps.
+4. Continue through stages 2 → 8.
+5. Smoke-test the feature on a real environment (Stage 7).
+6. Commit.
+
+### Brownfield path
+
+1. Pick a feature that already has code but no spec (or stale spec).
+2. Run `/audit-spec <name>`.
+3. Walk the intent rounds, then let the harness's fresh-context subagent read the code and produce an as-built reading.
+4. Resolve each delta (code-vs-spec) with the harness's a/b/c/d decision framing.
+5. Continue through stages 3+ if Section 9 has actionable deltas.
+6. Smoke-test.
+7. Commit.
+
+### What to watch for during Phase 2
+
+- **The CEO spec accidentally carrying tech jargon.** Stage 2's plain-language check should catch this, but it's worth watching during Stage 1.
+- **The audit gate not firing.** Confirm `.harness/scripts/auditor-gate.sh` actually invokes your auditor model.
+- **Lane misclassification.** A "trivial" change that should have been stability-fix; a "stability-fix" that turned out to need spec changes.
+- **Subagent invocation gaps.** A frontend change that didn't trigger `frontend-reviewer` (means your `client_code_paths` slot is wrong).
+
+If any of these happen, halt and fix the config before continuing.
+
+---
+
+## Phase 3 — Gradual adoption (brownfield only)
+
+After Phase 2, the brownfield project has one feature in the new spec model and many features still in the old shape (or no shape at all).
+
+Adopt remaining features in priority order. Suggested order:
+
+1. **Highest-risk features first** — auth, payments, anything touching PII. These benefit most from the harness's audit invariant.
+2. **Most-edited features second** — anything where you find yourself making changes weekly. The harness pays for itself fastest here.
+3. **Foundational features third** — features other features depend on. Improving them improves everything downstream.
+4. **Low-risk leaf features last** — simple settings screens, static content. The harness's overhead may exceed the value here.
+
+Each feature is one `/audit-spec <name>` invocation. The harness handles the rest.
+
+Optional: track progress in `.harness/audit-progress.md`:
+
+```markdown
+# Feature Audit Progress
+
+## Done
+- [x] auth (2026-MM-DD)
+
+## In Progress
+- [ ] chat
+
+## Backlog
+- [ ] sell
+- [ ] feed
+...
+```
+
+---
+
+## Tuning
+
+### `--force-load-bearing` (rare; explicit reset)
+
+LOAD_BEARING files (`CLAUDE.md`, `AGENTS.md`, `constitution.md`) carry user-rendered slot values from `/init` and accumulated `/constitution-edit` Section 3 red lines. The default content-hash detection in `install-into.sh` / `npx create-ccc-magi` preserves these whenever the file's current hash differs from the last-shipped hash (treated as "user-modified").
+
+Pass `--force-load-bearing` only when you explicitly want to discard local LOAD_BEARING modifications and reinstall the shipped version. The original file is backed up with the `.pre-ccc-magi` suffix before being overwritten. Use cases:
+
+- You're starting over after a botched `/init` run
+- Your `constitution.md` got corrupted by an editor mishap
+- You want to compare your customizations against the latest shipped template (look at the `.pre-ccc-magi` backup afterward)
+
+`--force` (existing flag) implies `--force-load-bearing`. For day-to-day re-installs (delivering harness updates), do NOT pass either flag — the content-hash registry at `.harness/state/shipped-hashes.json` auto-updates files you haven't modified while preserving everything else.
+
+### Tuning budget pressure
+
+CCC-MAGI includes a budget-pressure hook (P1.6) that emits advisory warnings as the session context fills up. The threshold is 200,000 tokens by default — the Opus historical baseline.
+
+If you're using a 1M-context model variant, raise the budget so the hook doesn't fire prematurely:
+
+```bash
+export CCC_CONTEXT_BUDGET=1000000  # add to ~/.zprofile or ~/.bashrc
+```
+
+Below 50% of budget: hook is silent (zero token overhead).
+At 50-89%: advisory `additionalContext` (~200 tokens) suggesting model downgrade for subagents + narrower reads.
+At 90%+: stronger advisory + recommendation that the user run `/compact`.
+
+---
+
+## Troubleshooting
+
+### Q: A skill keeps invoking my old CLI's CLAUDE.md location
+
+Your `.claude/settings.json` or `AGENTS.md` reference may be stale. Check `outcome/cli-configs/README.md § Required hook scripts` for the canonical paths the harness expects.
+
+### Q: My CEO spec keeps drifting into tech jargon
+
+You may have skipped Stage 2 or the auditor's plain-language check isn't firing. Re-run `/spec-finalize <name>` — Stage 2 explicitly scans for tech-term creep and halts on each match.
+
+### Q: The audit chain takes forever
+
+Audit cost scales with diff size, not change importance. If a feature change is too large for any reasonable audit, split it into smaller commits. The lane system exists partly to encourage this.
+
+If the auditor model is genuinely too slow for your iteration speed, consider:
+
+- Switching to a faster auditor model (smaller, faster variant of the same family).
+- Single-engine fallback (`auditor_model = None`) — weaker bias-cancellation, but viable for early-stage solo work.
+- Skipping audit on a per-commit basis is **not an option** (Constitution § 1).
+
+### Q: Lane classification is wrong, the harness wants to drag a 5-line change through full workflow
+
+If the change has no intent change AND no schema change AND no new dependency AND <20 LOC, it's trivial-change. Tell the harness explicitly during pre-stage: "this is a trivial-change."
+
+### Q: Smoke test feels like overhead for tiny UI tweaks
+
+Trivial-change skips Stage 7 for pure copy / text / translation changes. Spot-check on device for any logic change. If you find yourself wanting to skip Stage 7 for a logic change, that's a signal the change isn't actually trivial.
+
+### Q: I want to bypass the auditor for an emergency hotfix
+
+You don't bypass — you use the stability-fix lane with auditor Quick mode if it's truly small, or accept the full audit cost if it's not. Constitution § 1 isn't negotiable for emergencies. The discipline is the entire point.
+
+(If your project is in such a fragile state that hotfixes need to ship unaudited, the hotfix isn't the problem — the underlying stability is. Fix that, not the harness.)
+
+### Q: My team doesn't have a second model for cross-model audit
+
+Set `auditor_model = None` to enable single-engine fallback. Fresh-context invocation of the same model still catches a class of errors (the implementer's contextual blind spots) — it just doesn't catch model-prior blind spots. Better than no audit; worse than two-model.
+
+### Q: I want to extend the harness with my own stage / agent / skill
+
+- New agent: copy `agents/_template/junior-agent-template.md`, fill in, register in `junior_reviewers` slot.
+- New skill: copy an existing `skills/<skill>/SKILL.md` as a template, follow the shape.
+- New stage: this is a non-trivial extension — read `design-spec.md` first to understand why there are 9 stages, then propose changes via the harness's own flow (yes, dogfood your harness on the harness).
+
+---
+
+## Time estimates
+
+```
+Phase 0 (preconditions):    5–15 min
+Phase 1 (install + slots):  30–60 min  (longer for brownfield with deep customization)
+Phase 2 (first feature):    2–4 hours  (first run is slowest; later features run faster)
+Phase 3 (gradual adoption): per-feature, asynchronous, on your own schedule
+```
+
+The full Phase 0 → 2 install is typically a single afternoon for a solo developer on a clean project.
+
+---
+
+## Submitting to Anthropic Plugin Marketplace
+
+CCC-MAGI ships a plugin manifest at `.claude-plugin/plugin.json` so it can be submitted to Anthropic's `claude-community` marketplace.
+
+### Process (manual, external)
+
+1. **Verify the manifest is current**: bump `version` in `outcome/.claude-plugin/plugin.json` to match the new release
+2. **Tag the release**: `git tag v0.X.Y && git push --tags`
+3. **Fork** `anthropics/claude-plugins-community` on GitHub
+4. **Add CCC-MAGI** to their `marketplace.json` (or whatever submission format they use at submission time — check current docs)
+5. **Open a PR** with the addition
+6. **Wait for Anthropic review** (typically 1-2 weeks per their docs)
+7. **Once merged**, users can install via `/plugin install @claude-community/ccc-magi`
+
+### Trade-off note
+
+Plugin-only installation gives users the skills (e.g., `/feature-draft`, `/audit-spec`) globally — but NOT the constitution.md, slot registry, or `.harness/state/install.json` (those require per-project installation).
+
+For full CCC-MAGI experience: `install-into.sh` or `npx create-ccc-magi` remains the recommended primary path. The plugin marketplace is the "I want the skills, not the discipline" lightweight option.

package/template/docs-harness/ccc-step1-driver-template.md

@@ -0,0 +1,288 @@
+# CCC Step 1 Driver — Template
+
+This file is a **template / reference** for the Step 1 driver that CCC (Claude Code Controller) should bundle in its application package.
+
+It is NOT part of the runtime CCC-MAGI installed in a user's project. It lives in the CCC-MAGI GitHub repo's `docs-harness/` as a reference for the CCC team to copy + adapt into the CCC app bundle.
+
+---
+
+## Where it should live in CCC
+
+```
+<CCC project root>/
+└── packages/app/resources/
+    └── harness-step1-driver.md          ← copy this file's content here
+```
+
+This path is a suggestion; the actual location is at CCC's discretion. What matters is that CCC's `SessionManager` (or equivalent) can read this file and inject its contents as a prompt into the spawned AI CLI session.
+
+---
+
+## How CCC uses this driver
+
+```
+User clicks "Environment Detection" in CCC's HarnessWizard
+   ↓
+HarnessWizard sends IPC: HARNESS_STEP1_RUN { sessionPath: "/path/to/user/project" }
+   ↓
+Main process:
+  1. Read packages/app/resources/harness-step1-driver.md
+  2. Open new terminal at sessionPath
+  3. Launch user's preferred AI CLI (claude / codex / ...)
+  4. Inject the driver content as initial prompt
+  5. Monitor stdout for "✓ Task complete, close terminal"
+   ↓
+Driver runs (AI reads driver, walks user through detection + 3-option menu + git pull)
+   ↓
+On completion marker detected, close terminal
+   ↓
+HarnessWizard transitions to Step 2 state
+```
+
+---
+
+## Driver content (copy below into the CCC bundle's driver file)
+
+```markdown
+# CCC Bundled Step 1 Driver
+
+You are an AI assistant invoked by CCC (Claude Code Controller) to perform Step 1 of harness installation: **detect any existing harness configurations in this project + present a 3-option menu to the user + (optionally) pull CCC-MAGI from GitHub**.
+
+**You are running inside a CCC-spawned terminal.** Behaviors specific to this environment:
+
+- After completing your task, output the exact string `✓ Task complete, close terminal` on its own line. CCC monitors stdout for this; matching it triggers terminal close.
+- You can assume `git`, `bash`, and the user's chosen AI CLI tooling are available in PATH.
+- Do NOT prompt the user to "press any key" or other terminal-ish UX — CCC's GUI is also visible; user can scroll back if needed.
+
+## Language Awareness
+
+This driver is written in English (stable + token-efficient). When you talk to the user, talk in their OS locale's language. Detect at session start:
+
+```bash
+locale 2>/dev/null | head -1 | sed 's/LANG=//' | sed 's/\..*//'
+```
+
+Common locales: `en_*` → English; `zh_*` → 简体/繁體中文; `ja_*` → 日本語; `ko_*` → 한국어. Default English on failure.
+
+User-facing menus and prompts in this driver are templates — translate when displaying. The completion markers (`✓ Task complete, close terminal` / `✗ Task cancelled, close terminal`) are byte-exact and NEVER translated (CCC parses them).
+
+---
+
+## Step A — Scan for existing harness configurations
+
+(Same detection logic as `outcome/scripts/standalone-bootstrap.md` Step A. Refer to that file as the canonical source; the layers are:)
+
+- Layer 1: Known harness markers (BMAD, SpecKit, OpenSpec, Cursor rules, Cline rules, etc.)
+- Layer 2: Canonical AI config files, case-insensitive (CLAUDE.md / AGENTS.md / AGENT.md and variants)
+- Layer 3: AI-shaped directories (agent/, agents/, ai/, prompts/, skills/, rules/, instructions/, harness/, workflow/)
+- Layer 4: Suspicious markdown at project root (excluding README/LICENSE/CHANGELOG/etc., AND excluding anything in Layer 5)
+- Layer 5: CCC-MAGI owned files — ALWAYS filter out, surface separately in 🟢 section. In CCC mode (this driver), CCC-MAGI should NOT yet be present since this driver runs BEFORE git clone. But on a re-run (e.g., user previously clicked Environment Detection then closed without finishing), the partial install may have placed our files; recognize them by name + signature:
+  - `constitution.md` + signature `SLOT REGISTRY`
+  - `CLAUDE.md` + signature `Bootstrap Status Check`
+  - `AGENTS.md` + signature `Auditor Instructions (for MAGI / Codex)`
+  - `.harness/`, `.claude/`, `.codex/`, `docs-harness/` directories
+  - `CCC_MAGI_README.md`, `CCC_MAGI_LICENSE`
+- Layer 6: User's original files backed up by us — pattern `*.pre-ccc-magi` (or `*.pre-ccc-magi.<timestamp>`). Content is the user's, filename is ours. Surface separately in 🟡 section; do NOT include in the 3-option menu set.
+
+Use `Glob` + `Read` tools to scan. Read first 80 lines of suspicious candidates to make semantic judgments.
+
+## Step B — Present findings and confirm
+
+(Same as standalone-bootstrap.md Step B — refer to it for the canonical output template, including the 5-category grouping: 📕/📗/📘 numbered askable items, ✅ confirmed unrelated, 🟢 CCC-MAGI self, 🟡 user's backed-up originals.)
+
+Critical rules:
+- Numbered list (1, 2, 3...) ONLY for 📕/📗/📘 items the user actually decides on.
+- 🟢 and 🟡 sections are informational — show them so the user understands what's there, but they are NOT in the editable set.
+- Loop user confirmation until "done".
+
+### Special case: empty confirmed set
+
+If after the user's responses the confirmed-harness list is **empty** (user marked all candidates as "not harness", or said "none" upfront), there is nothing to archive or delete. **Skip Step C and Step D entirely; jump directly to Step E** (git clone CCC-MAGI + then invoke /init for Step 2 configuration).
+
+Acknowledge this to the user before jumping (translate to user's locale per Language Awareness):
+
+```
+You confirmed there are no existing harness files to handle.
+Proceeding directly to install stage (pull CCC-MAGI + configure).
+```
+
+Then proceed to Step E. The git clone runs unconditionally; the only thing skipped is the archive/delete action (which has nothing to act on).
+
+## Step C — Present 3-option menu
+
+Display this menu to the user (translate to user's locale per Language Awareness; the template below is English-canonical):
+
+```
+How would you like to handle these harness files?
+
+  [1] Take over + archive (recommended ★)
+      → Create old_version_harness/ directory at project root
+      → Move the confirmed files / directories above into it
+      → Then pull CCC-MAGI from GitHub
+      → On completion, proceed to Step 2 configuration
+
+  [2] Take over + delete
+      → Delete the confirmed files / directories above
+      → Then pull CCC-MAGI from GitHub
+      → On completion, proceed to Step 2 configuration
+      → Warning: deletion is irreversible
+
+  [3] Decline CCC-MAGI
+      → Close terminal
+      → CCC window will show a "Declined — rerun?" button
+      → No files in your project will be modified
+
+Enter 1 / 2 / 3:
+```
+
+## Step D — Execute the chosen option
+
+### Option 1 (Archive)
+
+1. Confirm with user.
+2. `mkdir old_version_harness && mv <files...> old_version_harness/`
+3. Write `old_version_harness/README.md` documenting the archive.
+4. Proceed to Step E (git pull).
+
+### Option 2 (Delete)
+
+1. Show explicit warning + require typed `DELETE` confirmation.
+2. `rm -rf <files...>`
+3. Proceed to Step E.
+
+### Option 3 (Decline)
+
+1. Acknowledge to the user (translate to user's locale):
+   ```
+   OK — CCC-MAGI will not be installed this time.
+   ```
+2. Output the **decline marker** (NOT the success marker — these are different so CCC can route correctly):
+   ```
+   ✗ Task cancelled, close terminal
+   ```
+   Note the leading `✗` (U+2717 BALLOT X) instead of `✓` (U+2713 CHECK MARK). CCC monitors stdout for both markers and routes to different UI states.
+3. Halt. CCC closes the terminal; HarnessWizard transitions to "Declined — rerun?" state.
+
+## Step E — Pull CCC-MAGI from GitHub
+
+**Reached if**: user picked option 1 or 2 in Step C, OR confirmed-set was empty (Step B special case).
+
+```bash
+# CUSTOMIZE THIS COMMAND when CCC-MAGI is published.
+# Placeholder — actual repo URL/method TBD per CCC_harness_flow.md decision 2 (deferred to Round 3).
+git clone https://github.com/<OWNER>/CCC-MAGI.git .ccc-magi-temp
+```
+
+Then move the cloned contents into the right project locations (mirror of /init Step 4 file mappings):
+
+- `.ccc-magi-temp/constitution.md` → `./constitution.md`
+- `.ccc-magi-temp/CLAUDE.md` → `./CLAUDE.md`
+- `.ccc-magi-temp/AGENTS.md` → `./AGENTS.md`
+- `.ccc-magi-temp/skills/*` → `.harness/skills/`
+- `.ccc-magi-temp/agents/*` → `.harness/agents/` (filtered)
+- `.ccc-magi-temp/scripts/*` → `.harness/scripts/` (with chmod +x on .sh)
+- `.ccc-magi-temp/cli-configs/claude/settings.json` → `.claude/settings.json`
+- `.ccc-magi-temp/cli-configs/codex/*` → `.codex/`
+- `.ccc-magi-temp/docs-harness/*` → `./docs-harness/`
+
+Clean up:
+```bash
+rm -rf .ccc-magi-temp
+```
+
+Verify the install:
+- `constitution.md` exists at project root
+- `.harness/scripts/auditor-gate.sh` exists and is executable
+- `.harness/scripts/standalone-bootstrap.md` exists
+
+If any verification fails, report it to the user with the specific failure; do NOT emit the completion marker (let CCC's terminal stay open so user can investigate).
+
+## Step F — Output completion marker
+
+**Two possible markers — pick based on outcome:**
+
+### After successful Step E (user picked 1 or 2 and install completed):
+```
+✓ Task complete, close terminal
+```
+(Leading `✓` = U+2713 CHECK MARK)
+
+### After Step D Option 3 (user declined):
+```
+✗ Task cancelled, close terminal
+```
+(Leading `✗` = U+2717 BALLOT X)
+
+These are the EXACT strings. No variations, no prefixes, no suffixes. Must be on its own line.
+
+CCC monitors stdout for **either** marker:
+- Matches `✓ Task complete, close terminal` → terminal closes; HarnessWizard transitions to "Step 1 complete" → enables "Step 2" button
+- Matches `✗ Task cancelled, close terminal` → terminal closes; HarnessWizard transitions to "Declined — rerun?" state
+
+Per CCC_harness_flow.md decision 4, the two markers exist specifically so CCC can route to the correct UI state from stdout alone, without filesystem post-checks.
+
+## Completion criteria for Step 1
+
+Step 1 is complete when ALL of the following are true:
+
+1. Detection has surfaced findings to the user (Step B loop completed with "done")
+2. User has explicitly picked option 1, 2, or 3 (Step C)
+3. The chosen option's action has executed (Step D + E if applicable)
+4. One of the two markers has been emitted on its own line (Step F):
+   - `✓ Task complete, close terminal` on options 1/2 success path
+   - `✗ Task cancelled, close terminal` on option 3 (decline) path
+
+**The completion marker is the contract between this driver and CCC.** Without ANY marker, CCC will hold the terminal open indefinitely. Emitting the WRONG marker will route CCC's UI to the wrong state.
+
+---
+
+## Rules you MUST follow
+
+(Same as standalone-bootstrap.md "Rules you MUST follow" section.)
+
+- Never skip the user-confirmation loops
+- Never delete files under option 1 (move only)
+- Never execute option 2 without typed DELETE confirmation
+- Never improvise the 3-option menu text
+- Never skip emitting the completion marker — CCC depends on it
+- Never emit `✓` marker on Option 3 (decline) — that would route CCC to "Step 1 complete" instead of "Declined". Emit `✗` instead.
+```
+
+---
+
+## What CCC needs to provide alongside this driver
+
+For this driver to work, CCC must:
+
+1. **Bundle this `.md` file** in its app resources
+2. **Spawn a terminal** at the user's session path
+3. **Launch the chosen AI CLI** in that terminal (existing CCC capability via `SessionManager.launchInteractive()`)
+4. **Inject this driver's content as the initial prompt** (new capability — currently CCC doesn't do prompt injection at session start; needs new IPC channel and main-process handler)
+5. **Monitor terminal stdout** for the completion marker `✓ Task complete, close terminal` and close the terminal when matched
+6. **Transition HarnessWizard UI state** based on Step 1 outcome (success → enable Step 2 button; declined → show "Rerun" button)
+
+Per `CCC_harness_flow.md` § 9.2, this maps to:
+- New file: `<CCC>/packages/app/resources/harness-step1-driver.md`
+- Updated `<CCC>/packages/app/src/main/SessionManager.ts` — add prompt injection capability
+- Updated `<CCC>/packages/app/src/shared/ipc-channels.ts` — add `HARNESS_STEP1_RUN` channel
+- Updated `<CCC>/packages/app/src/renderer/src/components/HarnessWizard.tsx` — enable the previously-dormant flow
+
+---
+
+## Difference vs standalone-bootstrap.md
+
+| Aspect | This driver (CCC-bundled) | standalone-bootstrap.md (in CCC-MAGI) |
+|--------|---------------------------|-------------------------------------------|
+| Where bundled | CCC app package | CCC-MAGI GitHub repo |
+| Triggered by | CCC UI button | CLAUDE.md Bootstrap Status Check block |
+| Includes git clone? | **Yes** (Step E pulls CCC-MAGI) | No (CCC-MAGI already cloned by user manually) |
+| Completion marker | **Required** (CCC closes terminal on match) | Optional (no terminal to close in standalone) |
+| Option 3 behavior | Closes terminal + CCC shows "declined" UI | AI continues working in same CLI session |
+
+---
+
+## Version
+
+```
+2026-05-21 v1 — initial template; CCC team copies into bundle
+```