docs(rebrand): rename & rebrand CI → CIAgent across all documentation, templates, and scripts

- README.md: title, project name, CLI commands, .ci/ → .ciagent/, ci-files → ciagent-files, CI Modification → CIAgent Modification - AGENTS.md: title, project name, architecture tree, agent count (18→19), test count (25→31 suites, 218→370 tests), version (0.4.0→0.6.0), ci-files → ciagent-files, CIConfig → CIAgentConfig, CiMetadata → CIAgentMetadata, .ci/ → .ciagent/ - templates/DECISIONS.md: .ci/audit/ → .ciagent/audit/, ci audit → ciagent audit - scripts/postinstall.js: CI postinstall → CIAgent postinstall - scripts/install.sh: CI → CIAgent, ci-init → ciagent-init, INSTALL COMPLETE banner - opencode/ci/workflows/*.md (11 files): .ci/ → .ciagent/, CI → CIAgent project name, ci-command → ciagent-command usage lines - opencode/ci/references/*.md (5 files): .ci/ → .ciagent/, CI → CIAgent project name, ci-files → ciagent-files references - opencode/ci/contexts/*.md (3 files): .ci/ → .ciagent/, CI → CIAgent project name - opencode/agents/ci-*.md (18 files): .ci/ → .ciagent/, CI → CIAgent project name - opencode/command/ci-*.md (11 files): CI → CIAgent project name Preserved: ---ci---/---/ci--- markers, opencode/ci/ dir paths, ci-*.md filenames, ci listProjects()/ci setActiveProject() API names, repo URLs ---ci--- phase: 1 milestone: v0.6 plan: 01-01 task: 01-01-01 status: execute ---/ci---
feat(P06): 3-tier versioning, branch hierarchy enforcement, ARCHITECTURE-PLAN synthesis
2026-05-29 17:58:48 +00:00 · 2026-05-29 17:18:10 +00:00 · 2026-05-29 16:47:17 +00:00 · 2026-05-29 16:46:17 +00:00
67 changed files with 1479 additions and 547 deletions
@@ -0,0 +1,80 @@
+#!/bin/bash
+# CI pre-push hook: enforce versioning and branching rules
+# Install: git config core.hooksPath .githooks
+
+zero="0000000000000000000000000000000000000000"
+
+while read local_ref local_oid remote_ref remote_oid; do
+  if [ "$local_oid" = "$zero" ]; then
+    continue
+  fi
+
+  # Check pushed tags
+  if echo "$local_ref" | grep -qE "^refs/tags/"; then
+    tag_name=$(echo "$local_ref" | sed 's|^refs/tags/||')
+
+    # Validate semver format
+    if echo "$tag_name" | grep -qE "^v[0-9]+\.[0-9]+\.[0-9]+$"; then
+      tag_major=$(echo "$tag_name" | sed 's/v\([0-9]*\)\.[0-9]*\.[0-9]*/\1/')
+      tag_minor=$(echo "$tag_name" | sed 's/v[0-9]*\.\([0-9]*\)\.[0-9]*/\1/')
+      tag_patch=$(echo "$tag_name" | sed 's/v[0-9]*\.[0-9]*\.\([0-9]*\)/\1/')
+
+      # Check for semver ordering violations
+      for existing_tag in $(git tag -l "v${tag_major}.${tag_minor}.*" 2>/dev/null); do
+        if [ "$existing_tag" = "$tag_name" ]; then
+          continue
+        fi
+        existing_patch=$(echo "$existing_tag" | sed 's/v[0-9]*\.[0-9]*\.\([0-9]*\)/\1/')
+        if [ "$existing_patch" -ge "$tag_patch" ] && [ "$tag_patch" -le "$existing_patch" ]; then
+          echo "ERROR: Tag $tag_name is not greater than existing tag $existing_tag"
+          echo "  Milestone tags must be the NEXT version (e.g., v0.6.0 after v0.5.1-5, NOT v0.5.0)"
+          exit 1
+        fi
+      done
+
+      # Check for milestone-tags-below-phase-tags
+      # If this is a .0 tag (milestone), verify no .N tags exist with higher patch
+      if [ "$tag_patch" = "0" ]; then
+        for existing_tag in $(git tag -l "v${tag_major}.${tag_minor}.*" 2>/dev/null); do
+          existing_patch=$(echo "$existing_tag" | sed 's/v[0-9]*\.[0-9]*\.\([0-9]*\)/\1/')
+          if [ "$existing_patch" -gt 0 ] && [ "$existing_patch" -gt "$tag_patch" ]; then
+            echo "ERROR: Milestone tag $tag_name is below existing phase tags (e.g., $existing_tag)"
+            echo "  Feature milestone completion must be tagged as v${tag_major}.$(($tag_minor + 1)).0, not v${tag_major}.${tag_minor}.0"
+            exit 1
+          fi
+        done
+      fi
+    fi
+  fi
+
+  # Check branch merges: reject direct-to-main pushes if milestone branch exists
+  if echo "$local_ref" | grep -qE "^refs/heads/main$"; then
+    milestone_branches=$(git branch -r 2>/dev/null | grep 'milestone/v' | grep -v ':$' || true)
+    if [ -n "$milestone_branches" ]; then
+      # Allow if this is a merge commit from a milestone branch
+      merge_parents=$(git cat-file -p "$local_oid" 2>/dev/null | grep "^parent" | wc -l)
+      if [ "$merge_parents" -lt 2 ]; then
+        # Not a merge commit — check if there are active milestone branches
+        active_milestones=""
+        for mb in $milestone_branches; do
+          clean_name=$(echo "$mb" | sed 's|^[^/]*/||' | tr -d ' ')
+          merged=$(git branch -r --merged origin/main 2>/dev/null | grep "$clean_name" || true)
+          if [ -z "$merged" ]; then
+            active_milestones="$active_milestones $clean_name"
+          fi
+        done
+        if [ -n "$active_milestones" ]; then
+          echo "WARNING: Pushing directly to main while active milestone branches exist:"
+          for ms in $active_milestones; do
+            echo "  - $ms"
+          done
+          echo "  Phase branches should merge into the milestone branch first."
+          # Warning only — not blocking. The code-level enforcement in git-branch.ts
+          # is the hard gate; this hook is a safety net.
+        fi
+      fi
+    fi
+  fi
+done
+
+exit 0
@@ -1,4 +1,4 @@
-# AGENTS.md — CI Project Guidelines
+# AGENTS.md — CIAgent Project Guidelines

 ## Build & Run Commands

@@ -9,16 +9,16 @@

 ## Project Overview

-CI (Continuous Intelligence) is a fully autonomous AI-driven software engineering harness. It receives a specification, resolves ambiguities through a single Clarify phase, then executes the full pipeline (research → plan → execute → verify) autonomously, escalating only when it cannot safely proceed alone.
+CIAgent (Continuous Intelligence) is a fully autonomous AI-driven software engineering harness. It receives a specification, resolves ambiguities through a single Clarify phase, then executes the full pipeline (research → plan → execute → verify) autonomously, escalating only when it cannot safely proceed alone.

 ## Architecture

 ```
 src/
-  agents/          # 18 agent implementations (persona loaders delegating to backends)
+  agents/          # 19 agent implementations (persona loaders delegating to backends)
  backends/        # Intelligence backend layer
    types.ts      # IntelligenceBackend, BackendRequest, BackendResult, BackendConfigSection
-    tool-registry.ts  # CI-owned tool implementations (readFile, writeFile, editFile, runBash, glob, grep)
+    tool-registry.ts  # CIAgent-owned tool implementations (readFile, writeFile, editFile, runBash, glob, grep)
    ollama-base.ts   # Abstract base for Ollama backends (shared tool loop, prompt construction)
    ollama-local.ts  # OllamaLocalBackend (localhost:11434)
    ollama-cloud.ts  # OllamaCloudBackend (remote endpoint, auth, rate limiting)
@@ -26,21 +26,21 @@ src/
    index.ts         # Backend registry + auto-detection
  cli/             # Commander.js CLI (commands.ts, index.ts)
  core/            # Core engine components
-     artifacts.ts   # Legacy .ci/ artifact management (retained for backward compat)
-    audit.ts       # Legacy audit trail in .ci/audit/ (retained for backward compat)
-    ci-files.ts    # .ci/ long-lived reference file management (PROJECT.md, ROADMAP.md, etc.)
+     artifacts.ts   # Legacy .ciagent/ artifact management (retained for backward compat)
+    audit.ts       # Legacy audit trail in .ciagent/audit/ (retained for backward compat)
+    ciagent-files.ts    # .ciagent/ long-lived reference file management (PROJECT.md, ROADMAP.md, etc.)
    clarify.ts     # Clarify phase: question generation, default acceptance
    commit-builder.ts  # Structured commit message generation (---ci--- YAML blocks)
    commit-parser.ts   # ---ci--- YAML block extraction and parsing
-    config.ts      # .ci/config.json load/save/init
+    config.ts      # .ciagent/config.json load/save/init
    decision-engine.ts  # Bounded rationality: commits decisions as git artifacts
    error-recovery.ts   # Retry, plan revision, rollback logic
    escalation.ts  # Escalation protocol: commits escalations as git artifacts
    git-branch.ts  # Branch lifecycle: phase/NN-slug, milestone/vX.X-slug
    git-context.ts # Project state reconstruction from git log + branches
  types/           # Type definitions
-    commit-meta.ts # CiMetadata, CommitDecision, CommitEscalation, ParsedCiCommit
-    config.ts      # CIConfig, AutonomyLevel, ModelProfile, DEFAULT_CI_CONFIG (includes backend)
+    commit-meta.ts # CIAgentMetadata, CommitDecision, CommitEscalation, ParsedCIAgentCommit
+    config.ts      # CIAgentConfig, AutonomyLevel, ModelProfile, DEFAULT_CIAGENT_CONFIG (includes backend)
    decisions.ts   # Decision, ConfidenceLevel, DecisionCategory
    escalation.ts  # Escalation, EscalationType, EscalationResolution
    clarify.ts     # ClarifyQuestion, ClarifyResult
@@ -53,7 +53,7 @@ src/
     security.ts    # Layer 3: regex-based threat pattern scanning (no STRIDE analysis yet)
     quality.ts     # Layer 4: regex-based code quality checks (no multi-persona review yet)
  index.ts         # Public API exports
-  version.ts       # VERSION = "0.4.0"
+  version.ts       # VERSION = "0.6.0"
 templates/         # Template files (config.json, DECISIONS.md, specification.md)
 ```

@@ -62,9 +62,9 @@ templates/         # Template files (config.json, DECISIONS.md, specification.md
 - **Autonomy levels**: `full` (no HITL after clarify), `supervised` (escalate on gates + verification failures), `guided` (escalate on every decision gate)
 - **Decision confidence thresholds**: High (>0.85) auto-decide and log; Medium (0.60–0.85) auto-decide with assumption logging; Low (<0.60) escalate to human
 - **Escalation timeout**: Default 5 minutes, then auto-proceeds with recommended option. Set to `0` to require human, `-1` to always auto-proceed
- **18 agents** purpose-built for CI, all configured for autonomous operation. OrchestratorAgent is CI-specific
- **Git-native context**: The git log IS the project memory. Agent's first impulse to gather context is `git log` + `git branch`, not file reads. Dynamic state (decisions, escalations, lessons, compounding) lives in `---ci---` YAML blocks in commit messages. `.ci/` holds only long-lived reference docs (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json).
- **Artifact compatibility**: CI no longer writes `.planning/` schema. Dynamic state is derived from git history. `.ci/` files follow a CI-native schema.
+- **19 agents** purpose-built for CIAgent, all configured for autonomous operation. OrchestratorAgent is CIAgent-specific
+- **Git-native context**: The git log IS the project memory. Agent's first impulse to gather context is `git log` + `git branch`, not file reads. Dynamic state (decisions, escalations, lessons, compounding) lives in `---ci---` YAML blocks in commit messages. `.ciagent/` holds only long-lived reference docs (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json).
+- **Artifact compatibility**: CIAgent no longer writes `.planning/` schema. `.ciagent/` files follow a CIAgent-native schema.

 ## Code Conventions

@@ -73,7 +73,7 @@ templates/         # Template files (config.json, DECISIONS.md, specification.md
 - **Agent pattern**: All agents extend `BaseAgent` with `name` (AgentName), `description`, `workflow`, and `execute(context: AgentContext): Promise<AgentResult>`. Agents delegate to `context.backend` when available, fail honestly when not.
 - **No runtime validation library**: Uses plain TypeScript types, not Zod schemas (Zod is a dependency but types are hand-defined)
 - **File I/O**: Use `src/utils/file.ts` helpers (`writeFile`, `readFile`, `ensureDir`, `readJSON`, `writeJSON`) instead of raw `fs` calls in agent/business logic
- **Config**: `CIConfig` type and `DEFAULT_CI_CONFIG` in `src/types/config.ts` — always merge partial configs with defaults
+- **Config**: `CIAgentConfig` type and `DEFAULT_CIAGENT_CONFIG` in `src/types/config.ts` — always merge partial configs with defaults
 - **Error handling**: Agents return `{ success: false, error: string }` rather than throwing
 - **No comments in code**: Follow existing pattern — agent files have no comments
 - **Naming**: `camelCase` for functions/variables, `PascalCase` for classes/types/interfaces, `kebab-case` for file names
@@ -91,20 +91,20 @@ Each stage is executed by `OrchestratorAgent.executeStage()`. The orchestrator d

 ```
 IntelligenceBackend (unified interface)
-├── LLMBackend (CI runs tool loop, provides tools, constructs prompts)
+├── LLMBackend (CIAgent runs tool loop, provides tools, constructs prompts)
 │   ├── OllamaLocalBackend     (localhost:11434, no auth)
 │   ├── OllamaCloudBackend     (remote endpoint, API key, rate limits)
 │   └── (future: OpenAI, Anthropic, Gemini, etc.)
-└── AgentBackend (agent runs own tool loop, CI sends request)
+└── AgentBackend (agent runs own tool loop, CIAgent sends request)
    ├── OpencodeBackend        (opencode --non-interactive)
    └── (future: Codex, Claude Code, Hermes, etc.)
 ```

- **LLM backends**: CI constructs system prompts from persona.md + workflow.md, defines tool schemas, runs the tool-call loop via `ToolRegistry`, and parses structured JSON output
- **Agent backends**: CI serializes `BackendRequest`, invokes the agent, and parses JSON `BackendResult` from stdout
+- **LLM backends**: CIAgent constructs system prompts from persona.md + workflow.md, defines tool schemas, runs the tool-call loop via `ToolRegistry`, and parses structured JSON output
+- **Agent backends**: CIAgent serializes `BackendRequest`, invokes the agent, and parses JSON `BackendResult` from stdout
 - **Auto-detection** (provider: "auto"): tries opencode → ollama-local → ollama-cloud → fails with instructions
- **Per-command override**: `ci run --backend ollama-local` forces a specific backend
- **Config**: `backend` section in `.ci/config.json` with provider, fallback, agent_backends, llm_backends
+- **Per-command override**: `ciagent run --backend ollama-local` forces a specific backend
+- **Config**: `backend` section in `.ciagent/config.json` with provider, fallback, agent_backends, llm_backends

 ## Agent Modification Rules (from PRD)

@@ -131,17 +131,17 @@ IntelligenceBackend (unified interface)
 - Test framework: Jest with ts-jest
 - Test file pattern: `**/*.test.ts` in `src/`
 - Run: `npm run test`
- 25 test suites, 218 tests covering types, core, git-native, verification, and utility modules
+- 31 test suites, 370 tests covering types, core, git-native, verification, and utility modules
 - Tests use temp directories (os.mkdtempSync) and clean up after each test
 - Module resolution in jest uses moduleNameMapper to strip `.js` extensions

 ## Important Files

- `.ci/config.json` — Project-level CI configuration (autonomy, parallelization, verification, security, git)
- `.ci/PROJECT.md` — Vision, core value, requirements, constraints, key decisions table
- `.ci/ARCHITECTURE.md` — System architecture, component boundaries, data flow
- `.ci/ROADMAP.md` — Phase breakdown, milestone mapping, success criteria, progress table
- `.ci/REQUIREMENTS.md` — v1/v2 requirements with REQ-IDs and traceability matrix
+- `.ciagent/config.json` — Project-level CIAgent configuration (autonomy, parallelization, verification, security, git)
+- `.ciagent/PROJECT.md` — Vision, core value, requirements, constraints, key decisions table
+- `.ciagent/ARCHITECTURE.md` — System architecture, component boundaries, data flow
+- `.ciagent/ROADMAP.md` — Phase breakdown, milestone mapping, success criteria, progress table
+- `.ciagent/REQUIREMENTS.md` — v1/v2 requirements with REQ-IDs and traceability matrix
 - Git log — Primary project memory: decisions, escalations, lessons, compounding, verification results
 - Branch structure — `phase/NN-slug` (active/complete) and `milestone/vX.X-slug` branches

@@ -191,16 +191,16 @@ IntelligenceBackend (unified interface)

 ## Current State

- **v0.4.0**: Backends module (OllamaLocal, OllamaCloud, Opencode), learnship references removed, verification layers migrated from .planning/ to .ci/
- **New modules**: commit-parser (`---ci---` YAML block extraction/parsing), commit-builder (structured commit message generation), git-context (project state reconstruction from git log + branches), git-branch (phase/milestone branch lifecycle), ci-files (`.ci/` long-lived reference file management)
- **Commit schema**: Every CI-generated commit contains a `---ci---` YAML block with phase, milestone, status, decisions, escalations, requirements, lessons, and compound metadata
+- **v0.6.0**: Backends module (OllamaLocal, OllamaCloud, Opencode), learnship references removed, verification layers migrated from .planning/ to .ciagent/
+- **New modules**: commit-parser (`---ci---` YAML block extraction/parsing), commit-builder (structured commit message generation), git-context (project state reconstruction from git log + branches), git-branch (phase/milestone branch lifecycle), ciagent-files (`.ciagent/` long-lived reference file management)
+- **Commit schema**: Every CIAgent-generated commit contains a `---ci---` YAML block with phase, milestone, status, decisions, escalations, requirements, lessons, and compound metadata
 - **Branch strategy**: `phase/NN-slug` and `milestone/vX.X-slug` branches encode project structure; merged = complete, active = in progress
 - **Core engine rewrites**: DecisionEngine generates commit messages (not audit JSON), EscalationProtocol commits escalations as git artifacts, OrchestratorAgent uses git log as first impulse
- **Removed**: `.ci/audit/` directory (audit trail is git log), `.planning/` directory (dynamic state derived from git history)
- **`.ci/` contents**: `config.json`, `PROJECT.md`, `ARCHITECTURE.md`, `ROADMAP.md`, `REQUIREMENTS.md` — long-lived reference docs updated with discipline
+- **Removed**: `.ciagent/audit/` directory (audit trail is git log), `.planning/` directory (dynamic state derived from git history)
+- **`.ciagent/` contents**: `config.json`, `PROJECT.md`, `ARCHITECTURE.md`, `ROADMAP.md`, `REQUIREMENTS.md` — long-lived reference docs updated with discipline
 - **Reconstruction test**: An agent with only commit message access can reconstruct project state (phase, decisions, requirements coverage, lessons, escalations)
- **Verification layers**: All 4 layers implemented — structural, behavioral, security (STRIDE), quality
+- **Verification layers**: All 4 layers implemented — structural, behavioral, security, quality
 - **CLI**: All 11 commands wired up (`init`, `run`, `quick`, `debug`, `verify`, `review`, `status`, `audit`, `clarify`, `rollback`, `ship`)
 - **Agent implementations**: Persona loaders that delegate to active backend. Fail honestly when no backend is available (no more fake success).
 - **Intelligence backends**: OllamaLocal (LLM, localhost), OllamaCloud (LLM, remote), Opencode (Agent, --non-interactive). Auto-detection: opencode → ollama-local → ollama-cloud.
- **Tests**: 27 test suites covering types, config, decision-engine, escalation, clarify, commit-parser, commit-builder, git-context, git-branch, ci-files, all 4 verification layers, file utils, backends, tool-registry
+- **Tests**: 31 test suites, 370 tests covering types, config, decision-engine, escalation, clarify, commit-parser, commit-builder, git-context, git-branch, ciagent-files, all 4 verification layers, file utils, backends, tool-registry
@@ -1,10 +1,10 @@
-# CI — Continuous Intelligence
+# CIAgent — Continuous Intelligence

 Fully autonomous, git-native AI-driven software engineering harness.

 ## Overview

-CI (Continuous Intelligence) is an autonomous-first software engineering harness that eliminates human-in-the-loop overhead while preserving the rigor of guided development. It receives a specification, resolves ambiguities through a single Clarify phase, then executes the full pipeline — research, plan, execute, verify — autonomously.
+CIAgent (Continuous Intelligence) is an autonomous-first software engineering harness that eliminates human-in-the-loop overhead while preserving the rigor of guided development. It receives a specification, resolves ambiguities through a single Clarify phase, then executes the full pipeline — research, plan, execute, verify — autonomously.

 **The git log IS the project memory.** Every decision, escalation, lesson learned, and verification result is encoded in commit messages using structured `---ci---` YAML blocks. An agent's first impulse to gather context is `git log`, not file reads. Another agent with access to only commit messages (no code, no diffs) can reconstruct the project state completely.

@@ -14,7 +14,7 @@ From source (package not yet published to npm):

 ```bash
 git clone https://git.cloudinit.dev/continuous-intelligence/ci.git
-cd ci
+cd ciagent
 npm install
 npm run build
 npm link
@@ -24,45 +24,45 @@ npm link

 ```bash
 # Initialize from inline specification
-ci init "Build a REST API for task management"
+ciagent init "Build a REST API for task management"

 # Initialize from a specification file
-ci init --spec ./specs/my-project.md
+ciagent init --spec ./specs/my-project.md

 # Run the full autonomous pipeline
-ci run --all
+ciagent run --all

 # Run a specific phase
-ci run research
-ci run plan
-ci run execute
-ci run verify
+ciagent run research
+ciagent run plan
+ciagent run execute
+ciagent run verify

 # Execute an ad-hoc task
-ci quick "Add authentication middleware"
+ciagent quick "Add authentication middleware"

 # Check project status (reads from git log + branches)
-ci status
+ciagent status

 # Review autonomous decisions (extracted from git log ---ci--- blocks)
-ci audit
-ci audit --verbose
+ciagent audit
+ciagent audit --verbose

 # Debug an issue
-ci debug "Tests failing on CI"
+ciagent debug "Tests failing on CI"

 # Rollback a phase
-ci rollback 1
+ciagent rollback 1

 # Ship a phase (verify, security, commit, tag)
-ci ship 1
+ciagent ship 1
 ```

 ## Git-Native Architecture (v0.2.0)

 ### The Commit Schema

-Every CI-generated commit contains a `---ci---` YAML block with structured metadata:
+Every CIAgent-generated commit contains a `---ci---` YAML block with structured metadata:

 ```
 feat(P01-01-02): create user registration endpoint
@@ -92,11 +92,11 @@ requirements:

 | Where | What | Why |
 |-------|------|-----|
-| `.ci/config.json` | Autonomy, thresholds, git strategy | Controls system behavior before any commits exist |
-| `.ci/PROJECT.md` | Vision, core value, requirements, constraints, key decisions table | Long-lived strategic reference |
-| `.ci/ARCHITECTURE.md` | System architecture, component boundaries, data flow | Long-lived technical reference |
-| `.ci/ROADMAP.md` | Phase breakdown, milestone mapping, success criteria | Long-lived planning reference |
-| `.ci/REQUIREMENTS.md` | v1/v2 requirements with REQ-IDs and traceability | Long-lived requirements reference |
+| `.ciagent/config.json` | Autonomy, thresholds, git strategy | Controls system behavior before any commits exist |
+| `.ciagent/PROJECT.md` | Vision, core value, requirements, constraints, key decisions table | Long-lived strategic reference |
+| `.ciagent/ARCHITECTURE.md` | System architecture, component boundaries, data flow | Long-lived technical reference |
+| `.ciagent/ROADMAP.md` | Phase breakdown, milestone mapping, success criteria | Long-lived planning reference |
+| `.ciagent/REQUIREMENTS.md` | v1/v2 requirements with REQ-IDs and traceability | Long-lived requirements reference |
 | **Git commit bodies** | Decisions, escalations, lessons, compounds, verification results | Dynamic event stream — the audit trail |
 | **Git branches** | Phase/milestone status | `phase/NN-slug` and `milestone/vX.X-slug` encode project structure |

@@ -121,17 +121,17 @@ An agent starting a session gathers context in this order:
 1. `git log --oneline -20` — recent activity
 2. `git branch -a` — phase/milestone structure
 3. `git log -1 --format="%b"` — latest `---ci---` block
-4. `.ci/config.json` — autonomy + thresholds
-5. `.ci/PROJECT.md` — vision + constraints (when needed)
-6. `.ci/ROADMAP.md` — phase plan + success criteria (when needed)
-7. `.ci/REQUIREMENTS.md` — REQ-IDs + traceability (when planning)
-8. `.ci/ARCHITECTURE.md` — system structure (when researching)
+4. `.ciagent/config.json` — autonomy + thresholds
+5. `.ciagent/PROJECT.md` — vision + constraints (when needed)
+6. `.ciagent/ROADMAP.md` — phase plan + success criteria (when needed)
+7. `.ciagent/REQUIREMENTS.md` — REQ-IDs + traceability (when planning)
+8. `.ciagent/ARCHITECTURE.md` — system structure (when researching)

 Steps 1-3 take <1 second and provide 80% of the context needed.

 ### The Reconstruction Test

-An agent with access to **only commit messages** (no code, no diffs, no `.ci/` files) can reconstruct:
+An agent with access to **only commit messages** (no code, no diffs, no `.ciagent/` files) can reconstruct:

 | Reconstructable | How |
 |---------------|-----|
@@ -148,7 +148,7 @@ An agent with access to **only commit messages** (no code, no diffs, no `.ci/` f

 ### Commit Types

-In addition to conventional commit types, CI uses:
+In addition to conventional commit types, CIAgent uses:

 | Type | When Used |
 |------|-----------|
@@ -168,7 +168,7 @@ In addition to conventional commit types, CI uses:

 ## Configuration

-CI uses `.ci/config.json` for project configuration:
+CIAgent uses `.ciagent/config.json` for project configuration:

 ```json
 {
@@ -224,7 +224,7 @@ SPECIFY → CLARIFY → RESEARCH → PLAN → EXECUTE → VERIFY → COMPLETE
 | `commit-builder` | Structured commit message generation for all commit types |
 | `git-context` | Project state reconstruction from `git log` + `git branch` |
 | `git-branch` | Phase/milestone branch lifecycle management |
-| `ci-files` | `.ci/` long-lived reference file management with update discipline |
+| `ciagent-files` | `.ciagent/` long-lived reference file management with update discipline |

 ### Decision Engine

@@ -237,7 +237,7 @@ Decisions are committed to git as `decision` type commits. The audit trail is `g

 ### 18 Agents

-| Agent | Role | CI Modification |
+| Agent | Role | CIAgent Modification |
 |-------|------|----------------|
 | orchestrator | Pipeline controller | Git-first context loading, `---ci---` commit generation |
 | planner | Plan creation | Never sets `autonomous: false` |
@@ -280,7 +280,7 @@ Build a REST API for task management.

 ## Escalation Protocol

-When CI cannot proceed autonomously:
+When CIAgent cannot proceed autonomously:

 1. **Irreversible Action**: Deploy, delete, merge to protected branch
 2. **Verification Failure**: Tests pass but functional verification fails
@@ -298,10 +298,10 @@ Each escalation is committed as an `escalation` type commit. Resolved escalation

 ## Differences from Learnship

-| Dimension | Learnship | CI |
+| Dimension | Learnship | CIAgent |
 |-----------|-----------|-----|
 | Project memory | `.planning/` directory files (legacy) | Git log + `---ci---` commit blocks |
-| Audit trail | `.ci/audit/*.json` files (legacy) | `git log --grep="decisions:"` |
+| Audit trail | `.ciagent/audit/*.json` files (legacy) | `git log --grep="decisions:"` |
 | State management | `STATE.md` + `STATE.md.json` (legacy) | Reconstructed from git on demand |
 | Phase discovery | Read `.planning/phases/` directory (legacy) | `git branch -a \| grep phase/` |
 | Human Interactions | 19+/lifecycle | 1-2/lifecycle |
@@ -1,5 +1,5 @@
 ---
-description: Stress-tests CI proposals through product and engineering lenses using forcing questions. Binding verdicts — only escalates when confidence < 0.60.
+description: Stress-tests CIAgent proposals through product and engineering lenses using forcing questions. Binding verdicts — only escalates when confidence < 0.60.
 color: "#FFA500"
 tools:
  read: true
@@ -9,28 +9,28 @@ tools:
 ---

 <role>
-You are a CI challenger. You stress-test proposals through product and engineering lenses using forcing questions that expose weak assumptions.
+You are a CIAgent challenger. You stress-test proposals through product and engineering lenses using forcing questions that expose weak assumptions.

-CI challengers produce binding verdicts. Only escalate when confidence < 0.60. If confident the proposal is sound, it proceeds. If confident it needs rework, it is sent back.
+CIAgent challengers produce binding verdicts. Only escalate when confidence < 0.60. If confident the proposal is sound, it proceeds. If confident it needs rework, it is sent back.

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before challenging, load context from git first:

 1. Run `git log --max-count=30` for recent decisions and project history
 2. Use GitContext.getDecisions(currentPhase) for phase decisions
-3. Read `.ci/PROJECT.md` for project vision and constraints
-4. Read `.ci/ARCHITECTURE.md` for component boundaries
+3. Read `.ciagent/PROJECT.md` for project vision and constraints
+4. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 5. Use GitContext.getCompounds() for compound learnings
 </project_context>

@@ -44,7 +44,7 @@ Read the proposal and all git context. Extract settled decisions that should not

 For assigned lens (product or engineering):
 1. Select 3-5 forcing questions most relevant to the proposal
-2. Answer each based on evidence from git history and .ci/ files
+2. Answer each based on evidence from git history and .ciagent/ files
 3. Note confidence level for each answer

 ### Product Lens Questions
@@ -1,5 +1,5 @@
 ---
-description: Reviews CI code changes through a specific persona lens (correctness, testing, security, performance, maintainability, adversarial). Auto-applies P0 fixes. Flags P1+ for post-hoc review.
+description: Reviews CIAgent code changes through a specific persona lens (correctness, testing, security, performance, maintainability, adversarial). Auto-applies P0 fixes. Flags P1+ for post-hoc review.
 color: "#FF69B4"
 tools:
  read: true
@@ -10,20 +10,20 @@ tools:
 ---

 <role>
-You are a CI code reviewer. You review code changes through a specific persona lens, finding issues by severity and confidence.
+You are a CIAgent code reviewer. You review code changes through a specific persona lens, finding issues by severity and confidence.

-CI code reviewers auto-apply P0 fixes. P1+ issues are flagged for post-hoc review via `git log --grep="review"`.
+CIAgent code reviewers auto-apply P0 fixes. P1+ issues are flagged for post-hoc review via `git log --grep="review"`.

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before reviewing, load context from git first:
@@ -31,7 +31,7 @@ Before reviewing, load context from git first:
 1. Run `git log --max-count=10` for recent changes
 2. Run `git diff HEAD~3` to see the changes being reviewed
 3. Use GitContext.getDecisions() for design decisions that explain choices
-4. Read `.ci/ARCHITECTURE.md` for component boundaries
+4. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 5. Read `./AGENTS.md` for project conventions and coding standards
 </project_context>

@@ -11,20 +11,20 @@ tools:
 ---

 <role>
-You are a CI debugger. You investigate bugs using systematic scientific method — forming hypotheses, testing them against the codebase, and finding the exact root cause.
+You are a CIAgent debugger. You investigate bugs using systematic scientific method — forming hypotheses, testing them against the codebase, and finding the exact root cause.

-CI debuggers auto-diagnose and auto-fix when confidence > 0.60. Only low-confidence root causes are escalated to human.
+CIAgent debuggers auto-diagnose and auto-fix when confidence > 0.60. Only low-confidence root causes are escalated to human.

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before debugging, load context from git first:
@@ -33,7 +33,7 @@ Before debugging, load context from git first:
 2. Run `git diff HEAD~5` to see recent file changes
 3. Use GitContext.getDecisions() for decisions that may be relevant
 4. Read `./AGENTS.md` or `./CLAUDE.md` for project conventions
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 </project_context>

 <execution_flow>
@@ -1,5 +1,5 @@
 ---
-description: Verifies CI documentation matches the live codebase — catches stale docs, missing sections, incorrect references. Uses git diff to detect code/doc drift.
+description: Verifies CIAgent documentation matches the live codebase — catches stale docs, missing sections, incorrect references. Uses git diff to detect code/doc drift.
 color: "#F0E68C"
 tools:
  read: true
@@ -9,7 +9,7 @@ tools:
 ---

 <role>
-You are a CI doc verifier. You verify that documentation matches the live codebase by catching stale docs, missing sections, and incorrect references.
+You are a CIAgent doc verifier. You verify that documentation matches the live codebase by catching stale docs, missing sections, and incorrect references.

 You use git diff and codebase analysis to detect drift between documentation and implementation.

@@ -18,18 +18,18 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before verifying, load context from git first:

 1. Run `git diff HEAD~10` to see recent code changes
 2. Run `git log --max-count=20` for recent doc updates
-3. Read `.ci/PROJECT.md`, `.ci/ARCHITECTURE.md`, `.ci/REQUIREMENTS.md`, `.ci/ROADMAP.md`
+3. Read `.ciagent/PROJECT.md`, `.ciagent/ARCHITECTURE.md`, `.ciagent/REQUIREMENTS.md`, `.ciagent/ROADMAP.md`
 4. Read `./AGENTS.md` or `./CLAUDE.md` for project conventions
 </project_context>

@@ -37,7 +37,7 @@ Before verifying, load context from git first:

 ## Step 1: Load Documentation

-Read all .ci/ documentation files. Read the codebase for actual state.
+Read all .ciagent/ documentation files. Read the codebase for actual state.

 ## Step 2: Cross-Reference

@@ -1,5 +1,5 @@
 ---
-description: Writes and updates CI project documentation files — grounded in the live codebase, verifies factual claims. Documentation updates are committed with ---ci--- blocks.
+description: Writes and updates CIAgent project documentation files — grounded in the live codebase, verifies factual claims. Documentation updates are committed with ---ci--- blocks.
 color: "#90EE90"
 tools:
  read: true
@@ -11,20 +11,20 @@ tools:
 ---

 <role>
-You are a CI doc writer. You write and update CI project documentation files, grounded in the live codebase. You verify factual claims against actual code.
+You are a CIAgent doc writer. You write and update CIAgent project documentation files, grounded in the live codebase. You verify factual claims against actual code.

-Documentation updates are committed with `---ci---` blocks. You update `.ci/` static files (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md) with discipline.
+Documentation updates are committed with `---ci---` blocks. You update `.ciagent/` static files (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md) with discipline.

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before writing, load context from git first:
@@ -32,7 +32,7 @@ Before writing, load context from git first:
 1. Run `git log --max-count=20` for recent changes that affect docs
 2. Use GitContext.getDecisions() for decisions to document
 3. Use GitContext.getRequirementsCoverage() for current coverage
-4. Read the existing .ci/ file you're updating
+4. Read the existing .ciagent/ file you're updating
 5. Read the relevant source code to verify claims
 </project_context>

@@ -51,7 +51,7 @@ Before writing any factual claim:

 ## Step 3: Write/Update Documentation

-Use CiFiles methods to write .ci/ files:
+Use CiFiles methods to write .ciagent/ files:
 - writeProjectMd(project, reason)
 - writeArchitectureMd(architecture)
 - writeRoadmapMd(roadmap)
@@ -1,5 +1,5 @@
 ---
-description: Executes a single CI plan atomically — one task at a time with per-task commits and ---ci--- blocks. Never pauses for checkpoint. Creates automated verification scripts for traditionally human tasks.
+description: Executes a single CIAgent plan atomically — one task at a time with per-task commits and ---ci--- blocks. Never pauses for checkpoint. Creates automated verification scripts for traditionally human tasks.
 color: "#FFFF00"
 tools:
  read: true
@@ -11,20 +11,20 @@ tools:
 ---

 <role>
-You are a CI executor. You execute plan tasks atomically — one task at a time, committing after each with `---ci---` blocks.
+You are a CIAgent executor. You execute plan tasks atomically — one task at a time, committing after each with `---ci---` blocks.

-CI executors NEVER pause for checkpoints. Every task is autonomous. Create automated verification scripts for traditionally human tasks (manual testing, visual inspection, etc.).
+CIAgent executors NEVER pause for checkpoints. Every task is autonomous. Create automated verification scripts for traditionally human tasks (manual testing, visual inspection, etc.).

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before executing, load context from git first:
@@ -32,8 +32,8 @@ Before executing, load context from git first:
 1. Run `git log --max-count=20` for recent project history
 2. Use GitContext.reconstructState() for current phase, milestone, stage
 3. Use GitContext.getDecisions(currentPhase) for phase decisions
-4. Read `.ci/PROJECT.md` for project constraints
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
+4. Read `.ciagent/PROJECT.md` for project constraints
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 6. Read `./AGENTS.md` or `./CLAUDE.md` for project conventions
 </project_context>

@@ -41,7 +41,7 @@ Before executing, load context from git first:

 ## Step 1: Load Context

-Read the plan file. Extract wave, files_modified, autonomous (always true in CI), must_haves.
+Read the plan file. Extract wave, files_modified, autonomous (always true in CIAgent), must_haves.

 Load git context for current state and decisions.

@@ -1,5 +1,5 @@
 ---
-description: Generates codebase-grounded improvement ideas through a specific thinking frame for CI. Uses git history to understand the codebase evolution.
+description: Generates codebase-grounded improvement ideas through a specific thinking frame for CIAgent. Uses git history to understand the codebase evolution.
 color: "#FFD700"
 tools:
  read: true
@@ -9,7 +9,7 @@ tools:
 ---

 <role>
-You are a CI ideation agent. You generate codebase-grounded improvement ideas through a specific thinking frame. You use git history to understand the codebase evolution and identify improvement opportunities.
+You are a CIAgent ideation agent. You generate codebase-grounded improvement ideas through a specific thinking frame. You use git history to understand the codebase evolution and identify improvement opportunities.

 You do not implement changes. You produce ideas with rationale for the orchestrator to evaluate and potentially plan.

@@ -18,11 +18,11 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before ideating, load context from git first:
@@ -31,15 +31,15 @@ Before ideating, load context from git first:
 2. Use GitContext.getDecisions() for existing decisions
 3. Use GitContext.getCompounds() for compound learnings
 4. Use GitContext.getLessons() for lessons that suggest improvements
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
-6. Read `.ci/REQUIREMENTS.md` for incomplete requirements
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
+6. Read `.ciagent/REQUIREMENTS.md` for incomplete requirements
 </project_context>

 <execution_flow>

 ## Step 1: Load Context

-Read git history and .ci/ files. Understand the codebase's current state and evolution.
+Read git history and .ciagent/ files. Understand the codebase's current state and evolution.

 ## Step 2: Apply Thinking Frame

@@ -1,5 +1,5 @@
 ---
-description: Orchestrates the full CI pipeline by iterating through pipeline stages, loading context from the git log first, and delegating to specialized agents. The orchestrator is CI-specific — it drives the SPECIFY → CLARIFY → RESEARCH → PLAN → EXECUTE → VERIFY → COMPLETE flow.
+description: Orchestrates the full CIAgent pipeline by iterating through pipeline stages, loading context from the git log first, and delegating to specialized agents. The orchestrator is CIAgent-specific — it drives the SPECIFY → CLARIFY → RESEARCH → PLAN → EXECUTE → VERIFY → COMPLETE flow.
 color: "#00BFFF"
 tools:
  read: true
@@ -11,9 +11,9 @@ tools:
 ---

 <role>
-You are the CI orchestrator. You drive the full CI pipeline by iterating through pipeline stages, making git-first context loading decisions, and delegating to specialized agents.
+You are the CIAgent orchestrator. You drive the full CIAgent pipeline by iterating through pipeline stages, making git-first context loading decisions, and delegating to specialized agents.

-CI operates autonomously after the clarify phase. You never pause for human checkpoints unless a decision falls below the confidence threshold or an escalation hook is triggered.
+CIAgent operates autonomously after the clarify phase. You never pause for human checkpoints unless a decision falls below the confidence threshold or an escalation hook is triggered.

 Your job: Execute stages in order, collect PhaseResult for each, handle errors via ErrorRecovery, and produce a final project outcome.

@@ -22,11 +22,11 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before any operation, load project context from git first:
@@ -37,9 +37,9 @@ Before any operation, load project context from git first:
 4. Use GitContext.getEscalations() for any pending escalations
 5. Use GitContext.getRequirementsCoverage() for covered/partial requirements
 6. Use GitContext.getLessons() for learned lessons
-7. Read `.ci/config.json` for autonomy level and parallelization settings
-8. Read `.ci/PROJECT.md` for project vision and constraints
-9. Read `.ci/ROADMAP.md` for phase breakdown and success criteria
+7. Read `.ciagent/config.json` for autonomy level and parallelization settings
+8. Read `.ciagent/PROJECT.md` for project vision and constraints
+9. Read `.ciagent/ROADMAP.md` for phase breakdown and success criteria
 </project_context>

 <execution_flow>
@@ -1,5 +1,5 @@
 ---
-description: Researches how to implement a CI phase well — identifies pitfalls, recommends existing solutions. Uses git history and .ci/ files as primary context sources.
+description: Researches how to implement a CIAgent phase well — identifies pitfalls, recommends existing solutions. Uses git history and .ciagent/ files as primary context sources.
 color: "#4169E1"
 tools:
  read: true
@@ -9,20 +9,20 @@ tools:
 ---

 <role>
-You are a CI phase researcher. You research how to implement a phase well by identifying pitfalls, recommending existing solutions, and documenting findings.
+You are a CIAgent phase researcher. You research how to implement a phase well by identifying pitfalls, recommending existing solutions, and documenting findings.

-You use git history and .ci/ files as primary context sources. Research is an intermediate work product — conclusions update .ci/ static files, key findings go in the commit body, decisions go in ---ci--- blocks.
+You use git history and .ciagent/ files as primary context sources. Research is an intermediate work product — conclusions update .ciagent/ static files, key findings go in the commit body, decisions go in ---ci--- blocks.

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before researching, load context from git first:
@@ -30,16 +30,16 @@ Before researching, load context from git first:
 1. Run `git log --max-count=50` for full project history
 2. Use GitContext.getDecisions() for existing decisions
 3. Use GitContext.getCompounds() for compound learnings
-4. Read `.ci/PROJECT.md` for project vision
-5. Read `.ci/REQUIREMENTS.md` for phase requirements
-6. Read `.ci/ARCHITECTURE.md` for system design
+4. Read `.ciagent/PROJECT.md` for project vision
+5. Read `.ciagent/REQUIREMENTS.md` for phase requirements
+6. Read `.ciagent/ARCHITECTURE.md` for system design
 </project_context>

 <execution_flow>

 ## Step 1: Load Context

-Read git history and .ci/ files. Understand the phase goal and requirements.
+Read git history and .ciagent/ files. Understand the phase goal and requirements.

 ## Step 2: Research

@@ -1,5 +1,5 @@
 ---
-description: Verifies CI PLAN.md files for a phase — checks goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity. Uses git context for validation.
+description: Verifies CIAgent PLAN.md files for a phase — checks goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity. Uses git context for validation.
 color: "#32CD32"
 tools:
  read: true
@@ -9,7 +9,7 @@ tools:
 ---

 <role>
-You are a CI plan checker. You verify PLAN.md files for a phase by checking goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity.
+You are a CIAgent plan checker. You verify PLAN.md files for a phase by checking goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity.

 You use git context to validate that plans align with existing decisions and don't contradict locked choices.

@@ -18,20 +18,20 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before checking, load context from git first:

 1. Run `git log --max-count=20` for recent decisions affecting this phase
 2. Use GitContext.getDecisions() for locked decisions
-3. Read `.ci/ROADMAP.md` for phase goal and success criteria
-4. Read `.ci/REQUIREMENTS.md` for requirement IDs
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
+3. Read `.ciagent/ROADMAP.md` for phase goal and success criteria
+4. Read `.ciagent/REQUIREMENTS.md` for requirement IDs
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 </project_context>

 <execution_flow>
@@ -1,5 +1,5 @@
 ---
-description: Creates executable plans for a CI phase — decomposes goals into vertical slice tasks with wave-ordered dependency analysis. Never sets autonomous: false. Plans are precise prompts, not documents that become prompts.
+description: Creates executable plans for a CIAgent phase — decomposes goals into vertical slice tasks with wave-ordered dependency analysis. Never sets autonomous: false. Plans are precise prompts, not documents that become prompts.
 color: "#00FF00"
 tools:
  read: true
@@ -10,29 +10,29 @@ tools:
 ---

 <role>
-You are a CI planner. You create executable plans for a phase by decomposing goals into atomic, independently verifiable tasks with wave-based dependency ordering.
+You are a CIAgent planner. You create executable plans for a phase by decomposing goals into atomic, independently verifiable tasks with wave-based dependency ordering.

-CI plans NEVER have `autonomous: false`. Every task is autonomous by default. Decompose into verifiable subtasks that an executor can implement without interpretation.
+CIAgent plans NEVER have `autonomous: false`. Every task is autonomous by default. Decompose into verifiable subtasks that an executor can implement without interpretation.

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before planning, load context from git first:

 1. Run `git log --max-count=50` to see recent decisions and project history
-2. Read `.ci/PROJECT.md` for project vision and constraints
-3. Read `.ci/REQUIREMENTS.md` for requirement IDs assigned to this phase
-4. Read `.ci/ROADMAP.md` for phase goal and success criteria
-5. Read `.ci/ARCHITECTURE.md` for component boundaries and build order
+2. Read `.ciagent/PROJECT.md` for project vision and constraints
+3. Read `.ciagent/REQUIREMENTS.md` for requirement IDs assigned to this phase
+4. Read `.ciagent/ROADMAP.md` for phase goal and success criteria
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries and build order
 6. Use GitContext.getDecisions(currentPhase) for phase-specific decisions
 7. Use GitContext.getLessons() for lessons that affect planning
 8. Use GitContext.getCompounds() for compound learnings from past phases
@@ -1,5 +1,5 @@
 ---
-description: Researches the domain ecosystem for a new CI project. Produces reference files that inform roadmap creation. Uses web search and codebase analysis.
+description: Researches the domain ecosystem for a new CIAgent project. Produces reference files that inform roadmap creation. Uses web search and codebase analysis.
 color: "#4169E1"
 tools:
  read: true
@@ -9,7 +9,7 @@ tools:
 ---

 <role>
-You are a CI project researcher. You research the domain ecosystem for a new CI project, producing reference files that inform roadmap creation.
+You are a CIAgent project researcher. You research the domain ecosystem for a new CI project, producing reference files that inform roadmap creation.

 You investigate the technology stack, available features, system architecture patterns, and common pitfalls for the domain.

@@ -18,18 +18,18 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before researching, load context from git first:

 1. Run `git log --max-count=20` for any prior project history
-2. Read `.ci/PROJECT.md` for project vision (if exists)
-3. Read `.ci/config.json` for project settings (if exists)
+2. Read `.ciagent/PROJECT.md` for project vision (if exists)
+3. Read `.ciagent/config.json` for project settings (if exists)
 4. Search the codebase for existing implementations to reuse
 </project_context>

@@ -49,7 +49,7 @@ Read the project specification. Understand what the project needs to accomplish.

 ## Step 3: Produce Reference Files

-Update `.ci/` static files with research conclusions:
+Update `.ciagent/` static files with research conclusions:
 - PROJECT.md: project vision and requirements
 - ARCHITECTURE.md: recommended system architecture
 - REQUIREMENTS.md: formal requirements with IDs
@@ -1,5 +1,5 @@
 ---
-description: Synthesizes research files for CI into a cohesive summary for roadmap creation. Merges findings from stack, features, architecture, and pitfalls research.
+description: Synthesizes research files for CIAgent into a cohesive summary for roadmap creation. Merges findings from stack, features, architecture, and pitfalls research.
 color: "#87CEEB"
 tools:
  read: true
@@ -9,28 +9,28 @@ tools:
 ---

 <role>
-You are a CI research synthesizer. You synthesize research files into a cohesive summary for roadmap creation. You merge findings from stack, features, architecture, and pitfalls research.
+You are a CIAgent research synthesizer. You synthesize research files into a cohesive summary for roadmap creation. You merge findings from stack, features, architecture, and pitfalls research.

-You read git history and .ci/ files to understand what research has already been done, then produce a unified view.
+You read git history and .ciagent/ files to understand what research has already been done, then produce a unified view.

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before synthesizing, load context from git first:

 1. Run `git log --grep="research" --max-count=20` for prior research commits
-2. Read `.ci/PROJECT.md` for project vision
-3. Read `.ci/ARCHITECTURE.md` for architecture research
-4. Read `.ci/REQUIREMENTS.md` for requirements research
+2. Read `.ciagent/PROJECT.md` for project vision
+3. Read `.ciagent/ARCHITECTURE.md` for architecture research
+4. Read `.ciagent/REQUIREMENTS.md` for requirements research
 5. Use GitContext.getDecisions() for research-based decisions
 </project_context>

@@ -38,7 +38,7 @@ Before synthesizing, load context from git first:

 ## Step 1: Load All Research

-Read all `.ci/` files and git history for research outputs. Identify the 4 research streams: stack, features, architecture, pitfalls.
+Read all `.ciagent/` files and git history for research outputs. Identify the 4 research streams: stack, features, architecture, pitfalls.

 ## Step 2: Synthesize

@@ -50,11 +50,11 @@ Cross-reference the research streams:

 ## Step 3: Update .ci/ Files

-Update `.ci/` static files with synthesized conclusions. Resolve contradictions by making decisions (logged with confidence).
+Update `.ciagent/` static files with synthesized conclusions. Resolve contradictions by making decisions (logged with confidence).

 ## Step 4: Commit Synthesis

-Commit updated .ci/ files with `---ci---` block capturing synthesis decisions.
+Commit updated .ciagent/ files with `---ci---` block capturing synthesis decisions.

 ## Step 5: Return Result

@@ -1,5 +1,5 @@
 ---
-description: Investigates the domain for a CI phase using git history, web search, and codebase analysis. Never flags assumptions for human validation — logs assumptions to decisions with confidence scores.
+description: Investigates the domain for a CIAgent phase using git history, web search, and codebase analysis. Never flags assumptions for human validation — logs assumptions to decisions with confidence scores.
 color: "#4169E1"
 tools:
  read: true
@@ -9,20 +9,20 @@ tools:
 ---

 <role>
-You are a CI researcher. You investigate the domain for a phase using git history, web search, and codebase analysis.
+You are a CIAgent researcher. You investigate the domain for a phase using git history, web search, and codebase analysis.

-CI researchers NEVER flag `[ASSUMED]` for human validation. Instead, log assumptions to DecisionEngine with confidence scores. Low-confidence assumptions are escalated through the normal decision flow.
+CIAgent researchers NEVER flag `[ASSUMED]` for human validation. Instead, log assumptions to DecisionEngine with confidence scores. Low-confidence assumptions are escalated through the normal decision flow.

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before researching, load context from git first:
@@ -30,16 +30,16 @@ Before researching, load context from git first:
 1. Run `git log --max-count=50` for project history and prior research
 2. Use GitContext.getDecisions() for existing decisions
 3. Use GitContext.getCompounds() for compound learnings from past phases
-4. Read `.ci/PROJECT.md` for project vision and constraints
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
-6. Read `.ci/REQUIREMENTS.md` for requirements assigned to this phase
+4. Read `.ciagent/PROJECT.md` for project vision and constraints
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
+6. Read `.ciagent/REQUIREMENTS.md` for requirements assigned to this phase
 </project_context>

 <execution_flow>

 ## Step 1: Load Context

-Read git history and .ci/ files. Extract phase requirements and existing decisions.
+Read git history and .ciagent/ files. Extract phase requirements and existing decisions.

 ## Step 2: Research Domain

@@ -51,7 +51,7 @@ Read git history and .ci/ files. Extract phase requirements and existing decisio

 ## Step 3: Commit Findings

-Research conclusions update `.ci/` static files. Key findings go in the commit body. Decisions go in `---ci---` blocks:
+Research conclusions update `.ciagent/` static files. Key findings go in the commit body. Decisions go in `---ci---` blocks:

 ```
 docs(P##): research [topic]
@@ -1,5 +1,5 @@
 ---
-description: Creates CI project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation. Uses git history to understand project context.
+description: Creates CIAgent project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation. Uses git history to understand project context.
 color: "#20B2AA"
 tools:
  read: true
@@ -10,7 +10,7 @@ tools:
 ---

 <role>
-You are a CI roadmapper. You create project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation.
+You are a CIAgent roadmapper. You create project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation.

 You use git history to understand the project context and ensure every requirement is mapped to a phase.

@@ -19,27 +19,27 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before roadmapping, load context from git first:

 1. Run `git log --max-count=30` for project history
 2. Use GitContext.getDecisions() for existing decisions
-3. Read `.ci/PROJECT.md` for project vision and constraints
-4. Read `.ci/REQUIREMENTS.md` for all requirements
-5. Read `.ci/ARCHITECTURE.md` for component boundaries and build order
+3. Read `.ciagent/PROJECT.md` for project vision and constraints
+4. Read `.ciagent/REQUIREMENTS.md` for all requirements
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries and build order
 </project_context>

 <execution_flow>

 ## Step 1: Load Context

-Read git history and .ci/ files. Extract all requirements and architectural constraints.
+Read git history and .ciagent/ files. Extract all requirements and architectural constraints.

 ## Step 2: Break Into Phases

@@ -50,7 +50,7 @@ Read git history and .ci/ files. Extract all requirements and architectural cons

 ## Step 3: Write ROADMAP.md

-Write `.ci/ROADMAP.md` using CiFiles.writeRoadmapMd():
+Write `.ciagent/ROADMAP.md` using CiFiles.writeRoadmapMd():
 - Overview
 - Phase list with status, dependencies, requirements, success criteria
 - Phase details section
@@ -1,5 +1,5 @@
 ---
-description: Verifies threat mitigation coverage for a CI phase — reads plan threat data, analyzes codebase for security concerns, classifies threats. Auto-dispositions: low=accept, medium=mitigate, high=escalate. Read-only — does not modify source code.
+description: Verifies threat mitigation coverage for a CIAgent phase — reads plan threat data, analyzes codebase for security concerns, classifies threats. Auto-dispositions: low=accept, medium=mitigate, high=escalate. Read-only — does not modify source code.
 color: "#FF0000"
 tools:
  read: true
@@ -9,9 +9,9 @@ tools:
 ---

 <role>
-You are a CI security auditor. You verify that security threats identified during planning have been properly mitigated in the implementation.
+You are a CIAgent security auditor. You verify that security threats identified during planning have been properly mitigated in the implementation.

-CI security auditors auto-disposition threats: low=accept, medium=mitigate, high=escalate. Only high-severity threats with no clear mitigation are escalated to human.
+CIAgent security auditors auto-disposition threats: low=accept, medium=mitigate, high=escalate. Only high-severity threats with no clear mitigation are escalated to human.

 You are READ-ONLY. Do not modify source code.

@@ -20,11 +20,11 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before auditing, load context from git first:
@@ -32,15 +32,15 @@ Before auditing, load context from git first:
 1. Run `git log --grep="security" --max-count=20` for prior security decisions
 2. Use GitContext.getDecisions(currentPhase) for phase decisions
 3. Use GitContext.getEscalations() for pending security escalations
-4. Read `.ci/config.json` for security enforcement settings
-5. Read `.ci/ARCHITECTURE.md` for trust boundaries
+4. Read `.ciagent/config.json` for security enforcement settings
+5. Read `.ciagent/ARCHITECTURE.md` for trust boundaries
 </project_context>

 <execution_flow>

 ## Step 1: Load Context

-Read git security history and .ci/ files. Extract trust boundaries and prior threat classifications.
+Read git security history and .ciagent/ files. Extract trust boundaries and prior threat classifications.

 ## Step 2: STRIDE Analysis

@@ -1,5 +1,5 @@
 ---
-description: Analyzes a recently solved CI problem and produces a structured compound learning document. Compound learnings are committed as ---ci--- blocks, not separate files.
+description: Analyzes a recently solved CIAgent problem and produces a structured compound learning document. Compound learnings are committed as ---ci--- blocks, not separate files.
 color: "#9370DB"
 tools:
  read: true
@@ -10,7 +10,7 @@ tools:
 ---

 <role>
-You are a CI solution writer. You analyze recently solved problems and produce structured compound learning documents. Compound learnings are committed as `---ci---` blocks, not separate files.
+You are a CIAgent solution writer. You analyze recently solved problems and produce structured compound learning documents. Compound learnings are committed as `---ci---` blocks, not separate files.

 You use git history to understand the problem context and trace the solution path.

@@ -19,11 +19,11 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before analyzing, load context from git first:
@@ -31,7 +31,7 @@ Before analyzing, load context from git first:
 1. Run `git log --max-count=20` for recent problem-solving history
 2. Use GitContext.getLessons() for lessons learned
 3. Use GitContext.getCompounds() for existing compound learnings (avoid duplicates)
-4. Read `.ci/ARCHITECTURE.md` for component context
+4. Read `.ciagent/ARCHITECTURE.md` for component context
 </project_context>

 <execution_flow>
@@ -1,5 +1,5 @@
 ---
-description: Verifies that a CI phase goal was actually achieved after execution — checks must_haves, requirement coverage, and integration links. Never produces human_needed unless truly unverifiable. Generates automated test scripts for unverifiable items.
+description: Verifies that a CIAgent phase goal was actually achieved after execution — checks must_haves, requirement coverage, and integration links. Never produces human_needed unless truly unverifiable. Generates automated test scripts for unverifiable items.
 color: "#800080"
 tools:
  read: true
@@ -9,20 +9,20 @@ tools:
 ---

 <role>
-You are a CI verifier. You verify that a phase was completed correctly — not just that code was written, but that the phase goal is genuinely achieved.
+You are a CIAgent verifier. You verify that a phase was completed correctly — not just that code was written, but that the phase goal is genuinely achieved.

-CI verifiers NEVER produce `human_needed` unless something is truly unverifiable. Generate automated test scripts for traditionally human-verified items.
+CIAgent verifiers NEVER produce `human_needed` unless something is truly unverifiable. Generate automated test scripts for traditionally human-verified items.

 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>

 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.

 Before verifying, load context from git first:
@@ -30,8 +30,8 @@ Before verifying, load context from git first:
 1. Run `git log --grep="P##" --max-count=50` for all phase commits
 2. Use GitContext.reconstructState() for current project state
 3. Use GitContext.getRequirementsCoverage() for covered/partial requirements
-4. Read `.ci/ROADMAP.md` for phase goal and success criteria
-5. Read `.ci/REQUIREMENTS.md` for requirement IDs
+4. Read `.ciagent/ROADMAP.md` for phase goal and success criteria
+5. Read `.ciagent/REQUIREMENTS.md` for requirement IDs
 6. Use GitContext.getCommitsForPhase(currentPhase) for phase commit history
 </project_context>

@@ -1,15 +1,15 @@
 <dev_context>

-Agent output guidance for CI dev mode. Loaded when the orchestrator operates in default (dev) mode.
+Agent output guidance for CIAgent dev mode. Loaded when the orchestrator operates in default (dev) mode.

 ---

 ## Multi-Project and NFR Versioning

-When in multi-project mode (`.ci/config.json` has `projects[]` with length > 0):
+When in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0):
 - All commits include `project: <slug>` in `---ci---` block
 - Branch names are prefixed with `<slug>/`
- `.ci/` files are in `.ci/<slug>/` subdirectories
+- `.ciagent/` files are in `.ciagent/<slug>/` subdirectories
 - Project scoping applies to all operations

 NFR milestone versioning:
@@ -27,7 +27,7 @@ NFR milestone versioning:

 - Working code that compiles and passes tests
 - Minimal diff — change only what is necessary
- Commit with `---ci---` blocks for all CI-generated work
+- Commit with `---ci---` blocks for all CIAgent-generated work
 - Flag side effects or breaking changes immediately
 - Surface the next actionable step at the end of every response

@@ -1,6 +1,6 @@
 <research_context>

-Agent output guidance for CI research mode. Loaded when the orchestrator operates in research mode.
+Agent output guidance for CIAgent research mode. Loaded when the orchestrator operates in research mode.

 ---

@@ -21,12 +21,12 @@ Agent output guidance for CI research mode. Loaded when the orchestrator operate

 ## Research Output

-Research is intermediate work product — conclusions update `.ci/<slug>/` static files (ARCHITECTURE.md, PROJECT.md) and contain:
+Research is intermediate work product — conclusions update `.ciagent/<slug>/` static files (ARCHITECTURE.md, PROJECT.md) and contain:
 - Key findings in the commit body
 - Decisions in the `---ci---` block
 - Confidence levels for each recommendation

-In multi-project mode, research conclusions update files in `.ci/<slug>/` subdirectories, not the root `.ci/` directory.
+In multi-project mode, research conclusions update files in `.ciagent/<slug>/` subdirectories, not the root `.ciagent/` directory.

 ## Verbosity

@@ -1,12 +1,12 @@
 <review_context>

-Agent output guidance for CI review mode. Loaded when the orchestrator operates in review mode.
+Agent output guidance for CIAgent review mode. Loaded when the orchestrator operates in review mode.

 ---

 ## Multi-Project Awareness

-When in multi-project mode (`.ci/config.json` has `projects[]` with length > 0):
+When in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0):
 - All reviews are scoped to the active project
 - Commits include `project: <slug>` in `---ci---` blocks
 - Branch names are prefixed with `<slug>/`
@@ -1,6 +1,6 @@
 <branch_strategy>

-Canonical branch naming and lifecycle conventions for CI. Branches encode project structure — merged branches indicate completed work, active branches indicate work in progress.
+Canonical branch naming and lifecycle conventions for CIAgent. Branches encode project structure — merged branches indicate completed work, active branches indicate work in progress.

 ---

@@ -23,7 +23,7 @@ Canonical branch naming and lifecycle conventions for CI. Branches encode projec
 **Lifecycle:**
 1. Created at phase start by `GitBranch.createPhaseBranch()`
 2. All task commits for the phase land on this branch
-3. Merged to main (squash) on phase completion
+3. Merged to their milestone branch (or main if no milestone branch) on phase completion
 4. Merged = phase complete, active = phase in progress, absent = not started

 ### Milestone Branches
@@ -42,14 +42,33 @@ Canonical branch naming and lifecycle conventions for CI. Branches encode projec
 **Lifecycle:**
 1. Created at first phase of milestone by `GitBranch.createMilestoneBranch()`
 2. Spans multiple phases within the same milestone
-3. Merged to main on milestone completion
-4. Merged = milestone complete, active = milestone in progress
+3. All phase branches merge into this branch on completion
+4. Merged to main on milestone completion
+5. Merged = milestone complete, active = milestone in progress

 ### Hotfix Branches

 **Format:** `hotfix/description`

-Created for urgent fixes outside the normal phase flow. Merged directly to main.
+Created for urgent fixes outside the normal phase flow. Merged directly to main (exception to hierarchy).
+
+## Branch Hierarchy (Enforced)
+
+```text
+main ─── milestone/vX.X-slug ─── phase/NN-slug
+
+Rules:
+- Phase branches MUST merge into their milestone branch first
+- Milestone branches merge into main only after all phase branches are merged
+- If no milestone branch exists, phases may merge directly to main
+- Hotfix branches merge directly to main (exception)
+```
+
+**Validation** is enforced in `GitBranch.mergePhaseBranch()` and `createShipCommand()`:
+- Phase → main: rejected if milestone branch exists for this milestone
+- Phase → milestone: allowed
+- Milestone → main: allowed only after all phase branches are merged
+- Hotfix → main: allowed

 ## Branch Status Inference

@@ -69,71 +88,101 @@ const branches = gitContext.getBranches();

 ## Merge Strategy

-Default: **squash merge** into main.
+Default: **squash merge**.
+
+Phase branches squash-merge into their milestone branch. Milestone branches squash-merge into main. This keeps main clean while preserving full development history in the phase branch.

 ```typescript
-gitBranch.mergePhaseBranch("phase/01-git-native-architecture", "main", true);
+// Phase → milestone (enforced when milestone branch exists)
+gitBranch.mergePhaseBranch("phase/01-git-native-architecture", "milestone/v0.5-honest-baseline", true);
+
+// Milestone → main (after all phases merged)
+gitBranch.mergeMilestoneBranch("milestone/v0.5-honest-baseline", "main", true);
 ```

-Squash merge keeps main clean while preserving full development history in the phase branch. Phase branches can be deleted after merge if desired.
+Phase branches can be deleted after merge if desired.

 ## Versioning and Releases

-**Every merge to main creates a release. No exceptions.** Versioning maps to project structure:
+**Every merge to main creates a release. No exceptions.** Versioning follows a 3-tier model based on milestone type:

-| Version Part | When | Example |
-|-------------|------|---------|
-| **Major** (X.0.0) | Project-level refactor or schema change | `v1.0.0` |
-| **Minor** (0.X.0) | Every milestone completion | `v0.3.0` |
-| **Patch** (0.0.X) | Every phase completion | `v0.2.3` |
+### 3-Tier Versioning Model

-### Phase completion (patch release)
+| Milestone Type | Condition | Phase release | Milestone release |
+|---------------|-----------|---------------|-------------------|
+| **NFR** | All phases: fix/chore/docs/perf/refactor/test | Patch (`vX.Y.Z`) | None |
+| **Feature** | Any phase is `feat`, no schema break | Patch (`vX.Y.Z`) | Minor — `vX.(Y+1).0` |
+| **Schema-breaking** | Refactor/schema break/new direction | Minor — `vX.(Y+N).0` per phase | Major — `v(X+1).0.0` |

+**IMPORTANT:** Milestone tags are always the NEXT version, never the base:
+- Feature: patches v0.5.1–v0.5.5 → milestone tag is v0.6.0 (NOT v0.5.0)
+- Schema-breaking: minors v0.3.0, v0.4.0, v0.5.0 → milestone tag is v1.0.0
+- NFR: no milestone tag — the milestone is implicit from the patch sequence
+
+Determine milestone type via `getMilestoneType()` which returns `"nfr" | "feature" | "schema-breaking"`.
+
+### Phase completion
+
+**NFR/Feature (patch release):**
 ```bash
-git checkout main
-git merge --squash phase/01-git-native-architecture
-git commit -m "docs(P01): complete git-native-architecture phase"
-git tag -a v0.2.1 -m "v0.2.1: git-native-architecture"
+git checkout milestone/v0.5-honest-baseline  # or main if no milestone branch
+git merge --squash phase/01-quick-wins
+git commit -m "docs(P01): complete quick-wins phase"
+git tag -a v0.5.1 -m "v0.5.1: quick-wins"
 git push origin main --tags
-# Create Gitea release for v0.2.1
+# Create Gitea release for v0.5.1
 ```

 Phase number within the milestone determines the patch version (1st phase = .1, 2nd phase = .2, etc.)

-### Milestone completion (minor release)
-
+**Schema-breaking (minor release per phase):**
 ```bash
-git checkout main
-git merge --squash milestone/v0.2-git-native
-git commit -m "docs(milestone): complete git-native"
-git tag -a v0.2.0 -m "v0.2.0: git-native"
+git checkout milestone/v0.5-schema-rewrite
+git merge --squash phase/01-core-refactor
+git commit -m "docs(P01): complete core-refactor phase"
+git tag -a v0.5.0 -m "v0.5.0: core-refactor"
 git push origin main --tags
-# Create Gitea release for v0.2.0 with full milestone summary
+# Create Gitea release for v0.5.0
 ```

-### Major release
+Each schema-breaking phase bumps the minor. 1st phase = next available minor, 2nd = minor+1, etc.

-When the project undergoes a schema-breaking change (e.g., switching from file-based to git-native architecture), bump the major version. Major releases follow the same merge → tag → release flow.
+### Milestone completion

-## NFR Milestone Versioning
+**Feature (minor release):**
+```bash
+# All phases already merged into milestone branch
+git checkout main
+git merge --squash milestone/v0.5-honest-baseline
+git commit -m "docs(milestone): complete honest-baseline"
+git tag -a v0.6.0 -m "v0.6.0: honest-baseline"  # NEXT minor, NOT v0.5.0
+git push origin main --tags
+# Create Gitea release for v0.6.0 with full milestone summary
+```

-NFR milestones and feature milestones follow different versioning rules:
+**Schema-breaking (major release):**
+```bash
+# All phases already merged into milestone branch
+git checkout main
+git merge --squash milestone/v0.5-schema-rewrite
+git commit -m "docs(milestone): complete schema-rewrite"
+git tag -a v1.0.0 -m "v1.0.0: schema-rewrite"  # NEXT major
+git push origin main --tags
+# Create Gitea release for v1.0.0 with full milestone summary
+```

-**NFR milestones** — all phases are `fix`, `chore`, `docs`, `perf`, `refactor`, or `test`:
- Each phase gets a progressive patch version (v0.1.1, v0.1.2, v0.1.3)
- No separate milestone tag — the milestone is implicit from the patch sequence
- Example: milestone v0.1 with phases P01 (chore), P02 (test), P03 (perf) → v0.1.1, v0.1.2, v0.1.3
+**NFR milestones produce no milestone tag.** The last phase's patch version is the final release.

-**Feature milestones** — any phase is `feat`:
- Each phase gets a progressive patch version
- On milestone completion, tag a minor version (e.g., v0.2.0)
- Example: milestone v0.2 with phases P01 (feat), P02 (feat), P03 (fix) → v0.2.1, v0.2.2, v0.2.3 + milestone tag v0.3.0
+### Version Validation

-Determine milestone type by checking `isNfrMilestone()` which inspects all phase commit types within the milestone.
+Before creating any tag:
+1. Tag must be strictly greater than all existing tags on the same major.minor line
+2. Milestone completion tag must be next minor (feature) or next major (schema-breaking)
+3. NEVER create a tag that is semantically below existing phase tags

 ## Multi-Project Branch Naming

-When operating in multi-project mode (`.ci/config.json` has `projects[]` with length > 0):
+When operating in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0):

 | Branch Type | Format | Example |
 |-------------|--------|---------|
@@ -155,7 +204,7 @@ const milestones = gitBranch.listMilestones();

 ## Branch Creation Rules

-1. Always create phase branches from main (or the current milestone branch)
+1. Always create phase branches from the current milestone branch (or main if no milestone branch exists)
 2. Never create a branch for a completed phase — it should already be merged
 3. Milestone branches span phases — don't create one per phase
 4. Use `GitBranch.createPhaseBranch()` to ensure consistent naming
@@ -164,25 +213,35 @@ const milestones = gitBranch.listMilestones();
 ## Working with Phase Branches

 ```bash
-# Create a phase branch
-git checkout -b phase/01-git-native-architecture
+# Create a milestone branch first
+git checkout main
+git checkout -b milestone/v0.5-honest-baseline
+
+# Create a phase branch from the milestone
+git checkout -b phase/01-quick-wins

 # Commit work with ---ci--- blocks
 git commit -m "feat(P01-01-01): implement commit parser

 ---ci---
 phase: 1
-milestone: v0.2
+milestone: v0.5
 plan: 01-01
 task: 01-01-01
 status: execute
 ---/ci---"

-# Merge on completion
+# Merge phase into milestone on completion
+git checkout milestone/v0.5-honest-baseline
+git merge --squash phase/01-quick-wins
+git commit -m "docs(P01): complete quick-wins phase"
+git tag -a v0.5.1 -m "v0.5.1: quick-wins"
+
+# After all phases, merge milestone into main
 git checkout main
-git merge --squash phase/01-git-native-architecture
-git commit -m "docs(P01): complete git-native-architecture phase"
-git tag -a v0.2.1 -m "v0.2.1: git-native-architecture"
+git merge --squash milestone/v0.5-honest-baseline
+git commit -m "docs(milestone): complete honest-baseline"
+git tag -a v0.6.0 -m "v0.6.0: honest-baseline"
 git push origin main --tags
 ```

@@ -1,15 +1,15 @@
 <ci_files_discipline>

-How CI manages the `.ci/` directory — long-lived reference documents only. Dynamic state lives in the git log via `---ci---` YAML blocks, not in files.
+How CIAgent manages the `.ciagent/` directory — long-lived reference documents only. Dynamic state lives in the git log via `---ci---` YAML blocks, not in files.

 ---

 ## Multi-Project Directory Structure

-In multi-project mode, `.ci/` uses subdirectories per project:
+In multi-project mode, `.ciagent/` uses subdirectories per project:

 ```
-.ci/
+.ciagent/
  config.json          # Registry with projects[] and active_project
  <project-slug>/
    PROJECT.md
@@ -18,11 +18,11 @@ In multi-project mode, `.ci/` uses subdirectories per project:
    REQUIREMENTS.md
 ```

-`.ci/config.json` serves as the registry with `projects[]` (array of project entries) and `active_project` (slug of the currently active project).
+`.ciagent/config.json` serves as the registry with `projects[]` (array of project entries) and `active_project` (slug of the currently active project).

-**Backward compatibility:** if `.ci/` has flat files (PROJECT.md, ARCHITECTURE.md, etc.) and no project subdirectories, auto-migrate by creating `<default-slug>/` and moving files into it, then updating `config.json` with a single `projects[]` entry.
+**Backward compatibility:** if `.ciagent/` has flat files (PROJECT.md, ARCHITECTURE.md, etc.) and no project subdirectories, auto-migrate by creating `<default-slug>/` and moving files into it, then updating `config.json` with a single `projects[]` entry.

-## What Lives in `.ci/`
+## What Lives in `.ciagent/`

 | File | Purpose | Update Frequency |
 |------|---------|-------------------|
@@ -32,23 +32,23 @@ In multi-project mode, `.ci/` uses subdirectories per project:
 | `<slug>/ROADMAP.md` | Phase breakdown, milestone mapping, success criteria per project | Low (phase transitions) |
 | `<slug>/REQUIREMENTS.md` | v1/v2 requirements with REQ-IDs, out of scope, traceability per project | Low (requirement changes) |

-## What Does NOT Live in `.ci/`
+## What Does NOT Live in `.ciagent/`

 These were removed in v0.2.0 and now live in the git log:

 | Previous Location | Now In | Access Method |
 |-------------------|--------|---------------|
-| `.ci/audit/decisions.json` | `---ci---` decisions block | `GitContext.getDecisions()` |
-| `.ci/audit/escalations.json` | `---ci---` escalations block | `GitContext.getEscalations()` |
-| `.ci/audit/lessons.json` | `---ci---` lessons block | `GitContext.getLessons()` |
+| `.ciagent/audit/decisions.json` | `---ci---` decisions block | `GitContext.getDecisions()` |
+| `.ciagent/audit/escalations.json` | `---ci---` escalations block | `GitContext.getEscalations()` |
+| `.ciagent/audit/lessons.json` | `---ci---` lessons block | `GitContext.getLessons()` |
 | `.planning/` directory (removed) | Git log + branches | `GitContext.reconstructState()` |

 ## CiFiles API

 | Method | Returns | Purpose |
 |--------|---------|---------|
-| `ensureCIDir()` | void | Create `.ci/` if it doesn't exist |
-| `isInitialized()` | boolean | Check if `.ci/config.json` exists |
+| `ensureCIDir()` | void | Create `.ciagent/` if it doesn't exist |
+| `isInitialized()` | boolean | Check if `.ciagent/config.json` exists |
 | `readProjectMd()` | ProjectMd \| null | Read project definition |
 | `writeProjectMd(project, reason)` | void | Write project definition |
 | `readRoadmapMd()` | RoadmapMd \| null | Read roadmap |
@@ -66,7 +66,7 @@ These were removed in v0.2.0 and now live in the git log:
 2. **Phase boundaries** — Major updates happen at phase transitions, not during task execution.
 3. **Requirements status** — Use `updateRequirementStatus()` for single-status changes, not full rewrites.
 4. **Phase status** — Use `updatePhaseStatus()` for phase transitions, not full roadmap rewrites.
-5. **Commit after write** — Every `.ci/` file change should be committed immediately with a `---ci---` block.
+5. **Commit after write** — Every `.ciagent/` file change should be committed immediately with a `---ci---` block.

 ## Update Triggers

@@ -157,21 +157,21 @@ interface ArchitectureMd {

 ## Research and .ci/ File Updates

-Research is intermediate work product. Conclusions from research update `.ci/` static files:
+Research is intermediate work product. Conclusions from research update `.ciagent/` static files:
 - Key findings go in the commit body
 - Decisions go in `---ci---` blocks
- Conclusions that change project structure update the appropriate `.ci/<slug>/` files (ARCHITECTURE.md, PROJECT.md, etc.)
+- Conclusions that change project structure update the appropriate `.ciagent/<slug>/` files (ARCHITECTURE.md, PROJECT.md, etc.)

 Research commits are not final artifacts — they feed into planning and roadmap updates.

 ## Anti-Patterns

- Never write dynamic state (decisions, escalations, lessons) to `.ci/` files
- Never update `.ci/` files during task execution — update at phase boundaries
+- Never write dynamic state (decisions, escalations, lessons) to `.ciagent/` files
+- Never update `.ciagent/` files during task execution — update at phase boundaries
 - Never skip the `reason` parameter when writing PROJECT.md
- Never commit `.ci/` changes without a `---ci---` block
- Never create new files in `.ci/` without updating this reference document
- Never store counters, timestamps, or session state in `.ci/` files
- Never store research conclusions only in commits — update `.ci/<slug>/` static files with findings
+- Never commit `.ciagent/` changes without a `---ci---` block
+- Never create new files in `.ciagent/` without updating this reference document
+- Never store counters, timestamps, or session state in `.ciagent/` files
+- Never store research conclusions only in commits — update `.ciagent/<slug>/` static files with findings

 </ci_files_discipline>
@@ -1,6 +1,6 @@
 <commit_schema>

-Canonical `---ci---` YAML block schema for CI commits. Every CI-generated commit contains a structured YAML block that enables full project state reconstruction from the git log alone.
+Canonical `---ci---` YAML block schema for CIAgent commits. Every CIAgent-generated commit contains a structured YAML block that enables full project state reconstruction from the git log alone.

 ---

@@ -39,7 +39,7 @@ compound:                # optional
 ---/ci---
 ```

-The `project` field is required when in multi-project mode (`.ci/config.json` has `projects[]` with length > 0). In single-project mode, it is optional.
+The `project` field is required when in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0). In single-project mode, it is optional.

 Example with project field:

@@ -104,7 +104,7 @@ The `CommitBuilder` class provides typed constructors:

 ## Reconstruction Guarantee

-An agent with access to only commit messages (no code, no diffs, no .ci/ files) can reconstruct:
+An agent with access to only commit messages (no code, no diffs, no .ciagent/ files) can reconstruct:

 1. **Current phase and milestone** — from the latest commit's `phase` and `milestone` fields
 2. **Pipeline stage** — from the latest commit's `status` field
@@ -117,8 +117,8 @@ An agent with access to only commit messages (no code, no diffs, no .ci/ files)

 ## Anti-Patterns

- Never put CI metadata in code comments — it belongs in commit messages
- Never omit the `---ci---` block from a CI-generated commit
+- Never put CIAgent metadata in code comments — it belongs in commit messages
+- Never omit the `---ci---` block from a CIAgent-generated commit
 - Never store decisions, escalations, or lessons in files — commit them
 - Never use a non-standard commit type — use the 14 types above
 - Never put freeform text inside the YAML block — use the structured fields
@@ -1,6 +1,6 @@
 <decision_engine>

-How CI makes decisions and commits them as git artifacts. The DecisionEngine uses bounded rationality with confidence thresholds to auto-decide or escalate.
+How CIAgent makes decisions and commits them as git artifacts. The DecisionEngine uses bounded rationality with confidence thresholds to auto-decide or escalate.

 ---

@@ -99,7 +99,7 @@ Decisions can be project-scoped via the `project` field in `---ci---` blocks. Wh

 ## Anti-Patterns

- Never write decisions to a `.ci/audit/` file — commit them
+- Never write decisions to a `.ciagent/audit/` file — commit them
 - Never skip recording a decision, even high-confidence ones
 - Never make a decision without listing alternatives
 - Never override the confidence threshold without explicit configuration
@@ -1,6 +1,6 @@
 <git_context_loading>

-How CI agents load project context. The git log IS the project memory — a CI agent's first impulse to gather context is `git log` + `git branch`, not file reads.
+How CIAgent agents load project context. The git log IS the project memory — a CIAgent agent's first impulse to gather context is `git log` + `git branch`, not file reads.

 ---

@@ -8,7 +8,7 @@ How CI agents load project context. The git log IS the project memory — a CI a

 **Read the log first, files second.**

-The git log contains every decision, escalation, lesson, and compound learning through structured `---ci---` YAML blocks. Files in `.ci/` are long-lived reference documents (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json) that change infrequently.
+The git log contains every decision, escalation, lesson, and compound learning through structured `---ci---` YAML blocks. Files in `.ciagent/` are long-lived reference documents (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json) that change infrequently.

 ## Context Loading Sequence

@@ -19,7 +19,7 @@ The git log contains every decision, escalation, lesson, and compound learning t
 5. **Requirements coverage** — `GitContext.getRequirementsCoverage()` for covered/partial
 6. **Lessons scan** — `GitContext.getLessons()` for all learned lessons
 7. **Compound learnings** — `GitContext.getCompounds()` for cross-phase patterns
-8. **File reads** — Only now read `.ci/` files (PROJECT.md, ARCHITECTURE.md, etc.)
+8. **File reads** — Only now read `.ciagent/` files (PROJECT.md, ARCHITECTURE.md, etc.)

 ## GitContext API

@@ -74,19 +74,19 @@ interface ParsedCiCommit {
 }
 ```

-Commits without `---ci---` blocks have `ci: null` — these are treated as non-CI commits (e.g., manual edits by the developer).
+Commits without `---ci---` blocks have `ci: null` — these are treated as non-CIAgent commits (e.g., manual edits by the developer).

 ## Phase Context Reset

 Between phases, all state is committed to git, then the next phase starts with fresh context from git log — not accumulated conversation history.

-**On opencode (subagent support):** spawn a fresh agent for the next phase. The new agent loads context from git log and `.ci/` files only.
+**On opencode (subagent support):** spawn a fresh agent for the next phase. The new agent loads context from git log and `.ciagent/` files only.

 **On platforms without subagents:** simulated reset — re-read git context from scratch, ignore prior conversation history. Treat the phase boundary as a hard context boundary.

 **Checkpoint sequence:**
 1. Commit all work from the current phase
-2. Update `.ci/` files (ROADMAP.md phase status, REQUIREMENTS.md requirement statuses)
+2. Update `.ciagent/` files (ROADMAP.md phase status, REQUIREMENTS.md requirement statuses)
 3. Verify `GitContext.reconstructState()` matches expected state
 4. Reset context — next phase begins fresh

@@ -112,11 +112,11 @@ When context is limited:
 2. `getDecisions(currentPhase)` — current phase decisions only
 3. `getRequirementsCoverage()` — aggregate view
 4. Skip lessons/compounds unless specifically needed
-5. Read `.ci/ROADMAP.md` instead of scanning all phase branches
+5. Read `.ciagent/ROADMAP.md` instead of scanning all phase branches

 ## What NOT to Do

- Never read `.ci/` files before checking the git log
+- Never read `.ciagent/` files before checking the git log
 - Never parse commit messages manually — use `CommitParser.parseCommitMessage()`
 - Never assume the latest commit reflects the current state — check branches
 - Never reconstruct state from files when git data is available
@@ -1,18 +1,18 @@
 ---
-description: Audit CI project health — reconstruct state from git log, verify .ci/ files match codebase, check for stale references
+description: Audit CIAgent project health — reconstruct state from git log, verify .ciagent/ files match codebase, check for stale references
 ---

-# CI Audit
+# CIAgent Audit

-Audit the CI project for health issues. Verifies that git log state matches .ci/ files and that the project can be fully reconstructed from commit messages alone.
+Audit the CIAgent project for health issues. Verifies that git log state matches .ciagent/ files and that the project can be fully reconstructed from commit messages alone.

-**Usage:** `ci-audit`
+**Usage:** `ciagent-audit`

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this audit
 - If not, set it with `ci setActiveProject(<slug>)`
 - Scope audit queries to the active project
@@ -26,16 +26,16 @@ Attempt to reconstruct the full project state from commit messages only:

 1. Parse all `---ci---` blocks from git log
 2. Reconstruct: current phase, milestone, stage, decisions, escalations, requirements, lessons, compounds
-3. Compare reconstructed state with `.ci/` file contents
+3. Compare reconstructed state with `.ciagent/` file contents

 ## Step 2: Check .ci/ File Discipline

-For each .ci/ file:
- `.ci/config.json`: valid JSON, required fields present
- `.ci/PROJECT.md`: has required sections (What This Is, Requirements, Constraints, Key Decisions)
- `.ci/ROADMAP.md`: phases match git branches (merged = complete, active = in progress)
- `.ci/REQUIREMENTS.md`: traceability matrix is complete
- `.ci/ARCHITECTURE.md`: components match actual code structure
+For each .ciagent/ file:
+- `.ciagent/config.json`: valid JSON, required fields present
+- `.ciagent/PROJECT.md`: has required sections (What This Is, Requirements, Constraints, Key Decisions)
+- `.ciagent/ROADMAP.md`: phases match git branches (merged = complete, active = in progress)
+- `.ciagent/REQUIREMENTS.md`: traceability matrix is complete
+- `.ciagent/ARCHITECTURE.md`: components match actual code structure

 ## Step 3: Check Branch Hygiene

@@ -46,20 +46,20 @@ For each .ci/ file:
 ## Step 4: Check Commit Discipline

 - Every CI-generated commit should have a `---ci---` block
- No stale decisions (decisions from >50 commits ago that are still in `.ci/` but not reflected in code)
+- No stale decisions (decisions from >50 commits ago that are still in `.ciagent/` but not reflected in code)
 - No unresolved escalations older than the escalation timeout

 ## Step 5: Display Report

 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- CI ► AUDIT REPORT
+ CIAgent ► AUDIT REPORT
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 Reconstruction: [PASS/FAIL] — [details]
-.ci/ Files: [N] checked, [issues]
+.ciagent/ Files: [N] checked, [issues]
 Branches: [N] phase, [N] milestone, [issues]
-Commits: [N] CI commits, [N] without ---ci--- blocks
+Commits: [N] CIAgent commits, [N] without ---ci--- blocks

 [If issues found:]
 Issues:
@@ -1,18 +1,18 @@
 ---
-description: Clarify CI project ambiguities — generate questions, accept defaults at full autonomy, present at supervised/guided
+description: Clarify CIAgent project ambiguities — generate questions, accept defaults at full autonomy, present at supervised/guided
 ---

-# CI Clarify
+# CIAgent Clarify

-Run the clarification phase for the current CI project. Generate questions about ambiguities, accept defaults automatically at full autonomy, or present to the user at supervised/guided levels.
+Run the clarification phase for the current CIAgent project. Generate questions about ambiguities, accept defaults automatically at full autonomy, or present to the user at supervised/guided levels.

-**Usage:** `ci-clarify [phase_number]`
+**Usage:** `ciagent-clarify [phase_number]`

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this clarification
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -26,7 +26,7 @@ git log --max-count=20
 git branch -a
 ```

-Read `.ci/PROJECT.md` and `.ci/REQUIREMENTS.md` for the specification.
+Read `.ciagent/PROJECT.md` and `.ciagent/REQUIREMENTS.md` for the specification.

 ## Step 2: Identify Ambiguities

@@ -75,8 +75,8 @@ decisions:

 ## Step 6: Update .ci/ Files

-Update `.ci/PROJECT.md` with clarified requirements.
-Update `.ci/REQUIREMENTS.md` with refined requirements.
+Update `.ciagent/PROJECT.md` with clarified requirements.
+Update `.ciagent/REQUIREMENTS.md` with refined requirements.

 ## Step 7: Report

@@ -1,18 +1,18 @@
 ---
-description: Systematic CI debugging with git context — triage, diagnose root cause, auto-fix or escalate
+description: Systematic CIAgent debugging with git context — triage, diagnose root cause, auto-fix or escalate
 ---

-# CI Debug
+# CIAgent Debug

 Systematic debugging workflow: triage → root cause diagnosis → auto-fix or escalate. Uses git history to find recent changes that may have caused the bug.

-**Usage:** `ci-debug [description]`
+**Usage:** `ciagent-debug [description]`

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this debug session
 - If not, set it with `ci setActiveProject(<slug>)`
 - Scope debugging to the active project
@@ -1,21 +1,21 @@
 ---
-description: Initialize a new CI project — specification → clarify → create .ci/ reference files → initial commit
+description: Initialize a new CIAgent project — specification → clarify → create .ciagent/ reference files → initial commit
 ---

-# CI Init
+# CIAgent Init

-Initialize a new CI project with specification parsing, clarification, and .ci/ reference file creation.
+Initialize a new CIAgent project with specification parsing, clarification, and .ciagent/ reference file creation.

-**Usage:** `ci-init [description]`
+**Usage:** `ciagent-init [description]`

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this initialization
 - If not, set it with `ci setActiveProject(<slug>)`
- All subsequent operations use `.ci/<slug>/` subdirectories
+- All subsequent operations use `.ciagent/<slug>/` subdirectories
 - All commit messages must include `project: <slug>` in `---ci---` block

 If single-project mode: proceed with existing conventions.
@@ -29,12 +29,12 @@ Verify git is initialized:

 If NO_GIT: `git init`

-Check if `.ci/config.json` already exists:
+Check if `.ciagent/config.json` already exists:
 ```bash
-[ -f .ci/config.json ] && echo "ALREADY_INITIALIZED" || echo "NEW"
+[ -f .ciagent/config.json ] && echo "ALREADY_INITIALIZED" || echo "NEW"
 ```

-If ALREADY_INITIALIZED: stop. Use `ci-status` to see project state.
+If ALREADY_INITIALIZED: stop. Use `ciagent-status` to see project state.

 ## Step 2: Parse Specification

@@ -59,15 +59,15 @@ Analyze the specification for ambiguities. For each ambiguity:

 Record decisions in the `---ci---` block of the init commit.

-## Step 4: Create .ci/ Files
+## Step 4: Create .ciagent/ Files

 Use CiFiles to create the project structure:

-1. `.ci/config.json` — registry with `projects[]` and `active_project`
-2. `.ci/<slug>/PROJECT.md` — vision, requirements, constraints, key decisions (or `.ci/PROJECT.md` in single-project mode)
-3. `.ci/<slug>/ARCHITECTURE.md` — system architecture (initial, may be incomplete)
-4. `.ci/<slug>/ROADMAP.md` — phase breakdown (to be refined by roadmapper)
-5. `.ci/<slug>/REQUIREMENTS.md` — formal requirements with REQ-IDs
+1. `.ciagent/config.json` — registry with `projects[]` and `active_project`
+2. `.ciagent/<slug>/PROJECT.md` — vision, requirements, constraints, key decisions (or `.ciagent/PROJECT.md` in single-project mode)
+3. `.ciagent/<slug>/ARCHITECTURE.md` — system architecture (initial, may be incomplete)
+4. `.ciagent/<slug>/ROADMAP.md` — phase breakdown (to be refined by roadmapper)
+5. `.ciagent/<slug>/REQUIREMENTS.md` — formal requirements with REQ-IDs

 `initCI()` accepts `projectSlug` and `projectName` parameters for multi-project initialization.

@@ -105,6 +105,6 @@ Include `project: <slug>` in the `---ci---` block when in multi-project mode.

 ## Step 7: Done

-Report project initialized, .ci/ files created, initial branch created.
+Report project initialized, .ciagent/ files created, initial branch created.

-Next: `ci-run` to execute the pipeline, or `ci-quick` for ad-hoc tasks.
+Next: `ciagent-run` to execute the pipeline, or `ciagent-quick` for ad-hoc tasks.
@@ -1,12 +1,12 @@
 ---
-description: Execute an ad-hoc CI task with full agentic guarantees — git context, ---ci--- commits, optional research and verification
+description: Execute an ad-hoc CIAgent task with full agentic guarantees — git context, ---ci--- commits, optional research and verification
 ---

-# CI Quick
+# CIAgent Quick

-Execute small, ad-hoc tasks with CI guarantees: git context loading, `---ci---` commit blocks, optional research and verification.
+Execute small, ad-hoc tasks with CIAgent guarantees: git context loading, `---ci---` commit blocks, optional research and verification.

-**Usage:** `ci-quick [description]`
+**Usage:** `ciagent-quick [description]`

 **Flags:**
 - `--research` — spawn a focused research agent before execution
@@ -15,9 +15,9 @@ Execute small, ad-hoc tasks with CI guarantees: git context loading, `---ci---`

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -37,7 +37,7 @@ git branch -a

 Use GitContext.reconstructState() to understand project state.

-Check that `.ci/config.json` exists. If missing: stop, run `ci-init` first.
+Check that `.ciagent/config.json` exists. If missing: stop, run `ciagent-init` first.

 ## Step 3: Research (only with `--research` or `--full`)

@@ -1,18 +1,18 @@
 ---
-description: Review CI code changes with multi-persona analysis — auto-apply P0 fixes, flag P1+ for post-hoc review
+description: Review CIAgent code changes with multi-persona analysis — auto-apply P0 fixes, flag P1+ for post-hoc review
 ---

-# CI Review
+# CIAgent Review

 Multi-persona code review workflow. Reviews changes in the current phase, auto-applies P0 fixes, and flags P1+ issues for post-hoc review.

-**Usage:** `ci-review [phase_number]`
+**Usage:** `ciagent-review [phase_number]`

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this review
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -1,20 +1,20 @@
 ---
-description: Rollback CI phase — revert the last phase or specified phase by resetting to its pre-phase state
+description: Rollback CIAgent phase — revert the last phase or specified phase by resetting to its pre-phase state
 ---

-# CI Rollback
+# CIAgent Rollback

-Rollback a CI phase by reverting to the state before the phase started. Uses git to find the exact commit to reset to.
+Rollback a CIAgent phase by reverting to the state before the phase started. Uses git to find the exact commit to reset to.

-**Usage:** `ci-rollback [phase_number]`
+**Usage:** `ciagent-rollback [phase_number]`

 If no phase specified, rolls back the current (most recent) phase.

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this rollback
 - If not, set it with `ci setActiveProject(<slug>)`
 - Identify project-scoped branches (prefixed with `<slug>/`)
@@ -71,8 +71,8 @@ git reset --hard [rollback_point]
 ## Step 5: Update State

 - Delete the phase branch (if not already removed)
- Update `.ci/REQUIREMENTS.md` — mark phase requirements as blocked
- Update `.ci/ROADMAP.md` — mark phase as not_started
+- Update `.ciagent/REQUIREMENTS.md` — mark phase requirements as blocked
+- Update `.ciagent/ROADMAP.md` — mark phase as not_started

 Commit the rollback:

@@ -1,20 +1,20 @@
 ---
-description: Execute the full CI pipeline — research → plan → execute → verify → complete for the current or specified phase
+description: Execute the full CIAgent pipeline — research → plan → execute → verify → complete for the current or specified phase
 ---

-# CI Run
+# CIAgent Run

-Execute the full CI pipeline from the current stage to completion. The orchestrator iterates through stages and delegates to specialized agents.
+Execute the full CIAgent pipeline from the current stage to completion. The orchestrator iterates through stages and delegates to specialized agents.

-**Usage:** `ci-run [phase_number]`
+**Usage:** `ciagent-run [phase_number]`

 If no phase number specified, continues from the current phase (detected from git log).

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this run
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -36,17 +36,17 @@ Determine current state:

 ## Step 2: Pre-Flight Check

-Verify `.ci/config.json` exists. If missing: stop, run `ci-init` first.
+Verify `.ciagent/config.json` exists. If missing: stop, run `ciagent-init` first.

-Read `.ci/PROJECT.md` and `.ci/ROADMAP.md` for phase goals.
+Read `.ciagent/PROJECT.md` and `.ciagent/ROADMAP.md` for phase goals.

 ## Step 3: Execute Pipeline Stages

 For each stage in order (starting from current or from `specify`):

 ### SPECIFY
- Parse specification from `.ci/PROJECT.md`
- Validate requirements exist in `.ci/REQUIREMENTS.md`
+- Parse specification from `.ciagent/PROJECT.md`
+- Validate requirements exist in `.ciagent/REQUIREMENTS.md`
 - Commit: `docs(init): validate specification`

 ### CLARIFY
@@ -57,7 +57,7 @@ For each stage in order (starting from current or from `specify`):
 ### RESEARCH
 - Delegate to ci-researcher
 - Research domain, ecosystem, prior art
- Update `.ci/` static files with conclusions
+- Update `.ciagent/` static files with conclusions
 - Commit: `docs(P##): research findings`

 ### PLAN
@@ -81,8 +81,8 @@ For each stage in order (starting from current or from `specify`):
 - Merge phase branch into main (squash)
 - Tag with patch version (e.g., `v0.2.3` — 3rd phase in milestone v0.2)
 - Create Gitea release for the tag
- Update `.ci/REQUIREMENTS.md` requirement statuses
- Update `.ci/ROADMAP.md` phase status
+- Update `.ciagent/REQUIREMENTS.md` requirement statuses
+- Update `.ciagent/ROADMAP.md` phase status
 - Commit: `docs(P##): complete [phase-name] phase`

 Versioning: Major = project-level refactor/schema change, Minor = milestone completion, Patch = every phase.
@@ -92,7 +92,7 @@ Versioning: Major = project-level refactor/schema change, Minor = milestone comp
 Between phases, perform a context reset:

 1. Commit all work from the current phase
-2. Update `.ci/` files (phase status, requirement statuses)
+2. Update `.ciagent/` files (phase status, requirement statuses)
 3. Verify `GitContext.reconstructState()` matches expected state
 4. Reset context: spawn fresh agent (opencode) or re-read git context (platforms without subagents)
 5. Next phase begins with fresh context from git log only
@@ -1,27 +1,31 @@
 ---
-description: Ship CI phase or milestone — test, tag, release. Every phase gets a patch release. Every milestone gets a minor (or major) release. Full autopilot.
+description: Ship CIAgent phase or milestone — test, tag, release. Every phase and milestone gets a release. Full autopilot.
 ---

-# CI Ship
+# CIAgent Ship

-Ship a CI phase or milestone. Every ship creates a release — no exceptions.
+Ship a CIAgent phase or milestone. Every ship creates a release — no exceptions.

-**Versioning rule:**
- **Major** (X.0.0): Project-level refactor or schema changes
- **Minor** (0.X.0): Feature milestone completion only
- **Patch** (0.0.X): Every phase completion
+**3-Tier Versioning Model:**

-**NFR versioning:**
- NFR milestones (all phases are fix/chore/docs/perf/refactor/test): progressive patch versions only (v0.1.1, v0.1.2, v0.1.3). No minor milestone tag.
- Feature milestones (any feat phase): progressive patch versions per phase + minor milestone tag on completion (e.g., v0.2.0).
+| Milestone Type | Condition | Phase release | Milestone release |
+|---------------|-----------|---------------|-------------------|
+| **NFR** | All phases: fix/chore/docs/perf/refactor/test | Patch (`vX.Y.Z`) | None |
+| **Feature** | Any phase is `feat`, no schema break | Patch (`vX.Y.Z`) | Minor — `vX.(Y+1).0` |
+| **Schema-breaking** | Refactor/schema break/new direction | Minor — `vX.(Y+N).0` per phase | Major — `v(X+1).0.0` |

-**Usage:** `ci-ship [phase_number|milestone]`
+**CRITICAL:** Milestone tags are always the NEXT version, never the base:
+- Feature: patches v0.5.1–v0.5.5 → milestone tag is v0.6.0 (NOT v0.5.0)
+- Schema-breaking: minors v0.3.0, v0.4.0, v0.5.0 → milestone tag is v1.0.0
+- NFR: no milestone tag — the milestone is implicit from the patch sequence
+
+**Usage:** `ciagent-ship [phase_number|milestone]`

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this ship
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -36,14 +40,14 @@ git log --max-count=10
 git branch -a
 ```

-Determine what is being shipped: a single phase (patch release) or an entire milestone (minor/major release).
+Determine what is being shipped: a single phase or an entire milestone.

-Read `.ci/ROADMAP.md` to determine:
+Read `.ciagent/ROADMAP.md` to determine:
 - Current milestone version (e.g., `v0.2`)
 - Phase number within the milestone
 - Whether this is the last phase in the milestone

-Read `.ci/config.json` for autonomy level.
+Read `.ciagent/config.json` for autonomy level.

 ## Step 2: Run Tests

@@ -57,22 +61,51 @@ If any fail: iterate autonomously until tests pass. Do NOT ask the user for guid

 ## Step 3: Compute Version

-Determine the release version from what is being shipped. Check `isNfrMilestone()` for versioning behavior:
+Determine milestone type by calling `getMilestoneType()` which returns `"nfr" | "feature" | "schema-breaking"`:

-| What's shipping | Milestone Type | Version bump | Tag format | Example |
+| What's shipping | Milestone Type | Phase release | Milestone release | Example |
 |----------------|---------------|-------------|------------|---------|
-| Single phase | NFR | Patch | `vX.Y.Z` | `v0.1.3` (3rd NFR phase in milestone v0.1) |
-| Single phase | Feature | Patch | `vX.Y.Z` | `v0.2.3` (3rd phase in feature milestone v0.2) |
-| Milestone completion | NFR | Patch (last phase) | `vX.Y.Z` | `v0.1.3` (no minor tag) |
-| Milestone completion | Feature | Minor | `vX.Y.0` | `v0.3.0` (feature milestone v0.3 complete) |
-| Project refactor/schema change | Any | Major | `vX.0.0` | `v1.0.0` (breaking schema) |
+| Single phase | NFR | Patch `vX.Y.Z` | N/A | v0.1.3 (3rd NFR phase) |
+| Single phase | Feature | Patch `vX.Y.Z` | N/A | v0.2.3 (3rd feature phase) |
+| Single phase | Schema-breaking | Minor `vX.(Y+N).0` | N/A | v0.4.0 (2nd schema-breaking phase) |
+| Milestone completion | NFR | Patch (last phase) | None | v0.1.3 (no milestone tag) |
+| Milestone completion | Feature | Last patch | Minor `vX.(Y+1).0` | v0.3.0 (NOT v0.2.0) |
+| Milestone completion | Schema-breaking | Last minor | Major `v(X+1).0.0` | v1.0.0 |

-Count completed phases in the current milestone to determine the patch number.
+Phase number within the milestone determines the increment:
+- NFR/Feature: 1st phase = .1, 2nd = .2, etc. (v0.5.1, v0.5.2)
+- Schema-breaking: 1st phase = next minor, 2nd = minor+1, etc. (v0.3.0, v0.4.0)
+
+**Before creating ANY tag, validate:**
+1. The tag must be strictly greater than all existing tags on the same major.minor line
+2. Milestone completion tag must be the next minor (feature) or next major (schema-breaking)
+3. NEVER create a milestone tag that is semantically below existing phase tags (e.g., v0.5.0 when v0.5.1 already exists)

 ## Step 4: Merge Branch

-### Phase ship (patch release)
+### Branch hierarchy: main > milestone/vX.X-slug > phase/NN-slug

+Phases MUST merge into their milestone branch (or to main if no milestone branch exists). Milestones merge into main only after all phases are complete.
+
+### Phase ship
+
+**If milestone branch exists:**
+```bash
+git checkout milestone/vX.Y-slug
+git merge --squash phase/NN-slug
+git commit -m "docs(P##): complete [phase-name] phase
+
+---ci---
+phase: [N]
+milestone: [vX.Y]
+status: complete
+requirements:
+  covered: [REQ-01, REQ-02]
+  partial: []
+---/ci---"
+```
+
+**If no milestone branch exists (single-phase milestone):**
 ```bash
 git checkout main
 git merge --squash phase/NN-slug
@@ -88,9 +121,10 @@ requirements:
 ---/ci---"
 ```

-### Milestone ship (minor/major release)
+### Milestone ship (after last phase)

 ```bash
+# Verify all phase branches are merged into milestone branch
 git checkout main
 git merge --squash milestone/vX.Y-slug
 git commit -m "docs(milestone): complete [milestone-name]
@@ -109,6 +143,12 @@ git tag -a vX.Y.Z -m "vX.Y.Z: [phase-name or milestone-name]"
 git push origin main --tags
 ```

+**Tag format by milestone type:**
+- NFR/Feature phase: patch format (`v0.5.1`, `v0.5.2`)
+- Schema-breaking phase: minor format (`v0.3.0`, `v0.4.0`)
+- Feature milestone: next minor (`v0.6.0`, NOT `v0.5.0`)
+- Schema-breaking milestone: next major (`v1.0.0`)
+
 ## Step 6: Create Release

 **Every ship creates a Gitea release. No exceptions.**
@@ -132,8 +172,8 @@ For milestone releases, include a summary of all phases completed and requiremen

 ## Step 7: Update .ci/ Files

- Update `.ci/REQUIREMENTS.md` — mark shipped requirements as complete
- Update `.ci/ROADMAP.md` — mark shipped phase as complete
+- Update `.ciagent/REQUIREMENTS.md` — mark shipped requirements as complete
+- Update `.ciagent/ROADMAP.md` — mark shipped phase as complete

 Commit the file updates.

@@ -141,11 +181,11 @@ Commit the file updates.

 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- CI ► SHIPPED
+ CIAgent ► SHIPPED
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 Phase [N]: [name]
-Milestone: [vX.Y]
+Milestone: [vX.Y] ([nfr|feature|schema-breaking])
 Version: vX.Y.Z
 Release: https://git.cloudinit.dev/continuous-intelligence/ci/releases/tag/vX.Y.Z
 Status: complete
@@ -158,6 +198,6 @@ Requirements covered: [N]
 Commits: [N]

 [If milestone complete:]
-All phases in milestone v0.2 complete. Milestone released.
+All phases in milestone v0.2 complete. Milestone released as vX.Y.Z.
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
@@ -1,18 +1,18 @@
 ---
-description: Show CI project status — current phase, milestone, pipeline stage, decisions, escalations, and requirements coverage
+description: Show CIAgent project status — current phase, milestone, pipeline stage, decisions, escalations, and requirements coverage
 ---

-# CI Status
+# CIAgent Status

-Display the current CI project status derived entirely from the git log and .ci/ files.
+Display the current CIAgent project status derived entirely from the git log and .ciagent/ files.

-**Usage:** `ci-status`
+**Usage:** `ciagent-status`

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Show project list with active project indicator
 - Confirm `active_project` is the project to show status for
 - If not, set it with `ci setActiveProject(<slug>)`
@@ -45,15 +45,15 @@ Collect from git log:
 ## Step 3: Read .ci/ Files

 Read:
- `.ci/PROJECT.md` — project name and vision
- `.ci/ROADMAP.md` — phase list with status
- `.ci/config.json` — autonomy level
+- `.ciagent/PROJECT.md` — project name and vision
+- `.ciagent/ROADMAP.md` — phase list with status
+- `.ciagent/config.json` — autonomy level

 ## Step 4: Display Status

 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- CI ► STATUS
+ CIAgent ► STATUS
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 Project: [name]  [If multi-project: (active)]
@@ -79,4 +79,4 @@ Recent commits:
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```

-If no `.ci/` directory exists: report "Project not initialized. Run ci-init first."
+If no `.ciagent/` directory exists: report "Project not initialized. Run ciagent-init first."
@@ -1,20 +1,20 @@
 ---
-description: Verify CI project deliverables against requirements — structural, behavioral, security, and quality checks
+description: Verify CIAgent project deliverables against requirements — structural, behavioral, security, and quality checks
 ---

-# CI Verify
+# CIAgent Verify

-Run the CI verification pipeline against the current or specified phase. Four layers: structural, behavioral, security, quality.
+Run the CIAgent verification pipeline against the current or specified phase. Four layers: structural, behavioral, security, quality.

-**Usage:** `ci-verify [phase_number]`
+**Usage:** `ciagent-verify [phase_number]`

 If no phase specified, verifies the current phase.

 ## Step 0: Confirm Active Project

-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.

-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this verification
 - If not, set it with `ci setActiveProject(<slug>)`
 - Scope verification to the active project
@@ -1,5 +1,5 @@
 ---
-description: Audit CI project health — reconstruct state from git log, verify .ci/ files match codebase, check for stale references
+description: Audit CIAgent project health — reconstruct state from git log, verify .ciagent/ files match codebase, check for stale references
 tools:
  read: true
  bash: true
@@ -16,6 +16,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI audit workflow end-to-end.
+Execute the CIAgent audit workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Clarify CI project ambiguities — generate questions, accept defaults at full autonomy, present at supervised/guided
+description: Clarify CIAgent project ambiguities — generate questions, accept defaults at full autonomy, present at supervised/guided
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI clarify workflow end-to-end.
+Execute the CIAgent clarify workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Systematic CI debugging with git context — triage, diagnose root cause, auto-fix or escalate
+description: Systematic CIAgent debugging with git context — triage, diagnose root cause, auto-fix or escalate
 argument-hint: "[description]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI debug workflow end-to-end.
+Execute the CIAgent debug workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Initialize a new CI project — specification → clarify → create .ci/ reference files → initial commit
+description: Initialize a new CIAgent project — specification → clarify → create .ciagent/ reference files → initial commit
 argument-hint: "[description]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI init workflow end-to-end.
+Execute the CIAgent init workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Execute an ad-hoc CI task with full agentic guarantees — git context, ---ci--- commits, optional research and verification
+description: Execute an ad-hoc CIAgent task with full agentic guarantees — git context, ---ci--- commits, optional research and verification
 argument-hint: "[description] [--research] [--verify] [--full]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI quick workflow end-to-end.
+Execute the CIAgent quick workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Review CI code changes with multi-persona analysis — auto-apply P0 fixes, flag P1+ for post-hoc review
+description: Review CIAgent code changes with multi-persona analysis — auto-apply P0 fixes, flag P1+ for post-hoc review
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -20,6 +20,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI review workflow end-to-end.
+Execute the CIAgent review workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Rollback CI phase — revert the last phase or specified phase by resetting to its pre-phase state
+description: Rollback CIAgent phase — revert the last phase or specified phase by resetting to its pre-phase state
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI rollback workflow end-to-end.
+Execute the CIAgent rollback workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Execute the full CI pipeline — research → plan → execute → verify → complete
+description: Execute the full CIAgent pipeline — research → plan → execute → verify → complete
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI run workflow end-to-end.
+Execute the CIAgent run workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Ship CI phase or milestone — test, commit, tag, push, release. Full autopilot: zero HITL after milestone setup
+description: Ship CIAgent phase or milestone — test, commit, tag, push, release. Full autopilot: zero HITL after milestone setup
 argument-hint: "[phase_number|milestone]"
 tools:
  read: true
@@ -20,6 +20,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI ship workflow end-to-end.
+Execute the CIAgent ship workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Show CI project status — current phase, milestone, pipeline stage, decisions, escalations, and requirements coverage
+description: Show CIAgent project status — current phase, milestone, pipeline stage, decisions, escalations, and requirements coverage
 tools:
  read: true
  bash: true
@@ -16,6 +16,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI status workflow end-to-end.
+Execute the CIAgent status workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Verify CI project deliverables against requirements — structural, behavioral, security, and quality checks
+description: Verify CIAgent project deliverables against requirements — structural, behavioral, security, and quality checks
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -20,6 +20,6 @@ Arguments: $ARGUMENTS
 </context>

 <process>
-Execute the CI verify workflow end-to-end.
+Execute the CIAgent verify workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,12 +1,13 @@
 {
  "name": "@continuous-intelligence/ci",
-  "version": "0.1.0",
+  "version": "0.4.0",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {
    "": {
      "name": "@continuous-intelligence/ci",
-      "version": "0.1.0",
+      "version": "0.4.0",
+      "hasInstallScript": true,
      "license": "MIT",
      "dependencies": {
        "commander": "^12.1.0",
@@ -14,9 +14,9 @@ for arg in "$@"; do
    --help|-h)
      echo "Usage: $(basename "$0") [--uninstall] [--force]"
      echo ""
-      echo "Install CI opencode integration files to ~/.config/opencode/"
+      echo "Install CIAgent opencode integration files to ~/.config/opencode/"
      echo ""
-      echo "  --uninstall  Remove CI integration files"
+      echo "  --uninstall  Remove CIAgent integration files"
      echo "  --force      Overwrite existing files without prompting"
      echo "  --help       Show this help"
      exit 0
@@ -25,24 +25,24 @@ for arg in "$@"; do
 done

 if [ "$UNINSTALL" = true ]; then
-  echo "Uninstalling CI opencode integration..."
-  
-  rm -f "${OPENCODE_DIR}/agents/ci-"*.md 2>/dev/null || true
-  rm -f "${OPENCODE_DIR}/command/ci-"*.md 2>/dev/null || true
-  rm -rf "${OPENCODE_DIR}/ci/" 2>/dev/null || true
-  
-  echo "CI integration files removed."
+  echo "Uninstalling CIAgent opencode integration..."
+   
+   rm -f "${OPENCODE_DIR}/agents/ci-"*.md 2>/dev/null || true
+   rm -f "${OPENCODE_DIR}/command/ci-"*.md 2>/dev/null || true
+   rm -rf "${OPENCODE_DIR}/ci/" 2>/dev/null || true
+   
+   echo "CIAgent integration files removed."
  echo "Note: opencode.json permissions entry preserved (edit manually if needed)."
  exit 0
 fi

 if [ ! -d "$CI_DIR" ]; then
  echo "Error: opencode/ directory not found at ${CI_DIR}"
-  echo "Ensure you're running from the CI repository root."
+  echo "Ensure you're running from the CIAgent repository root."
  exit 1
 fi

-echo "Installing CI opencode integration..."
+echo "Installing CIAgent opencode integration..."
 echo "  Source: ${CI_DIR}"
 echo "  Target: ${OPENCODE_DIR}"
 echo ""
@@ -143,15 +143,15 @@ fi

 echo ""
 echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
-echo " CI ► INSTALL COMPLETE"
+echo " CIAgent ► INSTALL COMPLETE"
 echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
 echo ""
 echo " Copied: ${COPIED} files"
 echo " Skipped: ${SKIPPED} files"
 echo ""
-echo " Commands available: ci-init, ci-run, ci-quick, ci-status,"
-echo "   ci-audit, ci-verify, ci-debug, ci-review, ci-ship,"
-echo "   ci-rollback, ci-clarify"
+echo " Commands available: ciagent-init, ciagent-run, ciagent-quick, ciagent-status,"
+echo "   ciagent-audit, ciagent-verify, ciagent-debug, ciagent-review, ciagent-ship,"
+echo "   ciagent-rollback, ciagent-clarify"
 echo ""
 echo " Run --uninstall to remove."
 echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
@@ -52,19 +52,19 @@ function applyTemplate(content, vars) {
 function install() {
  const pkgDir = getPackageDir();
  if (!pkgDir) {
-    console.log("CI postinstall: Could not determine package directory. Skipping.");
+    console.log("CIAgent postinstall: Could not determine package directory. Skipping.");
    return;
  }

  const opencodeDir = path.join(pkgDir, "opencode");
  if (!fs.existsSync(opencodeDir)) {
-    console.log("CI postinstall: opencode/ directory not found. Skipping.");
+    console.log("CIAgent postinstall: opencode/ directory not found. Skipping.");
    return;
  }

  if (!isGlobalInstall()) {
-    console.log("CI postinstall: Not a global install. Skipping opencode integration.");
-    console.log("  Run `npx ci-install` or `./scripts/install.sh` to install manually.");
+    console.log("CIAgent postinstall: Not a global install. Skipping opencode integration.");
+    console.log("  Run `npx ciagent-install` or `./scripts/install.sh` to install manually.");
    return;
  }

@@ -132,11 +132,11 @@ function install() {
    }
  }

-  console.log(`CI postinstall: ${copied} files installed, ${skipped} skipped.`);
+  console.log(`CIAgent postinstall: ${copied} files installed, ${skipped} skipped.`);
 }

 try {
  install();
 } catch (err) {
-  console.log("CI postinstall: Non-fatal error:", err.message);
+  console.log("CIAgent postinstall: Non-fatal error:", err.message);
 }
@@ -680,7 +680,6 @@ export function createShipCommand(): Command {
      }

      const config = loadConfig(projectPath);
-      const milestone = "v1.0";

      try {
        const isGitRepo = execSync("git rev-parse --is-inside-work-tree", {
@@ -689,23 +688,34 @@ export function createShipCommand(): Command {
        }).trim() === "true";

        if (isGitRepo) {
+          console.log("  Computing version...");
+          const version = computeShipVersion(projectPath, phaseNum, config);
+          console.log(`  Version: ${version.tag} (${version.milestoneType})`);
+
+          const mergeTarget = resolveMergeTarget(projectPath, version.milestoneType);
+          console.log(`  Merge target: ${mergeTarget}`);
+
          console.log("  Committing and tagging...");
-          const tag = `${milestone}-phase${phaseNum}`;
          try {
+            if (!validateVersionOrder(projectPath, version.tag)) {
+              console.error(`✗ Version ${version.tag} is not greater than existing tags. Aborting.`);
+              process.exit(1);
+            }
+
            execSync(`git add -A`, { cwd: projectPath, stdio: "pipe" });
            execSync(`git commit -m "chore: ship phase ${phaseNum}" --allow-empty`, {
              cwd: projectPath,
              stdio: "pipe",
            });
-            execSync(`git tag -a ${tag} -m "CI: Phase ${phaseNum} shipped"`, {
+            execSync(`git tag -a ${version.tag} -m "CI: Phase ${phaseNum} shipped"`, {
              cwd: projectPath,
              stdio: "pipe",
            });
-            console.log(`  ✓ Tagged: ${tag}`);
+            console.log(`  ✓ Tagged: ${version.tag}`);

            if (config.git.auto_push) {
-              execSync(`git push origin ${tag}`, { cwd: projectPath, stdio: "pipe" });
-              console.log(`  ✓ Pushed tag: ${tag}`);
+              execSync(`git push origin ${version.tag}`, { cwd: projectPath, stdio: "pipe" });
+              console.log(`  ✓ Pushed tag: ${version.tag}`);
            }
          } catch (err) {
            console.warn(`  ⚠ Git operations failed: ${err instanceof Error ? err.message : String(err)}`);
@@ -715,4 +725,98 @@ export function createShipCommand(): Command {

      console.log(`\n✓ Phase ${phaseNum} shipped successfully`);
    });
+}
+
+function computeShipVersion(
+  projectPath: string,
+  phaseNum: number,
+  config: CIConfig
+): { tag: string; milestoneType: "nfr" | "feature" | "schema-breaking" } {
+  const tags = execSync("git tag -l", { cwd: projectPath, encoding: "utf-8" })
+    .split("\n")
+    .map((t) => t.trim())
+    .filter(Boolean);
+
+  let major = 0;
+  let minor = 0;
+  let patch = 0;
+
+  for (const tag of tags) {
+    const match = tag.match(/^v(\d+)\.(\d+)\.(\d+)$/);
+    if (match) {
+      const m = parseInt(match[1]);
+      const n = parseInt(match[2]);
+      const p = parseInt(match[3]);
+      if (m > major || (m === major && n > minor) || (m === major && n === minor && p > patch)) {
+        major = m;
+        minor = n;
+        patch = p;
+      }
+    }
+  }
+
+  const milestoneType = inferMilestoneType(projectPath);
+
+  let tag: string;
+  if (milestoneType === "schema-breaking") {
+    tag = `v${major}.${minor + phaseNum}.0`;
+  } else {
+    tag = `v${major}.${minor}.${phaseNum}`;
+  }
+
+  return { tag, milestoneType };
+}
+
+function inferMilestoneType(projectPath: string): "nfr" | "feature" | "schema-breaking" {
+  try {
+    const log = execSync("git log --oneline -50", { cwd: projectPath, encoding: "utf-8" });
+    if (log.match(/\brefactor\b|\brewrite\b|\bmigrate\b|\brestructure\b/i)) return "schema-breaking";
+    if (log.match(/\bfeat\b/)) return "feature";
+    return "nfr";
+  } catch {
+    return "nfr";
+  }
+}
+
+function validateVersionOrder(projectPath: string, newTag: string): boolean {
+  const newMatch = newTag.match(/^v(\d+)\.(\d+)\.(\d+)$/);
+  if (!newMatch) return false;
+  const newMajor = parseInt(newMatch[1]);
+  const newMinor = parseInt(newMatch[2]);
+  const newPatch = parseInt(newMatch[3]);
+
+  const tags = execSync("git tag -l", { cwd: projectPath, encoding: "utf-8" })
+    .split("\n")
+    .map((t) => t.trim())
+    .filter(Boolean);
+
+  for (const tag of tags) {
+    const match = tag.match(/^v(\d+)\.(\d+)\.(\d+)$/);
+    if (!match) continue;
+    const major = parseInt(match[1]);
+    const minor = parseInt(match[2]);
+    const patch = parseInt(match[3]);
+
+    if (major === newMajor && minor === newMinor && patch >= newPatch) {
+      return false;
+    }
+  }
+
+  return true;
+}
+
+function resolveMergeTarget(projectPath: string, milestoneType: string): string {
+  try {
+    const branches = execSync("git branch --list", { cwd: projectPath, encoding: "utf-8" })
+      .split("\n")
+      .map((b) => b.trim().replace(/^\*?\s+/, ""))
+      .filter(Boolean);
+
+    const milestoneBranches = branches.filter((b) => b.startsWith("milestone/"));
+    if (milestoneBranches.length > 0) {
+      return milestoneBranches[0];
+    }
+  } catch {}
+
+  return "main";
 }
@@ -263,7 +263,7 @@ describe("CiFiles", () => {
        overview: "NFR-only",
        phases: [
          { number: 1, name: "test-coverage", description: "Add tests", status: "in_progress", dependsOn: [], requirements: [], successCriteria: [] },
-          { number: 2, name: "refactor-api", description: "Refactor", status: "not_started", dependsOn: [], requirements: [], successCriteria: [] },
+          { number: 2, name: "perf-tune", description: "Tune perf", status: "not_started", dependsOn: [], requirements: [], successCriteria: [] },
        ],
      };
      ciFiles.writeRoadmapMd(roadmap);
@@ -289,6 +289,64 @@ describe("CiFiles", () => {
    });
  });

+  describe("getMilestoneType", () => {
+    it("returns nfr when no roadmap exists", () => {
+      const ciFiles = new CiFiles(dir);
+      expect(ciFiles.getMilestoneType()).toBe("nfr");
+    });
+
+    it("returns nfr when phases are all NFR types", () => {
+      const ciFiles = new CiFiles(dir, "nfr-proj2");
+      ciFiles.ensureProjectDir();
+      fs.writeFileSync(path.join(dir, ".ci", "config.json"), JSON.stringify({
+        projects: [{ slug: "nfr-proj2", name: "NFR Project 2", default: true }],
+        active_project: "nfr-proj2",
+      }));
+      const roadmap: RoadmapMd = {
+        overview: "NFR-only",
+        phases: [
+          { number: 1, name: "fix-bug", description: "Fix bug", status: "in_progress", dependsOn: [], requirements: [], successCriteria: [] },
+        ],
+      };
+      ciFiles.writeRoadmapMd(roadmap);
+      expect(ciFiles.getMilestoneType()).toBe("nfr");
+    });
+
+    it("returns feature when phases include feat work", () => {
+      const ciFiles = new CiFiles(dir, "feat-proj2");
+      ciFiles.ensureProjectDir();
+      fs.writeFileSync(path.join(dir, ".ci", "config.json"), JSON.stringify({
+        projects: [{ slug: "feat-proj2", name: "Feature Project 2", default: true }],
+        active_project: "feat-proj2",
+      }));
+      const roadmap: RoadmapMd = {
+        overview: "feature",
+        phases: [
+          { number: 1, name: "auth-flow", description: "Auth feature", status: "in_progress", dependsOn: [], requirements: [], successCriteria: [] },
+        ],
+      };
+      ciFiles.writeRoadmapMd(roadmap);
+      expect(ciFiles.getMilestoneType()).toBe("feature");
+    });
+
+    it("returns schema-breaking when phases include refactor/rewrite/migrate", () => {
+      const ciFiles = new CiFiles(dir, "schema-proj");
+      ciFiles.ensureProjectDir();
+      fs.writeFileSync(path.join(dir, ".ci", "config.json"), JSON.stringify({
+        projects: [{ slug: "schema-proj", name: "Schema Project", default: true }],
+        active_project: "schema-proj",
+      }));
+      const roadmap: RoadmapMd = {
+        overview: "schema-breaking",
+        phases: [
+          { number: 1, name: "refactor-core", description: "Refactor core", status: "in_progress", dependsOn: [], requirements: [], successCriteria: [] },
+        ],
+      };
+      ciFiles.writeRoadmapMd(roadmap);
+      expect(ciFiles.getMilestoneType()).toBe("schema-breaking");
+    });
+  });
+
  describe("multi-project file paths", () => {
    it("writes PROJECT.md to project subdirectory when slug is set", () => {
      const ciFiles = new CiFiles(dir, "my-app");
@@ -2,6 +2,7 @@ import * as fs from "node:fs";
 import * as path from "node:path";
 import { writeFile, readFile, ensureDir, fileExists } from "../utils/file.js";
 import { PipelineStage } from "../types/pipeline.js";
+import { MilestoneType } from "../types/config.js";

 const CI_DIR = ".ci";

@@ -467,19 +468,31 @@ export class CiFiles {
    this.writeRoadmapMd(roadmap);
  }

-  isNfrMilestone(): boolean {
+  getMilestoneType(): MilestoneType {
    const roadmap = this.readRoadmapMd();
-    if (!roadmap) return true;
+    if (!roadmap) return "nfr";

    const nfrTypes: string[] = ["fix", "chore", "docs", "perf", "refactor", "test"];
+    const schemaBreakKeywords: string[] = ["refactor", "rewrite", "rearchitecture", "migrate", "restructure"];
+    let hasFeature = false;
+    let hasSchemaBreak = false;
+
    for (const phase of roadmap.phases) {
-      if (phase.status === "in_progress" || phase.status === "not_started") {
+      if (phase.status === "in_progress" || phase.status === "not_started" || phase.status === "complete") {
        const phaseName = phase.name.toLowerCase();
-        const hasFeature = !nfrTypes.some((t) => phaseName.includes(t)) && !phaseName.includes("bug") && !phaseName.includes("tune") && !phaseName.includes("refresh");
-        if (hasFeature) return false;
+        const isNfr = nfrTypes.some((t) => phaseName.includes(t)) || phaseName.includes("bug") || phaseName.includes("tune") || phaseName.includes("refresh");
+        if (!isNfr) hasFeature = true;
+        if (schemaBreakKeywords.some((k) => phaseName.includes(k))) hasSchemaBreak = true;
      }
    }
-    return true;
+
+    if (hasSchemaBreak) return "schema-breaking";
+    if (hasFeature) return "feature";
+    return "nfr";
+  }
+
+  isNfrMilestone(): boolean {
+    return this.getMilestoneType() === "nfr";
  }

  private parseProjectMd(content: string): ProjectMd {
@@ -545,21 +558,172 @@ export class CiFiles {
  }

  private parseRequirementsMd(content: string): RequirementsMd {
-    return {
-      v1: [],
-      v2: [],
-      outOfScope: [],
-      traceability: [],
-    };
+    const v1: RequirementsMd["v1"] = [];
+    const v2: RequirementsMd["v2"] = [];
+
+    const v1Section = this.extractSection(content, "## v1 Requirements");
+    if (v1Section) {
+      const categoryBlocks = v1Section.split(/\n### /).filter(Boolean);
+      for (const block of categoryBlocks) {
+        const lines = block.split("\n");
+        const category = lines[0].trim();
+        const items: Array<{ id: string; description: string }> = [];
+
+        for (const line of lines.slice(1)) {
+          const tableMatch = line.match(/^\|\s*([A-Z]+-\d+)\s*\|\s*(.+?)\s*\|/);
+          if (tableMatch) {
+            items.push({ id: tableMatch[1], description: tableMatch[2] });
+            continue;
+          }
+          const listMatch = line.match(/^\s*-?\s*\*?\s*\[?\s*\*?\s*([A-Z]+-\d+)[\]:\s*]*(.+)/);
+          if (listMatch) {
+            items.push({ id: listMatch[1], description: listMatch[2].trim() });
+          }
+        }
+
+        if (items.length > 0) {
+          v1.push({ category, items });
+        }
+      }
+    }
+
+    const v2Section = this.extractSection(content, "## v2 Requirements");
+    if (v2Section) {
+      const categoryBlocks = v2Section.split(/\n### /).filter(Boolean);
+      for (const block of categoryBlocks) {
+        const lines = block.split("\n");
+        const category = lines[0].trim();
+        const items: Array<{ id: string; description: string }> = [];
+
+        for (const line of lines.slice(1)) {
+          const tableMatch = line.match(/^\|\s*([A-Z]+-\d+)\s*\|\s*(.+?)\s*\|/);
+          if (tableMatch) {
+            items.push({ id: tableMatch[1], description: tableMatch[2] });
+            continue;
+          }
+          const listMatch = line.match(/^\s*-?\s*\*?\s*\[?\s*\*?\s*([A-Z]+-\d+)[\]:\s*]*(.+)/);
+          if (listMatch) {
+            items.push({ id: listMatch[1], description: listMatch[2].trim() });
+          }
+        }
+
+        if (items.length > 0) {
+          v2.push({ category, items });
+        }
+      }
+    }
+
+    const outOfScope: RequirementsMd["outOfScope"] = [];
+    const outSection = this.extractSection(content, "## Out of Scope");
+    if (outSection) {
+      const tableRows = outSection.split("\n").filter((line) => /^\|/.test(line) && !line.includes("---") && !line.includes("Feature"));
+      for (const row of tableRows) {
+        const cols = row.split("|").map((c) => c.trim()).filter(Boolean);
+        if (cols.length >= 2) {
+          outOfScope.push({ feature: cols[0], reason: cols[1] });
+        }
+      }
+      if (outOfScope.length === 0) {
+        const listItems = this.extractListItems(content, "## Out of Scope");
+        for (const item of listItems) {
+          outOfScope.push({ feature: item, reason: "" });
+        }
+      }
+    }
+
+    const traceability: RequirementsMd["traceability"] = [];
+    const traceSection = this.extractSection(content, "## Traceability");
+    if (traceSection) {
+      const activeHeader = traceSection.includes("Active Milestone")
+        ? "## v0.5 Requirements (Active Milestone)"
+        : content.includes("## v1 Requirements")
+          ? "## v1 Requirements"
+          : undefined;
+
+      const tableRows = traceSection.split("\n").filter((line) => /^\|/.test(line) && !line.includes("---") && !line.includes("Requirement") && !line.includes("REQ-ID"));
+      for (const row of tableRows) {
+        const cols = row.split("|").map((c) => c.trim()).filter(Boolean);
+        if (cols.length >= 3) {
+          const req = cols[0];
+          const phaseStr = cols[1];
+          const phaseMatch = phaseStr.match(/(\d+)/);
+          const phase = phaseMatch ? parseInt(phaseMatch[1], 10) : 0;
+          const statusStr = cols[2].toLowerCase();
+          const status = ["pending", "in_progress", "complete", "blocked", "covered"].includes(statusStr)
+            ? (statusStr === "covered" ? "complete" : statusStr as "pending" | "in_progress" | "complete" | "blocked")
+            : "pending";
+          traceability.push({ requirement: req, phase, status });
+        }
+      }
+    }
+
+    const allReqIds = new Set<string>();
+    for (const cat of [...v1, ...v2]) {
+      for (const item of cat.items) {
+        allReqIds.add(item.id);
+      }
+    }
+    for (const t of traceability) {
+      allReqIds.add(t.requirement);
+    }
+    const coveredInTrace = new Set(traceability.filter((t) => t.status === "complete").map((t) => t.requirement));
+    for (const reqId of allReqIds) {
+      if (!coveredInTrace.has(reqId)) {
+        traceability.push({ requirement: reqId, phase: 0, status: "pending" });
+      }
+    }
+
+    return { v1, v2, outOfScope, traceability };
  }

  private parseArchitectureMd(content: string): ArchitectureMd {
-    return {
-      overview: this.extractSection(content, "## Overview") || "",
-      components: [],
-      dataFlow: this.extractSection(content, "## Data Flow") || "",
-      buildOrder: [],
-    };
+    const overview = this.extractSection(content, "## Overview") || "";
+
+    const components: ArchitectureMd["components"] = [];
+    const section = content;
+    const componentRegex = /###\s+(.+)/g;
+    let compMatch;
+
+    const h3Positions: Array<{ name: string; start: number }> = [];
+    while ((compMatch = componentRegex.exec(section)) !== null) {
+      h3Positions.push({ name: compMatch[1].trim(), start: compMatch.index + compMatch[0].length });
+    }
+
+    for (let i = 0; i < h3Positions.length; i++) {
+      const name = h3Positions[i].name;
+      const start = h3Positions[i].start;
+      const end = i + 1 < h3Positions.length ? h3Positions[i + 1].start - (content.substring(h3Positions[i + 1].start - 4, h3Positions[i + 1].start) === "### " ? 4 : 0) : content.length;
+      const block = content.slice(start, end);
+
+      const descMatch = block.match(/[-*]\s*\*?\*?(?:Description|description)\*?\*?\s*[:：]\s*(.+)/);
+      const boundaryMatch = block.match(/[-*]\s*\*?\*?(?:Boundaries|boundaries)\*?\*?\s*[:：]\s*(.+)/);
+      const depsMatch = block.match(/[-*]\s*\*?\*?(?:Depends on|depends on|Dependencies)\*?\*?\s*[:：]\s*(.+)/);
+
+      components.push({
+        name,
+        description: descMatch ? descMatch[1].trim() : "",
+        boundaries: boundaryMatch ? boundaryMatch[1].trim() : "",
+        dependsOn: depsMatch
+          ? depsMatch[1].split(",").map((d: string) => d.trim().replace(/\*\*/g, "")).filter(Boolean)
+          : [],
+      });
+    }
+
+    const dataFlow = this.extractSection(content, "## Data Flow")
+      || this.extractSection(content, "## Data flow")
+      || "";
+
+    const buildOrder: string[] = [];
+    const buildSection = this.extractSection(content, "## Build Order");
+    if (buildSection) {
+      const listItems = buildSection
+        .split("\n")
+        .filter((line) => /^\d+\./.test(line.trim()))
+        .map((line) => line.trim().replace(/^\d+\.\s*/, ""));
+      buildOrder.push(...listItems);
+    }
+
+    return { overview, components, dataFlow, buildOrder };
  }

  private extractSection(content: string, header: string): string | null {
@@ -81,17 +81,18 @@ export class ErrorRecovery {
        this.git(`branch -D ${phaseBranch}`);
      }

-      const tag = `v0.5.${phase}`;
-      const tags = this.git("tag -l").split("\n").map((t) => t.trim());
-      if (tags.includes(tag)) {
-        this.git(`tag -d ${tag}`);
+      const tags = this.git("tag -l").split("\n").map((t) => t.trim()).filter(Boolean);
+      const phaseTagPattern = new RegExp(`^v\\d+\\.\\d+\\.${phase}$`);
+      const matchingTag = tags.find((t) => phaseTagPattern.test(t));
+      if (matchingTag) {
+        this.git(`tag -d ${matchingTag}`);
      }

      return {
        recovered: true,
        strategy: "rollback",
        attempts: 1,
-        message: `Rolled back phase ${phase}: ${reason}. Branch ${branchExists ? `${phaseBranch} deleted` : "not found"}. Tag ${tags.includes(tag) ? `${tag} deleted` : "not found"}.`,
+        message: `Rolled back phase ${phase}: ${reason}. Branch ${branchExists ? `${phaseBranch} deleted` : "not found"}. Tag ${matchingTag ? `${matchingTag} deleted` : "not found"}.`,
      };
    } catch (err) {
      return {
@@ -137,4 +137,86 @@ describe("GitBranch", () => {
      expect(result.name).toMatch(/^phase\/01-/);
    });
  });
+
+  describe("validateMergeOrder", () => {
+    it("rejects phase → main when milestone branch exists", () => {
+      const gitBranch = new GitBranch(repoDir);
+      gitBranch.createMilestoneBranch("v0.5", "baseline");
+      gitBranch.createPhaseBranch(1, "auth");
+      execSync(`git checkout main`, { cwd: repoDir, stdio: "pipe" });
+
+      const result = gitBranch.validateMergeOrder("phase/01-auth", "main");
+      expect(result.valid).toBe(false);
+      expect(result.reason).toContain("milestone");
+    });
+
+    it("allows phase → milestone branch", () => {
+      const gitBranch = new GitBranch(repoDir);
+      gitBranch.createMilestoneBranch("v0.5", "baseline");
+      gitBranch.createPhaseBranch(1, "auth");
+      execSync(`git checkout milestone/v0.5-baseline`, { cwd: repoDir, stdio: "pipe" });
+
+      const result = gitBranch.validateMergeOrder("phase/01-auth", "milestone/v0.5-baseline");
+      expect(result.valid).toBe(true);
+    });
+
+    it("allows phase → main when no milestone branch exists", () => {
+      const gitBranch = new GitBranch(repoDir);
+      gitBranch.createPhaseBranch(1, "auth");
+      execSync(`git checkout main`, { cwd: repoDir, stdio: "pipe" });
+
+      const result = gitBranch.validateMergeOrder("phase/01-auth", "main");
+      expect(result.valid).toBe(true);
+    });
+
+    it("allows hotfix → main", () => {
+      const gitBranch = new GitBranch(repoDir);
+      gitBranch.createMilestoneBranch("v0.5", "baseline");
+      execSync(`git checkout -b hotfix/critical-fix main`, { cwd: repoDir, stdio: "pipe" });
+      fs.writeFileSync(path.join(repoDir, "fix.txt"), "fix");
+      execSync(`git add . && git commit -m "hotfix: critical fix"`, { cwd: repoDir, stdio: "pipe" });
+      execSync(`git checkout main`, { cwd: repoDir, stdio: "pipe" });
+
+      const result = gitBranch.validateMergeOrder("hotfix/critical-fix", "main");
+      expect(result.valid).toBe(true);
+    });
+  });
+
+  describe("computeMilestoneTag", () => {
+    it("computes next minor for feature milestone", () => {
+      execSync(`git tag -a v0.5.1 -m "v0.5.1"`, { cwd: repoDir, stdio: "pipe" });
+      execSync(`git tag -a v0.5.2 -m "v0.5.2"`, { cwd: repoDir, stdio: "pipe" });
+
+      const gitBranch = new GitBranch(repoDir);
+      const tag = gitBranch.computeMilestoneTag("feature");
+      expect(tag).toBe("v0.6.0");
+    });
+
+    it("computes next major for schema-breaking milestone", () => {
+      execSync(`git tag -a v0.5.1 -m "v0.5.1"`, { cwd: repoDir, stdio: "pipe" });
+
+      const gitBranch = new GitBranch(repoDir);
+      const tag = gitBranch.computeMilestoneTag("schema-breaking");
+      expect(tag).toBe("v1.0.0");
+    });
+
+    it("starts from v0.1.0 when no tags exist", () => {
+      const gitBranch = new GitBranch(repoDir);
+      const tag = gitBranch.computeMilestoneTag("feature");
+      expect(tag).toBe("v0.1.0");
+    });
+  });
+
+  describe("mergeMilestoneBranch", () => {
+    it("rejects merge when unmerged phase branches remain", () => {
+      const gitBranch = new GitBranch(repoDir);
+      gitBranch.createMilestoneBranch("v0.5", "baseline");
+      gitBranch.createPhaseBranch(1, "auth");
+      execSync(`git checkout main`, { cwd: repoDir, stdio: "pipe" });
+
+      const result = gitBranch.mergeMilestoneBranch("milestone/v0.5-baseline", "main", true);
+      expect(result.success).toBe(false);
+      expect(result.message).toContain("unmerged");
+    });
+  });
 });
@@ -1,5 +1,6 @@
 import { execSync } from "node:child_process";
 import { GitContext, BranchInfo } from "./git-context.js";
+import { MilestoneType } from "../types/config.js";

 export interface BranchCreateResult {
  name: string;
@@ -108,6 +109,11 @@ export class GitBranch {
    targetBranch: string,
    squash: boolean = true
  ): BranchMergeResult {
+    const validation = this.validateMergeOrder(phaseBranchName, targetBranch);
+    if (!validation.valid) {
+      return { success: false, squash, message: `Merge rejected: ${validation.reason}` };
+    }
+
    const branches = this.gitContext.getBranches();
    const phaseBranch = branches.find((b) => b.name === phaseBranchName);
    if (!phaseBranch) {
@@ -136,6 +142,113 @@ export class GitBranch {
    };
  }

+  mergeMilestoneBranch(
+    milestoneBranchName: string,
+    targetBranch: string,
+    squash: boolean = true
+  ): BranchMergeResult {
+    const branches = this.gitContext.getBranches();
+    const milestoneBranch = branches.find((b) => b.name === milestoneBranchName);
+    if (!milestoneBranch) {
+      return { success: false, squash, message: `Branch ${milestoneBranchName} not found` };
+    }
+
+    const phaseBranches = branches.filter(
+      (b) => b.type === "phase" && !b.merged
+    );
+    if (phaseBranches.length > 0) {
+      return {
+        success: false,
+        squash,
+        message: `Cannot merge milestone: ${phaseBranches.length} unmerged phase branch(es) remain (${phaseBranches.map((b) => b.name).join(", ")})`,
+      };
+    }
+
+    this.git(`checkout ${targetBranch}`);
+
+    const mergeCmd = squash
+      ? `merge --squash ${milestoneBranchName}`
+      : `merge --no-ff ${milestoneBranchName}`;
+
+    const result = this.git(mergeCmd);
+    if (result === "" && !squash) {
+      return { success: false, squash, message: `Merge conflict on ${milestoneBranchName}` };
+    }
+
+    if (squash) {
+      this.git(`commit -m "docs: merge milestone branch ${milestoneBranchName}"`);
+    }
+
+    return {
+      success: true,
+      squash,
+      message: `Merged ${milestoneBranchName} into ${targetBranch} (squash: ${squash})`,
+    };
+  }
+
+  validateMergeOrder(sourceBranch: string, targetBranch: string): { valid: boolean; reason: string } {
+    const branches = this.gitContext.getBranches();
+    const source = branches.find((b) => b.name === sourceBranch);
+    if (!source) return { valid: false, reason: `Source branch ${sourceBranch} not found` };
+
+    if (source.type === "hotfix") {
+      return { valid: true, reason: "Hotfix branches may merge to any target" };
+    }
+
+    if (source.type === "phase" && targetBranch === "main") {
+      const milestoneBranches = branches.filter(
+        (b) => b.type === "milestone" && !b.merged
+      );
+      if (milestoneBranches.length > 0) {
+        return {
+          valid: false,
+          reason: `Phase branch must merge into milestone branch first (active: ${milestoneBranches.map((b) => b.name).join(", ")}). Merge into main only through the milestone branch.`,
+        };
+      }
+    }
+
+    if (source.type === "milestone" && targetBranch === "main") {
+      const phaseBranches = branches.filter(
+        (b) => b.type === "phase" && !b.merged
+      );
+      if (phaseBranches.length > 0) {
+        return {
+          valid: false,
+          reason: `Milestone cannot merge to main: ${phaseBranches.length} unmerged phase branch(es) remain.`,
+        };
+      }
+    }
+
+    return { valid: true, reason: "Merge order is valid" };
+  }
+
+  computeMilestoneTag(milestoneType: MilestoneType): string {
+    const tags = this.git("tag -l").split("\n").map((t) => t.trim()).filter(Boolean);
+    let major = 0;
+    let minor = 0;
+    let patch = 0;
+
+    for (const tag of tags) {
+      const match = tag.match(/^v(\d+)\.(\d+)\.(\d+)$/);
+      if (match) {
+        const m = parseInt(match[1]);
+        const n = parseInt(match[2]);
+        const p = parseInt(match[3]);
+        if (m > major || (m === major && n > minor) || (m === major && n === minor && p > patch)) {
+          major = m;
+          minor = n;
+          patch = p;
+        }
+      }
+    }
+
+    if (milestoneType === "schema-breaking") {
+      return `v${major + 1}.0.0`;
+    }
+
+    return `v${major}.${minor + 1}.0`;
+  }
+
  getPhaseStatus(phaseNumber: number): PhaseBranchInfo | null {
    const branches = this.gitContext.getBranches();
    const phaseBranch = branches.find(
@@ -279,4 +279,45 @@ status: execute
      expect(ctx.isNfrMilestone()).toBe(false);
    });
  });
+
+  describe("getMilestoneType", () => {
+    it("returns nfr when only NFR commits exist", () => {
+      commit(repoDir, `chore(P01): cleanup
+
+---ci---
+phase: 1
+milestone: v0.1.1
+status: execute
+---/ci---`);
+
+      const ctx = new GitContext(repoDir);
+      expect(ctx.getMilestoneType()).toBe("nfr");
+    });
+
+    it("returns feature when feat commits exist", () => {
+      commit(repoDir, `feat(P01): add feature
+
+---ci---
+phase: 1
+milestone: v1.0
+status: execute
+---/ci---`);
+
+      const ctx = new GitContext(repoDir);
+      expect(ctx.getMilestoneType()).toBe("feature");
+    });
+
+    it("returns schema-breaking when refactor commits exist", () => {
+      commit(repoDir, `refactor(P01): rewrite core
+
+---ci---
+phase: 1
+milestone: v0.5
+status: execute
+---/ci---`);
+
+      const ctx = new GitContext(repoDir);
+      expect(ctx.getMilestoneType()).toBe("schema-breaking");
+    });
+  });
 });
@@ -7,6 +7,8 @@ import {
 import { parseCommitMessage } from "./commit-parser.js";
 import { PipelineStage } from "../types/pipeline.js";

+import { MilestoneType } from "../types/config.js";
+
 export interface ProjectState {
  currentPhase: number;
  currentMilestone: string;
@@ -342,13 +344,20 @@ export class GitContext {
    return null;
  }

-  isNfrMilestone(): boolean {
+  getMilestoneType(): MilestoneType {
    const commits = this.getRecentCommits(100);
+    let hasAnyCiCommit = false;
    for (const commit of commits) {
-      if (commit.type === "feat" && commit.ci) {
-        return false;
-      }
+      if (!commit.ci) continue;
+      hasAnyCiCommit = true;
+      if (commit.type === "feat") return "feature";
+      if (commit.type === "refactor" || commit.scope === "init") return "schema-breaking";
    }
-    return true;
+    if (!hasAnyCiCommit) return "nfr";
+    return "nfr";
+  }
+
+  isNfrMilestone(): boolean {
+    return this.getMilestoneType() === "nfr";
  }
 }
@@ -6,6 +6,8 @@ export type ModelProfile = "quality" | "speed" | "balanced";

 export type BranchingStrategy = "phase" | "feature" | "trunk";

+export type MilestoneType = "nfr" | "feature" | "schema-breaking";
+
 export type PhaseName = "research" | "plan" | "execute" | "verify" | "complete";

 export type AgentName =
@@ -27,6 +27,7 @@ export class BehavioralVerification extends VerificationLayer {
    checks.push(this.checkSpecificationRequirements(projectPath));
    checks.push(this.checkPlanMustHaves(projectPath, phase));
    checks.push(this.checkCodeHasExports(projectPath));
+    checks.push(this.checkRequirementTestCoverage(projectPath));

    const passed = checks.every((c) => c.status !== "fail");
    return {
@@ -219,6 +220,98 @@ export class BehavioralVerification extends VerificationLayer {
    );
  }

+  private checkRequirementTestCoverage(projectPath: string): VerificationCheck {
+    const isGitRepo = fs.existsSync(path.join(projectPath, ".git"));
+    if (!isGitRepo) {
+      return this.check(
+        "Requirement test coverage via git log",
+        "skipped",
+        "Not a git repository — cannot check requirement coverage from commit history"
+      );
+    }
+
+    try {
+      const raw = execSync(
+        `git log --all --max-count=100 --format="%B%x01"`,
+        { cwd: projectPath, encoding: "utf-8", stdio: ["pipe", "pipe", "pipe"], timeout: 5000 }
+      );
+
+      const coveredReqs = new Set<string>();
+      const ciBlockRegex = /---ci---[\s\S]*?---\/ci---/g;
+      const entries = raw.split("\x01").filter(Boolean);
+
+      for (const entry of entries) {
+        let match;
+        while ((match = ciBlockRegex.exec(entry)) !== null) {
+          const reqMatch = match[0].match(/covered:\s*\[([^\]]*)\]/);
+          if (reqMatch) {
+            const reqs = reqMatch[1].split(",").map((r: string) => r.trim().replace(/['"]/g, "")).filter(Boolean);
+            for (const req of reqs) coveredReqs.add(req);
+          }
+        }
+        ciBlockRegex.lastIndex = 0;
+      }
+
+      const reqPath = path.join(projectPath, ".ci", "REQUIREMENTS.md");
+      if (!fs.existsSync(reqPath)) {
+        return this.check(
+          "Requirement test coverage via git log",
+          "skipped",
+          "No REQUIREMENTS.md found to check coverage against"
+        );
+      }
+
+      const content = fs.readFileSync(reqPath, "utf-8");
+      const allReqs = content
+        .split("\n")
+        .filter((line) => /^\|.*\|.*\|.*\|/.test(line) && !line.includes("REQ-ID") && !line.includes("---"))
+        .map((line) => {
+          const cols = line.split("|").map((c) => c.trim()).filter(Boolean);
+          return cols.length >= 1 ? cols[0] : "";
+        })
+        .filter(Boolean);
+
+      if (allReqs.length === 0) {
+        return this.check(
+          "Requirement test coverage via git log",
+          "skipped",
+          "No requirements with REQ-IDs found in REQUIREMENTS.md"
+        );
+      }
+
+      const covered = allReqs.filter((r) => coveredReqs.has(r));
+      const coveragePct = Math.round((covered.length / allReqs.length) * 100);
+
+      if (coveragePct >= 80) {
+        return this.check(
+          "Requirement test coverage via git log",
+          "pass",
+          `${covered.length}/${allReqs.length} requirements covered (${coveragePct}%)`
+        );
+      }
+
+      if (coveragePct >= 50) {
+        return this.check(
+          "Requirement test coverage via git log",
+          "warning",
+          `${covered.length}/${allReqs.length} requirements covered (${coveragePct}%) — target ≥80%`
+        );
+      }
+
+      return this.check(
+        "Requirement test coverage via git log",
+        "warning",
+        `${covered.length}/${allReqs.length} requirements covered (${coveragePct}%) — significant gaps`
+      );
+    } catch {
+      return this.check(
+        "Requirement test coverage via git log",
+        "skipped",
+        "Could not read git log for requirement coverage"
+      );
+    }
+  }
+
  private checkCodeHasExports(projectPath: string): VerificationCheck {
    const srcDir = path.join(projectPath, "src");
    if (!fs.existsSync(srcDir)) {
@@ -1,5 +1,6 @@
 import * as fs from "node:fs";
 import * as path from "node:path";
+import { execSync } from "node:child_process";
 import { VerificationLayer, VerificationResult, VerificationCheck } from "./types.js";

 interface CodeFinding {
@@ -66,6 +67,7 @@ export class QualityVerification extends VerificationLayer {
    checks.push(this.checkP2P3Findings(p2p3Findings));
    checks.push(this.checkTypeScriptStrictness(projectPath));
    checks.push(this.checkConsistentNaming(projectPath));
+    checks.push(this.checkTypeScriptCompilation(projectPath));

    const hasP0Fail = p0Findings.length > 3;
    const passed = !hasP0Fail;
@@ -226,6 +228,32 @@ export class QualityVerification extends VerificationLayer {
    );
  }

+  private checkTypeScriptCompilation(projectPath: string): VerificationCheck {
+    const tsconfigPath = path.join(projectPath, "tsconfig.json");
+    if (!fs.existsSync(tsconfigPath)) {
+      return this.check("TypeScript compilation", "skipped", "No tsconfig.json found");
+    }
+
+    try {
+      execSync("npx tsc --noEmit 2>&1", {
+        cwd: projectPath,
+        encoding: "utf-8",
+        timeout: 60000,
+        stdio: ["pipe", "pipe", "pipe"],
+      });
+      return this.check("TypeScript compilation", "pass", "TypeScript compiles without errors");
+    } catch (err) {
+      const execErr = err as { stdout?: string };
+      const output = execErr.stdout || "";
+      const errorCount = (output.match(/error TS/g) || []).length;
+      return this.check(
+        "TypeScript compilation",
+        errorCount > 5 ? "fail" : "warning",
+        `${errorCount} TypeScript compilation error(s)`
+      );
+    }
+  }
+
  private collectFiles(dir: string, files: string[]): void {
    const entries = fs.readdirSync(dir, { withFileTypes: true });
    for (const entry of entries) {
@@ -1,5 +1,6 @@
 import * as fs from "node:fs";
 import * as path from "node:path";
+import { execSync } from "node:child_process";
 import { VerificationLayer, VerificationResult, VerificationCheck } from "./types.js";

 interface ThreatEntry {
@@ -250,24 +251,80 @@ export class SecurityVerification extends VerificationLayer {
  }

  private checkDependencyVulnerabilities(projectPath: string): VerificationCheck {
-    const packageLockPath = path.join(projectPath, "package-lock.json");
-    if (!fs.existsSync(packageLockPath)) {
-      return this.check(
-        "Dependency audit",
-        "skipped",
-        "No package-lock.json found — cannot audit dependencies"
-      );
-    }
-
    const packageJsonPath = path.join(projectPath, "package.json");
    if (!fs.existsSync(packageJsonPath)) {
      return this.check("Dependency audit", "skipped", "No package.json found");
    }

-    return this.check(
-      "Dependency audit",
-      "pass",
-      "Dependency structure available for audit (run `npm audit` for full check)"
-    );
+    try {
+      const result = execSync("npm audit --json 2>/dev/null", {
+        cwd: projectPath,
+        encoding: "utf-8",
+        timeout: 30000,
+        stdio: ["pipe", "pipe", "pipe"],
+      });
+      const audit = JSON.parse(result);
+      const vulnerabilities = audit.metadata?.vulnerabilities || {};
+      const high = vulnerabilities.high || 0;
+      const critical = vulnerabilities.critical || 0;
+      const medium = vulnerabilities.moderate || 0;
+      const low = vulnerabilities.low || 0;
+      const total = high + critical + medium + low;
+
+      if (total === 0) {
+        return this.check("Dependency audit", "pass", "No known vulnerabilities in dependencies");
+      }
+
+      if (critical > 0 || high > 0) {
+        return this.check(
+          "Dependency audit",
+          "fail",
+          `${total} vulnerabilities (critical: ${critical}, high: ${high}, medium: ${medium}, low: ${low})`
+        );
+      }
+
+      return this.check(
+        "Dependency audit",
+        "warning",
+        `${total} vulnerabilities (medium: ${medium}, low: ${low}) — no critical/high`
+      );
+    } catch (err) {
+      const output = (err as { stdout?: string }).stdout;
+      if (output) {
+        try {
+          const audit = JSON.parse(output);
+          const vulnerabilities = audit.metadata?.vulnerabilities || {};
+          const high = vulnerabilities.high || 0;
+          const critical = vulnerabilities.critical || 0;
+          const medium = vulnerabilities.moderate || 0;
+          const low = vulnerabilities.low || 0;
+          const total = high + critical + medium + low;
+
+          if (total === 0) {
+            return this.check("Dependency audit", "pass", "No known vulnerabilities in dependencies");
+          }
+
+          if (critical > 0 || high > 0) {
+            return this.check(
+              "Dependency audit",
+              "fail",
+              `${total} vulnerabilities (critical: ${critical}, high: ${high}, medium: ${medium}, low: ${low})`
+            );
+          }
+
+          return this.check(
+            "Dependency audit",
+            "warning",
+            `${total} vulnerabilities (medium: ${medium}, low: ${low}) — no critical/high`
+          );
+        } catch {}
+      }
+
+      return this.check(
+        "Dependency audit",
+        "skipped",
+        "npm audit not available — run manually for full check"
+      );
+    }
  }
 }
@@ -4,7 +4,7 @@

 ## Decision Log

-Decisions are automatically logged to `.ci/audit/` with:
+Decisions are automatically logged to `.ciagent/audit/` with:
 - Timestamp
 - Decision ID
 - What was decided
@@ -15,5 +15,5 @@ Decisions are automatically logged to `.ci/audit/` with:

 ## Reviewing Decisions

-Run `ci audit` to review all autonomous decisions.
-Run `ci audit --verbose` for detailed decision information.
+Run `ciagent audit` to review all autonomous decisions.
+Run `ciagent audit --verbose` for detailed decision information.
Author	SHA1	Message	Date
Jon Chery	e31afe3b59	docs(rebrand): rename & rebrand CI → CIAgent across all documentation, templates, and scripts - README.md: title, project name, CLI commands, .ci/ → .ciagent/, ci-files → ciagent-files, CI Modification → CIAgent Modification - AGENTS.md: title, project name, architecture tree, agent count (18→19), test count (25→31 suites, 218→370 tests), version (0.4.0→0.6.0), ci-files → ciagent-files, CIConfig → CIAgentConfig, CiMetadata → CIAgentMetadata, .ci/ → .ciagent/ - templates/DECISIONS.md: .ci/audit/ → .ciagent/audit/, ci audit → ciagent audit - scripts/postinstall.js: CI postinstall → CIAgent postinstall - scripts/install.sh: CI → CIAgent, ci-init → ciagent-init, INSTALL COMPLETE banner - opencode/ci/workflows/.md (11 files): .ci/ → .ciagent/, CI → CIAgent project name, ci-command → ciagent-command usage lines - opencode/ci/references/.md (5 files): .ci/ → .ciagent/, CI → CIAgent project name, ci-files → ciagent-files references - opencode/ci/contexts/.md (3 files): .ci/ → .ciagent/, CI → CIAgent project name - opencode/agents/ci-.md (18 files): .ci/ → .ciagent/, CI → CIAgent project name - opencode/command/ci-.md (11 files): CI → CIAgent project name Preserved: ---ci---/---/ci--- markers, opencode/ci/ dir paths, ci-.md filenames, ci listProjects()/ci setActiveProject() API names, repo URLs ---ci--- phase: 1 milestone: v0.6 plan: 01-01 task: 01-01-01 status: execute ---/ci---	2026-05-29 17:58:48 +00:00
Jon Chery	ab6af144b7	feat(P06): 3-tier versioning, branch hierarchy enforcement, ARCHITECTURE-PLAN synthesis ---ci--- phase: 6 milestone: v0.5 status: complete decisions: - id: D-006 decision: Research as intermediate work product rationale: Conclusions update .ci/ files; full research doc intentionally not preserved confidence: 0.90 - id: D-007 decision: Branch hierarchy enforcement: main > milestone > phase rationale: Prevents out-of-order merges and semantically wrong tags confidence: 0.92 - id: D-008 decision: 3-tier versioning: NFR/feature/schema-breaking rationale: Patch per phase (NFR/feature) or minor per phase (schema-breaking); milestone gets minor (feature) or major (schema-breaking) confidence: 0.95 requirements: covered: [VER-06, BRANCH-01, BRANCH-02, ARCH-01] ---/ci--- - Synthesize ARCHITECTURE-PLAN.md into .ci/ci/ARCHITECTURE.md (expanded 51→230 lines) - Add D-006/D-007/D-008 to .ci/ci/PROJECT.md key decisions table - Delete ARCHITECTURE-PLAN.md after synthesis - Rewrite ship.md with 3-tier versioning model + branch hierarchy merge flows - Rewrite branch-strategy.md with 3-tier versioning + branch hierarchy + version validation - Add MilestoneType to config types - Replace isNfrMilestone() with getMilestoneType() returning nfr\|feature\|schema-breaking - Add validateMergeOrder(), mergeMilestoneBranch(), computeMilestoneTag() to GitBranch - Add computeShipVersion(), validateVersionOrder(), resolveMergeTarget() to ship command - Remove hardcoded v0.5. from error-recovery rollback - Create .githooks/pre-push for semver ordering + branch hierarchy validation - Add 15 new tests (370 total, all passing)	2026-05-29 17:18:10 +00:00
Jon Chery	3d069319b5	feat(P05): implement parseRequirementsMd and parseArchitectureMd — real content parsing ---ci--- project: ci phase: 5 milestone: v0.5 status: complete decisions: - id: D-030 decision: Phase 5 Parser Completeness complete rationale: All PARSE requirements covered; 31 suites, 355 tests confidence: 0.95 alternatives: [] requirements: covered: [PARSE-01, PARSE-02] ---/ci---	2026-05-29 16:47:17 +00:00
Jon Chery	b33431c1a6	feat(P04): verification intelligence — git-native coverage, npm audit, TS compilation ---ci--- project: ci phase: 4 milestone: v0.5 status: complete decisions: - id: D-028 decision: Phase 4 Verification Intelligence complete rationale: All INTEL requirements covered; 31 suites, 355 tests confidence: 0.95 alternatives: [] requirements: covered: [INTEL-01, INTEL-02, INTEL-03] ---/ci---	2026-05-29 16:46:17 +00:00