From cf1175bfd7230d9519101a75fba9f91b46fb0bae Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 09:02:14 +0200
Subject: [PATCH 01/13] [US-278] test: add failing conformance guard for
 bootstrap quick mode
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- 25 RED tests over dataset/.skills/process/bootstrap/** + root mirror
- Cover selector/$mode + guided declared default (AC1/AC2)
- Cover composition of the Guided/Quick Setup Convention, no bespoke resolution (AC3)
- Cover per-decision defaultability doc, adoption-file sameness (AC4), edge cases
- Cover guided-path anchors (no regression), mirror equality, timed CP + docs
- Task: T1 — identify defaultable vs still-asked bootstrap decisions (RED)

Refs: #278
---
 .../src/conformance/bootstrap.test.ts         | 261 ++++++++++++++++++
 1 file changed, 261 insertions(+)
 create mode 100644 packages/knowledge-hub/src/conformance/bootstrap.test.ts

diff --git a/packages/knowledge-hub/src/conformance/bootstrap.test.ts b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
new file mode 100644
index 00000000..cee0da1d
--- /dev/null
+++ b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
@@ -0,0 +1,261 @@
+import { describe, it, expect } from 'vitest'
+import { existsSync, readFileSync } from 'fs'
+import { join } from 'path'
+import { syncFrontmatter } from '@pair/content-ops'
+import {
+  buildDatasetSkillNameMap,
+  buildSkillLinkPathMap,
+  applyKnownMirrorTransforms,
+} from '../tools/skills-guide-mirror'
+
+// Conformance guard for the `bootstrap` skill artifact
+// (dataset/.skills/process/bootstrap/** + its root mirror).
+//
+// Story #278 — Quickstart path: bootstrap gains a QUICK setup depth as an
+// ADDITIVE second resolution depth of the same skill (no new skill, no second
+// entry point). It composes the already-merged Guided/Quick Setup Convention
+// (#276) rather than inventing a Quickstart-specific resolution (AC3): the
+// convention fixes the selector direction, the defaults cascade, and the
+// non-interactive safety rule; bootstrap only declares its per-adopter delta
+// (which decision points are defaultable, which are still asked, and from which
+// source each tier is filled) in the disclosed `quick-mode-defaults.md`.
+//
+// Guided remains bootstrap's DECLARED DEFAULT — absent an explicit quick signal
+// the existing interview runs unchanged (AC2), and every file quick mode writes
+// is a normal adoption file, editable exactly as guided mode's would be (AC4).
+// See issue #278 and epic #213.
+
+const ROOT = join(__dirname, '../../../..')
+const SKILLS_DIR = join(__dirname, '../../dataset/.skills')
+const DATASET_DIR = join(SKILLS_DIR, 'process/bootstrap')
+const MIRROR_DIR = join(ROOT, '.claude/skills/pair-process-bootstrap')
+
+const CONVENTION_REL =
+  '.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md'
+
+const read = (p: string): string => readFileSync(p, 'utf-8')
+const datasetSkill = (): string => read(join(DATASET_DIR, 'SKILL.md'))
+const datasetDefaults = (): string => read(join(DATASET_DIR, 'quick-mode-defaults.md'))
+const mirrorSkill = (): string => read(join(MIRROR_DIR, 'SKILL.md'))
+const mirrorDefaults = (): string => read(join(MIRROR_DIR, 'quick-mode-defaults.md'))
+
+/**
+ * The dataset → root-mirror transform pair (`pair update`): skill-reference
+ * rewrite (`/bootstrap` → `/pair-process-bootstrap`) + SKILL.md link-path
+ * rewrite. Same helper the implement/skills-guide mirror guards use.
+ */
+const toMirror = (text: string): string =>
+  applyKnownMirrorTransforms(
+    text,
+    buildDatasetSkillNameMap(SKILLS_DIR),
+    buildSkillLinkPathMap(SKILLS_DIR),
+  )
+
+// The flatten/prefix link-rewriter prepends `./` to a bare SAME-DIR relative
+// link when the file moves (link-rewriter computeNewHref). Neutralize exactly
+// that shape on both sides — a `./sub/file.md` drift still fails.
+const neutralizeSameDirDotSlash = (s: string): string => s.replace(/\]\(\.\/([^/)]+)\)/g, ']($1)')
+
+describe('prerequisite: the Guided/Quick Setup Convention exists (#276)', () => {
+  it('is present in both the dataset and the root KB mirror', () => {
+    expect(existsSync(join(__dirname, '../../dataset', CONVENTION_REL))).toBe(true)
+    expect(existsSync(join(ROOT, CONVENTION_REL))).toBe(true)
+  })
+})
+
+describe('bootstrap quick mode: selector + declared default (AC1/AC2)', () => {
+  it('declares a $mode argument with guided as the default and quick as the opt-in', () => {
+    const c = datasetSkill()
+    expect(c).toMatch(/##\s*Arguments/)
+    expect(c).toMatch(/\$mode/)
+    // Both depths named, guided explicitly the declared default.
+    expect(c).toMatch(/guided/i)
+    expect(c).toMatch(/quick/i)
+    expect(c).toMatch(/declared default[^.\n]*guided|guided[^.\n]*declared default/i)
+  })
+
+  it('treats an absent $mode as guided — the existing interview, unchanged (AC2)', () => {
+    const c = datasetSkill().toLowerCase()
+    expect(c).toMatch(/absent|omitted|without/)
+    expect(c).toMatch(/additive/)
+    // quick is a second resolution depth of the SAME skill, never a new skill.
+    expect(c).toMatch(/no new skill|not a separate skill|same skill/)
+  })
+
+  it('reaches a first workable story with no interview in quick mode (AC1)', () => {
+    const c = datasetSkill().toLowerCase()
+    expect(c).toMatch(/no interview|without an interview|asks no questions/)
+    expect(c).toMatch(/first workable story/)
+  })
+})
+
+describe('quick mode composes the Guided/Quick Setup Convention (AC3)', () => {
+  it('links the convention from SKILL.md instead of restating a resolution order', () => {
+    expect(datasetSkill()).toContain('guided-quick-setup.md')
+  })
+
+  it('states explicitly that no bespoke Quickstart resolution exists', () => {
+    const c = `${datasetSkill()}\n${datasetDefaults()}`.toLowerCase()
+    expect(c).toMatch(/no bespoke|never a bespoke|not a bespoke/)
+  })
+
+  it('names the four convention cascade tiers as bootstrap sources (per-adopter delta)', () => {
+    const c = datasetDefaults()
+    expect(c).toContain('guided-quick-setup.md')
+    const low = c.toLowerCase()
+    expect(low).toMatch(/explicit argument/)
+    expect(low).toMatch(/project state/)
+    expect(low).toMatch(/preferences/)
+    expect(low).toMatch(/fallback/)
+    // the KB fallback tier is the bootstrap checklist's per-type defaults,
+    // not a value invented here.
+    expect(c).toContain('bootstrap-checklist.md')
+  })
+
+  it('keeps the selector direction of the convention (explicit signal ⇒ non-default depth)', () => {
+    const c = datasetDefaults().toLowerCase()
+    expect(c).toMatch(/selector/)
+    expect(c).toMatch(/\$mode/)
+  })
+})
+
+describe('per-decision defaultability — T1 (AC1/AC4)', () => {
+  const c = (): string => datasetDefaults()
+
+  it('is disclosed from SKILL.md as a sibling doc, not inlined', () => {
+    expect(datasetSkill()).toContain('quick-mode-defaults.md')
+    expect(c()).toContain('SKILL.md')
+  })
+
+  it('maps every bootstrap decision point to a resolution, phase by phase', () => {
+    const doc = c()
+    for (const anchor of [
+      'PRD',
+      'categoriz',
+      'assess-',
+      'quality gate',
+      'PM tool',
+      'domain model',
+    ]) {
+      expect(doc.toLowerCase()).toContain(anchor.toLowerCase())
+    }
+  })
+
+  it('still asks the decisions with no safe KB default (PM tool, stack when undetectable)', () => {
+    const doc = c().toLowerCase()
+    expect(doc).toMatch(/still ask/)
+    expect(doc).toMatch(/pm tool/)
+    expect(doc).toMatch(/tech stack|stack/)
+    // reduces questions to the genuinely-defaultable ones, never eliminates all.
+    expect(doc).toMatch(/does not eliminate|never eliminates|not eliminate/)
+  })
+
+  it('writes the same adoption files guided mode would, in the same format (AC4)', () => {
+    const doc = `${datasetSkill()}\n${c()}`.toLowerCase()
+    expect(doc).toMatch(/normal adoption file/)
+    expect(doc).toMatch(/no quick-mode-only|never a quick-mode-only|same shape/)
+  })
+})
+
+describe('edge cases (#278)', () => {
+  it('confirms rather than overwrites an already-configured project', () => {
+    const c = `${datasetSkill()}\n${datasetDefaults()}`.toLowerCase()
+    expect(c).toMatch(/confirm.*rather than overwrit|never overwrit/)
+  })
+
+  it('applies the convention non-interactive safety rule (no TTY can never run guided)', () => {
+    const c = `${datasetSkill()}\n${datasetDefaults()}`
+    expect(c.toLowerCase()).toMatch(/tty/)
+    expect(c.toLowerCase()).toMatch(/never hang|without hanging|never wait/)
+  })
+
+  it('HALTs when a non-defaultable input can neither be resolved nor asked', () => {
+    const c = datasetSkill()
+    expect(c).toContain('HALT')
+    expect(c.toLowerCase()).toMatch(/non-defaultable|cannot be asked|cannot be resolved/)
+  })
+})
+
+describe('no regression on the guided path (AC2)', () => {
+  const c = datasetSkill()
+
+  it('keeps every guided phase/step anchor intact', () => {
+    for (const anchor of [
+      /Phase 0: PRD Verification \(BLOCKING\)/,
+      /Step 1\.2: Categorize Project/,
+      /Step 2\.2: Assessment Phase \(Optional\)/,
+      /Step 2\.3: Gather Information per Section/,
+      /Step 3\.1: Generate Adoption Documents/,
+      /Step 3\.2: Quality Gate Setup/,
+      /Phase 3\.5: Domain Modeling/,
+      /Step 4\.2: PM Tool Configuration/,
+      /Step 4\.3: Final Summary/,
+    ]) {
+      expect(c).toMatch(anchor)
+    }
+  })
+
+  it('keeps the guided questions themselves (they are the guided depth)', () => {
+    expect(c).toMatch(/Does this categorization match your project\?/)
+    expect(c).toMatch(/Do you want custom quality gates beyond the standard pipeline\?/)
+    expect(c).toMatch(/Ask 3-4 focused questions per section/)
+  })
+
+  it('reports the resolved depth in the output format', () => {
+    expect(c).toMatch(/Mode:\s*\[?\s*guided/i)
+  })
+})
+
+describe('root mirror is in sync with the dataset (pair update)', () => {
+  it('SKILL.md equals the dataset run through the real transform', () => {
+    const expected = toMirror(
+      syncFrontmatter(datasetSkill(), { from: 'bootstrap', to: 'pair-process-bootstrap' }),
+    )
+    expect(neutralizeSameDirDotSlash(mirrorSkill())).toBe(neutralizeSameDirDotSlash(expected))
+  })
+
+  it('the disclosed sibling doc is ported too (frontmatter-free, same transform)', () => {
+    expect(existsSync(join(MIRROR_DIR, 'quick-mode-defaults.md'))).toBe(true)
+    expect(neutralizeSameDirDotSlash(mirrorDefaults())).toBe(
+      neutralizeSameDirDotSlash(toMirror(datasetDefaults())),
+    )
+  })
+
+  it('the mirror references prefixed skill names', () => {
+    expect(mirrorSkill()).toMatch(/\/pair-capability-setup-pm\b/)
+    expect(mirrorDefaults()).toMatch(/\/pair-capability-setup-gates\b|\/pair-capability-setup-pm\b/)
+  })
+})
+
+describe('timed onboarding scenario + docs (AC1, DoD)', () => {
+  const CP = join(ROOT, 'qa/release-validation/CP9-quickstart-onboarding.md')
+  const DOC = join(ROOT, 'apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx')
+
+  it('adds a reproducible timed critical path with the <10 minute target', () => {
+    expect(existsSync(CP)).toBe(true)
+    const c = read(CP)
+    expect(c).toMatch(/10\s*min/i)
+    // reproducible: outside-the-repo workdir + explicit stopwatch steps.
+    expect(c).toContain('$WORKDIR')
+    expect(c.toLowerCase()).toMatch(/elapsed|stopwatch|timer/)
+  })
+
+  it('covers the guided-mode regression in the same critical path (AC2)', () => {
+    expect(read(CP).toLowerCase()).toMatch(/guided/)
+  })
+
+  it('registers the critical path in the suite index', () => {
+    expect(read(join(ROOT, 'qa/release-validation/README.md'))).toContain(
+      'CP9-quickstart-onboarding.md',
+    )
+  })
+
+  it('documents quick mode on the docs site and registers the page in nav', () => {
+    expect(existsSync(DOC)).toBe(true)
+    const doc = read(DOC)
+    expect(doc).toMatch(/\$mode\s*[:=]\s*quick/)
+    expect(doc.toLowerCase()).toMatch(/guided/)
+    const meta = read(join(ROOT, 'apps/website/content/docs/getting-started/meta.json'))
+    expect(meta).toContain('bootstrap-quick-mode')
+  })
+})

From c4ed62f14dbfe57a65536311d6d901636bd19609 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 09:22:51 +0200
Subject: [PATCH 02/13] =?UTF-8?q?[US-278]=20feat:=20bootstrap=20$mode=20qu?=
 =?UTF-8?q?ick=20=E2=80=94=20additive=20second=20resolution=20depth?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- $mode selector, guided declared default, absent => guided unchanged (AC1/AC2)
- composes the Guided/Quick Setup Convention cascade, no bespoke order (AC3)
- quick-mode-defaults.md: per-decision defaultability + still-asked (PM tool, undetectable stack)
- same adoption files/format as guided (AC4); no-TTY safety + HALT on unresolvable input
- root mirror ported (SKILL.md + sibling)
---
 .../skills/pair-process-bootstrap/SKILL.md    | 30 +++++++++++
 .../quick-mode-defaults.md                    | 53 +++++++++++++++++++
 .../.skills/process/bootstrap/SKILL.md        | 40 ++++++++++++--
 .../process/bootstrap/quick-mode-defaults.md  | 53 +++++++++++++++++++
 4 files changed, 171 insertions(+), 5 deletions(-)
 create mode 100644 .claude/skills/pair-process-bootstrap/quick-mode-defaults.md
 create mode 100644 packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md

diff --git a/.claude/skills/pair-process-bootstrap/SKILL.md b/.claude/skills/pair-process-bootstrap/SKILL.md
index 021c7cb5..2aa1245d 100644
--- a/.claude/skills/pair-process-bootstrap/SKILL.md
+++ b/.claude/skills/pair-process-bootstrap/SKILL.md
@@ -27,6 +27,23 @@ Orchestrate the complete project setup sequence. Transforms a PRD into a fully c
 | `/pair-capability-map-subdomains`       | Capability | Optional — full-catalog (`$scope: all`) domain mapping, the only caller allowed this scope. Graceful degradation if absent. |
 | `/pair-capability-map-contexts`         | Capability | Optional — full-catalog (`$scope: all`) context mapping, the only caller allowed this scope. Graceful degradation if absent. |
 
+## Arguments
+
+| Argument | Required | Description |
+| -------- | -------- | ----------- |
+| `$mode`  | No       | Resolution depth: `guided` (the **declared default**) or `quick`. Absent ⇒ `guided`, and Phases 0-4 below run unchanged. `quick` takes KB-sensible defaults instead of asking, per the [Guided / Quick Setup Convention](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md). See Resolution Depth below. |
+
+## Resolution Depth: guided (default) or quick
+
+One entry point, two resolution depths. Quick mode is **additive**: a second resolution depth of the same skill — not a separate skill, not a replacement for the guided path. Both depths run the same phases, compose the same skills, and write the same files; the depth decides only whether the developer is *asked* for each decision (guided) or the resolved default is *taken as-is* (quick).
+
+- **guided** — bootstrap's **declared default**, per the convention's "each adopter declares its own default": bootstrap is a human-facing, first-time setup skill, so absent any signal it asks. An omitted `$mode` changes nothing in Phases 0-4.
+- **quick** — `$mode: quick` is the explicit opt-in signal. Bootstrap **asks no questions** for any decision that has a safe default, so an empty repository reaches a **first workable story** in minutes rather than a full interview.
+- **The resolution is the convention's, not bootstrap's.** Defaults resolve through the convention's cascade (explicit argument > project state > saved preferences > hardcoded fallback). Bootstrap declares only its per-adopter delta — which decision points are defaultable, which tier fills each, which are still asked — in [quick-mode-defaults.md](./quick-mode-defaults.md). There is **no bespoke** Quickstart resolution order.
+- **Not every question disappears.** Decisions with no safe KB default (PM tool; tech stack on a genuinely empty repo) are still asked in quick mode — see [quick-mode-defaults.md](./quick-mode-defaults.md).
+- **Non-interactive safety**: guided needs a TTY. With no TTY (CI, piped stdin) guided can never run — bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
+- **Already configured**: identical in both depths — every phase checks its own output first and confirms rather than overwriting.
+
 ## Phase 0: PRD Verification (BLOCKING)
 
 ### Step 0.1: Check PRD State
@@ -82,6 +99,8 @@ Orchestrate the complete project setup sequence. Transforms a PRD into a fully c
 
 4. **Verify**: Categorization decision recorded.
 
+**Quick mode**: the confirmation question is skipped — the type is derived from the PRD signals above and recorded directly ([quick-mode-defaults.md](./quick-mode-defaults.md)).
+
 ## Phase 2: Checklist Completion
 
 ### Step 2.1: Check Existing Adoption Files
@@ -132,6 +151,8 @@ For each missing adoption file, work through the relevant checklist section. Ref
 - Wait for developer responses before proceeding
 - Record each significant decision via `/pair-capability-record-decision` (`non-architectural` → ADL, `architectural` → ADR)
 
+**Quick mode**: no section questions — each section is filled from the project-type defaults in [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md), with the same `/pair-capability-record-decision` calls. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked ([quick-mode-defaults.md](./quick-mode-defaults.md)).
+
 ## Phase 3: Standards Generation
 
 ### Step 3.1: Generate Adoption Documents
@@ -173,6 +194,8 @@ For each missing adoption file (in order: architecture → tech-stack → infras
 
 6. **Verify**: Quality gates documented in way-of-working and placeholder scripts exist.
 
+**Quick mode**: the custom-gate question is skipped — the standard pipeline only, written as the same registry entries and scripts guided mode would produce ([quick-mode-defaults.md](./quick-mode-defaults.md)).
+
 ## Phase 3.5: Domain Modeling (optional, full-catalog)
 
 Runs after architecture and tech-stack are adopted (Step 3.1) — both are prerequisites for `/pair-capability-map-contexts`.
@@ -214,6 +237,8 @@ Runs after architecture and tech-stack are adopted (Step 3.1) — both are prere
 3. **Act**: Compose `/pair-capability-setup-pm`. The skill handles tool selection, configuration, and ADL recording.
 4. **Verify**: PM tool configured and recorded.
 
+**Quick mode**: the PM tool has no safe KB default — it is **still asked** here unless project state already names one. If it can neither be resolved nor asked (no TTY) → **HALT**, naming the input to pass explicitly ([quick-mode-defaults.md](./quick-mode-defaults.md)).
+
 ### Step 4.3: Final Summary
 
 1. **Act**: Present bootstrap completion summary to the developer for final approval:
@@ -223,10 +248,13 @@ Runs after architecture and tech-stack are adopted (Step 3.1) — both are prere
 
 2. **Verify**: Developer approves. If not → iterate on specific concerns.
 
+**Quick mode**: the summary is printed but not gated on approval — every value it reports is a normal adoption file the developer can edit afterwards.
+
 ## Output Format
 
 ```text
 BOOTSTRAP COMPLETE:
+├── Mode:            [guided (default) | quick — N questions asked]
 ├── PRD:             [verified | created via /specify-prd]
 ├── Categorization:  [Type A | Type B | Type C] — [ADL path]
 ├── Adoption Files:
@@ -248,6 +276,7 @@ BOOTSTRAP COMPLETE:
 - **Project categorization rejected** (Phase 1) — developer must confirm before technical decisions
 - **Critical technical decision unresolved** (Phase 2) — cannot generate adoption files with gaps
 - **Adoption file generation rejected** (Phase 3) — each document needs developer approval
+- **Non-defaultable input unresolvable in quick mode** (Step 2.3, Step 4.2) — a decision with no safe KB default (PM tool, undetectable tech stack) that cannot be resolved from the cascade and cannot be asked (no TTY); report which input to pass explicitly, never guess it
 
 On HALT: report the blocker clearly, propose resolution, wait for developer.
 
@@ -275,6 +304,7 @@ See [graceful degradation](../../../.pair/knowledge/guidelines/technical-standar
 - **Adoption directory doesn't exist**: Create `adoption/tech/` and `adoption/decision-log/` on first write.
 - **/record-decision not installed**: Adoption cannot be persisted automatically — assess-\* skills are output-only and never write adoption themselves. Warn: "/pair-capability-record-decision not installed — assess-\* proposals cannot be persisted. Write adoption files manually from the proposals and record decisions by hand."
 - **/map-subdomains or /pair-capability-map-contexts not installed**: Skip the corresponding step in Phase 3.5 with a warning. Domain modeling never blocks bootstrap completion.
+- **No TTY (CI, piped stdin)**: guided cannot run — warn and run `$mode: quick` instead, never hang on input that cannot arrive. If a still-asked decision (PM tool, undetectable stack) is then unresolvable → **HALT**.
 
 ## Notes
 
diff --git a/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md b/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
new file mode 100644
index 00000000..8de3c0b1
--- /dev/null
+++ b/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
@@ -0,0 +1,53 @@
+# Bootstrap Quick Mode — Per-Decision Defaults
+
+Disclosed from [SKILL.md](./SKILL.md) — the `$mode` selector and its two resolution depths. This file is bootstrap's **per-adopter delta** of the Guided / Quick Setup Convention (`.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md`): the convention owns the selector direction, the defaults cascade and the non-interactive safety rule. Bootstrap declares only which of its own decision points are defaultable, which cascade tier fills each, and which are still asked. There is **no bespoke** Quickstart resolution order — nothing below re-invents or re-orders the cascade.
+
+## Selector
+
+`$mode` is the selector, and it points at the non-default depth exactly as the convention prescribes:
+
+- `guided` — bootstrap's declared default. Absent `$mode`, the full interview runs unchanged.
+- `quick` — the explicit opt-in signal. No interview: every defaultable decision is resolved from the cascade instead of asked.
+- No TTY (CI, piped stdin) is an explicit environment fact and outranks the depth preference: guided can never run there. Bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
+
+## Cascade tiers, as bootstrap fills them
+
+The convention's precedence, highest wins, with bootstrap's source named per tier:
+
+| Tier (convention)             | What fills it in bootstrap                                                                                     |
+| ----------------------------- | -------------------------------------------------------------------------------------------------------------- |
+| explicit argument             | `$mode`, plus any value the invocation names outright (e.g. the PM tool)                                        |
+| project state                 | what is already on disk: `.pair/adoption/**`, the PRD, `package.json` and lockfiles, CI workflows, `git config` |
+| saved or inferred preferences | decisions a previous run recorded — the ADLs/ADRs in `.pair/adoption/decision-log/`                             |
+| hardcoded fallback            | the per-project-type defaults in `bootstrap-checklist.md` — a KB value, never one invented here                 |
+
+## Per-decision resolution
+
+| Phase / step | Decision point                                                       | Quick mode                                                                                                     | Tier              |
+| ------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------- |
+| Phase 0      | PRD present and populated                                            | never defaulted — composes `/pair-process-specify-prd` when missing, HALTs if the PRD is still absent                        | project state     |
+| Step 1.2     | project categorization (Type A/B/C)                                  | derived from PRD signals (team size, budget, compliance) and recorded, not confirmed                            | project state     |
+| Step 2.2     | which `assess-*` skills run                                          | installed ones run with their own quick signal (Path A `$choice`) where project state resolves the choice       | project state     |
+| Step 2.3     | per-section questions (architecture, stack, infrastructure, ux-ui, way-of-working) | not asked — each section is filled from the project-type defaults, except an undetectable stack (still asked)   | fallback          |
+| Step 3.1     | adoption documents                                                   | generated and written without the per-document approval round                                                  | fallback          |
+| Step 3.2     | quality gate setup                                                   | standard pipeline only (type check, test, lint, format), no custom gates — same registry entries guided writes  | fallback          |
+| Phase 3.5    | domain model (subdomains, bounded contexts)                          | runs when `/pair-capability-map-subdomains` / `/pair-capability-map-contexts` are installed, skipped with a warning otherwise — never blocking  | project state     |
+| Step 4.2     | PM tool                                                              | **still asked** unless project state already names one (see below)                                              | explicit argument |
+| Step 4.3     | final summary                                                        | printed, not gated on approval                                                                                 | —                 |
+
+## Still asked in quick mode
+
+Quick mode reduces the questions to the genuinely-defaultable ones; it does not eliminate every question unconditionally.
+
+- **PM tool** (Step 4.2) — the choice is organisational, not technical, so no KB value is safe: a wrong guess wires up a tracker nobody uses. Project state resolves it when `way-of-working.md` already names one; otherwise `/pair-capability-setup-pm` is composed and asks that single question.
+- **Tech stack when undetectable** (Step 2.3) — normally read from project state (`package.json`, lockfiles, config files). On a genuinely empty repository there is nothing to read and no universally-correct default, so quick mode asks rather than guessing.
+
+Everything else in the table above resolves without a question. If one of these two can neither be resolved from the cascade nor asked (quick mode with no TTY), bootstrap HALTs and names the input to pass explicitly — see SKILL.md.
+
+## Same files, same format as guided (AC4)
+
+Every file quick mode writes is a normal adoption file, in the same location and the same format guided mode would have produced for the same values: `.pair/adoption/tech/*.md`, the Custom Gate Registry in `way-of-working.md`, ADLs/ADRs via `/pair-capability-record-decision`. There is **no quick-mode-only** file, marker, or format — a default installed by quick mode is edited exactly like any other adopted decision, and re-running a phase (or `/pair-capability-record-decision` on that topic) supersedes it.
+
+## Already-configured project
+
+Unchanged from guided mode: each phase checks its own output first, so quick mode confirms rather than overwriting an existing PRD, categorization ADL, adoption file, gate registry, or PM configuration. Detection is the composed capability's own (`/pair-capability-setup-gates`, `/pair-capability-setup-pm`), never a second implementation here.
diff --git a/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md b/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
index e24a79fb..988f3ad0 100644
--- a/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
+++ b/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
@@ -27,6 +27,23 @@ Orchestrate the complete project setup sequence. Transforms a PRD into a fully c
 | `/map-subdomains`       | Capability | Optional — full-catalog (`$scope: all`) domain mapping, the only caller allowed this scope. Graceful degradation if absent. |
 | `/map-contexts`         | Capability | Optional — full-catalog (`$scope: all`) context mapping, the only caller allowed this scope. Graceful degradation if absent. |
 
+## Arguments
+
+| Argument | Required | Description |
+| -------- | -------- | ----------- |
+| `$mode`  | No       | Resolution depth: `guided` (the **declared default**) or `quick`. Absent ⇒ `guided`, and Phases 0-4 below run unchanged. `quick` takes KB-sensible defaults instead of asking, per the [Guided / Quick Setup Convention](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md). See Resolution Depth below. |
+
+## Resolution Depth: guided (default) or quick
+
+One entry point, two resolution depths. Quick mode is **additive**: a second resolution depth of the same skill — not a separate skill, not a replacement for the guided path. Both depths run the same phases, compose the same skills, and write the same files; the depth decides only whether the developer is *asked* for each decision (guided) or the resolved default is *taken as-is* (quick).
+
+- **guided** — bootstrap's **declared default**, per the convention's "each adopter declares its own default": bootstrap is a human-facing, first-time setup skill, so absent any signal it asks. An omitted `$mode` changes nothing in Phases 0-4.
+- **quick** — `$mode: quick` is the explicit opt-in signal. Bootstrap **asks no questions** for any decision that has a safe default, so an empty repository reaches a **first workable story** in minutes rather than a full interview.
+- **The resolution is the convention's, not bootstrap's.** Defaults resolve through the convention's cascade (explicit argument > project state > saved preferences > hardcoded fallback). Bootstrap declares only its per-adopter delta — which decision points are defaultable, which tier fills each, which are still asked — in [quick-mode-defaults.md](quick-mode-defaults.md). There is **no bespoke** Quickstart resolution order.
+- **Not every question disappears.** Decisions with no safe KB default (PM tool; tech stack on a genuinely empty repo) are still asked in quick mode — see [quick-mode-defaults.md](quick-mode-defaults.md).
+- **Non-interactive safety**: guided needs a TTY. With no TTY (CI, piped stdin) guided can never run — bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
+- **Already configured**: identical in both depths — every phase checks its own output first and confirms rather than overwriting.
+
 ## Phase 0: PRD Verification (BLOCKING)
 
 ### Step 0.1: Check PRD State
@@ -52,7 +69,7 @@ Orchestrate the complete project setup sequence. Transforms a PRD into a fully c
 
 ### Step 1.1: Check Existing Categorization
 
-1. **Check**: Does [adoption/decision-log/](../../../.pair/adoption/decision-log/) contain a `*-project-categorization.md` file?
+1. **Check**: Does [adoption/decision-log/](../../../.pair/adoption/decision-log) contain a `*-project-categorization.md` file?
 2. **Skip**: If categorization already recorded, read it and move to Phase 2.
 3. **Act**: Proceed to categorization analysis.
 
@@ -82,11 +99,13 @@ Orchestrate the complete project setup sequence. Transforms a PRD into a fully c
 
 4. **Verify**: Categorization decision recorded.
 
+**Quick mode**: the confirmation question is skipped — the type is derived from the PRD signals above and recorded directly ([quick-mode-defaults.md](quick-mode-defaults.md)).
+
 ## Phase 2: Checklist Completion
 
 ### Step 2.1: Check Existing Adoption Files
 
-1. **Check**: Scan [adoption/tech/](../../../.pair/adoption/tech/) for existing files. Classify each as populated or template:
+1. **Check**: Scan [adoption/tech/](../../../.pair/adoption/tech) for existing files. Classify each as populated or template:
    - `architecture.md`
    - `tech-stack.md`
    - `infrastructure.md` (optional — not all project types need it)
@@ -132,6 +151,8 @@ For each missing adoption file, work through the relevant checklist section. Ref
 - Wait for developer responses before proceeding
 - Record each significant decision via `/record-decision` (`non-architectural` → ADL, `architectural` → ADR)
 
+**Quick mode**: no section questions — each section is filled from the project-type defaults in [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md), with the same `/record-decision` calls. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked ([quick-mode-defaults.md](quick-mode-defaults.md)).
+
 ## Phase 3: Standards Generation
 
 ### Step 3.1: Generate Adoption Documents
@@ -146,7 +167,7 @@ For each missing adoption file (in order: architecture → tech-stack → infras
    - References to KB guidelines for detailed rationale
 3. **Act**: Present key decisions with rationale for developer review.
 4. **Act**: Iterate on feedback until approved.
-5. **Act**: Save to [adoption/tech/](../../../.pair/adoption/tech/)`<filename>.md`.
+5. **Act**: Save to [adoption/tech/](../../../.pair/adoption/tech)`<filename>.md`.
 6. **Verify**: File written, consistent with other adoption files.
 
 ### Step 3.2: Quality Gate Setup
@@ -173,20 +194,22 @@ For each missing adoption file (in order: architecture → tech-stack → infras
 
 6. **Verify**: Quality gates documented in way-of-working and placeholder scripts exist.
 
+**Quick mode**: the custom-gate question is skipped — the standard pipeline only, written as the same registry entries and scripts guided mode would produce ([quick-mode-defaults.md](quick-mode-defaults.md)).
+
 ## Phase 3.5: Domain Modeling (optional, full-catalog)
 
 Runs after architecture and tech-stack are adopted (Step 3.1) — both are prerequisites for `/map-contexts`.
 
 ### Step 3.5.1: Subdomain Placement
 
-1. **Check**: Is `/map-subdomains` installed? Does [`adoption/product/subdomain/`](../../../.pair/adoption/product/subdomain/) already contain populated entries?
+1. **Check**: Is `/map-subdomains` installed? Does [`adoption/product/subdomain/`](../../../.pair/adoption/product/subdomain) already contain populated entries?
 2. **Skip**: If not installed → warn and proceed to Step 3.5.2 without subdomain placement. If already populated → proceed to Step 3.5.2.
 3. **Act**: Compose `/map-subdomains` with `$scope: all` — the only caller allowed a full-catalog run. Uses PRD (always present at this point); falls back to "system areas" if no initiatives exist yet.
 4. **Verify**: Subdomain catalog created/updated, or fallback noted. Proceed regardless of outcome.
 
 ### Step 3.5.2: Bounded Context Placement
 
-1. **Check**: Is `/map-contexts` installed? Does [`adoption/tech/boundedcontext/`](../../../.pair/adoption/tech/boundedcontext/) already contain populated entries?
+1. **Check**: Is `/map-contexts` installed? Does [`adoption/tech/boundedcontext/`](../../../.pair/adoption/tech/boundedcontext) already contain populated entries?
 2. **Skip**: If not installed → warn and proceed to Phase 4 without context mapping. If already populated → proceed to Phase 4.
 3. **Act**: Compose `/map-contexts` with `$scope: all` — the only caller allowed a full-catalog run. Uses the subdomain catalog (Step 3.5.1) plus architecture.md and tech-stack.md (Step 3.1).
 4. **Verify**: Bounded context catalog created/updated, or fallback noted. Domain modeling never blocks bootstrap completion — proceed to Phase 4 regardless of outcome.
@@ -214,6 +237,8 @@ Runs after architecture and tech-stack are adopted (Step 3.1) — both are prere
 3. **Act**: Compose `/setup-pm`. The skill handles tool selection, configuration, and ADL recording.
 4. **Verify**: PM tool configured and recorded.
 
+**Quick mode**: the PM tool has no safe KB default — it is **still asked** here unless project state already names one. If it can neither be resolved nor asked (no TTY) → **HALT**, naming the input to pass explicitly ([quick-mode-defaults.md](quick-mode-defaults.md)).
+
 ### Step 4.3: Final Summary
 
 1. **Act**: Present bootstrap completion summary to the developer for final approval:
@@ -223,10 +248,13 @@ Runs after architecture and tech-stack are adopted (Step 3.1) — both are prere
 
 2. **Verify**: Developer approves. If not → iterate on specific concerns.
 
+**Quick mode**: the summary is printed but not gated on approval — every value it reports is a normal adoption file the developer can edit afterwards.
+
 ## Output Format
 
 ```text
 BOOTSTRAP COMPLETE:
+├── Mode:            [guided (default) | quick — N questions asked]
 ├── PRD:             [verified | created via /specify-prd]
 ├── Categorization:  [Type A | Type B | Type C] — [ADL path]
 ├── Adoption Files:
@@ -248,6 +276,7 @@ BOOTSTRAP COMPLETE:
 - **Project categorization rejected** (Phase 1) — developer must confirm before technical decisions
 - **Critical technical decision unresolved** (Phase 2) — cannot generate adoption files with gaps
 - **Adoption file generation rejected** (Phase 3) — each document needs developer approval
+- **Non-defaultable input unresolvable in quick mode** (Step 2.3, Step 4.2) — a decision with no safe KB default (PM tool, undetectable tech stack) that cannot be resolved from the cascade and cannot be asked (no TTY); report which input to pass explicitly, never guess it
 
 On HALT: report the blocker clearly, propose resolution, wait for developer.
 
@@ -275,6 +304,7 @@ See [graceful degradation](../../../.pair/knowledge/guidelines/technical-standar
 - **Adoption directory doesn't exist**: Create `adoption/tech/` and `adoption/decision-log/` on first write.
 - **/record-decision not installed**: Adoption cannot be persisted automatically — assess-\* skills are output-only and never write adoption themselves. Warn: "/record-decision not installed — assess-\* proposals cannot be persisted. Write adoption files manually from the proposals and record decisions by hand."
 - **/map-subdomains or /map-contexts not installed**: Skip the corresponding step in Phase 3.5 with a warning. Domain modeling never blocks bootstrap completion.
+- **No TTY (CI, piped stdin)**: guided cannot run — warn and run `$mode: quick` instead, never hang on input that cannot arrive. If a still-asked decision (PM tool, undetectable stack) is then unresolvable → **HALT**.
 
 ## Notes
 
diff --git a/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md b/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
new file mode 100644
index 00000000..3e722a57
--- /dev/null
+++ b/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
@@ -0,0 +1,53 @@
+# Bootstrap Quick Mode — Per-Decision Defaults
+
+Disclosed from [SKILL.md](SKILL.md) — the `$mode` selector and its two resolution depths. This file is bootstrap's **per-adopter delta** of the Guided / Quick Setup Convention (`.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md`): the convention owns the selector direction, the defaults cascade and the non-interactive safety rule. Bootstrap declares only which of its own decision points are defaultable, which cascade tier fills each, and which are still asked. There is **no bespoke** Quickstart resolution order — nothing below re-invents or re-orders the cascade.
+
+## Selector
+
+`$mode` is the selector, and it points at the non-default depth exactly as the convention prescribes:
+
+- `guided` — bootstrap's declared default. Absent `$mode`, the full interview runs unchanged.
+- `quick` — the explicit opt-in signal. No interview: every defaultable decision is resolved from the cascade instead of asked.
+- No TTY (CI, piped stdin) is an explicit environment fact and outranks the depth preference: guided can never run there. Bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
+
+## Cascade tiers, as bootstrap fills them
+
+The convention's precedence, highest wins, with bootstrap's source named per tier:
+
+| Tier (convention)             | What fills it in bootstrap                                                                                     |
+| ----------------------------- | -------------------------------------------------------------------------------------------------------------- |
+| explicit argument             | `$mode`, plus any value the invocation names outright (e.g. the PM tool)                                        |
+| project state                 | what is already on disk: `.pair/adoption/**`, the PRD, `package.json` and lockfiles, CI workflows, `git config` |
+| saved or inferred preferences | decisions a previous run recorded — the ADLs/ADRs in `.pair/adoption/decision-log/`                             |
+| hardcoded fallback            | the per-project-type defaults in `bootstrap-checklist.md` — a KB value, never one invented here                 |
+
+## Per-decision resolution
+
+| Phase / step | Decision point                                                       | Quick mode                                                                                                     | Tier              |
+| ------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------- |
+| Phase 0      | PRD present and populated                                            | never defaulted — composes `/specify-prd` when missing, HALTs if the PRD is still absent                        | project state     |
+| Step 1.2     | project categorization (Type A/B/C)                                  | derived from PRD signals (team size, budget, compliance) and recorded, not confirmed                            | project state     |
+| Step 2.2     | which `assess-*` skills run                                          | installed ones run with their own quick signal (Path A `$choice`) where project state resolves the choice       | project state     |
+| Step 2.3     | per-section questions (architecture, stack, infrastructure, ux-ui, way-of-working) | not asked — each section is filled from the project-type defaults, except an undetectable stack (still asked)   | fallback          |
+| Step 3.1     | adoption documents                                                   | generated and written without the per-document approval round                                                  | fallback          |
+| Step 3.2     | quality gate setup                                                   | standard pipeline only (type check, test, lint, format), no custom gates — same registry entries guided writes  | fallback          |
+| Phase 3.5    | domain model (subdomains, bounded contexts)                          | runs when `/map-subdomains` / `/map-contexts` are installed, skipped with a warning otherwise — never blocking  | project state     |
+| Step 4.2     | PM tool                                                              | **still asked** unless project state already names one (see below)                                              | explicit argument |
+| Step 4.3     | final summary                                                        | printed, not gated on approval                                                                                 | —                 |
+
+## Still asked in quick mode
+
+Quick mode reduces the questions to the genuinely-defaultable ones; it does not eliminate every question unconditionally.
+
+- **PM tool** (Step 4.2) — the choice is organisational, not technical, so no KB value is safe: a wrong guess wires up a tracker nobody uses. Project state resolves it when `way-of-working.md` already names one; otherwise `/setup-pm` is composed and asks that single question.
+- **Tech stack when undetectable** (Step 2.3) — normally read from project state (`package.json`, lockfiles, config files). On a genuinely empty repository there is nothing to read and no universally-correct default, so quick mode asks rather than guessing.
+
+Everything else in the table above resolves without a question. If one of these two can neither be resolved from the cascade nor asked (quick mode with no TTY), bootstrap HALTs and names the input to pass explicitly — see SKILL.md.
+
+## Same files, same format as guided (AC4)
+
+Every file quick mode writes is a normal adoption file, in the same location and the same format guided mode would have produced for the same values: `.pair/adoption/tech/*.md`, the Custom Gate Registry in `way-of-working.md`, ADLs/ADRs via `/record-decision`. There is **no quick-mode-only** file, marker, or format — a default installed by quick mode is edited exactly like any other adopted decision, and re-running a phase (or `/record-decision` on that topic) supersedes it.
+
+## Already-configured project
+
+Unchanged from guided mode: each phase checks its own output first, so quick mode confirms rather than overwriting an existing PRD, categorization ADL, adoption file, gate registry, or PM configuration. Detection is the composed capability's own (`/setup-gates`, `/setup-pm`), never a second implementation here.

From 469d991ed4b2886f17f49d6abdcd25ad8845a523 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 09:24:20 +0200
Subject: [PATCH 03/13] [US-278] test: CP9 timed quickstart onboarding critical
 path

- MT-CP901..905: empty project -> first workable story, stopwatch protocol, <10 min target
- MT-CP903 asserts adoption files are normal (no quick-mode-only marker)
- MT-CP904 guided-default regression, MT-CP905 no-TTY never hangs
- registered in the suite index + maintenance checklist
---
 .../CP9-quickstart-onboarding.md              | 142 ++++++++++++++++++
 qa/release-validation/README.md               |   2 +
 2 files changed, 144 insertions(+)
 create mode 100644 qa/release-validation/CP9-quickstart-onboarding.md

diff --git a/qa/release-validation/CP9-quickstart-onboarding.md b/qa/release-validation/CP9-quickstart-onboarding.md
new file mode 100644
index 00000000..6d87d64d
--- /dev/null
+++ b/qa/release-validation/CP9-quickstart-onboarding.md
@@ -0,0 +1,142 @@
+# CP9 — Quickstart Onboarding (timed)
+
+**Priority**: P1
+**Scope**: `/pair-process-bootstrap $mode: quick` — an empty project reaches a first workable story in under 10 minutes, and the guided depth still behaves as before
+**Preconditions**: Working CLI binary (from CP2), `$CLI` = path to that binary. `$WORKDIR` created outside the repo. An AI assistant session with the pair skills installed (`.claude/skills/`), able to run `/pair-process-bootstrap`.
+
+**Why timed**: the quick depth exists to make the time-to-first-story short enough to be measured. The target is the acceptance criterion, so it is asserted here rather than assumed.
+
+---
+
+## Variables
+
+| Variable   | How to resolve                                                                   |
+| ---------- | -------------------------------------------------------------------------------- |
+| `$WORKDIR` | Temp directory **outside** the repo: `mktemp -d /tmp/pair-quickstart-test.XXXXX` |
+| `$CLI`     | Path to the working `pair-cli` binary under test (from CP2)                       |
+| `$T0`      | Stopwatch start, captured as `date +%s` immediately before MT-CP902 step 1        |
+
+**Stopwatch protocol** — the elapsed time must be measured, never estimated:
+
+1. Before the timed step: `T0=$(date +%s)`
+2. After the timed step: `T1=$(date +%s); echo "elapsed: $(( (T1 - T0) / 60 ))m $(( (T1 - T0) % 60 ))s"`
+3. Record the printed elapsed value in the report. Human think-time counts — this measures onboarding, not machine speed.
+
+---
+
+## MT-CP901: Empty project, KB installed
+
+**Priority**: P1
+**Preconditions**: `$WORKDIR` exists
+**Category**: Onboarding
+
+### Steps
+
+1. `mkdir -p $WORKDIR/quickstart && cd $WORKDIR/quickstart && git init`
+2. `$CLI install`
+3. `ls .pair/adoption/tech/`
+
+### Expected Result
+
+- Exit code 0
+- `.pair/knowledge/` and `.claude/skills/pair-process-bootstrap/SKILL.md` exist
+- `.pair/adoption/tech/` holds templates only — no populated adoption file (this is a genuinely empty project)
+
+---
+
+## MT-CP902: Quick mode reaches a first workable story in under 10 minutes
+
+**Priority**: P1
+**Preconditions**: MT-CP901 passes
+**Category**: Onboarding
+**Target**: under 10 min elapsed, wall-clock
+
+### Steps
+
+1. `T0=$(date +%s)` — start the stopwatch
+2. In the AI session rooted at `$WORKDIR/quickstart`, run `/pair-process-bootstrap $mode: quick`
+3. Answer only the questions the skill actually asks. Per `quick-mode-defaults.md` these are at most two: the PM tool, and the tech stack if it cannot be detected. Answer them immediately — deliberating is out of scope for the measurement
+4. When bootstrap reports `BOOTSTRAP COMPLETE`, run `/pair-next` and follow its suggestion until one user story exists in the tracker
+5. `T1=$(date +%s); echo "elapsed: $(( (T1 - T0) / 60 ))m $(( (T1 - T0) % 60 ))s"`
+
+### Expected Result
+
+- Elapsed under **10 min**
+- Bootstrap asked **no** question outside the two still-asked decisions above (no categorization confirmation, no per-section interview, no per-document approval round, no custom-gate question)
+- The completion summary reports `Mode: quick — N questions asked` with `N` matching what was actually asked
+- `.pair/adoption/tech/architecture.md`, `tech-stack.md` and `way-of-working.md` are populated
+- One user story exists and is workable (it has acceptance criteria, so `/pair-process-implement` can start on it)
+
+### Notes
+
+- If the run exceeds the target, record which step consumed the time — the failure is only meaningful with the breakdown.
+
+---
+
+## MT-CP903: Every file quick mode wrote is a normal adoption file
+
+**Priority**: P1
+**Preconditions**: MT-CP902 passes
+**Category**: Onboarding
+
+### Steps
+
+1. `cd $WORKDIR/quickstart`
+2. `ls .pair/adoption/tech/ .pair/adoption/decision-log/`
+3. `grep -rniE "quick[- ]mode|generated by quick" .pair/adoption/ | head`
+4. Edit one value in `.pair/adoption/tech/tech-stack.md` by hand, then run `/pair-next`
+
+### Expected Result
+
+- Adoption files sit in their normal locations, in the same format the guided depth produces (no extra directory, no sidecar file)
+- Step 3 finds **no** quick-mode-only marker, flag, or format inside `.pair/adoption/`
+- The hand edit survives, and `/pair-next` reads the edited value — a quick-mode default is editable exactly like any other adopted decision
+
+---
+
+## MT-CP904: Guided remains the default — no regression
+
+**Priority**: P1
+**Preconditions**: MT-CP901 passes, in a **second** clean project
+**Category**: Regression
+
+### Steps
+
+1. `mkdir -p $WORKDIR/guided && cd $WORKDIR/guided && git init && $CLI install`
+2. In the AI session rooted at `$WORKDIR/guided`, run `/pair-process-bootstrap` with **no** `$mode` argument
+3. Observe the first three interactions
+
+### Expected Result
+
+- The **guided** interview runs: Phase 0 PRD verification, then the Step 1.2 categorization confirmation question, then the Step 2.3 per-section questions
+- The skill asks rather than assuming — an omitted `$mode` behaves exactly as it did before quick mode existed
+- The completion summary reports `Mode: guided (default)`
+
+### Notes
+
+- This is the additive-change guard: quick mode must not have changed the no-argument path.
+
+---
+
+## MT-CP905: No TTY can never hang
+
+**Priority**: P2
+**Preconditions**: MT-CP901 passes
+**Category**: Edge case
+
+### Steps
+
+1. Simulate a non-interactive environment (CI runner, or an agent session with stdin closed) rooted at a third clean project
+2. Request the guided depth explicitly
+
+### Expected Result
+
+- Guided does not run: the skill warns that no TTY is available and runs the quick depth instead
+- The run never blocks waiting for input that cannot arrive
+- If a still-asked decision (PM tool, undetectable stack) is then unresolvable, the run **HALTs** and names the input to pass explicitly — it does not guess
+
+---
+
+## Changelog
+
+- Added for #278 (bootstrap quick mode): MT-CP901..905.
diff --git a/qa/release-validation/README.md b/qa/release-validation/README.md
index df1c71bf..f57c5a72 100644
--- a/qa/release-validation/README.md
+++ b/qa/release-validation/README.md
@@ -31,6 +31,7 @@ Execute in order. P0 blocks release sign-off.
 | CP6 | [CP6-website-search-navigation.md](CP6-website-search-navigation.md) | P1 | Orama search, sidebar, prev/next, llms.txt, privacy |
 | CP7 | [CP7-registry-publish.md](CP7-registry-publish.md) | P0 | npmjs.org visibility, install from public registry |
 | CP8 | [CP8-packaging.md](CP8-packaging.md) | P1 | `pair package` with source/target layouts, metadata, validation |
+| CP9 | [CP9-quickstart-onboarding.md](CP9-quickstart-onboarding.md) | P1 | Timed quickstart onboarding: bootstrap `$mode: quick` under 10 min, guided regression |
 
 ## Execution by AI Assistant
 
@@ -94,5 +95,6 @@ Consult before each release. If any condition is true, update the corresponding
 - [ ] New distribution channel (brew, npx global, etc.) → add to CP2 or new CP
 - [ ] npmjs.org publish config changed → update CP7
 - [ ] Landing page sections changed → update CP1
+- [ ] Bootstrap resolution depths or their defaults changed → update CP9
 
 When updating, increment the test count in this README and add a changelog entry at the bottom of the affected CP file.

From de0d8cbbc50b560240cf5b0788feb099fe2ea069 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 09:26:17 +0200
Subject: [PATCH 04/13] [US-278] docs: Bootstrap Quick Mode page + quickstart
 cross-link

- new getting-started page: depth comparison, the two still-asked questions,
  cascade tiers, no quick-mode-only output, CI/no-TTY behaviour
- registered in getting-started/meta.json nav and CP5 page list
- quickstart.mdx (CLI install) cross-links it; guided stays the default there
---
 .../getting-started/bootstrap-quick-mode.mdx  | 70 +++++++++++++++++++
 .../content/docs/getting-started/meta.json    |  9 ++-
 .../docs/getting-started/quickstart.mdx       |  2 +
 .../CP5-website-docs-completeness.md          |  1 +
 4 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx

diff --git a/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx b/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
new file mode 100644
index 00000000..5d62b4d8
--- /dev/null
+++ b/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
@@ -0,0 +1,70 @@
+---
+title: Bootstrap Quick Mode
+description: Bootstrap your project's adoption files in one shot with KB-sensible defaults, instead of answering the full interview.
+---
+
+Bootstrap has two resolution depths and one entry point. **Guided** — the default — interviews you decision by decision. **Quick** takes the same defaults without asking, so an empty project reaches a first workable story in minutes.
+
+This page is about the `/pair-process-bootstrap` skill. For installing the CLI and the Knowledge Base first, see the [Quickstart](/docs/getting-started/quickstart).
+
+## Which depth do you want?
+
+| | Guided (default) | Quick |
+|---|---|---|
+| **You get asked** | every decision, one at a time | only what has no safe default |
+| **Best for** | a first setup, or a project whose direction is still open | an experienced user, a spike, a CI/scripted setup |
+| **Time** | as long as the conversation takes | minutes |
+| **Files written** | adoption files | the same adoption files |
+
+Quick mode is **additive**. It is a second depth of the same skill, not a separate skill and not a replacement: if you omit the argument, the interview you already know runs exactly as before.
+
+## Run it
+
+```text
+/pair-process-bootstrap $mode: quick
+```
+
+Expect at most two questions:
+
+- **Which PM tool?** — the choice is organisational, not technical, so there is no safe default to guess. Skipped if your `way-of-working.md` already names one.
+- **Which tech stack?** — normally read straight from `package.json`, lockfiles and config. Only asked on a genuinely empty repository, where there is nothing to read.
+
+Everything else — project categorization, the per-section architecture/infrastructure/way-of-working decisions, the adoption documents, the standard quality-gate pipeline — is resolved from defaults and reported, not asked.
+
+When it finishes, the summary names the depth that ran and how many questions it asked:
+
+```text
+BOOTSTRAP COMPLETE:
+├── Mode:            quick — 1 question asked
+├── PRD:             verified
+├── Categorization:  Type B — .pair/adoption/decision-log/...
+...
+```
+
+## Nothing about the output is "quick mode"
+
+Every file quick mode writes is a normal adoption file, in the normal location and format: `.pair/adoption/tech/*.md`, the gate registry in `way-of-working.md`, ADRs and ADLs in the decision log. There is no quick-mode-only file, marker, or format.
+
+So a default you disagree with is not a lock-in — edit the file by hand, or re-run the relevant phase, and the change sticks like any other adopted decision. Accepting a default costs you nothing you cannot change later.
+
+An already-configured project is **confirmed, not overwritten**: each phase checks its own output first, in both depths.
+
+## Where the defaults come from
+
+Quick mode does not invent its own resolution order. It follows the shared Guided / Quick Setup Convention that `pair package` and the `assess-*` skills already use — highest wins:
+
+1. **Explicit argument** — anything you named in the invocation
+2. **Project state** — what is already on disk: `.pair/adoption/**`, the PRD, `package.json`, lockfiles, CI workflows, `git config`
+3. **Saved preferences** — decisions a previous run recorded in the decision log
+4. **Fallback** — the per-project-type defaults in the KB bootstrap checklist
+
+Bootstrap only declares which of its own decisions each tier fills. That mapping, decision by decision, lives next to the skill in `quick-mode-defaults.md` (`.claude/skills/pair-process-bootstrap/quick-mode-defaults.md` once the KB is installed).
+
+## In CI or a non-interactive session
+
+Guided needs a terminal. With no TTY, bootstrap warns and runs quick instead rather than hanging on input that can never arrive. If a still-asked decision cannot be resolved either, the run halts and tells you which input to pass explicitly — it does not guess.
+
+## Next
+
+- [Adopter Checklist](/docs/getting-started/checklist) — verify the setup that quick mode just produced
+- [Quickstart: Solo](/docs/getting-started/quickstart-solo) · [Team](/docs/getting-started/quickstart-team) · [Organization](/docs/getting-started/quickstart-org) — environment-specific configuration
diff --git a/apps/website/content/docs/getting-started/meta.json b/apps/website/content/docs/getting-started/meta.json
index 2d1f91a1..42f5d38c 100644
--- a/apps/website/content/docs/getting-started/meta.json
+++ b/apps/website/content/docs/getting-started/meta.json
@@ -1,4 +1,11 @@
 {
   "title": "Getting Started",
-  "pages": ["quickstart", "quickstart-solo", "quickstart-team", "quickstart-org", "checklist"]
+  "pages": [
+    "quickstart",
+    "bootstrap-quick-mode",
+    "quickstart-solo",
+    "quickstart-team",
+    "quickstart-org",
+    "checklist"
+  ]
 }
diff --git a/apps/website/content/docs/getting-started/quickstart.mdx b/apps/website/content/docs/getting-started/quickstart.mdx
index b8a28f44..0f7e21e5 100644
--- a/apps/website/content/docs/getting-started/quickstart.mdx
+++ b/apps/website/content/docs/getting-started/quickstart.mdx
@@ -90,6 +90,8 @@ Run `/pair-next` in your AI assistant. It detects empty adoption files and walks
 2. **Bootstrap** — the AI guides you through architecture, tech stack, infrastructure, and way-of-working decisions, generating adoption files in `.pair/adoption/tech/adopted/`
 3. **What comes next** — `/pair-next` continues to suggest the right next step as your project evolves
 
+In a hurry, or setting up from a script? Bootstrap also runs one-shot from KB-sensible defaults instead of interviewing you — see **[Bootstrap Quick Mode](/docs/getting-started/bootstrap-quick-mode)**. The interview above stays the default.
+
 ### Existing Project
 
 For projects with an existing codebase, the AI reverse-engineers your project context — reading dependencies, config files, Git history, and code structure — then proposes adoption files for you to review and refine.
diff --git a/qa/release-validation/CP5-website-docs-completeness.md b/qa/release-validation/CP5-website-docs-completeness.md
index e5e34634..cf000b4a 100644
--- a/qa/release-validation/CP5-website-docs-completeness.md
+++ b/qa/release-validation/CP5-website-docs-completeness.md
@@ -19,6 +19,7 @@
 **Getting Started** (6 pages):
 - `$BASE_URL/docs/getting-started`
 - `$BASE_URL/docs/getting-started/quickstart`
+- `$BASE_URL/docs/getting-started/bootstrap-quick-mode`
 - `$BASE_URL/docs/getting-started/quickstart-solo`
 - `$BASE_URL/docs/getting-started/quickstart-team`
 - `$BASE_URL/docs/getting-started/quickstart-org`

From 175c64bfd1f529d9d5dc06242f8dc0edd8746591 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 09:27:45 +0200
Subject: [PATCH 05/13] =?UTF-8?q?[US-278]=20docs:=20ADL=20=E2=80=94=20quic?=
 =?UTF-8?q?k=20is=20a=20bootstrap=20depth,=20not=20a=20second=20skill?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Records the #276 application: $mode selector, guided as bootstrap's declared
default, no bespoke resolution order, no quick-mode-only output. Alternatives
(separate skill / quick-as-default / third partial depth) rejected with reasons.
---
 ...-bootstrap-quick-is-a-depth-not-a-skill.md | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 .pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md

diff --git a/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md b/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md
new file mode 100644
index 00000000..34e8dd3c
--- /dev/null
+++ b/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md
@@ -0,0 +1,50 @@
+# Decision: bootstrap's quick setup is a second resolution depth of the same skill, with guided as bootstrap's declared default
+
+## Date
+
+2026-07-31
+
+## Status
+
+Active
+
+## Category
+
+Convention Adoption
+
+## Context
+
+Story #278 asked for a "Quickstart path" in bootstrap: an opinionated one-command setup that gets an empty project to a first workable story in minutes instead of through the full Phase 0-4 interview. Two shapes were available: ship a separate `/pair-process-quickstart` skill, or add a mode to `/pair-process-bootstrap`.
+
+The Guided / Quick Setup Convention (#276, PR #349) had just landed and already fixes the selector direction, the four-tier defaults cascade (`explicit argument > project state > saved preferences > hardcoded fallback`), and the non-interactive safety rule — while explicitly leaving *which mode is the default* to each adopter. Its two shipped adopters declare opposite defaults (`pair package` → quick; the `assess-*` family → guided), so bootstrap had to declare its own rather than inherit one.
+
+## Decision
+
+Quick setup is an **additive second resolution depth of `/pair-process-bootstrap`**, selected by `$mode: quick`, and **guided is bootstrap's declared default**. Absent `$mode`, Phases 0-4 run exactly as before.
+
+Three constraints follow, and are asserted in `packages/knowledge-hub/src/conformance/bootstrap.test.ts`:
+
+1. **No second skill, no second entry point.** One skill, one catalog row, one frontmatter description; both depths run the same phases, compose the same skills, and write the same files.
+2. **No bespoke resolution order.** Bootstrap composes the convention's cascade and declares only its per-adopter delta — which decision points are defaultable, which tier fills each, which are still asked — in the disclosed sibling `quick-mode-defaults.md`. Two decisions stay asked in quick mode because no KB value is safe: the PM tool (organisational, not technical) and the tech stack when the repo is genuinely empty.
+3. **No quick-mode-only output.** Every file quick mode writes is a normal adoption file in the normal location and format, with no marker distinguishing it, so an accepted default is editable exactly like any other adopted decision.
+
+Guided is the declared default because bootstrap is human-facing first-time setup — the convention's own recommendation for that shape ("ask rather than silently assume"). The non-interactive path is the convention's, not a bootstrap invention: no TTY warns and falls back to quick rather than hanging, and HALTs if a still-asked decision is then unresolvable.
+
+## Alternatives Considered
+
+- **A separate `/pair-process-quickstart` skill**: Rejected. Two entry points for the same job diverge — a phase added to bootstrap would silently not exist in quickstart, and `/pair-next` would need a rule for which to suggest. It also duplicates the composition table and the already-configured-project detection.
+- **Quick as bootstrap's default, guided opt-in via `--interactive`** (the `pair package` shape): Rejected. Bootstrap's first run is a human's first contact with the process; silently assuming an architecture and a project type is a worse failure than asking. It would also be a behaviour change for every existing adopter, not an additive one.
+- **A bootstrap-specific resolution order** (e.g. always prefer the checklist fallback for speed): Rejected — it re-invents #276 one week after it landed, and makes an explicit argument losable to a hardcoded default.
+- **A third partially-guided depth** (ask only the "important" ones): Rejected for now. The convention permits a documented deviation, but "important" is not definable without adopter data; the still-asked set already covers the only two decisions with no safe default.
+
+## Consequences
+
+- A future setup-oriented skill adopting the same duality follows the convention plus this precedent: mode argument on the existing skill, declared default stated explicitly, per-adopter delta in a disclosed sibling doc.
+- Any new bootstrap phase or decision point must also declare its quick-mode resolution in `quick-mode-defaults.md`; the conformance test's per-decision anchors fail if a phase is added without one.
+- Bootstrap's frontmatter description is unchanged, so no skills-catalog row moves.
+- The <10 minute claim is validated, not asserted: `qa/release-validation/CP9-quickstart-onboarding.md` measures it with an explicit stopwatch protocol and covers the guided-default regression in the same critical path.
+
+## Adoption Impact
+
+- No adoption file changes: this records how an existing KB convention was applied to one skill, and adds no new project rule.
+- No knowledge-base/dataset mirror: sibling ADLs in `adoption/decision-log/` are adoption-only records; the dataset (`packages/knowledge-hub/dataset/`) is a curated sample, not an auto-mirror of adoption, so this decision is not copied there.

From 202d3194171a123969a5a36dee11a837e8ff89f2 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 09:44:09 +0200
Subject: [PATCH 06/13] [US-278] test: CP5 page count follows the new docs page

Adding the bootstrap-quick-mode URL without bumping the Getting Started
count and the 60->61 total left CP5 self-contradictory.
---
 qa/release-validation/CP5-website-docs-completeness.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/qa/release-validation/CP5-website-docs-completeness.md b/qa/release-validation/CP5-website-docs-completeness.md
index cf000b4a..03416215 100644
--- a/qa/release-validation/CP5-website-docs-completeness.md
+++ b/qa/release-validation/CP5-website-docs-completeness.md
@@ -16,7 +16,7 @@
 
 1. For each URL below, issue an HTTP request and check status code
 
-**Getting Started** (6 pages):
+**Getting Started** (7 pages):
 - `$BASE_URL/docs/getting-started`
 - `$BASE_URL/docs/getting-started/quickstart`
 - `$BASE_URL/docs/getting-started/bootstrap-quick-mode`
@@ -99,13 +99,13 @@
 
 ### Expected Result
 
-- All 60 URLs return HTTP 200
+- All 61 URLs return HTTP 200
 - Log any non-200 as FAIL with status code
 
 ### Notes
 
 - Use batch `curl -sI` or WebFetch for efficiency
-- Total: 60 pages
+- Total: 61 pages
 
 ---
 

From 9d5b9e2ad6f490b224ac5809284020d98bc2ac3a Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 09:44:51 +0200
Subject: [PATCH 07/13] [US-278] test: smoke-cover the new docs page in the e2e
 page lists

Registering the page in meta.json alone leaves it outside the 200/title
smoke list and the prev/next circularity sweep.
---
 apps/website/e2e/docs.e2e.test.ts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/apps/website/e2e/docs.e2e.test.ts b/apps/website/e2e/docs.e2e.test.ts
index a1cbd84b..497e1a53 100644
--- a/apps/website/e2e/docs.e2e.test.ts
+++ b/apps/website/e2e/docs.e2e.test.ts
@@ -160,6 +160,7 @@ test('smoke: all docs pages return 200 with correct titles', async ({ page }) =>
   const pages = [
     { url: '/docs/getting-started', title: 'What is pair?' },
     { url: '/docs/getting-started/quickstart', title: 'Quickstart' },
+    { url: '/docs/getting-started/bootstrap-quick-mode', title: 'Bootstrap Quick Mode' },
     { url: '/docs/getting-started/quickstart-solo', title: 'Quickstart: Solo' },
     { url: '/docs/getting-started/quickstart-team', title: 'Quickstart: Team' },
     { url: '/docs/getting-started/quickstart-org', title: 'Quickstart: Organization' },
@@ -909,6 +910,7 @@ test('no circular prev/next footer links on any docs page', async ({ page }) =>
     '/docs',
     '/docs/getting-started',
     '/docs/getting-started/quickstart',
+    '/docs/getting-started/bootstrap-quick-mode',
     '/docs/getting-started/quickstart-solo',
     '/docs/getting-started/quickstart-team',
     '/docs/getting-started/quickstart-org',

From c41dad711c83d1673854a3c879b5ae54280ba07e Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 09:51:24 +0200
Subject: [PATCH 08/13] [US-278] test: guard convention adopter enumeration
 names bootstrap
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- RED: convention still says "two shipped adopters" post-#278
- Assert both copies (dataset + root KB) enumerate bootstrap
- Task: T2 — quick-mode entry per the Guided/Quick Setup Convention

Refs: #278
---
 .../knowledge-hub/src/conformance/bootstrap.test.ts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/packages/knowledge-hub/src/conformance/bootstrap.test.ts b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
index cee0da1d..de620b83 100644
--- a/packages/knowledge-hub/src/conformance/bootstrap.test.ts
+++ b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
@@ -61,6 +61,19 @@ describe('prerequisite: the Guided/Quick Setup Convention exists (#276)', () =>
     expect(existsSync(join(__dirname, '../../dataset', CONVENTION_REL))).toBe(true)
     expect(existsSync(join(ROOT, CONVENTION_REL))).toBe(true)
   })
+
+  // The convention enumerates its shipped adopters to prove "guided is always
+  // the default" is false. Bootstrap is now one of them, so the enumeration
+  // must name it — otherwise the convention documents a stale adopter set and
+  // the next adopter reads a list that is missing the closest precedent.
+  it('enumerates bootstrap among its shipped adopters, in both copies', () => {
+    for (const p of [join(__dirname, '../../dataset', CONVENTION_REL), join(ROOT, CONVENTION_REL)]) {
+      const c = read(p)
+      expect(c).toMatch(/bootstrap/i)
+      // the count of enumerated adopters must not still say "two"
+      expect(c).not.toMatch(/two shipped adopters/i)
+    }
+  })
 })
 
 describe('bootstrap quick mode: selector + declared default (AC1/AC2)', () => {

From 2dd2eaa70fe288ddb3e04c747ab569cd31c68378 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 09:52:09 +0200
Subject: [PATCH 09/13] [US-278] docs: list bootstrap as a third adopter of the
 convention
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- GREEN: enumeration named only pair package + assess-*
- bootstrap declares guided default, quick via $mode; delta stays in the skill
- Both copies (root KB + dataset) kept identical
- Task: T2 — quick-mode entry per the Guided/Quick Setup Convention

Refs: #278
---
 .../ai-development/skill-conventions/guided-quick-setup.md     | 3 ++-
 .../ai-development/skill-conventions/guided-quick-setup.md     | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md b/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
index 1338950c..0855496f 100644
--- a/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
+++ b/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
@@ -22,10 +22,11 @@ Neither mode is universally "the default." Each adopter **declares its own defau
 - **Selector direction**: an explicit signal selects the *non-default* mode. A guided selector (a `--interactive` flag) opts into guided; a quick selector (an override argument) opts into quick. Absence of any signal → the adopter's declared default.
 - **Non-interactive safety**: guided needs a TTY. A detected non-interactive environment (no TTY, CI) can never run guided — the command must fail with a clear message or fall back to quick, and must never hang waiting for input it cannot receive.
 
-The two shipped adopters declare **opposite** defaults, which is precisely why "guided is always the default" is false:
+The shipped adopters declare **opposite** defaults, which is precisely why "guided is always the default" is false:
 
 - `pair package` declares **quick** as its default — a CLI/scripting-first command runs one-shot from resolved defaults, and guided is opt-in via `--interactive`.
 - the `assess-*` family declares **guided** as its default (Path C — Full Assessment), and quick is opt-in via an explicit `$choice` override (Path A).
+- `bootstrap` declares **guided** as its default — human-facing first-time setup asks rather than assumes — and quick is opt-in via `$mode: quick`. Its per-adopter delta (which decision points are defaultable, which tier fills each, which stay asked) lives beside the skill in `quick-mode-defaults.md`.
 
 Recommended default when adopting: a human-facing, first-time setup skill should lean **guided** (ask rather than silently assume); a scripting-first CLI command should lean **quick**. Whichever is chosen, declare it explicitly rather than leaving it implicit.
 
diff --git a/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md b/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
index 1338950c..0855496f 100644
--- a/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
+++ b/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
@@ -22,10 +22,11 @@ Neither mode is universally "the default." Each adopter **declares its own defau
 - **Selector direction**: an explicit signal selects the *non-default* mode. A guided selector (a `--interactive` flag) opts into guided; a quick selector (an override argument) opts into quick. Absence of any signal → the adopter's declared default.
 - **Non-interactive safety**: guided needs a TTY. A detected non-interactive environment (no TTY, CI) can never run guided — the command must fail with a clear message or fall back to quick, and must never hang waiting for input it cannot receive.
 
-The two shipped adopters declare **opposite** defaults, which is precisely why "guided is always the default" is false:
+The shipped adopters declare **opposite** defaults, which is precisely why "guided is always the default" is false:
 
 - `pair package` declares **quick** as its default — a CLI/scripting-first command runs one-shot from resolved defaults, and guided is opt-in via `--interactive`.
 - the `assess-*` family declares **guided** as its default (Path C — Full Assessment), and quick is opt-in via an explicit `$choice` override (Path A).
+- `bootstrap` declares **guided** as its default — human-facing first-time setup asks rather than assumes — and quick is opt-in via `$mode: quick`. Its per-adopter delta (which decision points are defaultable, which tier fills each, which stay asked) lives beside the skill in `quick-mode-defaults.md`.
 
 Recommended default when adopting: a human-facing, first-time setup skill should lean **guided** (ask rather than silently assume); a scripting-first CLI command should lean **quick**. Whichever is chosen, declare it explicitly rather than leaving it implicit.
 

From 950839171c5b408396c7965312ca517916892bc9 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 11:03:44 +0200
Subject: [PATCH 10/13] [US-278] style: prettier formatting on the conformance
 file
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The file was committed before prettier ran on it, so it would have landed on
main unformatted and added to the existing drift. Formatting only — no
assertion changed.

Two unrelated pair-cli test files that prettier also rewrote were deliberately
left out: that drift pre-dates this story and belongs to #394 (pre-push gate
should run the formatters in write-mode), not to a bootstrap PR.

Refs #278

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 packages/knowledge-hub/src/conformance/bootstrap.test.ts | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/packages/knowledge-hub/src/conformance/bootstrap.test.ts b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
index de620b83..e144429f 100644
--- a/packages/knowledge-hub/src/conformance/bootstrap.test.ts
+++ b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
@@ -67,7 +67,10 @@ describe('prerequisite: the Guided/Quick Setup Convention exists (#276)', () =>
   // must name it — otherwise the convention documents a stale adopter set and
   // the next adopter reads a list that is missing the closest precedent.
   it('enumerates bootstrap among its shipped adopters, in both copies', () => {
-    for (const p of [join(__dirname, '../../dataset', CONVENTION_REL), join(ROOT, CONVENTION_REL)]) {
+    for (const p of [
+      join(__dirname, '../../dataset', CONVENTION_REL),
+      join(ROOT, CONVENTION_REL),
+    ]) {
       const c = read(p)
       expect(c).toMatch(/bootstrap/i)
       // the count of enumerated adopters must not still say "two"

From 67e02fd0c8612d943f9029f3a280e9546b9c8fb7 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 12:25:11 +0200
Subject: [PATCH 11/13] =?UTF-8?q?[US-278]=20fix:=20review=20round=201=20?=
 =?UTF-8?q?=E2=80=94=20quick=20mode=20stated=20where=20the=20questions=20a?=
 =?UTF-8?q?re?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Resolves every finding on PR #408.

Major:
- SKILL.md: quick-mode notes added to Step 2.2 (compose assess-* with Path A
  $choice, never plain — family default is guided) and Step 3.1 (no
  per-document approval round); Phase 1/3 HALT conditions marked guided-only.
- KB asset: new `bootstrap-checklist.md` § Quick-Mode Per-Project-Type
  Defaults — the fallback tier now points at real per-type values for
  architecture/infra/observability/ux-ui/way-of-working. No stack, no PM tool
  row (project state or asked); worked examples ruled out as a default source.
- PRD is a precondition, not a default: stated in SKILL.md,
  quick-mode-defaults.md and the docs page; CP9 gains MT-CP902 (PRD authored
  outside the stopwatch), timed test renumbered MT-CP903 with bootstrap/story
  splits.
- meta.json: bootstrap-quick-mode moved after the quickstart trio, so
  Quickstart's footer next is Quickstart: Solo again (landing e2e stays
  meaningful); nav order pinned in conformance.

Minor / questions:
- cascade tiers disjoint (project state excludes decision-log/).
- ADL softened to what the suite actually guards; suite now derives the
  interview-marker check per step section.
- CP5 gains a Changelog; getting-started/index.mdx cross-links the page.
- convention wording: adopters "do not agree on a default".
- skill `version` 0.5.0 → 0.6.0 and the bump rule written down in
  contributing/writing-skills.mdx.

risk:yellow · quality gates: PASS (22 + 12 turbo tasks, conformance 39/39)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../skills/pair-process-bootstrap/SKILL.md    |  19 ++-
 .../quick-mode-defaults.md                    |  22 ++-
 ...-bootstrap-quick-is-a-depth-not-a-skill.md |   5 +-
 .pair/knowledge/assets/bootstrap-checklist.md |  75 +++++---
 .../skill-conventions/guided-quick-setup.md   |   2 +-
 .../docs/contributing/writing-skills.mdx      |   4 +-
 .../getting-started/bootstrap-quick-mode.mdx  |  10 +-
 .../content/docs/getting-started/index.mdx    |   1 +
 .../content/docs/getting-started/meta.json    |   2 +-
 apps/website/e2e/docs.e2e.test.ts             |   4 +-
 .../knowledge/assets/bootstrap-checklist.md   |  75 +++++---
 .../skill-conventions/guided-quick-setup.md   |   2 +-
 .../.skills/process/bootstrap/SKILL.md        |  19 ++-
 .../process/bootstrap/quick-mode-defaults.md  |  22 ++-
 .../src/conformance/bootstrap.test.ts         | 161 ++++++++++++++++++
 .../CP5-website-docs-completeness.md          |   8 +-
 .../CP9-quickstart-onboarding.md              |  88 +++++++---
 17 files changed, 406 insertions(+), 113 deletions(-)

diff --git a/.claude/skills/pair-process-bootstrap/SKILL.md b/.claude/skills/pair-process-bootstrap/SKILL.md
index 2aa1245d..0a6977f6 100644
--- a/.claude/skills/pair-process-bootstrap/SKILL.md
+++ b/.claude/skills/pair-process-bootstrap/SKILL.md
@@ -1,7 +1,7 @@
 ---
 name: pair-process-bootstrap
 description: "Orchestrates full project setup — PRD verification, project categorization, checklist, standards, quality gates, PM tool — for a brand-new project, end to end. Composes /pair-process-specify-prd, /pair-capability-setup-pm, /pair-capability-record-decision, assess-* (optional)."
-version: 0.5.0
+version: 0.6.0
 author: Foomakers
 ---
 
@@ -31,7 +31,7 @@ Orchestrate the complete project setup sequence. Transforms a PRD into a fully c
 
 | Argument | Required | Description |
 | -------- | -------- | ----------- |
-| `$mode`  | No       | Resolution depth: `guided` (the **declared default**) or `quick`. Absent ⇒ `guided`, and Phases 0-4 below run unchanged. `quick` takes KB-sensible defaults instead of asking, per the [Guided / Quick Setup Convention](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md). See Resolution Depth below. |
+| `$mode`  | No       | Resolution depth: `guided` (the **declared default**) or `quick`. Absent ⇒ `guided`, and Phases 0-4 below run unchanged. `quick` takes KB-sensible defaults instead of asking, per the [Guided / Quick Setup Convention](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md). Passing `guided` explicitly is accepted as a **loud no-op** — a deliberate, documented deviation from the convention's minimum (it fixes only that an explicit signal must select the **non-default** depth), kept for callers that want the depth visible at the call site; see [quick-mode-defaults.md](./quick-mode-defaults.md) § Selector. See Resolution Depth below. |
 
 ## Resolution Depth: guided (default) or quick
 
@@ -41,6 +41,7 @@ One entry point, two resolution depths. Quick mode is **additive**: a second res
 - **quick** — `$mode: quick` is the explicit opt-in signal. Bootstrap **asks no questions** for any decision that has a safe default, so an empty repository reaches a **first workable story** in minutes rather than a full interview.
 - **The resolution is the convention's, not bootstrap's.** Defaults resolve through the convention's cascade (explicit argument > project state > saved preferences > hardcoded fallback). Bootstrap declares only its per-adopter delta — which decision points are defaultable, which tier fills each, which are still asked — in [quick-mode-defaults.md](./quick-mode-defaults.md). There is **no bespoke** Quickstart resolution order.
 - **Not every question disappears.** Decisions with no safe KB default (PM tool; tech stack on a genuinely empty repo) are still asked in quick mode — see [quick-mode-defaults.md](./quick-mode-defaults.md).
+- **A populated PRD is a precondition, not a default.** Phase 0 is BLOCKING and identical in both depths: a missing or template PRD composes `/pair-process-specify-prd`, an interactive authoring session. That session is **outside** the quick-mode question budget and outside the minutes-scale claim — quick mode reaches a first workable story in minutes *from a populated PRD*. On a repo with no PRD, author it first (or expect the PRD interview before quick mode's own path starts).
 - **Non-interactive safety**: guided needs a TTY. With no TTY (CI, piped stdin) guided can never run — bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
 - **Already configured**: identical in both depths — every phase checks its own output first and confirms rather than overwriting.
 
@@ -126,6 +127,8 @@ One entry point, two resolution depths. Quick mode is **additive**: a second res
 
 4. **Verify**: Assessment data collected (via skills or manually) and persisted via `/pair-capability-record-decision`. All adoption files written from assess-\* proposals are consistent.
 
+**Quick mode**: composed assess-\* skills must be invoked with their own quick signal — the resolution cascade's **Path A `$choice`**, resolved from project state — never plain, because the assess-\* family's declared default is guided (Path C, the full interview). A domain project state cannot resolve falls back to the per-project-type default named in [quick-mode-defaults.md](./quick-mode-defaults.md); the tech stack on a genuinely empty repo is the one exception and is still asked (Step 2.3). The manual-assessment path (item 3) asks nothing either — it takes the same defaults and reports them.
+
 ### Step 2.3: Gather Information per Section
 
 For each missing adoption file, work through the relevant checklist section. Reference the [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md) for section-specific questions.
@@ -136,10 +139,10 @@ For each missing adoption file, work through the relevant checklist section. Ref
 2. **Tech Stack** — languages, frameworks, libraries with versions
    - Reference: [Technical Standards](../../../.pair/knowledge/guidelines/technical-standards/README.md)
 
-3. **Infrastructure** — deployment, CI/CD, monitoring, environments
+3. *`Infrastructure`* — deployment, CI/CD, monitoring, environments
    - Reference: [Infrastructure Guidelines](../../../.pair/knowledge/guidelines/infrastructure/README.md)
 
-4. **UX/UI** — design system, accessibility, device support
+4. *`UX/UI`* — design system, accessibility, device support
    - Reference: [UX Guidelines](../../../.pair/knowledge/guidelines/user-experience/README.md)
 
 5. **Way of Working** — processes, quality gates, release cycles
@@ -151,7 +154,7 @@ For each missing adoption file, work through the relevant checklist section. Ref
 - Wait for developer responses before proceeding
 - Record each significant decision via `/pair-capability-record-decision` (`non-architectural` → ADL, `architectural` → ADR)
 
-**Quick mode**: no section questions — each section is filled from the project-type defaults in [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md), with the same `/pair-capability-record-decision` calls. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked ([quick-mode-defaults.md](./quick-mode-defaults.md)).
+**Quick mode**: no section questions — each section is filled from one named KB anchor, [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md) § `Quick-Mode Per-Project-Type Defaults` (plus § `Decision Framework` for the core architectural pattern), with the same `/pair-capability-record-decision` calls. The § `Context-Specific Examples` are worked examples of already-decided projects — **never** a default source. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked; the table has no stack row by design ([quick-mode-defaults.md](./quick-mode-defaults.md)).
 
 ## Phase 3: Standards Generation
 
@@ -170,6 +173,8 @@ For each missing adoption file (in order: architecture → tech-stack → infras
 5. **Act**: Save to [adoption/tech/](../../../.pair/adoption/tech)`<filename>.md`.
 6. **Verify**: File written, consistent with other adoption files.
 
+**Quick mode**: steps 3 and 4 are skipped for **every** document — no per-document presentation, no approval round, no iteration loop. Documents are generated, written and then reported once in the Step 4.3 summary; steps 1, 2, 5 and 6 are identical in both depths ([quick-mode-defaults.md](./quick-mode-defaults.md)).
+
 ### Step 3.2: Quality Gate Setup
 
 1. **Check**: Does [adoption/tech/way-of-working.md](../../../.pair/adoption/tech/way-of-working.md) already contain a Custom Gate Registry with entries?
@@ -273,9 +278,9 @@ BOOTSTRAP COMPLETE:
 ## HALT Conditions
 
 - **PRD missing or template and /pair-process-specify-prd fails** (Phase 0) — cannot bootstrap without product context
-- **Project categorization rejected** (Phase 1) — developer must confirm before technical decisions
+- **Project categorization rejected** (Phase 1, **guided only**) — developer must confirm before technical decisions; quick mode derives the type from PRD signals and records it without a confirmation round
 - **Critical technical decision unresolved** (Phase 2) — cannot generate adoption files with gaps
-- **Adoption file generation rejected** (Phase 3) — each document needs developer approval
+- **Adoption file generation rejected** (Phase 3, **guided only**) — each document needs developer approval in the guided depth; quick mode writes without an approval round (Step 3.1), so this condition cannot arise there
 - **Non-defaultable input unresolvable in quick mode** (Step 2.3, Step 4.2) — a decision with no safe KB default (PM tool, undetectable tech stack) that cannot be resolved from the cascade and cannot be asked (no TTY); report which input to pass explicitly, never guess it
 
 On HALT: report the blocker clearly, propose resolution, wait for developer.
diff --git a/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md b/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
index 8de3c0b1..2b8875ff 100644
--- a/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
+++ b/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
@@ -8,6 +8,7 @@ Disclosed from [SKILL.md](./SKILL.md) — the `$mode` selector and its two resol
 
 - `guided` — bootstrap's declared default. Absent `$mode`, the full interview runs unchanged.
 - `quick` — the explicit opt-in signal. No interview: every defaultable decision is resolved from the cascade instead of asked.
+- **`guided` is also accepted explicitly — a documented deviation.** The convention fixes the selector's **minimum** (an explicit signal must select the non-default depth) and says nothing about naming the default; bootstrap accepts `$mode: guided` as a loud no-op so a script or a handoff can make the depth visible at the call site. It resolves to exactly the same behaviour as an omitted `$mode`.
 - No TTY (CI, piped stdin) is an explicit environment fact and outranks the depth preference: guided can never run there. Bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
 
 ## Cascade tiers, as bootstrap fills them
@@ -17,19 +18,23 @@ The convention's precedence, highest wins, with bootstrap's source named per tie
 | Tier (convention)             | What fills it in bootstrap                                                                                     |
 | ----------------------------- | -------------------------------------------------------------------------------------------------------------- |
 | explicit argument             | `$mode`, plus any value the invocation names outright (e.g. the PM tool)                                        |
-| project state                 | what is already on disk: `.pair/adoption/**`, the PRD, `package.json` and lockfiles, CI workflows, `git config` |
-| saved or inferred preferences | decisions a previous run recorded — the ADLs/ADRs in `.pair/adoption/decision-log/`                             |
-| hardcoded fallback            | the per-project-type defaults in `bootstrap-checklist.md` — a KB value, never one invented here                 |
+| project state                 | what is already on disk **excluding** `.pair/adoption/decision-log/` (that is the tier below): `.pair/adoption/tech/**`, `.pair/adoption/product/**`, the PRD, `package.json` and lockfiles, config files, CI workflows, `git config` |
+| saved or inferred preferences | what a previous run recorded as a decision rather than as adopted state — the ADLs/ADRs in `.pair/adoption/decision-log/`. A decision-log entry whose value never reached an adoption file is still honoured here, and loses to the adoption file when both exist |
+| hardcoded fallback            | `bootstrap-checklist.md` § `Quick-Mode Per-Project-Type Defaults` (and § `Architecture Foundation Assessment → Decision Framework` for the core architectural pattern) — a KB value, never one invented here, and **never** read from § `Context-Specific Examples`, which are worked examples of already-decided projects |
 
 ## Per-decision resolution
 
 | Phase / step | Decision point                                                       | Quick mode                                                                                                     | Tier              |
 | ------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------- |
-| Phase 0      | PRD present and populated                                            | never defaulted — composes `/pair-process-specify-prd` when missing, HALTs if the PRD is still absent                        | project state     |
+| Phase 0      | PRD present and populated                                            | **never defaulted, and a precondition of the minutes-scale claim** — a populated PRD is read; a missing or template PRD composes `/pair-process-specify-prd`, an interactive authoring session outside quick mode's question budget (see `Still asked`). HALTs if the PRD is still absent | project state     |
 | Step 1.2     | project categorization (Type A/B/C)                                  | derived from PRD signals (team size, budget, compliance) and recorded, not confirmed                            | project state     |
-| Step 2.2     | which `assess-*` skills run                                          | installed ones run with their own quick signal (Path A `$choice`) where project state resolves the choice       | project state     |
-| Step 2.3     | per-section questions (architecture, stack, infrastructure, ux-ui, way-of-working) | not asked — each section is filled from the project-type defaults, except an undetectable stack (still asked)   | fallback          |
-| Step 3.1     | adoption documents                                                   | generated and written without the per-document approval round                                                  | fallback          |
+| Step 2.2     | which `assess-*` skills run, and how                                 | installed ones are composed **with** their quick signal (Path A `$choice`), never plain — the family's declared default is guided (Path C). Project state fills `$choice` where it can; otherwise the per-type fallback row below does | project state     |
+| Step 2.3     | architecture section (core pattern, style, data)                     | not asked — `bootstrap-checklist.md` § `Decision Framework` (core pattern) + § `Quick-Mode Per-Project-Type Defaults` rows `Architecture — style` / `— data` | fallback          |
+| Step 2.3     | tech stack section                                                   | read from project state (`package.json`, lockfiles, config files); **still asked** on an empty repo — the fallback table has no stack row by design | project state     |
+| Step 2.3     | infrastructure + observability sections                              | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Infrastructure` / `Observability`                    | fallback          |
+| Step 2.3     | ux-ui section                                                        | not asked — § `Quick-Mode Per-Project-Type Defaults` row `UX/UI`                                               | fallback          |
+| Step 2.3     | way-of-working section (flow, branching, release)                    | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Way of Working — …`. The PM tool is excluded from this row and still asked (Step 4.2) | fallback          |
+| Step 3.1     | adoption documents                                                   | generated and written without the per-document presentation or approval round, for every document (Step 3.1 items 3-4 skipped) | fallback          |
 | Step 3.2     | quality gate setup                                                   | standard pipeline only (type check, test, lint, format), no custom gates — same registry entries guided writes  | fallback          |
 | Phase 3.5    | domain model (subdomains, bounded contexts)                          | runs when `/pair-capability-map-subdomains` / `/pair-capability-map-contexts` are installed, skipped with a warning otherwise — never blocking  | project state     |
 | Step 4.2     | PM tool                                                              | **still asked** unless project state already names one (see below)                                              | explicit argument |
@@ -41,8 +46,9 @@ Quick mode reduces the questions to the genuinely-defaultable ones; it does not
 
 - **PM tool** (Step 4.2) — the choice is organisational, not technical, so no KB value is safe: a wrong guess wires up a tracker nobody uses. Project state resolves it when `way-of-working.md` already names one; otherwise `/pair-capability-setup-pm` is composed and asks that single question.
 - **Tech stack when undetectable** (Step 2.3) — normally read from project state (`package.json`, lockfiles, config files). On a genuinely empty repository there is nothing to read and no universally-correct default, so quick mode asks rather than guessing.
+- **The PRD, when absent** (Phase 0) — not a bootstrap question but a whole composed session: `/pair-process-specify-prd` authors it interactively and iterates to approval. Phase 0 is BLOCKING and identical in both depths, so **a populated PRD is a precondition of the minutes-scale claim**, not something quick mode defaults. Measure or plan quick mode from a project that already has one; on a repo without one, expect the PRD session first.
 
-Everything else in the table above resolves without a question. If one of these two can neither be resolved from the cascade nor asked (quick mode with no TTY), bootstrap HALTs and names the input to pass explicitly — see SKILL.md.
+Everything else in the table above resolves without a question **once the PRD exists**. If one of the two still-asked decisions can neither be resolved from the cascade nor asked (quick mode with no TTY), bootstrap HALTs and names the input to pass explicitly — see SKILL.md.
 
 ## Same files, same format as guided (AC4)
 
diff --git a/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md b/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md
index 34e8dd3c..8388f665 100644
--- a/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md
+++ b/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md
@@ -25,7 +25,8 @@ Quick setup is an **additive second resolution depth of `/pair-process-bootstrap
 Three constraints follow, and are asserted in `packages/knowledge-hub/src/conformance/bootstrap.test.ts`:
 
 1. **No second skill, no second entry point.** One skill, one catalog row, one frontmatter description; both depths run the same phases, compose the same skills, and write the same files.
-2. **No bespoke resolution order.** Bootstrap composes the convention's cascade and declares only its per-adopter delta — which decision points are defaultable, which tier fills each, which are still asked — in the disclosed sibling `quick-mode-defaults.md`. Two decisions stay asked in quick mode because no KB value is safe: the PM tool (organisational, not technical) and the tech stack when the repo is genuinely empty.
+2. **No bespoke resolution order.** Bootstrap composes the convention's cascade and declares only its per-adopter delta — which decision points are defaultable, which tier fills each, which are still asked — in the disclosed sibling `quick-mode-defaults.md`. Two decisions stay asked in quick mode because no KB value is safe: the PM tool (organisational, not technical) and the tech stack when the repo is genuinely empty. A populated PRD is a **precondition**, not a default: Phase 0 is blocking in both depths, so the minutes-scale claim is measured from a project that already has one.
+   The `hardcoded fallback` tier needed a real KB anchor to point at, so this story also adds `bootstrap-checklist.md` § _Quick-Mode Per-Project-Type Defaults_ — one value per adoption section per project type. It deliberately has no tech-stack and no PM-tool row (those are project state or asked), and the pre-existing § _Context-Specific Examples_ are explicitly ruled out as a default source.
 3. **No quick-mode-only output.** Every file quick mode writes is a normal adoption file in the normal location and format, with no marker distinguishing it, so an accepted default is editable exactly like any other adopted decision.
 
 Guided is the declared default because bootstrap is human-facing first-time setup — the convention's own recommendation for that shape ("ask rather than silently assume"). The non-interactive path is the convention's, not a bootstrap invention: no TTY warns and falls back to quick rather than hanging, and HALTs if a still-asked decision is then unresolvable.
@@ -40,7 +41,7 @@ Guided is the declared default because bootstrap is human-facing first-time setu
 ## Consequences
 
 - A future setup-oriented skill adopting the same duality follows the convention plus this precedent: mode argument on the existing skill, declared default stated explicitly, per-adopter delta in a disclosed sibling doc.
-- Any new bootstrap phase or decision point must also declare its quick-mode resolution in `quick-mode-defaults.md`; the conformance test's per-decision anchors fail if a phase is added without one.
+- Any new bootstrap phase or decision point must also declare its quick-mode resolution in `quick-mode-defaults.md`. The conformance suite guards something narrower than that rule, and the difference matters: it asserts (a) that every SKILL.md step whose text carries an **interview marker** — a question blockquote, `Ask 3-4`, a "for developer review" / "until approved" round — also carries a `**Quick mode**:` note in the same section, and (b) a fixed anchor list (PRD, categorization, `assess-*`, quality gate, PM tool, domain model) in the defaults doc. A new decision point that asks nothing new is therefore caught by review, not by the suite.
 - Bootstrap's frontmatter description is unchanged, so no skills-catalog row moves.
 - The <10 minute claim is validated, not asserted: `qa/release-validation/CP9-quickstart-onboarding.md` measures it with an explicit stopwatch protocol and covers the guided-default regression in the same critical path.
 
diff --git a/.pair/knowledge/assets/bootstrap-checklist.md b/.pair/knowledge/assets/bootstrap-checklist.md
index 069cf0fc..595e9738 100644
--- a/.pair/knowledge/assets/bootstrap-checklist.md
+++ b/.pair/knowledge/assets/bootstrap-checklist.md
@@ -5,10 +5,11 @@
 1. [Project Categorization](#project-categorization)
 2. [Architecture Foundation Assessment](#architecture-foundation-assessment)
 3. [Process Methodology Assessment](#process-methodology-assessment)
-4. [Core Checklists](#core-checklists)
-5. [Documentation Requirements](#documentation-requirements)
-6. [Context-Specific Examples](#context-specific-examples)
-7. [Bootstrap Templates](#bootstrap-templates)
+4. [Quick-Mode Per-Project-Type Defaults](#quick-mode-per-project-type-defaults)
+5. [Core Checklists](#core-checklists)
+6. [Documentation Requirements](#documentation-requirements)
+7. [Context-Specific Examples](#context-specific-examples)
+8. [Bootstrap Templates](#bootstrap-templates)
 
 ---
 
@@ -112,6 +113,36 @@
 
 ---
 
+## Quick-Mode Per-Project-Type Defaults
+
+The `hardcoded fallback` tier for a setup skill running its **quick** depth — see the [Guided / Quick Setup Convention](../guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md). One value per section per project type, so a quick run resolves each adoption section from a KB value instead of inventing one or asking. Resolve the project type first ([Project Categorization](#project-categorization)), then read the column. Every value here is a starting point, overridable exactly like any other adopted decision.
+
+**Deliberately absent from this table** — a quick run must not invent these:
+
+- **Tech stack** — read from project state (`package.json`, lockfiles, config files), or asked. No per-type stack is safe: a Type A project is as plausibly a Python CLI as a Next.js portfolio.
+- **Project management tool** — organisational, not technical. Read from `way-of-working.md`, or asked.
+- **[Context-Specific Examples](#context-specific-examples)** (below) are worked examples of three *already-decided* projects, including their stack and PM tool. They illustrate; they are never a default source.
+
+| Section / decision            | Type A (Pet / PoC)                                            | Type B (Startup / Scale-up)                                | Type C (Enterprise)                                                             |
+| ----------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------- |
+| Architecture — core pattern   | Modular Monolith (per [Decision Framework](#decision-framework)) | Modular Monolith with microservice preparation              | Modular Monolith until a domain split is justified — evaluate per Decision Framework |
+| Architecture — style          | Layered                                                       | Hexagonal                                                  | Hexagonal                                                                       |
+| Architecture — data           | Single database                                               | Single database, read replica when load requires            | Database per bounded context, integration via events                            |
+| Infrastructure — environments | prod only                                                     | dev + prod                                                  | dev + staging + prod                                                            |
+| Infrastructure — hosting      | managed platform (PaaS), no orchestration                     | managed platform or containers                              | containers or managed cloud, IaC mandatory                                      |
+| Infrastructure — CI/CD        | repository-native CI: build, test, deploy from `main`         | repository-native CI + preview environments                 | repository-native CI + gated promotion per environment                          |
+| Infrastructure — IaC          | none                                                          | app-tier IaC                                                | full IaC, no manual infrastructure changes                                      |
+| Observability                 | platform logs + one uptime check                              | + error tracking + a metrics dashboard                      | + APM, log aggregation, security monitoring, alert routing                      |
+| UX/UI                         | off-the-shelf component library, responsive web, WCAG 2.1 AA on new UI | design tokens + component library, responsive web, WCAG 2.1 AA | versioned design-system package, supported-browser matrix, WCAG 2.1 AA (AAA where regulated) |
+| Way of Working — flow         | Kanban, no ceremonies                                         | 2-week sprints: standup, planning, review, retro            | 2-week sprints, full ceremony set including backlog refinement                  |
+| Way of Working — branching    | trunk-based, short-lived branches, PR with 1 review           | same, with protected `main`                                 | same + a release branch for hotfixes                                            |
+| Way of Working — commits/PRs  | Conventional Commits, KB PR template                          | idem                                                        | idem + a linked work item required on every PR                                  |
+| Way of Working — quality gates | standard pipeline: type check, test, lint, format            | idem                                                        | idem + dependency and security scanning                                         |
+| Way of Working — DoD          | KB Definition of Done template, unchanged                     | idem + a coverage threshold                                 | idem + compliance/audit evidence                                                |
+| Release                       | on demand from `main`                                         | every sprint                                                | milestone-driven, with a manual approval gate                                   |
+
+---
+
 ## Core Checklists
 
 ### Architecture Checklist (Post-Foundation)
@@ -348,15 +379,15 @@
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Modular Monolith → _Single Next.js application_
-- ✅ **Architectural Style**: Layered → _Pages/Components/Utils structure_
-- ✅ **Data Strategy**: Static + Headless CMS → _Markdown files + optional Sanity_
+- ✅ **Monolith vs Microservices**: Modular Monolith → *Single Next.js application*
+- ✅ **Architectural Style**: Layered → *Pages/Components/Utils structure*
+- ✅ **Data Strategy**: Static + Headless CMS → *Markdown files + optional Sanity*
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: Kanban → _Feature-based development, no sprints_
-- ✅ **Release Strategy**: Continuous deployment → _Vercel auto-deploy on push_
-- ✅ **Quality Gates**: Minimal → _TypeScript + basic testing_
+- ✅ **Iteration Model**: Kanban → *Feature-based development, no sprints*
+- ✅ **Release Strategy**: Continuous deployment → *Vercel auto-deploy on push*
+- ✅ **Quality Gates**: Minimal → *TypeScript + basic testing*
 
 #### Project Management Tool:
 
@@ -391,9 +422,9 @@ Monitoring: Vercel built-in monitoring
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Modular Monolith → _Single deployable with service layers_
-- ✅ **Architectural Style**: Event-Driven → _Real-time data processing architecture_
-- ✅ **Data Strategy**: Polyglot Persistence → _PostgreSQL + ClickHouse + Redis_
+- ✅ **Monolith vs Microservices**: Modular Monolith → *Single deployable with service layers*
+- ✅ **Architectural Style**: Event-Driven → *Real-time data processing architecture*
+- ✅ **Data Strategy**: Polyglot Persistence → *PostgreSQL + ClickHouse + Redis*
 
 #### Project Management Tool:
 
@@ -401,9 +432,9 @@ Monitoring: Vercel built-in monitoring
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: 2-week Sprints → _Balanced planning with fast delivery_
-- ✅ **Release Strategy**: Sprint-based with feature flags → _Risk mitigation_
-- ✅ **Quality Gates**: High → _95% test coverage, performance budgets_
+- ✅ **Iteration Model**: 2-week Sprints → *Balanced planning with fast delivery*
+- ✅ **Release Strategy**: Sprint-based with feature flags → *Risk mitigation*
+- ✅ **Quality Gates**: High → *95% test coverage, performance budgets*
 
 #### Final Tech Stack (Definitive):
 
@@ -435,15 +466,15 @@ Testing: Jest 29.x + Cypress 13.x + Artillery (load testing)
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Domain Microservices → _Customer, Sales, Marketing, Integration services_
-- ✅ **Architectural Style**: Hexagonal + CQRS → _Complex business logic isolation_
-- ✅ **Data Strategy**: Database per Service + Event Sourcing → _Audit requirements_
+- ✅ **Monolith vs Microservices**: Domain Microservices → *Customer, Sales, Marketing, Integration services*
+- ✅ **Architectural Style**: Hexagonal + CQRS → *Complex business logic isolation*
+- ✅ **Data Strategy**: Database per Service + Event Sourcing → *Audit requirements*
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: 3-week Sprints → _Enterprise coordination needs_
-- ✅ **Release Strategy**: Quarterly releases with monthly patches → _Risk management_
-- ✅ **Quality Gates**: Enterprise → _Security scans, compliance checks, performance testing_
+- ✅ **Iteration Model**: 3-week Sprints → *Enterprise coordination needs*
+- ✅ **Release Strategy**: Quarterly releases with monthly patches → *Risk management*
+- ✅ **Quality Gates**: Enterprise → *Security scans, compliance checks, performance testing*
 
 #### Project Management Tool:
 
diff --git a/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md b/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
index 0855496f..22336b38 100644
--- a/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
+++ b/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
@@ -22,7 +22,7 @@ Neither mode is universally "the default." Each adopter **declares its own defau
 - **Selector direction**: an explicit signal selects the *non-default* mode. A guided selector (a `--interactive` flag) opts into guided; a quick selector (an override argument) opts into quick. Absence of any signal → the adopter's declared default.
 - **Non-interactive safety**: guided needs a TTY. A detected non-interactive environment (no TTY, CI) can never run guided — the command must fail with a clear message or fall back to quick, and must never hang waiting for input it cannot receive.
 
-The shipped adopters declare **opposite** defaults, which is precisely why "guided is always the default" is false:
+The shipped adopters do **not** agree on a default, which is precisely why "guided is always the default" is false:
 
 - `pair package` declares **quick** as its default — a CLI/scripting-first command runs one-shot from resolved defaults, and guided is opt-in via `--interactive`.
 - the `assess-*` family declares **guided** as its default (Path C — Full Assessment), and quick is opt-in via an explicit `$choice` override (Path A).
diff --git a/apps/website/content/docs/contributing/writing-skills.mdx b/apps/website/content/docs/contributing/writing-skills.mdx
index 9208eca9..6203fcac 100644
--- a/apps/website/content/docs/contributing/writing-skills.mdx
+++ b/apps/website/content/docs/contributing/writing-skills.mdx
@@ -208,8 +208,9 @@ Hard mechanics on top of the principles:
 - **Size limits** — the spec caps `name` at 64 chars and `description` at 1024 chars separately; Pair adopts a stricter combined ≤1024 bound for both together.
 - **Portability** — the [agentskills.io](https://agentskills.io) spec's top-level frontmatter fields are `name` and `description` (required) plus `license`, `compatibility`, `metadata`, and `allowed-tools` (optional); the spec's own example `version`/`author` keys live *under* `metadata:`, not top-level. Pair skills carry `version`/`author` at top level instead — a tolerated **Pair extension** beyond the spec's optional fields, kept there for provenance tracking (who authored/last bumped a skill) until a future skill-corpus pass considers moving them under `metadata:`. Assistant-specific fields (e.g., `disable-model-invocation`) stay out of the dataset regardless: a skill must install identically on Claude Code, Cursor, VS Code Copilot, and Codex.
 - **Mirror sync** — the dataset copy (`packages/knowledge-hub/dataset/.skills/`) and the installed mirror (`.claude/skills/`) change in the same commit, always.
+- **`version` bumps track observable behaviour, not edits** — minor (`0.5.0 → 0.6.0`) when a skill gains or changes something a caller can observe: a new argument, a new mode/execution depth, a new or removed phase, a changed HALT condition. Patch (`0.6.0 → 0.6.1`) for a behaviour-preserving correction to the algorithm's wording. **No bump** for prose, formatting, link, or documentation-only edits — which is why a clarity pass across many skills leaves their versions alone. Same value in both copies: the mirror transform rewrites `name`/`description`, never `version`.
 
-**How to check:** character-count `name` and `description` against the combined bound; diff the frontmatter's fields against the spec's top-level list plus the tolerated `version`/`author` extension — anything else is a portability violation; confirm the commit touches both copies.
+**How to check:** character-count `name` and `description` against the combined bound; diff the frontmatter's fields against the spec's top-level list plus the tolerated `version`/`author` extension — anything else is a portability violation; confirm the commit touches both copies; if the diff adds an argument, a mode, or a phase, confirm `version` moved.
 
 ### 9. Evaluation
 
@@ -229,6 +230,7 @@ One line per principle — use it when authoring or reviewing any skill change:
 - [ ] Prohibitions only as hard guardrails, each paired with its positive target
 - [ ] Each concept's rules co-located under one heading, adjacent to the step they govern
 - [ ] `name` ≤ 64 / `description` ≤ 1024 chars separately (spec), and both together ≤ 1024 (Pair's stricter bound); frontmatter limited to spec fields + the tolerated `version`/`author` extension (no assistant-specific fields); dataset + mirror in the same commit
+- [ ] `version` bumped iff observable behaviour changed (new argument/mode/phase → minor; wording-only → no bump), identical in both copies
 - [ ] Description rewrites carry before/after trigger-eval evidence
 
 ## Writing a new skill
diff --git a/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx b/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
index 5d62b4d8..07eee119 100644
--- a/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
+++ b/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
@@ -24,7 +24,9 @@ Quick mode is **additive**. It is a second depth of the same skill, not a separa
 /pair-process-bootstrap $mode: quick
 ```
 
-Expect at most two questions:
+**One precondition**: a populated `.pair/adoption/product/PRD.md`. Phase 0 of bootstrap is blocking in both depths — with no PRD it composes `/pair-process-specify-prd`, a full interactive authoring session that is neither defaulted nor counted below. Write the PRD first, then run quick mode.
+
+With the PRD in place, expect at most two questions:
 
 - **Which PM tool?** — the choice is organisational, not technical, so there is no safe default to guess. Skipped if your `way-of-working.md` already names one.
 - **Which tech stack?** — normally read straight from `package.json`, lockfiles and config. Only asked on a genuinely empty repository, where there is nothing to read.
@@ -54,9 +56,9 @@ An already-configured project is **confirmed, not overwritten**: each phase chec
 Quick mode does not invent its own resolution order. It follows the shared Guided / Quick Setup Convention that `pair package` and the `assess-*` skills already use — highest wins:
 
 1. **Explicit argument** — anything you named in the invocation
-2. **Project state** — what is already on disk: `.pair/adoption/**`, the PRD, `package.json`, lockfiles, CI workflows, `git config`
-3. **Saved preferences** — decisions a previous run recorded in the decision log
-4. **Fallback** — the per-project-type defaults in the KB bootstrap checklist
+2. **Project state** — what is already on disk, except the decision log: `.pair/adoption/tech/**`, `.pair/adoption/product/**`, the PRD, `package.json`, lockfiles, CI workflows, `git config`
+3. **Saved preferences** — decisions a previous run recorded in `.pair/adoption/decision-log/`
+4. **Fallback** — the _Quick-Mode Per-Project-Type Defaults_ table in the KB bootstrap checklist (never its worked examples)
 
 Bootstrap only declares which of its own decisions each tier fills. That mapping, decision by decision, lives next to the skill in `quick-mode-defaults.md` (`.claude/skills/pair-process-bootstrap/quick-mode-defaults.md` once the KB is installed).
 
diff --git a/apps/website/content/docs/getting-started/index.mdx b/apps/website/content/docs/getting-started/index.mdx
index d4a77910..b543ffa4 100644
--- a/apps/website/content/docs/getting-started/index.mdx
+++ b/apps/website/content/docs/getting-started/index.mdx
@@ -33,6 +33,7 @@ You don't write these files manually. Run `/pair-next` and the AI walks you thro
 - **[Quickstart: Solo](/docs/getting-started/quickstart-solo)** — Working alone? Minimal configuration, no team coordination.
 - **[Quickstart: Team](/docs/getting-started/quickstart-team)** — Shared standards and the agent bridge pattern for multi-developer teams.
 - **[Quickstart: Organization](/docs/getting-started/quickstart-org)** — Custom KB packaging, distribution, and governance across multiple teams.
+- **[Bootstrap Quick Mode](/docs/getting-started/bootstrap-quick-mode)** — In a hurry? Generate the adoption files from KB defaults instead of answering the full interview.
 
 ## Go deeper with tutorials
 
diff --git a/apps/website/content/docs/getting-started/meta.json b/apps/website/content/docs/getting-started/meta.json
index 42f5d38c..7a71a560 100644
--- a/apps/website/content/docs/getting-started/meta.json
+++ b/apps/website/content/docs/getting-started/meta.json
@@ -2,10 +2,10 @@
   "title": "Getting Started",
   "pages": [
     "quickstart",
-    "bootstrap-quick-mode",
     "quickstart-solo",
     "quickstart-team",
     "quickstart-org",
+    "bootstrap-quick-mode",
     "checklist"
   ]
 }
diff --git a/apps/website/e2e/docs.e2e.test.ts b/apps/website/e2e/docs.e2e.test.ts
index 497e1a53..8cbcaec5 100644
--- a/apps/website/e2e/docs.e2e.test.ts
+++ b/apps/website/e2e/docs.e2e.test.ts
@@ -160,10 +160,10 @@ test('smoke: all docs pages return 200 with correct titles', async ({ page }) =>
   const pages = [
     { url: '/docs/getting-started', title: 'What is pair?' },
     { url: '/docs/getting-started/quickstart', title: 'Quickstart' },
-    { url: '/docs/getting-started/bootstrap-quick-mode', title: 'Bootstrap Quick Mode' },
     { url: '/docs/getting-started/quickstart-solo', title: 'Quickstart: Solo' },
     { url: '/docs/getting-started/quickstart-team', title: 'Quickstart: Team' },
     { url: '/docs/getting-started/quickstart-org', title: 'Quickstart: Organization' },
+    { url: '/docs/getting-started/bootstrap-quick-mode', title: 'Bootstrap Quick Mode' },
     { url: '/docs/concepts/ai-assisted-sdlc', title: 'AI-Assisted SDLC' },
     { url: '/docs/concepts/knowledge-base', title: 'Knowledge Base' },
     { url: '/docs/concepts/skills', title: 'Skills' },
@@ -910,10 +910,10 @@ test('no circular prev/next footer links on any docs page', async ({ page }) =>
     '/docs',
     '/docs/getting-started',
     '/docs/getting-started/quickstart',
-    '/docs/getting-started/bootstrap-quick-mode',
     '/docs/getting-started/quickstart-solo',
     '/docs/getting-started/quickstart-team',
     '/docs/getting-started/quickstart-org',
+    '/docs/getting-started/bootstrap-quick-mode',
     '/docs/developer-journey',
     '/docs/developer-journey/induction',
     '/docs/developer-journey/strategic-planning',
diff --git a/packages/knowledge-hub/dataset/.pair/knowledge/assets/bootstrap-checklist.md b/packages/knowledge-hub/dataset/.pair/knowledge/assets/bootstrap-checklist.md
index 069cf0fc..595e9738 100644
--- a/packages/knowledge-hub/dataset/.pair/knowledge/assets/bootstrap-checklist.md
+++ b/packages/knowledge-hub/dataset/.pair/knowledge/assets/bootstrap-checklist.md
@@ -5,10 +5,11 @@
 1. [Project Categorization](#project-categorization)
 2. [Architecture Foundation Assessment](#architecture-foundation-assessment)
 3. [Process Methodology Assessment](#process-methodology-assessment)
-4. [Core Checklists](#core-checklists)
-5. [Documentation Requirements](#documentation-requirements)
-6. [Context-Specific Examples](#context-specific-examples)
-7. [Bootstrap Templates](#bootstrap-templates)
+4. [Quick-Mode Per-Project-Type Defaults](#quick-mode-per-project-type-defaults)
+5. [Core Checklists](#core-checklists)
+6. [Documentation Requirements](#documentation-requirements)
+7. [Context-Specific Examples](#context-specific-examples)
+8. [Bootstrap Templates](#bootstrap-templates)
 
 ---
 
@@ -112,6 +113,36 @@
 
 ---
 
+## Quick-Mode Per-Project-Type Defaults
+
+The `hardcoded fallback` tier for a setup skill running its **quick** depth — see the [Guided / Quick Setup Convention](../guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md). One value per section per project type, so a quick run resolves each adoption section from a KB value instead of inventing one or asking. Resolve the project type first ([Project Categorization](#project-categorization)), then read the column. Every value here is a starting point, overridable exactly like any other adopted decision.
+
+**Deliberately absent from this table** — a quick run must not invent these:
+
+- **Tech stack** — read from project state (`package.json`, lockfiles, config files), or asked. No per-type stack is safe: a Type A project is as plausibly a Python CLI as a Next.js portfolio.
+- **Project management tool** — organisational, not technical. Read from `way-of-working.md`, or asked.
+- **[Context-Specific Examples](#context-specific-examples)** (below) are worked examples of three *already-decided* projects, including their stack and PM tool. They illustrate; they are never a default source.
+
+| Section / decision            | Type A (Pet / PoC)                                            | Type B (Startup / Scale-up)                                | Type C (Enterprise)                                                             |
+| ----------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------- |
+| Architecture — core pattern   | Modular Monolith (per [Decision Framework](#decision-framework)) | Modular Monolith with microservice preparation              | Modular Monolith until a domain split is justified — evaluate per Decision Framework |
+| Architecture — style          | Layered                                                       | Hexagonal                                                  | Hexagonal                                                                       |
+| Architecture — data           | Single database                                               | Single database, read replica when load requires            | Database per bounded context, integration via events                            |
+| Infrastructure — environments | prod only                                                     | dev + prod                                                  | dev + staging + prod                                                            |
+| Infrastructure — hosting      | managed platform (PaaS), no orchestration                     | managed platform or containers                              | containers or managed cloud, IaC mandatory                                      |
+| Infrastructure — CI/CD        | repository-native CI: build, test, deploy from `main`         | repository-native CI + preview environments                 | repository-native CI + gated promotion per environment                          |
+| Infrastructure — IaC          | none                                                          | app-tier IaC                                                | full IaC, no manual infrastructure changes                                      |
+| Observability                 | platform logs + one uptime check                              | + error tracking + a metrics dashboard                      | + APM, log aggregation, security monitoring, alert routing                      |
+| UX/UI                         | off-the-shelf component library, responsive web, WCAG 2.1 AA on new UI | design tokens + component library, responsive web, WCAG 2.1 AA | versioned design-system package, supported-browser matrix, WCAG 2.1 AA (AAA where regulated) |
+| Way of Working — flow         | Kanban, no ceremonies                                         | 2-week sprints: standup, planning, review, retro            | 2-week sprints, full ceremony set including backlog refinement                  |
+| Way of Working — branching    | trunk-based, short-lived branches, PR with 1 review           | same, with protected `main`                                 | same + a release branch for hotfixes                                            |
+| Way of Working — commits/PRs  | Conventional Commits, KB PR template                          | idem                                                        | idem + a linked work item required on every PR                                  |
+| Way of Working — quality gates | standard pipeline: type check, test, lint, format            | idem                                                        | idem + dependency and security scanning                                         |
+| Way of Working — DoD          | KB Definition of Done template, unchanged                     | idem + a coverage threshold                                 | idem + compliance/audit evidence                                                |
+| Release                       | on demand from `main`                                         | every sprint                                                | milestone-driven, with a manual approval gate                                   |
+
+---
+
 ## Core Checklists
 
 ### Architecture Checklist (Post-Foundation)
@@ -348,15 +379,15 @@
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Modular Monolith → _Single Next.js application_
-- ✅ **Architectural Style**: Layered → _Pages/Components/Utils structure_
-- ✅ **Data Strategy**: Static + Headless CMS → _Markdown files + optional Sanity_
+- ✅ **Monolith vs Microservices**: Modular Monolith → *Single Next.js application*
+- ✅ **Architectural Style**: Layered → *Pages/Components/Utils structure*
+- ✅ **Data Strategy**: Static + Headless CMS → *Markdown files + optional Sanity*
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: Kanban → _Feature-based development, no sprints_
-- ✅ **Release Strategy**: Continuous deployment → _Vercel auto-deploy on push_
-- ✅ **Quality Gates**: Minimal → _TypeScript + basic testing_
+- ✅ **Iteration Model**: Kanban → *Feature-based development, no sprints*
+- ✅ **Release Strategy**: Continuous deployment → *Vercel auto-deploy on push*
+- ✅ **Quality Gates**: Minimal → *TypeScript + basic testing*
 
 #### Project Management Tool:
 
@@ -391,9 +422,9 @@ Monitoring: Vercel built-in monitoring
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Modular Monolith → _Single deployable with service layers_
-- ✅ **Architectural Style**: Event-Driven → _Real-time data processing architecture_
-- ✅ **Data Strategy**: Polyglot Persistence → _PostgreSQL + ClickHouse + Redis_
+- ✅ **Monolith vs Microservices**: Modular Monolith → *Single deployable with service layers*
+- ✅ **Architectural Style**: Event-Driven → *Real-time data processing architecture*
+- ✅ **Data Strategy**: Polyglot Persistence → *PostgreSQL + ClickHouse + Redis*
 
 #### Project Management Tool:
 
@@ -401,9 +432,9 @@ Monitoring: Vercel built-in monitoring
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: 2-week Sprints → _Balanced planning with fast delivery_
-- ✅ **Release Strategy**: Sprint-based with feature flags → _Risk mitigation_
-- ✅ **Quality Gates**: High → _95% test coverage, performance budgets_
+- ✅ **Iteration Model**: 2-week Sprints → *Balanced planning with fast delivery*
+- ✅ **Release Strategy**: Sprint-based with feature flags → *Risk mitigation*
+- ✅ **Quality Gates**: High → *95% test coverage, performance budgets*
 
 #### Final Tech Stack (Definitive):
 
@@ -435,15 +466,15 @@ Testing: Jest 29.x + Cypress 13.x + Artillery (load testing)
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Domain Microservices → _Customer, Sales, Marketing, Integration services_
-- ✅ **Architectural Style**: Hexagonal + CQRS → _Complex business logic isolation_
-- ✅ **Data Strategy**: Database per Service + Event Sourcing → _Audit requirements_
+- ✅ **Monolith vs Microservices**: Domain Microservices → *Customer, Sales, Marketing, Integration services*
+- ✅ **Architectural Style**: Hexagonal + CQRS → *Complex business logic isolation*
+- ✅ **Data Strategy**: Database per Service + Event Sourcing → *Audit requirements*
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: 3-week Sprints → _Enterprise coordination needs_
-- ✅ **Release Strategy**: Quarterly releases with monthly patches → _Risk management_
-- ✅ **Quality Gates**: Enterprise → _Security scans, compliance checks, performance testing_
+- ✅ **Iteration Model**: 3-week Sprints → *Enterprise coordination needs*
+- ✅ **Release Strategy**: Quarterly releases with monthly patches → *Risk management*
+- ✅ **Quality Gates**: Enterprise → *Security scans, compliance checks, performance testing*
 
 #### Project Management Tool:
 
diff --git a/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md b/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
index 0855496f..22336b38 100644
--- a/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
+++ b/packages/knowledge-hub/dataset/.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md
@@ -22,7 +22,7 @@ Neither mode is universally "the default." Each adopter **declares its own defau
 - **Selector direction**: an explicit signal selects the *non-default* mode. A guided selector (a `--interactive` flag) opts into guided; a quick selector (an override argument) opts into quick. Absence of any signal → the adopter's declared default.
 - **Non-interactive safety**: guided needs a TTY. A detected non-interactive environment (no TTY, CI) can never run guided — the command must fail with a clear message or fall back to quick, and must never hang waiting for input it cannot receive.
 
-The shipped adopters declare **opposite** defaults, which is precisely why "guided is always the default" is false:
+The shipped adopters do **not** agree on a default, which is precisely why "guided is always the default" is false:
 
 - `pair package` declares **quick** as its default — a CLI/scripting-first command runs one-shot from resolved defaults, and guided is opt-in via `--interactive`.
 - the `assess-*` family declares **guided** as its default (Path C — Full Assessment), and quick is opt-in via an explicit `$choice` override (Path A).
diff --git a/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md b/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
index 988f3ad0..3f29fff3 100644
--- a/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
+++ b/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
@@ -1,7 +1,7 @@
 ---
 name: bootstrap
 description: "Orchestrates full project setup — PRD verification, project categorization, checklist, standards, quality gates, PM tool — for a brand-new project, end to end. Composes /specify-prd, /setup-pm, /record-decision, assess-* (optional)."
-version: 0.5.0
+version: 0.6.0
 author: Foomakers
 ---
 
@@ -31,7 +31,7 @@ Orchestrate the complete project setup sequence. Transforms a PRD into a fully c
 
 | Argument | Required | Description |
 | -------- | -------- | ----------- |
-| `$mode`  | No       | Resolution depth: `guided` (the **declared default**) or `quick`. Absent ⇒ `guided`, and Phases 0-4 below run unchanged. `quick` takes KB-sensible defaults instead of asking, per the [Guided / Quick Setup Convention](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md). See Resolution Depth below. |
+| `$mode`  | No       | Resolution depth: `guided` (the **declared default**) or `quick`. Absent ⇒ `guided`, and Phases 0-4 below run unchanged. `quick` takes KB-sensible defaults instead of asking, per the [Guided / Quick Setup Convention](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md). Passing `guided` explicitly is accepted as a **loud no-op** — a deliberate, documented deviation from the convention's minimum (it fixes only that an explicit signal must select the **non-default** depth), kept for callers that want the depth visible at the call site; see [quick-mode-defaults.md](quick-mode-defaults.md) § Selector. See Resolution Depth below. |
 
 ## Resolution Depth: guided (default) or quick
 
@@ -41,6 +41,7 @@ One entry point, two resolution depths. Quick mode is **additive**: a second res
 - **quick** — `$mode: quick` is the explicit opt-in signal. Bootstrap **asks no questions** for any decision that has a safe default, so an empty repository reaches a **first workable story** in minutes rather than a full interview.
 - **The resolution is the convention's, not bootstrap's.** Defaults resolve through the convention's cascade (explicit argument > project state > saved preferences > hardcoded fallback). Bootstrap declares only its per-adopter delta — which decision points are defaultable, which tier fills each, which are still asked — in [quick-mode-defaults.md](quick-mode-defaults.md). There is **no bespoke** Quickstart resolution order.
 - **Not every question disappears.** Decisions with no safe KB default (PM tool; tech stack on a genuinely empty repo) are still asked in quick mode — see [quick-mode-defaults.md](quick-mode-defaults.md).
+- **A populated PRD is a precondition, not a default.** Phase 0 is BLOCKING and identical in both depths: a missing or template PRD composes `/specify-prd`, an interactive authoring session. That session is **outside** the quick-mode question budget and outside the minutes-scale claim — quick mode reaches a first workable story in minutes *from a populated PRD*. On a repo with no PRD, author it first (or expect the PRD interview before quick mode's own path starts).
 - **Non-interactive safety**: guided needs a TTY. With no TTY (CI, piped stdin) guided can never run — bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
 - **Already configured**: identical in both depths — every phase checks its own output first and confirms rather than overwriting.
 
@@ -126,6 +127,8 @@ One entry point, two resolution depths. Quick mode is **additive**: a second res
 
 4. **Verify**: Assessment data collected (via skills or manually) and persisted via `/record-decision`. All adoption files written from assess-\* proposals are consistent.
 
+**Quick mode**: composed assess-\* skills must be invoked with their own quick signal — the resolution cascade's **Path A `$choice`**, resolved from project state — never plain, because the assess-\* family's declared default is guided (Path C, the full interview). A domain project state cannot resolve falls back to the per-project-type default named in [quick-mode-defaults.md](quick-mode-defaults.md); the tech stack on a genuinely empty repo is the one exception and is still asked (Step 2.3). The manual-assessment path (item 3) asks nothing either — it takes the same defaults and reports them.
+
 ### Step 2.3: Gather Information per Section
 
 For each missing adoption file, work through the relevant checklist section. Reference the [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md) for section-specific questions.
@@ -136,10 +139,10 @@ For each missing adoption file, work through the relevant checklist section. Ref
 2. **Tech Stack** — languages, frameworks, libraries with versions
    - Reference: [Technical Standards](../../../.pair/knowledge/guidelines/technical-standards/README.md)
 
-3. **Infrastructure** — deployment, CI/CD, monitoring, environments
+3. *`Infrastructure`* — deployment, CI/CD, monitoring, environments
    - Reference: [Infrastructure Guidelines](../../../.pair/knowledge/guidelines/infrastructure/README.md)
 
-4. **UX/UI** — design system, accessibility, device support
+4. *`UX/UI`* — design system, accessibility, device support
    - Reference: [UX Guidelines](../../../.pair/knowledge/guidelines/user-experience/README.md)
 
 5. **Way of Working** — processes, quality gates, release cycles
@@ -151,7 +154,7 @@ For each missing adoption file, work through the relevant checklist section. Ref
 - Wait for developer responses before proceeding
 - Record each significant decision via `/record-decision` (`non-architectural` → ADL, `architectural` → ADR)
 
-**Quick mode**: no section questions — each section is filled from the project-type defaults in [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md), with the same `/record-decision` calls. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked ([quick-mode-defaults.md](quick-mode-defaults.md)).
+**Quick mode**: no section questions — each section is filled from one named KB anchor, [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md) § `Quick-Mode Per-Project-Type Defaults` (plus § `Decision Framework` for the core architectural pattern), with the same `/record-decision` calls. The § `Context-Specific Examples` are worked examples of already-decided projects — **never** a default source. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked; the table has no stack row by design ([quick-mode-defaults.md](quick-mode-defaults.md)).
 
 ## Phase 3: Standards Generation
 
@@ -170,6 +173,8 @@ For each missing adoption file (in order: architecture → tech-stack → infras
 5. **Act**: Save to [adoption/tech/](../../../.pair/adoption/tech)`<filename>.md`.
 6. **Verify**: File written, consistent with other adoption files.
 
+**Quick mode**: steps 3 and 4 are skipped for **every** document — no per-document presentation, no approval round, no iteration loop. Documents are generated, written and then reported once in the Step 4.3 summary; steps 1, 2, 5 and 6 are identical in both depths ([quick-mode-defaults.md](quick-mode-defaults.md)).
+
 ### Step 3.2: Quality Gate Setup
 
 1. **Check**: Does [adoption/tech/way-of-working.md](../../../.pair/adoption/tech/way-of-working.md) already contain a Custom Gate Registry with entries?
@@ -273,9 +278,9 @@ BOOTSTRAP COMPLETE:
 ## HALT Conditions
 
 - **PRD missing or template and /specify-prd fails** (Phase 0) — cannot bootstrap without product context
-- **Project categorization rejected** (Phase 1) — developer must confirm before technical decisions
+- **Project categorization rejected** (Phase 1, **guided only**) — developer must confirm before technical decisions; quick mode derives the type from PRD signals and records it without a confirmation round
 - **Critical technical decision unresolved** (Phase 2) — cannot generate adoption files with gaps
-- **Adoption file generation rejected** (Phase 3) — each document needs developer approval
+- **Adoption file generation rejected** (Phase 3, **guided only**) — each document needs developer approval in the guided depth; quick mode writes without an approval round (Step 3.1), so this condition cannot arise there
 - **Non-defaultable input unresolvable in quick mode** (Step 2.3, Step 4.2) — a decision with no safe KB default (PM tool, undetectable tech stack) that cannot be resolved from the cascade and cannot be asked (no TTY); report which input to pass explicitly, never guess it
 
 On HALT: report the blocker clearly, propose resolution, wait for developer.
diff --git a/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md b/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
index 3e722a57..94ac7ecb 100644
--- a/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
+++ b/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
@@ -8,6 +8,7 @@ Disclosed from [SKILL.md](SKILL.md) — the `$mode` selector and its two resolut
 
 - `guided` — bootstrap's declared default. Absent `$mode`, the full interview runs unchanged.
 - `quick` — the explicit opt-in signal. No interview: every defaultable decision is resolved from the cascade instead of asked.
+- **`guided` is also accepted explicitly — a documented deviation.** The convention fixes the selector's **minimum** (an explicit signal must select the non-default depth) and says nothing about naming the default; bootstrap accepts `$mode: guided` as a loud no-op so a script or a handoff can make the depth visible at the call site. It resolves to exactly the same behaviour as an omitted `$mode`.
 - No TTY (CI, piped stdin) is an explicit environment fact and outranks the depth preference: guided can never run there. Bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
 
 ## Cascade tiers, as bootstrap fills them
@@ -17,19 +18,23 @@ The convention's precedence, highest wins, with bootstrap's source named per tie
 | Tier (convention)             | What fills it in bootstrap                                                                                     |
 | ----------------------------- | -------------------------------------------------------------------------------------------------------------- |
 | explicit argument             | `$mode`, plus any value the invocation names outright (e.g. the PM tool)                                        |
-| project state                 | what is already on disk: `.pair/adoption/**`, the PRD, `package.json` and lockfiles, CI workflows, `git config` |
-| saved or inferred preferences | decisions a previous run recorded — the ADLs/ADRs in `.pair/adoption/decision-log/`                             |
-| hardcoded fallback            | the per-project-type defaults in `bootstrap-checklist.md` — a KB value, never one invented here                 |
+| project state                 | what is already on disk **excluding** `.pair/adoption/decision-log/` (that is the tier below): `.pair/adoption/tech/**`, `.pair/adoption/product/**`, the PRD, `package.json` and lockfiles, config files, CI workflows, `git config` |
+| saved or inferred preferences | what a previous run recorded as a decision rather than as adopted state — the ADLs/ADRs in `.pair/adoption/decision-log/`. A decision-log entry whose value never reached an adoption file is still honoured here, and loses to the adoption file when both exist |
+| hardcoded fallback            | `bootstrap-checklist.md` § `Quick-Mode Per-Project-Type Defaults` (and § `Architecture Foundation Assessment → Decision Framework` for the core architectural pattern) — a KB value, never one invented here, and **never** read from § `Context-Specific Examples`, which are worked examples of already-decided projects |
 
 ## Per-decision resolution
 
 | Phase / step | Decision point                                                       | Quick mode                                                                                                     | Tier              |
 | ------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------- |
-| Phase 0      | PRD present and populated                                            | never defaulted — composes `/specify-prd` when missing, HALTs if the PRD is still absent                        | project state     |
+| Phase 0      | PRD present and populated                                            | **never defaulted, and a precondition of the minutes-scale claim** — a populated PRD is read; a missing or template PRD composes `/specify-prd`, an interactive authoring session outside quick mode's question budget (see `Still asked`). HALTs if the PRD is still absent | project state     |
 | Step 1.2     | project categorization (Type A/B/C)                                  | derived from PRD signals (team size, budget, compliance) and recorded, not confirmed                            | project state     |
-| Step 2.2     | which `assess-*` skills run                                          | installed ones run with their own quick signal (Path A `$choice`) where project state resolves the choice       | project state     |
-| Step 2.3     | per-section questions (architecture, stack, infrastructure, ux-ui, way-of-working) | not asked — each section is filled from the project-type defaults, except an undetectable stack (still asked)   | fallback          |
-| Step 3.1     | adoption documents                                                   | generated and written without the per-document approval round                                                  | fallback          |
+| Step 2.2     | which `assess-*` skills run, and how                                 | installed ones are composed **with** their quick signal (Path A `$choice`), never plain — the family's declared default is guided (Path C). Project state fills `$choice` where it can; otherwise the per-type fallback row below does | project state     |
+| Step 2.3     | architecture section (core pattern, style, data)                     | not asked — `bootstrap-checklist.md` § `Decision Framework` (core pattern) + § `Quick-Mode Per-Project-Type Defaults` rows `Architecture — style` / `— data` | fallback          |
+| Step 2.3     | tech stack section                                                   | read from project state (`package.json`, lockfiles, config files); **still asked** on an empty repo — the fallback table has no stack row by design | project state     |
+| Step 2.3     | infrastructure + observability sections                              | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Infrastructure` / `Observability`                    | fallback          |
+| Step 2.3     | ux-ui section                                                        | not asked — § `Quick-Mode Per-Project-Type Defaults` row `UX/UI`                                               | fallback          |
+| Step 2.3     | way-of-working section (flow, branching, release)                    | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Way of Working — …`. The PM tool is excluded from this row and still asked (Step 4.2) | fallback          |
+| Step 3.1     | adoption documents                                                   | generated and written without the per-document presentation or approval round, for every document (Step 3.1 items 3-4 skipped) | fallback          |
 | Step 3.2     | quality gate setup                                                   | standard pipeline only (type check, test, lint, format), no custom gates — same registry entries guided writes  | fallback          |
 | Phase 3.5    | domain model (subdomains, bounded contexts)                          | runs when `/map-subdomains` / `/map-contexts` are installed, skipped with a warning otherwise — never blocking  | project state     |
 | Step 4.2     | PM tool                                                              | **still asked** unless project state already names one (see below)                                              | explicit argument |
@@ -41,8 +46,9 @@ Quick mode reduces the questions to the genuinely-defaultable ones; it does not
 
 - **PM tool** (Step 4.2) — the choice is organisational, not technical, so no KB value is safe: a wrong guess wires up a tracker nobody uses. Project state resolves it when `way-of-working.md` already names one; otherwise `/setup-pm` is composed and asks that single question.
 - **Tech stack when undetectable** (Step 2.3) — normally read from project state (`package.json`, lockfiles, config files). On a genuinely empty repository there is nothing to read and no universally-correct default, so quick mode asks rather than guessing.
+- **The PRD, when absent** (Phase 0) — not a bootstrap question but a whole composed session: `/specify-prd` authors it interactively and iterates to approval. Phase 0 is BLOCKING and identical in both depths, so **a populated PRD is a precondition of the minutes-scale claim**, not something quick mode defaults. Measure or plan quick mode from a project that already has one; on a repo without one, expect the PRD session first.
 
-Everything else in the table above resolves without a question. If one of these two can neither be resolved from the cascade nor asked (quick mode with no TTY), bootstrap HALTs and names the input to pass explicitly — see SKILL.md.
+Everything else in the table above resolves without a question **once the PRD exists**. If one of the two still-asked decisions can neither be resolved from the cascade nor asked (quick mode with no TTY), bootstrap HALTs and names the input to pass explicitly — see SKILL.md.
 
 ## Same files, same format as guided (AC4)
 
diff --git a/packages/knowledge-hub/src/conformance/bootstrap.test.ts b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
index e144429f..c5ed37f5 100644
--- a/packages/knowledge-hub/src/conformance/bootstrap.test.ts
+++ b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
@@ -135,6 +135,149 @@ describe('quick mode composes the Guided/Quick Setup Convention (AC3)', () => {
   })
 })
 
+/**
+ * Split SKILL.md into `### Step x.y` sections (heading + body up to the next
+ * `##`/`###` heading), so a quick-mode note can be asserted WHERE it belongs
+ * rather than anywhere in the file.
+ */
+const stepSections = (skill: string): Map<string, string> => {
+  const out = new Map<string, string>()
+  const lines = skill.split('\n')
+  let current: string | null = null
+  let buf: string[] = []
+  const flush = (): void => {
+    if (current) out.set(current, buf.join('\n'))
+  }
+  for (const line of lines) {
+    const m = /^###\s+Step\s+([0-9.]+):/.exec(line)
+    if (m) {
+      flush()
+      current = m[1].replace(/\.$/, '')
+      buf = [line]
+      continue
+    }
+    if (/^##\s/.test(line)) {
+      flush()
+      current = null
+      buf = []
+      continue
+    }
+    if (current) buf.push(line)
+  }
+  flush()
+  return out
+}
+
+// A step is question-bearing if its own text interviews the developer: a
+// blockquote line ending in a question, an explicit "ask N questions" rule, or
+// a present-and-approve round. Those are exactly the steps quick mode has to
+// say something about — and the derivation makes a FUTURE interview step fail
+// this guard unless its author adds the note too.
+const INTERVIEW_MARKERS = [
+  /^\s*>.*\?\s*$/m,
+  /Ask \d+(-\d+)? focused questions/i,
+  /for developer review/i,
+  /until approved/i,
+]
+
+describe('quick mode is declared where the questions are (AC1)', () => {
+  const sections = stepSections(datasetSkill())
+
+  it('finds the guided step sections it is supposed to check', () => {
+    for (const step of ['1.2', '2.2', '2.3', '3.1', '3.2', '4.2', '4.3']) {
+      expect(sections.has(step), `Step ${step} section not found`).toBe(true)
+    }
+  })
+
+  it('carries a `**Quick mode**:` note in EVERY question-bearing step', () => {
+    const missing: string[] = []
+    for (const [step, body] of sections) {
+      const interviews = INTERVIEW_MARKERS.some(re => re.test(body))
+      if (interviews && !/\*\*Quick mode\*\*/.test(body)) missing.push(step)
+    }
+    expect(
+      missing,
+      `question-bearing steps with no quick-mode note: ${missing.join(', ')}`,
+    ).toEqual([])
+  })
+
+  it('covers the composed-assessment and finalization steps too (2.2, 4.2, 4.3)', () => {
+    for (const step of ['2.2', '4.2', '4.3']) {
+      expect(sections.get(step), `Step ${step}`).toMatch(/\*\*Quick mode\*\*/)
+    }
+  })
+
+  it('tells composed assess-* skills to use their own quick signal (Path A $choice)', () => {
+    // the assess-* family's declared default is GUIDED, so plain composition
+    // would interview once per installed skill.
+    expect(sections.get('2.2')).toMatch(/\$choice/)
+    expect(sections.get('2.2')?.toLowerCase()).toMatch(/path a/)
+  })
+
+  it('qualifies the approval-round HALT conditions as guided-only', () => {
+    const halt = datasetSkill().split('## HALT Conditions')[1] ?? ''
+    expect(halt).toMatch(/Adoption file generation rejected[^\n]*guided only/i)
+    expect(halt).toMatch(/Project categorization rejected[^\n]*guided only/i)
+  })
+})
+
+describe('the fallback tier points at a KB anchor that exists (AC3)', () => {
+  const CHECKLIST_REL = '.pair/knowledge/assets/bootstrap-checklist.md'
+  const ANCHOR = '## Quick-Mode Per-Project-Type Defaults'
+
+  it('bootstrap-checklist.md carries the per-project-type defaults table, in both copies', () => {
+    for (const p of [join(ROOT, CHECKLIST_REL), join(__dirname, '../../dataset', CHECKLIST_REL)]) {
+      const c = read(p)
+      expect(c).toContain(ANCHOR)
+      // one column per project type, and the rows quick mode resolves from
+      expect(c).toMatch(/Type A[^|]*\|[^|]*Type B[^|]*\|[^|]*Type C/)
+      for (const row of ['Architecture — style', 'Infrastructure —', 'UX/UI', 'Way of Working —']) {
+        expect(c, `${p}: missing fallback row ${row}`).toContain(row)
+      }
+      // and it must NOT invent the two non-defaultable ones
+      expect(c).toMatch(/Deliberately absent from this table/)
+    }
+  })
+
+  it('names that anchor as the fallback source instead of the asset as a whole', () => {
+    const c = `${datasetSkill()}\n${datasetDefaults()}`
+    expect(c).toContain('Quick-Mode Per-Project-Type Defaults')
+    // the worked examples are explicitly ruled out as a default source
+    expect(c).toMatch(/Context-Specific Examples/)
+  })
+
+  it('keeps the cascade tiers disjoint — decision-log belongs to preferences only', () => {
+    const defaults = datasetDefaults()
+    expect(defaults).toMatch(/excluding[^|]*decision-log/i)
+  })
+})
+
+describe('the PRD is a precondition, not a quick-mode default (AC1)', () => {
+  it('SKILL.md and the defaults doc both say so', () => {
+    for (const c of [datasetSkill(), datasetDefaults()]) {
+      expect(c.toLowerCase()).toMatch(/precondition/)
+      expect(c).toMatch(/PRD/)
+    }
+  })
+
+  it('the timed critical path authors the PRD outside the stopwatch', () => {
+    const cp = read(join(ROOT, 'qa/release-validation/CP9-quickstart-onboarding.md'))
+    expect(cp).toMatch(/outside\s+the\s+stopwatch/i)
+    expect(cp).toMatch(/PRD/)
+    // two splits, so a slow run names the phase that caused it
+    expect(cp.toLowerCase()).toMatch(/bootstrap-elapsed/)
+    expect(cp.toLowerCase()).toMatch(/story-elapsed/)
+  })
+
+  it('the docs page states the same precondition', () => {
+    const doc = read(
+      join(ROOT, 'apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx'),
+    )
+    expect(doc.toLowerCase()).toMatch(/precondition/)
+    expect(doc).toMatch(/PRD/)
+  })
+})
+
 describe('per-decision defaultability — T1 (AC1/AC4)', () => {
   const c = (): string => datasetDefaults()
 
@@ -274,4 +417,22 @@ describe('timed onboarding scenario + docs (AC1, DoD)', () => {
     const meta = read(join(ROOT, 'apps/website/content/docs/getting-started/meta.json'))
     expect(meta).toContain('bootstrap-quick-mode')
   })
+
+  // landing.e2e.test.ts walks Quickstart's footer `next` link and asserts it
+  // lands on Quickstart: Solo. Inserting a page BETWEEN them would still pass
+  // that test (its locator resolves the sidebar link) while silently voiding
+  // the prev/next guarantee it exists to check — so pin the order here, in the
+  // local gate, where e2e ordering is not otherwise observable.
+  it('sits after the quickstart-{solo,team,org} trio in nav order', () => {
+    const pages: string[] = JSON.parse(
+      read(join(ROOT, 'apps/website/content/docs/getting-started/meta.json')),
+    ).pages
+    expect(pages[pages.indexOf('quickstart') + 1]).toBe('quickstart-solo')
+    expect(pages.indexOf('bootstrap-quick-mode')).toBeGreaterThan(pages.indexOf('quickstart-org'))
+  })
+
+  it('is cross-linked from the Getting Started index (DoD)', () => {
+    const index = read(join(ROOT, 'apps/website/content/docs/getting-started/index.mdx'))
+    expect(index).toContain('/docs/getting-started/bootstrap-quick-mode')
+  })
 })
diff --git a/qa/release-validation/CP5-website-docs-completeness.md b/qa/release-validation/CP5-website-docs-completeness.md
index 03416215..821d2d82 100644
--- a/qa/release-validation/CP5-website-docs-completeness.md
+++ b/qa/release-validation/CP5-website-docs-completeness.md
@@ -19,10 +19,10 @@
 **Getting Started** (7 pages):
 - `$BASE_URL/docs/getting-started`
 - `$BASE_URL/docs/getting-started/quickstart`
-- `$BASE_URL/docs/getting-started/bootstrap-quick-mode`
 - `$BASE_URL/docs/getting-started/quickstart-solo`
 - `$BASE_URL/docs/getting-started/quickstart-team`
 - `$BASE_URL/docs/getting-started/quickstart-org`
+- `$BASE_URL/docs/getting-started/bootstrap-quick-mode`
 - `$BASE_URL/docs/getting-started/checklist`
 
 **Concepts** (7 pages):
@@ -143,3 +143,9 @@
 
 - Title contains "Welcome" or equivalent
 - Has navigation or links to major doc sections
+
+---
+
+## Changelog
+
+- #278 (bootstrap quick mode): MT-CP501 page count 60 → 61, Getting Started 6 → 7 — added `/docs/getting-started/bootstrap-quick-mode`.
diff --git a/qa/release-validation/CP9-quickstart-onboarding.md b/qa/release-validation/CP9-quickstart-onboarding.md
index 6d87d64d..0446a216 100644
--- a/qa/release-validation/CP9-quickstart-onboarding.md
+++ b/qa/release-validation/CP9-quickstart-onboarding.md
@@ -1,8 +1,8 @@
 # CP9 — Quickstart Onboarding (timed)
 
 **Priority**: P1
-**Scope**: `/pair-process-bootstrap $mode: quick` — an empty project reaches a first workable story in under 10 minutes, and the guided depth still behaves as before
-**Preconditions**: Working CLI binary (from CP2), `$CLI` = path to that binary. `$WORKDIR` created outside the repo. An AI assistant session with the pair skills installed (`.claude/skills/`), able to run `/pair-process-bootstrap`.
+**Scope**: `/pair-process-bootstrap $mode: quick` — a project with a PRD but no adoption files reaches a first workable story in under 10 minutes, and the guided depth still behaves as before
+**Preconditions**: Working CLI binary (from CP2), `$CLI` = path to that binary. `$WORKDIR` created outside the repo. An AI assistant session with the pair skills installed (`.claude/skills/`), able to run `/pair-process-bootstrap`. **A populated `.pair/adoption/product/PRD.md` in the project under test** — authored in MT-CP902, deliberately **outside** the stopwatch: bootstrap Phase 0 is blocking in both depths and composes the interactive `/pair-process-specify-prd` when the PRD is missing or still a template, which is a PRD-authoring session, not a bootstrap question.
 
 **Why timed**: the quick depth exists to make the time-to-first-story short enough to be measured. The target is the acceptance criterion, so it is asserted here rather than assumed.
 
@@ -10,17 +10,27 @@
 
 ## Variables
 
-| Variable   | How to resolve                                                                   |
-| ---------- | -------------------------------------------------------------------------------- |
-| `$WORKDIR` | Temp directory **outside** the repo: `mktemp -d /tmp/pair-quickstart-test.XXXXX` |
-| `$CLI`     | Path to the working `pair-cli` binary under test (from CP2)                       |
-| `$T0`      | Stopwatch start, captured as `date +%s` immediately before MT-CP902 step 1        |
+| Variable   | How to resolve                                                                    |
+| ---------- | --------------------------------------------------------------------------------- |
+| `$WORKDIR` | Temp directory **outside** the repo: `mktemp -d /tmp/pair-quickstart-test.XXXXX`  |
+| `$CLI`     | Path to the working `pair-cli` binary under test (from CP2)                        |
+| `$T0`      | Stopwatch start, captured as `date +%s` immediately before MT-CP903 step 1         |
+| `$T1`      | Split: captured when bootstrap reports `BOOTSTRAP COMPLETE` (**bootstrap-elapsed**) |
+| `$T2`      | Stop: captured when the first workable story exists (**story-elapsed** = `T2 - T1`) |
 
-**Stopwatch protocol** — the elapsed time must be measured, never estimated:
+**Stopwatch protocol** — the elapsed time must be measured, never estimated, and is recorded as **two splits** so a slow run points at the phase that caused it:
 
 1. Before the timed step: `T0=$(date +%s)`
-2. After the timed step: `T1=$(date +%s); echo "elapsed: $(( (T1 - T0) / 60 ))m $(( (T1 - T0) % 60 ))s"`
-3. Record the printed elapsed value in the report. Human think-time counts — this measures onboarding, not machine speed.
+2. At `BOOTSTRAP COMPLETE`: `T1=$(date +%s)`
+3. When the first story exists: `T2=$(date +%s)`
+4. Report both splits and the total:
+
+   ```bash
+   fmt() { echo "$(( $1 / 60 ))m $(( $1 % 60 ))s"; }
+   echo "bootstrap: $(fmt $((T1 - T0))) · story: $(fmt $((T2 - T1))) · total: $(fmt $((T2 - T0)))"
+   ```
+
+5. Record all three values in the report. Human think-time counts — this measures onboarding, not machine speed.
 
 ---
 
@@ -44,39 +54,62 @@
 
 ---
 
-## MT-CP902: Quick mode reaches a first workable story in under 10 minutes
+## MT-CP902: PRD authored — outside the stopwatch
 
 **Priority**: P1
 **Preconditions**: MT-CP901 passes
 **Category**: Onboarding
-**Target**: under 10 min elapsed, wall-clock
+
+### Steps
+
+1. In the AI session rooted at `$WORKDIR/quickstart`, run `/pair-process-specify-prd` and author a small PRD (a one-page product is enough: users, constraints, three P0 features)
+2. `grep -c "\[Product/feature name\]" .pair/adoption/product/PRD.md` — expect `0`
+
+### Expected Result
+
+- `.pair/adoption/product/PRD.md` exists and is populated (no template placeholders left)
+- The PRD session is **not** timed and **not** counted as a bootstrap question: Phase 0 is identical in both depths, and a populated PRD is the documented precondition of the minutes-scale claim (`quick-mode-defaults.md` § Still asked in quick mode)
+
+### Notes
+
+- Skipping this test and starting MT-CP903 on a template PRD is a **different** scenario: bootstrap will correctly compose the PRD interview inside the measured window, and the measurement is then meaningless for AC1.
+
+---
+
+## MT-CP903: Quick mode reaches a first workable story in under 10 minutes
+
+**Priority**: P1
+**Preconditions**: MT-CP902 passes
+**Category**: Onboarding
+**Target**: under 10 min elapsed total, wall-clock, split into bootstrap-elapsed + story-elapsed
 
 ### Steps
 
 1. `T0=$(date +%s)` — start the stopwatch
 2. In the AI session rooted at `$WORKDIR/quickstart`, run `/pair-process-bootstrap $mode: quick`
-3. Answer only the questions the skill actually asks. Per `quick-mode-defaults.md` these are at most two: the PM tool, and the tech stack if it cannot be detected. Answer them immediately — deliberating is out of scope for the measurement
-4. When bootstrap reports `BOOTSTRAP COMPLETE`, run `/pair-next` and follow its suggestion until one user story exists in the tracker
-5. `T1=$(date +%s); echo "elapsed: $(( (T1 - T0) / 60 ))m $(( (T1 - T0) % 60 ))s"`
+3. Answer only the questions bootstrap actually asks. Per `quick-mode-defaults.md` these are at most two: the PM tool, and the tech stack if it cannot be detected. Answer them immediately — deliberating is out of scope for the measurement
+4. When bootstrap reports `BOOTSTRAP COMPLETE`: `T1=$(date +%s)` — bootstrap split
+5. Run `/pair-next` and follow its suggestion until one user story with acceptance criteria exists in the tracker. This routes through the planning and refinement skills (`/pair-process-plan-*`, `/pair-process-refine-story`), which **are interactive by design** — their turns are expected here and are counted in story-elapsed
+6. `T2=$(date +%s)` and print the two splits + total (see the stopwatch protocol)
 
 ### Expected Result
 
-- Elapsed under **10 min**
-- Bootstrap asked **no** question outside the two still-asked decisions above (no categorization confirmation, no per-section interview, no per-document approval round, no custom-gate question)
+- Total elapsed under **10 min**, with both splits recorded
+- **Bootstrap asked no question outside the two still-asked decisions** — no categorization confirmation, no per-section interview, no per-document approval round, no custom-gate question. This assertion is scoped to bootstrap (the `T0 → T1` window); the planning/refinement turns in step 5 are interactive and not covered by it
 - The completion summary reports `Mode: quick — N questions asked` with `N` matching what was actually asked
 - `.pair/adoption/tech/architecture.md`, `tech-stack.md` and `way-of-working.md` are populated
 - One user story exists and is workable (it has acceptance criteria, so `/pair-process-implement` can start on it)
 
 ### Notes
 
-- If the run exceeds the target, record which step consumed the time — the failure is only meaningful with the breakdown.
+- If the run exceeds the target, the two splits are the report: which of bootstrap or story-authoring consumed the time. A failure without the breakdown is not actionable.
 
 ---
 
-## MT-CP903: Every file quick mode wrote is a normal adoption file
+## MT-CP904: Every file quick mode wrote is a normal adoption file
 
 **Priority**: P1
-**Preconditions**: MT-CP902 passes
+**Preconditions**: MT-CP903 passes
 **Category**: Onboarding
 
 ### Steps
@@ -94,7 +127,7 @@
 
 ---
 
-## MT-CP904: Guided remains the default — no regression
+## MT-CP905: Guided remains the default — no regression
 
 **Priority**: P1
 **Preconditions**: MT-CP901 passes, in a **second** clean project
@@ -103,14 +136,16 @@
 ### Steps
 
 1. `mkdir -p $WORKDIR/guided && cd $WORKDIR/guided && git init && $CLI install`
-2. In the AI session rooted at `$WORKDIR/guided`, run `/pair-process-bootstrap` with **no** `$mode` argument
-3. Observe the first three interactions
+2. Author a PRD as in MT-CP902 (so Phase 0 is satisfied and the comparison is apples-to-apples)
+3. In the AI session rooted at `$WORKDIR/guided`, run `/pair-process-bootstrap` with **no** `$mode` argument
+4. Observe the first three interactions
 
 ### Expected Result
 
-- The **guided** interview runs: Phase 0 PRD verification, then the Step 1.2 categorization confirmation question, then the Step 2.3 per-section questions
+- The **guided** interview runs: Phase 0 PRD verification (skipped as already populated), then the Step 1.2 categorization confirmation question, then the Step 2.3 per-section questions
 - The skill asks rather than assuming — an omitted `$mode` behaves exactly as it did before quick mode existed
 - The completion summary reports `Mode: guided (default)`
+- Running `/pair-process-bootstrap $mode: guided` explicitly is accepted and behaves identically to the omitted argument (the documented loud no-op)
 
 ### Notes
 
@@ -118,7 +153,7 @@
 
 ---
 
-## MT-CP905: No TTY can never hang
+## MT-CP906: No TTY can never hang
 
 **Priority**: P2
 **Preconditions**: MT-CP901 passes
@@ -139,4 +174,5 @@
 
 ## Changelog
 
-- Added for #278 (bootstrap quick mode): MT-CP901..905.
+- Added for #278 (bootstrap quick mode): MT-CP901..906.
+- Review round 1 (#408): added MT-CP902 (PRD authored outside the stopwatch) — the PRD is a third question-generating input, not a quick-mode default; the timed test is now MT-CP903 with a bootstrap/story split, and its "no question" assertion is scoped to the bootstrap window.

From 01f964f024f0b0d564bca420d7169b6235adcb39 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 12:55:08 +0200
Subject: [PATCH 12/13] =?UTF-8?q?[US-278]=20fix:=20review=20round=202=20?=
 =?UTF-8?q?=E2=80=94=20quick=20mode=20asks=20nothing,=20incl.=20Path=20A?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Path A is $choice + a confirmation round; 8 composed assess-* skills would
mean up to 8 questions inside a depth that claims none. Quick mode now
suppresses that round, disclosed as a per-adopter deviation beside the
explicit-guided no-op, asserted in conformance and in CP9 MT-CP903.

Also: testing + AI sections of tech-stack.md get fallback rows (they are
separate assess-* invocations); Step 2.3 list back to uniform bold;
MT-CP906 gets its own project + PRD setup; interview markers now catch
Step 4.3's own approval phrasing; ADL emphasis + checklist emphasis churn
reverted to underscores (24 lines, both corpora).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../skills/pair-process-bootstrap/SKILL.md    |  8 +--
 .../quick-mode-defaults.md                    | 15 ++++-
 ...-bootstrap-quick-is-a-depth-not-a-skill.md |  6 +-
 .pair/knowledge/assets/bootstrap-checklist.md | 42 ++++++------
 .../getting-started/bootstrap-quick-mode.mdx  |  4 +-
 .../knowledge/assets/bootstrap-checklist.md   | 42 ++++++------
 .../.skills/process/bootstrap/SKILL.md        |  8 +--
 .../process/bootstrap/quick-mode-defaults.md  | 15 ++++-
 .../src/conformance/bootstrap.test.ts         | 66 ++++++++++++++++++-
 .../CP9-quickstart-onboarding.md              | 13 +++-
 10 files changed, 158 insertions(+), 61 deletions(-)

diff --git a/.claude/skills/pair-process-bootstrap/SKILL.md b/.claude/skills/pair-process-bootstrap/SKILL.md
index 0a6977f6..bf2a3f02 100644
--- a/.claude/skills/pair-process-bootstrap/SKILL.md
+++ b/.claude/skills/pair-process-bootstrap/SKILL.md
@@ -127,7 +127,7 @@ One entry point, two resolution depths. Quick mode is **additive**: a second res
 
 4. **Verify**: Assessment data collected (via skills or manually) and persisted via `/pair-capability-record-decision`. All adoption files written from assess-\* proposals are consistent.
 
-**Quick mode**: composed assess-\* skills must be invoked with their own quick signal — the resolution cascade's **Path A `$choice`**, resolved from project state — never plain, because the assess-\* family's declared default is guided (Path C, the full interview). A domain project state cannot resolve falls back to the per-project-type default named in [quick-mode-defaults.md](./quick-mode-defaults.md); the tech stack on a genuinely empty repo is the one exception and is still asked (Step 2.3). The manual-assessment path (item 3) asks nothing either — it takes the same defaults and reports them.
+**Quick mode**: composed assess-\* skills must be invoked with their own quick signal — the resolution cascade's **Path A `$choice`**, resolved from project state — never plain, because the assess-\* family's declared default is guided (Path C, the full interview). **Path A's confirmation round is not run here**: the [resolution cascade](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/resolution-cascade.md) Path A steps 3-4 ask the developer to confirm the override, and each assess-\* skill declares its own prompt for it — eight composed skills would emit up to eight confirmations inside a depth that asks nothing. In quick mode the resolved `$choice` is accepted as-is and reported once in the Step 4.3 summary. This is a **disclosed per-adopter deviation**, like the explicit-`guided` no-op above; see [quick-mode-defaults.md](./quick-mode-defaults.md) § Disclosed deviations. A domain project state cannot resolve falls back to the per-project-type default named in [quick-mode-defaults.md](./quick-mode-defaults.md); the tech stack on a genuinely empty repo is the one exception and is still asked (Step 2.3). The manual-assessment path (item 3) asks nothing either — it takes the same defaults and reports them.
 
 ### Step 2.3: Gather Information per Section
 
@@ -139,10 +139,10 @@ For each missing adoption file, work through the relevant checklist section. Ref
 2. **Tech Stack** — languages, frameworks, libraries with versions
    - Reference: [Technical Standards](../../../.pair/knowledge/guidelines/technical-standards/README.md)
 
-3. *`Infrastructure`* — deployment, CI/CD, monitoring, environments
+3. **Infrastructure** — deployment, CI/CD, monitoring, environments
    - Reference: [Infrastructure Guidelines](../../../.pair/knowledge/guidelines/infrastructure/README.md)
 
-4. *`UX/UI`* — design system, accessibility, device support
+4. **UX/UI** — design system, accessibility, device support
    - Reference: [UX Guidelines](../../../.pair/knowledge/guidelines/user-experience/README.md)
 
 5. **Way of Working** — processes, quality gates, release cycles
@@ -154,7 +154,7 @@ For each missing adoption file, work through the relevant checklist section. Ref
 - Wait for developer responses before proceeding
 - Record each significant decision via `/pair-capability-record-decision` (`non-architectural` → ADL, `architectural` → ADR)
 
-**Quick mode**: no section questions — each section is filled from one named KB anchor, [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md) § `Quick-Mode Per-Project-Type Defaults` (plus § `Decision Framework` for the core architectural pattern), with the same `/pair-capability-record-decision` calls. The § `Context-Specific Examples` are worked examples of already-decided projects — **never** a default source. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked; the table has no stack row by design ([quick-mode-defaults.md](./quick-mode-defaults.md)).
+**Quick mode**: no section questions — each section is filled from one named KB anchor, [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md) § `Quick-Mode Per-Project-Type Defaults` (plus § `Decision Framework` for the core architectural pattern), with the same `/pair-capability-record-decision` calls. The § `Context-Specific Examples` are worked examples of already-decided projects — **never** a default source. The **testing** and **AI** sub-sections of `tech-stack.md` (separate assess-\* invocations — see [assess-orchestration.md](./assess-orchestration.md)) have their own rows in the same table; the test runner and the assistant follow from the resolved stack and project state, the strategy values from the table. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked; the table has no stack row by design ([quick-mode-defaults.md](./quick-mode-defaults.md)).
 
 ## Phase 3: Standards Generation
 
diff --git a/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md b/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
index 2b8875ff..516ed26d 100644
--- a/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
+++ b/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
@@ -11,6 +11,13 @@ Disclosed from [SKILL.md](./SKILL.md) — the `$mode` selector and its two resol
 - **`guided` is also accepted explicitly — a documented deviation.** The convention fixes the selector's **minimum** (an explicit signal must select the non-default depth) and says nothing about naming the default; bootstrap accepts `$mode: guided` as a loud no-op so a script or a handoff can make the depth visible at the call site. It resolves to exactly the same behaviour as an omitted `$mode`.
 - No TTY (CI, piped stdin) is an explicit environment fact and outranks the depth preference: guided can never run there. Bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
 
+## Disclosed deviations
+
+Two, both deliberate and both scoped to bootstrap. They are listed here rather than left implicit because the conventions they deviate from are shared.
+
+1. **`$mode: guided` is accepted as a loud no-op** — see § Selector above. The convention fixes only that an explicit signal must select the **non-default** depth; naming the default is bootstrap's addition.
+2. **In quick mode, Path A's confirmation round is not run on composed `assess-*` skills.** The [resolution cascade](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/resolution-cascade.md) defines Path A as `$choice` **plus** a confirmation round (steps 3-4: "Confirm the override with the developer" / "Developer confirms"), and each assess-\* skill declares its own prompt for it. Bootstrap sequences up to eight of them (`assess-orchestration.md`), so running that round would emit up to eight questions inside a depth whose whole point is asking none — and no assess-\* skill currently has a non-interactive signal of its own. Quick mode therefore accepts each resolved `$choice` **as-is** and reports the whole set once, in the Step 4.3 summary; every value stays an ordinary adoption file the developer can edit afterwards (§ Same files, same format as guided). Guided is untouched — it runs Path A exactly as written. The cleaner long-term shape is a first-class non-interactive signal on the assess-\* family itself; that changes eight skills plus the cascade convention, so it belongs to its own story, and this deviation is what bootstrap does until then.
+
 ## Cascade tiers, as bootstrap fills them
 
 The convention's precedence, highest wins, with bootstrap's source named per tier:
@@ -28,9 +35,11 @@ The convention's precedence, highest wins, with bootstrap's source named per tie
 | ------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------- |
 | Phase 0      | PRD present and populated                                            | **never defaulted, and a precondition of the minutes-scale claim** — a populated PRD is read; a missing or template PRD composes `/pair-process-specify-prd`, an interactive authoring session outside quick mode's question budget (see `Still asked`). HALTs if the PRD is still absent | project state     |
 | Step 1.2     | project categorization (Type A/B/C)                                  | derived from PRD signals (team size, budget, compliance) and recorded, not confirmed                            | project state     |
-| Step 2.2     | which `assess-*` skills run, and how                                 | installed ones are composed **with** their quick signal (Path A `$choice`), never plain — the family's declared default is guided (Path C). Project state fills `$choice` where it can; otherwise the per-type fallback row below does | project state     |
+| Step 2.2     | which `assess-*` skills run, and how                                 | installed ones are composed **with** their quick signal (Path A `$choice`), never plain — the family's declared default is guided (Path C). Project state fills `$choice` where it can; otherwise the per-type fallback row below does. **Path A's confirmation round (cascade steps 3-4) is not run** — the resolved `$choice` is accepted as-is and reported once in the Step 4.3 summary (§ Disclosed deviations) | project state     |
 | Step 2.3     | architecture section (core pattern, style, data)                     | not asked — `bootstrap-checklist.md` § `Decision Framework` (core pattern) + § `Quick-Mode Per-Project-Type Defaults` rows `Architecture — style` / `— data` | fallback          |
-| Step 2.3     | tech stack section                                                   | read from project state (`package.json`, lockfiles, config files); **still asked** on an empty repo — the fallback table has no stack row by design | project state     |
+| Step 2.3     | tech stack section (core)                                            | read from project state (`package.json`, lockfiles, config files); **still asked** on an empty repo — the fallback table has no stack row by design | project state     |
+| Step 2.3     | testing section of `tech-stack.md` (`/pair-capability-assess-testing`)               | not asked — the **runner follows the resolved stack** (the same answer that filled the core section, never a separate question), the strategy from § `Quick-Mode Per-Project-Type Defaults` row `Testing — strategy` | project state + fallback |
+| Step 2.3     | AI section of `tech-stack.md` (`/pair-capability-assess-ai`)                         | not asked — the **assistant/agent tooling follows project state** (`.claude/`, `.cursor/`, `AGENTS.md`, MCP config; on an empty repo, the assistant running bootstrap), the maturity level from § `Quick-Mode Per-Project-Type Defaults` row `AI development tooling` | project state + fallback |
 | Step 2.3     | infrastructure + observability sections                              | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Infrastructure` / `Observability`                    | fallback          |
 | Step 2.3     | ux-ui section                                                        | not asked — § `Quick-Mode Per-Project-Type Defaults` row `UX/UI`                                               | fallback          |
 | Step 2.3     | way-of-working section (flow, branching, release)                    | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Way of Working — …`. The PM tool is excluded from this row and still asked (Step 4.2) | fallback          |
@@ -45,7 +54,7 @@ The convention's precedence, highest wins, with bootstrap's source named per tie
 Quick mode reduces the questions to the genuinely-defaultable ones; it does not eliminate every question unconditionally.
 
 - **PM tool** (Step 4.2) — the choice is organisational, not technical, so no KB value is safe: a wrong guess wires up a tracker nobody uses. Project state resolves it when `way-of-working.md` already names one; otherwise `/pair-capability-setup-pm` is composed and asks that single question.
-- **Tech stack when undetectable** (Step 2.3) — normally read from project state (`package.json`, lockfiles, config files). On a genuinely empty repository there is nothing to read and no universally-correct default, so quick mode asks rather than guessing.
+- **Tech stack when undetectable** (Step 2.3) — normally read from project state (`package.json`, lockfiles, config files). On a genuinely empty repository there is nothing to read and no universally-correct default, so quick mode asks rather than guessing. It is **one** question, not three: `tech-stack.md`'s testing and AI sections are separate `assess-*` invocations, but once the stack is known its test runner follows from it and its AI tooling follows from project state — neither asks again (see the two rows above).
 - **The PRD, when absent** (Phase 0) — not a bootstrap question but a whole composed session: `/pair-process-specify-prd` authors it interactively and iterates to approval. Phase 0 is BLOCKING and identical in both depths, so **a populated PRD is a precondition of the minutes-scale claim**, not something quick mode defaults. Measure or plan quick mode from a project that already has one; on a repo without one, expect the PRD session first.
 
 Everything else in the table above resolves without a question **once the PRD exists**. If one of the two still-asked decisions can neither be resolved from the cascade nor asked (quick mode with no TTY), bootstrap HALTs and names the input to pass explicitly — see SKILL.md.
diff --git a/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md b/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md
index 8388f665..53c1bbc4 100644
--- a/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md
+++ b/.pair/adoption/decision-log/2026-07-31-bootstrap-quick-is-a-depth-not-a-skill.md
@@ -26,7 +26,8 @@ Three constraints follow, and are asserted in `packages/knowledge-hub/src/confor
 
 1. **No second skill, no second entry point.** One skill, one catalog row, one frontmatter description; both depths run the same phases, compose the same skills, and write the same files.
 2. **No bespoke resolution order.** Bootstrap composes the convention's cascade and declares only its per-adopter delta — which decision points are defaultable, which tier fills each, which are still asked — in the disclosed sibling `quick-mode-defaults.md`. Two decisions stay asked in quick mode because no KB value is safe: the PM tool (organisational, not technical) and the tech stack when the repo is genuinely empty. A populated PRD is a **precondition**, not a default: Phase 0 is blocking in both depths, so the minutes-scale claim is measured from a project that already has one.
-   The `hardcoded fallback` tier needed a real KB anchor to point at, so this story also adds `bootstrap-checklist.md` § _Quick-Mode Per-Project-Type Defaults_ — one value per adoption section per project type. It deliberately has no tech-stack and no PM-tool row (those are project state or asked), and the pre-existing § _Context-Specific Examples_ are explicitly ruled out as a default source.
+   The `hardcoded fallback` tier needed a real KB anchor to point at, so this story also adds `bootstrap-checklist.md` § *Quick-Mode Per-Project-Type Defaults* — one value per adoption section per project type. It deliberately has no tech-stack and no PM-tool row (those are project state or asked), and the pre-existing § *Context-Specific Examples* are explicitly ruled out as a default source.
+   Two deviations from the shared conventions are **disclosed** rather than silent, both in `quick-mode-defaults.md` § Disclosed deviations: `$mode: guided` is accepted as a loud no-op, and in quick mode the resolution cascade's **Path A confirmation round** is not run on composed `assess-*` skills (bootstrap sequences up to eight of them, each with its own confirmation prompt — running that round would mean up to eight questions inside a depth that asks none). Guided runs Path A exactly as written.
 3. **No quick-mode-only output.** Every file quick mode writes is a normal adoption file in the normal location and format, with no marker distinguishing it, so an accepted default is editable exactly like any other adopted decision.
 
 Guided is the declared default because bootstrap is human-facing first-time setup — the convention's own recommendation for that shape ("ask rather than silently assume"). The non-interactive path is the convention's, not a bootstrap invention: no TTY warns and falls back to quick rather than hanging, and HALTs if a still-asked decision is then unresolvable.
@@ -36,12 +37,13 @@ Guided is the declared default because bootstrap is human-facing first-time setu
 - **A separate `/pair-process-quickstart` skill**: Rejected. Two entry points for the same job diverge — a phase added to bootstrap would silently not exist in quickstart, and `/pair-next` would need a rule for which to suggest. It also duplicates the composition table and the already-configured-project detection.
 - **Quick as bootstrap's default, guided opt-in via `--interactive`** (the `pair package` shape): Rejected. Bootstrap's first run is a human's first contact with the process; silently assuming an architecture and a project type is a worse failure than asking. It would also be a behaviour change for every existing adopter, not an additive one.
 - **A bootstrap-specific resolution order** (e.g. always prefer the checklist fallback for speed): Rejected — it re-invents #276 one week after it landed, and makes an explicit argument losable to a hardcoded default.
+- **A first-class non-interactive signal on the `assess-*` family** (instead of bootstrap suppressing Path A's confirmation round): the cleaner shape, and rejected only for scope — it changes eight skills plus the cascade convention itself, so it belongs to its own story against that family. Until then bootstrap carries the deviation, disclosed.
 - **A third partially-guided depth** (ask only the "important" ones): Rejected for now. The convention permits a documented deviation, but "important" is not definable without adopter data; the still-asked set already covers the only two decisions with no safe default.
 
 ## Consequences
 
 - A future setup-oriented skill adopting the same duality follows the convention plus this precedent: mode argument on the existing skill, declared default stated explicitly, per-adopter delta in a disclosed sibling doc.
-- Any new bootstrap phase or decision point must also declare its quick-mode resolution in `quick-mode-defaults.md`. The conformance suite guards something narrower than that rule, and the difference matters: it asserts (a) that every SKILL.md step whose text carries an **interview marker** — a question blockquote, `Ask 3-4`, a "for developer review" / "until approved" round — also carries a `**Quick mode**:` note in the same section, and (b) a fixed anchor list (PRD, categorization, `assess-*`, quality gate, PM tool, domain model) in the defaults doc. A new decision point that asks nothing new is therefore caught by review, not by the suite.
+- Any new bootstrap phase or decision point must also declare its quick-mode resolution in `quick-mode-defaults.md`. The conformance suite guards something narrower than that rule, and the difference matters: it asserts (a) that every SKILL.md step whose text carries an **interview marker** — a question blockquote, `Ask 3-4`, a "for developer review" / "until approved" round, an approval gate written as "for (final) approval" / "Developer approves" — also carries a `**Quick mode**:` note in the same section, and (b) a fixed anchor list (PRD, categorization, `assess-*`, quality gate, PM tool, domain model) in the defaults doc. A new decision point that asks nothing new is therefore caught by review, not by the suite.
 - Bootstrap's frontmatter description is unchanged, so no skills-catalog row moves.
 - The <10 minute claim is validated, not asserted: `qa/release-validation/CP9-quickstart-onboarding.md` measures it with an explicit stopwatch protocol and covers the guided-default regression in the same critical path.
 
diff --git a/.pair/knowledge/assets/bootstrap-checklist.md b/.pair/knowledge/assets/bootstrap-checklist.md
index 595e9738..f041fdc3 100644
--- a/.pair/knowledge/assets/bootstrap-checklist.md
+++ b/.pair/knowledge/assets/bootstrap-checklist.md
@@ -119,15 +119,17 @@ The `hardcoded fallback` tier for a setup skill running its **quick** depth —
 
 **Deliberately absent from this table** — a quick run must not invent these:
 
-- **Tech stack** — read from project state (`package.json`, lockfiles, config files), or asked. No per-type stack is safe: a Type A project is as plausibly a Python CLI as a Next.js portfolio.
+- **Tech stack** — read from project state (`package.json`, lockfiles, config files), or asked. No per-type stack is safe: a Type A project is as plausibly a Python CLI as a Next.js portfolio. Once it is resolved, the test runner follows from it and the AI tooling follows from project state, so the `Testing — strategy` and `AI development tooling` rows below cover only what does **not** follow — they never name a framework or a vendor.
 - **Project management tool** — organisational, not technical. Read from `way-of-working.md`, or asked.
-- **[Context-Specific Examples](#context-specific-examples)** (below) are worked examples of three *already-decided* projects, including their stack and PM tool. They illustrate; they are never a default source.
+- **[Context-Specific Examples](#context-specific-examples)** (below) are worked examples of three _already-decided_ projects, including their stack and PM tool. They illustrate; they are never a default source.
 
 | Section / decision            | Type A (Pet / PoC)                                            | Type B (Startup / Scale-up)                                | Type C (Enterprise)                                                             |
 | ----------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------- |
 | Architecture — core pattern   | Modular Monolith (per [Decision Framework](#decision-framework)) | Modular Monolith with microservice preparation              | Modular Monolith until a domain split is justified — evaluate per Decision Framework |
 | Architecture — style          | Layered                                                       | Hexagonal                                                  | Hexagonal                                                                       |
 | Architecture — data           | Single database                                               | Single database, read replica when load requires            | Database per bounded context, integration via events                            |
+| Testing — strategy            | unit tests on core logic, no enforced coverage threshold (runner follows the stack) | + integration tests on critical boundaries, [70/20/10 pyramid](../guidelines/testing/test-strategy/test-pyramid.md), [80-85% on standard code](../guidelines/testing/test-strategy/coverage-strategy.md) | idem + E2E on critical journeys, 90-95% on critical business logic, differential coverage enforced in CI |
+| AI development tooling        | [maturity Level 1-2](../guidelines/technical-standards/ai-development/README.md#ai-development-maturity-model) — the assistant already in project state, human review of all AI-generated code | Level 2-3 — + project MCP integration and agent skills, AI-assisted review in the PR flow | Level 3 — + standardized AI development environments, a governed tool list, enhanced security review of AI-generated code |
 | Infrastructure — environments | prod only                                                     | dev + prod                                                  | dev + staging + prod                                                            |
 | Infrastructure — hosting      | managed platform (PaaS), no orchestration                     | managed platform or containers                              | containers or managed cloud, IaC mandatory                                      |
 | Infrastructure — CI/CD        | repository-native CI: build, test, deploy from `main`         | repository-native CI + preview environments                 | repository-native CI + gated promotion per environment                          |
@@ -379,15 +381,15 @@ The `hardcoded fallback` tier for a setup skill running its **quick** depth —
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Modular Monolith → *Single Next.js application*
-- ✅ **Architectural Style**: Layered → *Pages/Components/Utils structure*
-- ✅ **Data Strategy**: Static + Headless CMS → *Markdown files + optional Sanity*
+- ✅ **Monolith vs Microservices**: Modular Monolith → _Single Next.js application_
+- ✅ **Architectural Style**: Layered → _Pages/Components/Utils structure_
+- ✅ **Data Strategy**: Static + Headless CMS → _Markdown files + optional Sanity_
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: Kanban → *Feature-based development, no sprints*
-- ✅ **Release Strategy**: Continuous deployment → *Vercel auto-deploy on push*
-- ✅ **Quality Gates**: Minimal → *TypeScript + basic testing*
+- ✅ **Iteration Model**: Kanban → _Feature-based development, no sprints_
+- ✅ **Release Strategy**: Continuous deployment → _Vercel auto-deploy on push_
+- ✅ **Quality Gates**: Minimal → _TypeScript + basic testing_
 
 #### Project Management Tool:
 
@@ -422,9 +424,9 @@ Monitoring: Vercel built-in monitoring
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Modular Monolith → *Single deployable with service layers*
-- ✅ **Architectural Style**: Event-Driven → *Real-time data processing architecture*
-- ✅ **Data Strategy**: Polyglot Persistence → *PostgreSQL + ClickHouse + Redis*
+- ✅ **Monolith vs Microservices**: Modular Monolith → _Single deployable with service layers_
+- ✅ **Architectural Style**: Event-Driven → _Real-time data processing architecture_
+- ✅ **Data Strategy**: Polyglot Persistence → _PostgreSQL + ClickHouse + Redis_
 
 #### Project Management Tool:
 
@@ -432,9 +434,9 @@ Monitoring: Vercel built-in monitoring
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: 2-week Sprints → *Balanced planning with fast delivery*
-- ✅ **Release Strategy**: Sprint-based with feature flags → *Risk mitigation*
-- ✅ **Quality Gates**: High → *95% test coverage, performance budgets*
+- ✅ **Iteration Model**: 2-week Sprints → _Balanced planning with fast delivery_
+- ✅ **Release Strategy**: Sprint-based with feature flags → _Risk mitigation_
+- ✅ **Quality Gates**: High → _95% test coverage, performance budgets_
 
 #### Final Tech Stack (Definitive):
 
@@ -466,15 +468,15 @@ Testing: Jest 29.x + Cypress 13.x + Artillery (load testing)
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Domain Microservices → *Customer, Sales, Marketing, Integration services*
-- ✅ **Architectural Style**: Hexagonal + CQRS → *Complex business logic isolation*
-- ✅ **Data Strategy**: Database per Service + Event Sourcing → *Audit requirements*
+- ✅ **Monolith vs Microservices**: Domain Microservices → _Customer, Sales, Marketing, Integration services_
+- ✅ **Architectural Style**: Hexagonal + CQRS → _Complex business logic isolation_
+- ✅ **Data Strategy**: Database per Service + Event Sourcing → _Audit requirements_
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: 3-week Sprints → *Enterprise coordination needs*
-- ✅ **Release Strategy**: Quarterly releases with monthly patches → *Risk management*
-- ✅ **Quality Gates**: Enterprise → *Security scans, compliance checks, performance testing*
+- ✅ **Iteration Model**: 3-week Sprints → _Enterprise coordination needs_
+- ✅ **Release Strategy**: Quarterly releases with monthly patches → _Risk management_
+- ✅ **Quality Gates**: Enterprise → _Security scans, compliance checks, performance testing_
 
 #### Project Management Tool:
 
diff --git a/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx b/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
index 07eee119..b2066ce1 100644
--- a/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
+++ b/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
@@ -31,7 +31,9 @@ With the PRD in place, expect at most two questions:
 - **Which PM tool?** — the choice is organisational, not technical, so there is no safe default to guess. Skipped if your `way-of-working.md` already names one.
 - **Which tech stack?** — normally read straight from `package.json`, lockfiles and config. Only asked on a genuinely empty repository, where there is nothing to read.
 
-Everything else — project categorization, the per-section architecture/infrastructure/way-of-working decisions, the adoption documents, the standard quality-gate pipeline — is resolved from defaults and reported, not asked.
+Everything else — project categorization, the per-section architecture/infrastructure/way-of-working decisions, the testing and AI sections that follow from your stack, the adoption documents, the standard quality-gate pipeline — is resolved from defaults and reported, not asked.
+
+The `assess-*` skills bootstrap composes do not add confirmations of their own either: in quick mode their resolved values are accepted as-is and listed in the final summary, instead of being confirmed one skill at a time (there are eight of them).
 
 When it finishes, the summary names the depth that ran and how many questions it asked:
 
diff --git a/packages/knowledge-hub/dataset/.pair/knowledge/assets/bootstrap-checklist.md b/packages/knowledge-hub/dataset/.pair/knowledge/assets/bootstrap-checklist.md
index 595e9738..f041fdc3 100644
--- a/packages/knowledge-hub/dataset/.pair/knowledge/assets/bootstrap-checklist.md
+++ b/packages/knowledge-hub/dataset/.pair/knowledge/assets/bootstrap-checklist.md
@@ -119,15 +119,17 @@ The `hardcoded fallback` tier for a setup skill running its **quick** depth —
 
 **Deliberately absent from this table** — a quick run must not invent these:
 
-- **Tech stack** — read from project state (`package.json`, lockfiles, config files), or asked. No per-type stack is safe: a Type A project is as plausibly a Python CLI as a Next.js portfolio.
+- **Tech stack** — read from project state (`package.json`, lockfiles, config files), or asked. No per-type stack is safe: a Type A project is as plausibly a Python CLI as a Next.js portfolio. Once it is resolved, the test runner follows from it and the AI tooling follows from project state, so the `Testing — strategy` and `AI development tooling` rows below cover only what does **not** follow — they never name a framework or a vendor.
 - **Project management tool** — organisational, not technical. Read from `way-of-working.md`, or asked.
-- **[Context-Specific Examples](#context-specific-examples)** (below) are worked examples of three *already-decided* projects, including their stack and PM tool. They illustrate; they are never a default source.
+- **[Context-Specific Examples](#context-specific-examples)** (below) are worked examples of three _already-decided_ projects, including their stack and PM tool. They illustrate; they are never a default source.
 
 | Section / decision            | Type A (Pet / PoC)                                            | Type B (Startup / Scale-up)                                | Type C (Enterprise)                                                             |
 | ----------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------- |
 | Architecture — core pattern   | Modular Monolith (per [Decision Framework](#decision-framework)) | Modular Monolith with microservice preparation              | Modular Monolith until a domain split is justified — evaluate per Decision Framework |
 | Architecture — style          | Layered                                                       | Hexagonal                                                  | Hexagonal                                                                       |
 | Architecture — data           | Single database                                               | Single database, read replica when load requires            | Database per bounded context, integration via events                            |
+| Testing — strategy            | unit tests on core logic, no enforced coverage threshold (runner follows the stack) | + integration tests on critical boundaries, [70/20/10 pyramid](../guidelines/testing/test-strategy/test-pyramid.md), [80-85% on standard code](../guidelines/testing/test-strategy/coverage-strategy.md) | idem + E2E on critical journeys, 90-95% on critical business logic, differential coverage enforced in CI |
+| AI development tooling        | [maturity Level 1-2](../guidelines/technical-standards/ai-development/README.md#ai-development-maturity-model) — the assistant already in project state, human review of all AI-generated code | Level 2-3 — + project MCP integration and agent skills, AI-assisted review in the PR flow | Level 3 — + standardized AI development environments, a governed tool list, enhanced security review of AI-generated code |
 | Infrastructure — environments | prod only                                                     | dev + prod                                                  | dev + staging + prod                                                            |
 | Infrastructure — hosting      | managed platform (PaaS), no orchestration                     | managed platform or containers                              | containers or managed cloud, IaC mandatory                                      |
 | Infrastructure — CI/CD        | repository-native CI: build, test, deploy from `main`         | repository-native CI + preview environments                 | repository-native CI + gated promotion per environment                          |
@@ -379,15 +381,15 @@ The `hardcoded fallback` tier for a setup skill running its **quick** depth —
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Modular Monolith → *Single Next.js application*
-- ✅ **Architectural Style**: Layered → *Pages/Components/Utils structure*
-- ✅ **Data Strategy**: Static + Headless CMS → *Markdown files + optional Sanity*
+- ✅ **Monolith vs Microservices**: Modular Monolith → _Single Next.js application_
+- ✅ **Architectural Style**: Layered → _Pages/Components/Utils structure_
+- ✅ **Data Strategy**: Static + Headless CMS → _Markdown files + optional Sanity_
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: Kanban → *Feature-based development, no sprints*
-- ✅ **Release Strategy**: Continuous deployment → *Vercel auto-deploy on push*
-- ✅ **Quality Gates**: Minimal → *TypeScript + basic testing*
+- ✅ **Iteration Model**: Kanban → _Feature-based development, no sprints_
+- ✅ **Release Strategy**: Continuous deployment → _Vercel auto-deploy on push_
+- ✅ **Quality Gates**: Minimal → _TypeScript + basic testing_
 
 #### Project Management Tool:
 
@@ -422,9 +424,9 @@ Monitoring: Vercel built-in monitoring
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Modular Monolith → *Single deployable with service layers*
-- ✅ **Architectural Style**: Event-Driven → *Real-time data processing architecture*
-- ✅ **Data Strategy**: Polyglot Persistence → *PostgreSQL + ClickHouse + Redis*
+- ✅ **Monolith vs Microservices**: Modular Monolith → _Single deployable with service layers_
+- ✅ **Architectural Style**: Event-Driven → _Real-time data processing architecture_
+- ✅ **Data Strategy**: Polyglot Persistence → _PostgreSQL + ClickHouse + Redis_
 
 #### Project Management Tool:
 
@@ -432,9 +434,9 @@ Monitoring: Vercel built-in monitoring
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: 2-week Sprints → *Balanced planning with fast delivery*
-- ✅ **Release Strategy**: Sprint-based with feature flags → *Risk mitigation*
-- ✅ **Quality Gates**: High → *95% test coverage, performance budgets*
+- ✅ **Iteration Model**: 2-week Sprints → _Balanced planning with fast delivery_
+- ✅ **Release Strategy**: Sprint-based with feature flags → _Risk mitigation_
+- ✅ **Quality Gates**: High → _95% test coverage, performance budgets_
 
 #### Final Tech Stack (Definitive):
 
@@ -466,15 +468,15 @@ Testing: Jest 29.x + Cypress 13.x + Artillery (load testing)
 
 #### Architecture Foundation Decisions:
 
-- ✅ **Monolith vs Microservices**: Domain Microservices → *Customer, Sales, Marketing, Integration services*
-- ✅ **Architectural Style**: Hexagonal + CQRS → *Complex business logic isolation*
-- ✅ **Data Strategy**: Database per Service + Event Sourcing → *Audit requirements*
+- ✅ **Monolith vs Microservices**: Domain Microservices → _Customer, Sales, Marketing, Integration services_
+- ✅ **Architectural Style**: Hexagonal + CQRS → _Complex business logic isolation_
+- ✅ **Data Strategy**: Database per Service + Event Sourcing → _Audit requirements_
 
 #### Process Methodology Decisions:
 
-- ✅ **Iteration Model**: 3-week Sprints → *Enterprise coordination needs*
-- ✅ **Release Strategy**: Quarterly releases with monthly patches → *Risk management*
-- ✅ **Quality Gates**: Enterprise → *Security scans, compliance checks, performance testing*
+- ✅ **Iteration Model**: 3-week Sprints → _Enterprise coordination needs_
+- ✅ **Release Strategy**: Quarterly releases with monthly patches → _Risk management_
+- ✅ **Quality Gates**: Enterprise → _Security scans, compliance checks, performance testing_
 
 #### Project Management Tool:
 
diff --git a/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md b/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
index 3f29fff3..6d96fc28 100644
--- a/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
+++ b/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
@@ -127,7 +127,7 @@ One entry point, two resolution depths. Quick mode is **additive**: a second res
 
 4. **Verify**: Assessment data collected (via skills or manually) and persisted via `/record-decision`. All adoption files written from assess-\* proposals are consistent.
 
-**Quick mode**: composed assess-\* skills must be invoked with their own quick signal — the resolution cascade's **Path A `$choice`**, resolved from project state — never plain, because the assess-\* family's declared default is guided (Path C, the full interview). A domain project state cannot resolve falls back to the per-project-type default named in [quick-mode-defaults.md](quick-mode-defaults.md); the tech stack on a genuinely empty repo is the one exception and is still asked (Step 2.3). The manual-assessment path (item 3) asks nothing either — it takes the same defaults and reports them.
+**Quick mode**: composed assess-\* skills must be invoked with their own quick signal — the resolution cascade's **Path A `$choice`**, resolved from project state — never plain, because the assess-\* family's declared default is guided (Path C, the full interview). **Path A's confirmation round is not run here**: the [resolution cascade](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/resolution-cascade.md) Path A steps 3-4 ask the developer to confirm the override, and each assess-\* skill declares its own prompt for it — eight composed skills would emit up to eight confirmations inside a depth that asks nothing. In quick mode the resolved `$choice` is accepted as-is and reported once in the Step 4.3 summary. This is a **disclosed per-adopter deviation**, like the explicit-`guided` no-op above; see [quick-mode-defaults.md](quick-mode-defaults.md) § Disclosed deviations. A domain project state cannot resolve falls back to the per-project-type default named in [quick-mode-defaults.md](quick-mode-defaults.md); the tech stack on a genuinely empty repo is the one exception and is still asked (Step 2.3). The manual-assessment path (item 3) asks nothing either — it takes the same defaults and reports them.
 
 ### Step 2.3: Gather Information per Section
 
@@ -139,10 +139,10 @@ For each missing adoption file, work through the relevant checklist section. Ref
 2. **Tech Stack** — languages, frameworks, libraries with versions
    - Reference: [Technical Standards](../../../.pair/knowledge/guidelines/technical-standards/README.md)
 
-3. *`Infrastructure`* — deployment, CI/CD, monitoring, environments
+3. **Infrastructure** — deployment, CI/CD, monitoring, environments
    - Reference: [Infrastructure Guidelines](../../../.pair/knowledge/guidelines/infrastructure/README.md)
 
-4. *`UX/UI`* — design system, accessibility, device support
+4. **UX/UI** — design system, accessibility, device support
    - Reference: [UX Guidelines](../../../.pair/knowledge/guidelines/user-experience/README.md)
 
 5. **Way of Working** — processes, quality gates, release cycles
@@ -154,7 +154,7 @@ For each missing adoption file, work through the relevant checklist section. Ref
 - Wait for developer responses before proceeding
 - Record each significant decision via `/record-decision` (`non-architectural` → ADL, `architectural` → ADR)
 
-**Quick mode**: no section questions — each section is filled from one named KB anchor, [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md) § `Quick-Mode Per-Project-Type Defaults` (plus § `Decision Framework` for the core architectural pattern), with the same `/record-decision` calls. The § `Context-Specific Examples` are worked examples of already-decided projects — **never** a default source. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked; the table has no stack row by design ([quick-mode-defaults.md](quick-mode-defaults.md)).
+**Quick mode**: no section questions — each section is filled from one named KB anchor, [Bootstrap Checklist](../../../.pair/knowledge/assets/bootstrap-checklist.md) § `Quick-Mode Per-Project-Type Defaults` (plus § `Decision Framework` for the core architectural pattern), with the same `/record-decision` calls. The § `Context-Specific Examples` are worked examples of already-decided projects — **never** a default source. The **testing** and **AI** sub-sections of `tech-stack.md` (separate assess-\* invocations — see [assess-orchestration.md](assess-orchestration.md)) have their own rows in the same table; the test runner and the assistant follow from the resolved stack and project state, the strategy values from the table. Exception: an undetectable tech stack (empty repo, nothing to read from project state) is still asked; the table has no stack row by design ([quick-mode-defaults.md](quick-mode-defaults.md)).
 
 ## Phase 3: Standards Generation
 
diff --git a/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md b/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
index 94ac7ecb..7e6b8e62 100644
--- a/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
+++ b/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
@@ -11,6 +11,13 @@ Disclosed from [SKILL.md](SKILL.md) — the `$mode` selector and its two resolut
 - **`guided` is also accepted explicitly — a documented deviation.** The convention fixes the selector's **minimum** (an explicit signal must select the non-default depth) and says nothing about naming the default; bootstrap accepts `$mode: guided` as a loud no-op so a script or a handoff can make the depth visible at the call site. It resolves to exactly the same behaviour as an omitted `$mode`.
 - No TTY (CI, piped stdin) is an explicit environment fact and outranks the depth preference: guided can never run there. Bootstrap warns and runs quick instead, and never hangs waiting for input it cannot receive.
 
+## Disclosed deviations
+
+Two, both deliberate and both scoped to bootstrap. They are listed here rather than left implicit because the conventions they deviate from are shared.
+
+1. **`$mode: guided` is accepted as a loud no-op** — see § Selector above. The convention fixes only that an explicit signal must select the **non-default** depth; naming the default is bootstrap's addition.
+2. **In quick mode, Path A's confirmation round is not run on composed `assess-*` skills.** The [resolution cascade](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/resolution-cascade.md) defines Path A as `$choice` **plus** a confirmation round (steps 3-4: "Confirm the override with the developer" / "Developer confirms"), and each assess-\* skill declares its own prompt for it. Bootstrap sequences up to eight of them (`assess-orchestration.md`), so running that round would emit up to eight questions inside a depth whose whole point is asking none — and no assess-\* skill currently has a non-interactive signal of its own. Quick mode therefore accepts each resolved `$choice` **as-is** and reports the whole set once, in the Step 4.3 summary; every value stays an ordinary adoption file the developer can edit afterwards (§ Same files, same format as guided). Guided is untouched — it runs Path A exactly as written. The cleaner long-term shape is a first-class non-interactive signal on the assess-\* family itself; that changes eight skills plus the cascade convention, so it belongs to its own story, and this deviation is what bootstrap does until then.
+
 ## Cascade tiers, as bootstrap fills them
 
 The convention's precedence, highest wins, with bootstrap's source named per tier:
@@ -28,9 +35,11 @@ The convention's precedence, highest wins, with bootstrap's source named per tie
 | ------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------- |
 | Phase 0      | PRD present and populated                                            | **never defaulted, and a precondition of the minutes-scale claim** — a populated PRD is read; a missing or template PRD composes `/specify-prd`, an interactive authoring session outside quick mode's question budget (see `Still asked`). HALTs if the PRD is still absent | project state     |
 | Step 1.2     | project categorization (Type A/B/C)                                  | derived from PRD signals (team size, budget, compliance) and recorded, not confirmed                            | project state     |
-| Step 2.2     | which `assess-*` skills run, and how                                 | installed ones are composed **with** their quick signal (Path A `$choice`), never plain — the family's declared default is guided (Path C). Project state fills `$choice` where it can; otherwise the per-type fallback row below does | project state     |
+| Step 2.2     | which `assess-*` skills run, and how                                 | installed ones are composed **with** their quick signal (Path A `$choice`), never plain — the family's declared default is guided (Path C). Project state fills `$choice` where it can; otherwise the per-type fallback row below does. **Path A's confirmation round (cascade steps 3-4) is not run** — the resolved `$choice` is accepted as-is and reported once in the Step 4.3 summary (§ Disclosed deviations) | project state     |
 | Step 2.3     | architecture section (core pattern, style, data)                     | not asked — `bootstrap-checklist.md` § `Decision Framework` (core pattern) + § `Quick-Mode Per-Project-Type Defaults` rows `Architecture — style` / `— data` | fallback          |
-| Step 2.3     | tech stack section                                                   | read from project state (`package.json`, lockfiles, config files); **still asked** on an empty repo — the fallback table has no stack row by design | project state     |
+| Step 2.3     | tech stack section (core)                                            | read from project state (`package.json`, lockfiles, config files); **still asked** on an empty repo — the fallback table has no stack row by design | project state     |
+| Step 2.3     | testing section of `tech-stack.md` (`/assess-testing`)               | not asked — the **runner follows the resolved stack** (the same answer that filled the core section, never a separate question), the strategy from § `Quick-Mode Per-Project-Type Defaults` row `Testing — strategy` | project state + fallback |
+| Step 2.3     | AI section of `tech-stack.md` (`/assess-ai`)                         | not asked — the **assistant/agent tooling follows project state** (`.claude/`, `.cursor/`, `AGENTS.md`, MCP config; on an empty repo, the assistant running bootstrap), the maturity level from § `Quick-Mode Per-Project-Type Defaults` row `AI development tooling` | project state + fallback |
 | Step 2.3     | infrastructure + observability sections                              | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Infrastructure` / `Observability`                    | fallback          |
 | Step 2.3     | ux-ui section                                                        | not asked — § `Quick-Mode Per-Project-Type Defaults` row `UX/UI`                                               | fallback          |
 | Step 2.3     | way-of-working section (flow, branching, release)                    | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Way of Working — …`. The PM tool is excluded from this row and still asked (Step 4.2) | fallback          |
@@ -45,7 +54,7 @@ The convention's precedence, highest wins, with bootstrap's source named per tie
 Quick mode reduces the questions to the genuinely-defaultable ones; it does not eliminate every question unconditionally.
 
 - **PM tool** (Step 4.2) — the choice is organisational, not technical, so no KB value is safe: a wrong guess wires up a tracker nobody uses. Project state resolves it when `way-of-working.md` already names one; otherwise `/setup-pm` is composed and asks that single question.
-- **Tech stack when undetectable** (Step 2.3) — normally read from project state (`package.json`, lockfiles, config files). On a genuinely empty repository there is nothing to read and no universally-correct default, so quick mode asks rather than guessing.
+- **Tech stack when undetectable** (Step 2.3) — normally read from project state (`package.json`, lockfiles, config files). On a genuinely empty repository there is nothing to read and no universally-correct default, so quick mode asks rather than guessing. It is **one** question, not three: `tech-stack.md`'s testing and AI sections are separate `assess-*` invocations, but once the stack is known its test runner follows from it and its AI tooling follows from project state — neither asks again (see the two rows above).
 - **The PRD, when absent** (Phase 0) — not a bootstrap question but a whole composed session: `/specify-prd` authors it interactively and iterates to approval. Phase 0 is BLOCKING and identical in both depths, so **a populated PRD is a precondition of the minutes-scale claim**, not something quick mode defaults. Measure or plan quick mode from a project that already has one; on a repo without one, expect the PRD session first.
 
 Everything else in the table above resolves without a question **once the PRD exists**. If one of the two still-asked decisions can neither be resolved from the cascade nor asked (quick mode with no TTY), bootstrap HALTs and names the input to pass explicitly — see SKILL.md.
diff --git a/packages/knowledge-hub/src/conformance/bootstrap.test.ts b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
index c5ed37f5..7b8ca0b1 100644
--- a/packages/knowledge-hub/src/conformance/bootstrap.test.ts
+++ b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
@@ -173,11 +173,17 @@ const stepSections = (skill: string): Map<string, string> => {
 // a present-and-approve round. Those are exactly the steps quick mode has to
 // say something about — and the derivation makes a FUTURE interview step fail
 // this guard unless its author adds the note too.
+//
+// The last two shapes are the ones Step 4.3 itself uses ("…for final approval",
+// "**Verify**: Developer approves"): without them a future approval gate written
+// in Step 4.3's own phrasing would land with no quick-mode note and stay green.
 const INTERVIEW_MARKERS = [
   /^\s*>.*\?\s*$/m,
   /Ask \d+(-\d+)? focused questions/i,
   /for developer review/i,
   /until approved/i,
+  /for (final )?approval/i,
+  /Developer approves/i,
 ]
 
 describe('quick mode is declared where the questions are (AC1)', () => {
@@ -214,6 +220,24 @@ describe('quick mode is declared where the questions are (AC1)', () => {
     expect(sections.get('2.2')?.toLowerCase()).toMatch(/path a/)
   })
 
+  // Path A is `$choice` PLUS a confirmation round (resolution-cascade.md steps
+  // 3-4), and each assess-* skill declares its own prompt for it. Naming Path A
+  // without suppressing that round would put up to EIGHT confirmations
+  // (assess-orchestration.md sequences eight skills) inside a depth that claims
+  // to ask nothing — so the suppression has to be stated, not implied.
+  it('suppresses Path A’s confirmation round in quick mode, as a disclosed deviation', () => {
+    const step = sections.get('2.2') ?? ''
+    expect(step).toMatch(/confirmation round[^.]*not run|not run[^.]*confirmation round/i)
+    expect(step.toLowerCase()).toMatch(/deviation/)
+
+    // and the deviation is disclosed where the other one (the explicit-`guided`
+    // no-op) already is, not buried in the step note
+    const defaults = datasetDefaults()
+    expect(defaults).toMatch(/##\s*Disclosed deviations/)
+    expect(defaults).toMatch(/Path A[\s\S]{0,400}confirmation round[\s\S]{0,400}not run/i)
+    expect(defaults.toLowerCase()).toMatch(/loud no-op/)
+  })
+
   it('qualifies the approval-round HALT conditions as guided-only', () => {
     const halt = datasetSkill().split('## HALT Conditions')[1] ?? ''
     expect(halt).toMatch(/Adoption file generation rejected[^\n]*guided only/i)
@@ -231,7 +255,18 @@ describe('the fallback tier points at a KB anchor that exists (AC3)', () => {
       expect(c).toContain(ANCHOR)
       // one column per project type, and the rows quick mode resolves from
       expect(c).toMatch(/Type A[^|]*\|[^|]*Type B[^|]*\|[^|]*Type C/)
-      for (const row of ['Architecture — style', 'Infrastructure —', 'UX/UI', 'Way of Working —']) {
+      for (const row of [
+        'Architecture — style',
+        'Infrastructure —',
+        'UX/UI',
+        'Way of Working —',
+        // tech-stack.md's testing and AI sections are SEPARATE assess-*
+        // invocations (assess-orchestration.md), each needing its own resolved
+        // value — without these rows quick mode has nothing to resolve them
+        // from and must either invent a value or ask.
+        'Testing — strategy',
+        'AI development tooling',
+      ]) {
         expect(c, `${p}: missing fallback row ${row}`).toContain(row)
       }
       // and it must NOT invent the two non-defaultable ones
@@ -246,6 +281,19 @@ describe('the fallback tier points at a KB anchor that exists (AC3)', () => {
     expect(c).toMatch(/Context-Specific Examples/)
   })
 
+  // Eight assess-* invocations, not five sections: the testing and the AI
+  // section of tech-stack.md are their own skills. Quick mode must say where
+  // each resolves from, or "at most two questions" is not true.
+  it('resolves the testing and AI sections of tech-stack.md without a question', () => {
+    const doc = datasetDefaults()
+    expect(doc).toMatch(/testing section of `tech-stack\.md`/i)
+    expect(doc).toMatch(/AI section of `tech-stack\.md`/i)
+    expect(doc).toContain('Testing — strategy')
+    expect(doc).toContain('AI development tooling')
+    // and the still-asked list stays at ONE stack question, not three
+    expect(doc).toMatch(/one\*\* question, not three|one question, not three/i)
+  })
+
   it('keeps the cascade tiers disjoint — decision-log belongs to preferences only', () => {
     const defaults = datasetDefaults()
     expect(defaults).toMatch(/excluding[^|]*decision-log/i)
@@ -363,6 +411,22 @@ describe('no regression on the guided path (AC2)', () => {
   it('reports the resolved depth in the output format', () => {
     expect(c).toMatch(/Mode:\s*\[?\s*guided/i)
   })
+
+  // the guided Step 2.3 list is one list: all five items bold. Two of them
+  // drifted to `*`code`*` in a quick-mode commit, which is exactly the kind of
+  // silent edit to guided-path text AC2 exists to prevent.
+  it('keeps the Step 2.3 section list in a single emphasis style', () => {
+    const step = stepSections(c).get('2.3') ?? ''
+    for (const item of [
+      '**Architecture**',
+      '**Tech Stack**',
+      '**Infrastructure**',
+      '**UX/UI**',
+      '**Way of Working**',
+    ]) {
+      expect(step, `Step 2.3 list item ${item}`).toContain(item)
+    }
+  })
 })
 
 describe('root mirror is in sync with the dataset (pair update)', () => {
diff --git a/qa/release-validation/CP9-quickstart-onboarding.md b/qa/release-validation/CP9-quickstart-onboarding.md
index 0446a216..30082357 100644
--- a/qa/release-validation/CP9-quickstart-onboarding.md
+++ b/qa/release-validation/CP9-quickstart-onboarding.md
@@ -95,7 +95,7 @@
 ### Expected Result
 
 - Total elapsed under **10 min**, with both splits recorded
-- **Bootstrap asked no question outside the two still-asked decisions** — no categorization confirmation, no per-section interview, no per-document approval round, no custom-gate question. This assertion is scoped to bootstrap (the `T0 → T1` window); the planning/refinement turns in step 5 are interactive and not covered by it
+- **Bootstrap asked no question outside the two still-asked decisions** — no categorization confirmation, no per-section interview, no per-document approval round, no custom-gate question, and **no `assess-*` Path A override confirmation** (the disclosed deviation in `quick-mode-defaults.md` § Disclosed deviations: with eight composable assess-\* skills, that round alone would be up to eight questions). This assertion is scoped to bootstrap (the `T0 → T1` window); the planning/refinement turns in step 5 are interactive and not covered by it
 - The completion summary reports `Mode: quick — N questions asked` with `N` matching what was actually asked
 - `.pair/adoption/tech/architecture.md`, `tech-stack.md` and `way-of-working.md` are populated
 - One user story exists and is workable (it has acceptance criteria, so `/pair-process-implement` can start on it)
@@ -161,8 +161,10 @@
 
 ### Steps
 
-1. Simulate a non-interactive environment (CI runner, or an agent session with stdin closed) rooted at a third clean project
-2. Request the guided depth explicitly
+1. `mkdir -p $WORKDIR/nontty && cd $WORKDIR/nontty && git init && $CLI install` — a **third** clean project
+2. Author a PRD as in MT-CP902 (Phase 0 is BLOCKING in both depths, so without it the run HALTs on the PRD before the depth fallback is reachable — see Notes)
+3. Simulate a non-interactive environment (CI runner, or an agent session with stdin closed) rooted at `$WORKDIR/nontty`
+4. Request the guided depth explicitly
 
 ### Expected Result
 
@@ -170,9 +172,14 @@
 - The run never blocks waiting for input that cannot arrive
 - If a still-asked decision (PM tool, undetectable stack) is then unresolvable, the run **HALTs** and names the input to pass explicitly — it does not guess
 
+### Notes
+
+- **Sub-case, if step 2 is skipped on purpose**: with no PRD the correct behaviour is a HALT at Phase 0 — `/pair-process-specify-prd` cannot run without a TTY either — and the depth fallback above is never reached. That is a PASS for the no-hang guarantee and **not** an observation of the fallback; run step 2 to test the fallback itself.
+
 ---
 
 ## Changelog
 
 - Added for #278 (bootstrap quick mode): MT-CP901..906.
+- Review round 2 (#408): MT-CP906 gained its own project setup + PRD (its preconditions were unreachable otherwise) and a "no PRD ⇒ HALT at Phase 0" sub-case; MT-CP903 now also asserts no `assess-*` Path A confirmation.
 - Review round 1 (#408): added MT-CP902 (PRD authored outside the stopwatch) — the PRD is a third question-generating input, not a quick-mode default; the timed test is now MT-CP903 with a bootstrap/story split, and its "no question" assertion is scoped to the bootstrap window.

From f15478b46c6ad122859206cfc2397aefee443b46 Mon Sep 17 00:00:00 2001
From: Gianluca Carucci <gianluca@carucci.org>
Date: Fri, 31 Jul 2026 13:36:56 +0200
Subject: [PATCH 13/13] =?UTF-8?q?[US-278]=20fix:=20review=20round=203=20?=
 =?UTF-8?q?=E2=80=94=20Phase=203.5's=20composed=20map-*=20skills=20also=20?=
 =?UTF-8?q?ask?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Round 3's Major finding, and it is the SAME defect class round 2 fixed, in a
surface round 2's guard structurally cannot see: Phase 3.5 composes
/map-subdomains and /map-contexts, and BOTH end in an unconditional
"Approve or adjust?". So "at most two questions" was false again, two questions
further on.

Why the round-2 guard missed it: that guard derives "question-bearing" steps
from a step's OWN text — a blockquote question, an ask-N rule, an approval
round. Phase 3.5's steps contain none of those; the questions live inside the
skills it composes. A caller-side note cannot see the next composed skill that
asks, which is exactly why the real fix is a non-interactive signal on the
composed families — filed as #410, and referenced from both deviations.

- SKILL.md Phase 3.5: quick-mode note, both corpora
- quick-mode-defaults.md: disclosed deviations go from two to three; the Phase
  3.5 cascade row no longer claims "never blocking"
- ONE GATE KEPT DELIBERATELY: /map-contexts HALTs on an unbalanced + volatile
  relationship offered with neither mitigation nor acceptance. Quick mode does
  NOT suppress it — writing a domain model that records a coupling risk nobody
  judged is worse than one more question. Documented in the skill, the sibling,
  the docs page and CP9's MT-CP903, and pinned so a future "ask nothing at all"
  change cannot silently swallow it.
- bootstrap-quick-mode.mdx: the rarer third case stated instead of "two"
- CP9 MT-CP903: the map-* rounds added to the no-question assertion, with the
  HALT named as the one admissible exception

Minor — quick-mode-defaults.md attributed gate-registry detection to
/setup-gates, which bootstrap never composes (Step 3.2 does it). The Graceful
Degradation bullet for missing assess-* skills was not depth-qualified, and read
as if the manual path asks in quick mode too.

NOT touched, deliberately: map-subdomains/SKILL.md and map-contexts/SKILL.md are
modified by PR #387. Editing them would destroy this PR's zero-collision
property, which is its main merit at the merge gate. The fix is caller-side, as
round 2's was; #410 does it properly once #387 has merged.

Both mirrors REGENERATED with the real transform rather than hand-ported: my
hand-port drifted by one character (the pipeline prepends `./` to a same-dir
link) and #352's mirror-equality guard caught it. The sibling was regenerated
through applyKnownMirrorTransforms for the same reason.

44 conformance assertions, 98 with the mirror suite. `pnpm quality-gate` green.
All new relative links verified to resolve on this branch.

Refs #278 · #410

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../skills/pair-process-bootstrap/SKILL.md    |  4 ++-
 .../quick-mode-defaults.md                    | 11 ++++---
 .../getting-started/bootstrap-quick-mode.mdx  |  3 ++
 .../.skills/process/bootstrap/SKILL.md        |  4 ++-
 .../process/bootstrap/quick-mode-defaults.md  |  9 +++---
 .../src/conformance/bootstrap.test.ts         | 31 +++++++++++++++++++
 .../CP9-quickstart-onboarding.md              |  2 +-
 7 files changed, 52 insertions(+), 12 deletions(-)

diff --git a/.claude/skills/pair-process-bootstrap/SKILL.md b/.claude/skills/pair-process-bootstrap/SKILL.md
index bf2a3f02..5c4e4825 100644
--- a/.claude/skills/pair-process-bootstrap/SKILL.md
+++ b/.claude/skills/pair-process-bootstrap/SKILL.md
@@ -219,6 +219,8 @@ Runs after architecture and tech-stack are adopted (Step 3.1) — both are prere
 3. **Act**: Compose `/pair-capability-map-contexts` with `$scope: all` — the only caller allowed a full-catalog run. Uses the subdomain catalog (Step 3.5.1) plus architecture.md and tech-stack.md (Step 3.1).
 4. **Verify**: Bounded context catalog created/updated, or fallback noted. Domain modeling never blocks bootstrap completion — proceed to Phase 4 regardless of outcome.
 
+**Quick mode**: both composed `map-*` skills carry their own **unconditional** developer-approval round (`/pair-capability-map-subdomains` Step 3 "Approve or adjust?", `/pair-capability-map-contexts` Step 4 the same), so composing them plainly would emit two more questions inside a depth that asks none — the same collision as the assess-\* family in Step 2.2, in a different surface. Quick mode therefore **accepts each proposed delta as-is** and reports the catalogs once in the Step 4.3 summary; every entry stays an ordinary adoption file the developer can edit afterwards. This is a **disclosed per-adopter deviation** — see [quick-mode-defaults.md](./quick-mode-defaults.md) § Disclosed deviations. **One exception survives**: `/pair-capability-map-contexts` HALTs on an unbalanced + volatile relationship offered with neither mitigation nor acceptance, and quick mode does **not** suppress that — accepting it silently would write a domain model recording a coupling risk nobody judged. That single gate is the one place Phase 3.5 can still ask in quick mode.
+
 ## Phase 4: Finalization
 
 ### Step 4.1: Consistency Verification
@@ -302,7 +304,7 @@ Phase completion is detected via output file existence — never re-does complet
 
 See [graceful degradation](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/graceful-degradation.md) (optional skill not installed → skip that phase/step with a warning, never blocks) and [record-decision contract](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/record-decision-contract.md) (`/pair-capability-record-decision` not installed → proposals cannot be persisted, document manually) for the standard scenarios. Additional cases (bootstrap's per-phase optional dependencies):
 
-- **assess-\* skills not installed**: Skip assessment phase, reference guideline files directly, ask developer for manual decisions. Log: "assess-\* skills not installed — using manual assessment."
+- **assess-\* skills not installed**: Skip assessment phase, reference guideline files directly, ask developer for manual decisions **in guided mode only** — in quick mode the manual path asks nothing either, taking the same per-project-type defaults and reporting them (Step 2.2). Log: "assess-\* skills not installed — using manual assessment."
 - **/specify-prd not installed**: HALT at Phase 0 if PRD is missing (a required dependency, not optional). Suggest creating PRD manually using how-to-01.
 - **/setup-pm not installed**: Skip PM configuration in Phase 4. Warn: "PM tool not configured — /pair-capability-setup-pm not installed."
 - **Bootstrap checklist asset not found**: Use Phase 2 section questions as fallback — they cover the same areas.
diff --git a/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md b/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
index 516ed26d..0b501a28 100644
--- a/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
+++ b/.claude/skills/pair-process-bootstrap/quick-mode-defaults.md
@@ -1,6 +1,6 @@
 # Bootstrap Quick Mode — Per-Decision Defaults
 
-Disclosed from [SKILL.md](./SKILL.md) — the `$mode` selector and its two resolution depths. This file is bootstrap's **per-adopter delta** of the Guided / Quick Setup Convention (`.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md`): the convention owns the selector direction, the defaults cascade and the non-interactive safety rule. Bootstrap declares only which of its own decision points are defaultable, which cascade tier fills each, and which are still asked. There is **no bespoke** Quickstart resolution order — nothing below re-invents or re-orders the cascade.
+Disclosed from [SKILL.md](SKILL.md) — the `$mode` selector and its two resolution depths. This file is bootstrap's **per-adopter delta** of the Guided / Quick Setup Convention (`.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/guided-quick-setup.md`): the convention owns the selector direction, the defaults cascade and the non-interactive safety rule. Bootstrap declares only which of its own decision points are defaultable, which cascade tier fills each, and which are still asked. There is **no bespoke** Quickstart resolution order — nothing below re-invents or re-orders the cascade.
 
 ## Selector
 
@@ -13,10 +13,11 @@ Disclosed from [SKILL.md](./SKILL.md) — the `$mode` selector and its two resol
 
 ## Disclosed deviations
 
-Two, both deliberate and both scoped to bootstrap. They are listed here rather than left implicit because the conventions they deviate from are shared.
+Three, all deliberate and all scoped to bootstrap. They are listed here rather than left implicit because the conventions they deviate from are shared.
 
 1. **`$mode: guided` is accepted as a loud no-op** — see § Selector above. The convention fixes only that an explicit signal must select the **non-default** depth; naming the default is bootstrap's addition.
-2. **In quick mode, Path A's confirmation round is not run on composed `assess-*` skills.** The [resolution cascade](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/resolution-cascade.md) defines Path A as `$choice` **plus** a confirmation round (steps 3-4: "Confirm the override with the developer" / "Developer confirms"), and each assess-\* skill declares its own prompt for it. Bootstrap sequences up to eight of them (`assess-orchestration.md`), so running that round would emit up to eight questions inside a depth whose whole point is asking none — and no assess-\* skill currently has a non-interactive signal of its own. Quick mode therefore accepts each resolved `$choice` **as-is** and reports the whole set once, in the Step 4.3 summary; every value stays an ordinary adoption file the developer can edit afterwards (§ Same files, same format as guided). Guided is untouched — it runs Path A exactly as written. The cleaner long-term shape is a first-class non-interactive signal on the assess-\* family itself; that changes eight skills plus the cascade convention, so it belongs to its own story, and this deviation is what bootstrap does until then.
+2. **In quick mode, Path A's confirmation round is not run on composed `assess-*` skills.** The [resolution cascade](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/resolution-cascade.md) defines Path A as `$choice` **plus** a confirmation round (steps 3-4: "Confirm the override with the developer" / "Developer confirms"), and each assess-\* skill declares its own prompt for it. Bootstrap sequences up to eight of them (`assess-orchestration.md`), so running that round would emit up to eight questions inside a depth whose whole point is asking none — and no assess-\* skill currently has a non-interactive signal of its own. Quick mode therefore accepts each resolved `$choice` **as-is** and reports the whole set once, in the Step 4.3 summary; every value stays an ordinary adoption file the developer can edit afterwards (§ Same files, same format as guided). Guided is untouched — it runs Path A exactly as written. The cleaner long-term shape is a first-class non-interactive signal on the assess-\* family itself; that changes eight skills plus the cascade convention, so it belongs to its own story (#410), and this deviation is what bootstrap does until then.
+3. **In quick mode, the composed `map-*` skills' approval round is not run.** `/pair-capability-map-subdomains` (Step 3) and `/pair-capability-map-contexts` (Step 4) each end in an unconditional "Approve or adjust?" — neither has a non-interactive signal of its own, so composing them plainly would add two questions to a depth that asks none. Quick mode accepts each proposed delta as-is and reports the catalogs once in the Step 4.3 summary; every entry stays an ordinary adoption file (§ Same files, same format as guided). Guided is untouched. **One gate survives deliberately**: `/pair-capability-map-contexts` HALTs on an unbalanced + volatile relationship offered with neither mitigation nor acceptance, and quick mode does not suppress it — writing a domain model that records a coupling risk nobody judged would be worse than asking. Same long-term shape as deviation 2: a first-class non-interactive signal on the composed families, tracked as its own story (#410).
 
 ## Cascade tiers, as bootstrap fills them
 
@@ -45,7 +46,7 @@ The convention's precedence, highest wins, with bootstrap's source named per tie
 | Step 2.3     | way-of-working section (flow, branching, release)                    | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Way of Working — …`. The PM tool is excluded from this row and still asked (Step 4.2) | fallback          |
 | Step 3.1     | adoption documents                                                   | generated and written without the per-document presentation or approval round, for every document (Step 3.1 items 3-4 skipped) | fallback          |
 | Step 3.2     | quality gate setup                                                   | standard pipeline only (type check, test, lint, format), no custom gates — same registry entries guided writes  | fallback          |
-| Phase 3.5    | domain model (subdomains, bounded contexts)                          | runs when `/pair-capability-map-subdomains` / `/pair-capability-map-contexts` are installed, skipped with a warning otherwise — never blocking  | project state     |
+| Phase 3.5    | domain model (subdomains, bounded contexts)                          | runs when `/pair-capability-map-subdomains` / `/pair-capability-map-contexts` are installed, skipped with a warning otherwise. Both skills' approval round is **not run** (§ Disclosed deviations 3). Non-blocking **except** one case: `/pair-capability-map-contexts` HALTs on an unbalanced + volatile relationship with no mitigation or acceptance, and quick mode keeps that gate | project state     |
 | Step 4.2     | PM tool                                                              | **still asked** unless project state already names one (see below)                                              | explicit argument |
 | Step 4.3     | final summary                                                        | printed, not gated on approval                                                                                 | —                 |
 
@@ -65,4 +66,4 @@ Every file quick mode writes is a normal adoption file, in the same location and
 
 ## Already-configured project
 
-Unchanged from guided mode: each phase checks its own output first, so quick mode confirms rather than overwriting an existing PRD, categorization ADL, adoption file, gate registry, or PM configuration. Detection is the composed capability's own (`/pair-capability-setup-gates`, `/pair-capability-setup-pm`), never a second implementation here.
+Unchanged from guided mode: each phase checks its own output first, so quick mode confirms rather than overwriting an existing PRD, categorization ADL, adoption file, gate registry, or PM configuration. Detection belongs to whoever performs it: the PM configuration check is the composed `/pair-capability-setup-pm`'s own, while the **gate registry check is Step 3.2's**, because bootstrap does not compose `/pair-capability-setup-gates` (it is absent from the Composed Skills table). Either way it is never a second implementation of a check that already exists.
diff --git a/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx b/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
index b2066ce1..679989d2 100644
--- a/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
+++ b/apps/website/content/docs/getting-started/bootstrap-quick-mode.mdx
@@ -31,6 +31,9 @@ With the PRD in place, expect at most two questions:
 - **Which PM tool?** — the choice is organisational, not technical, so there is no safe default to guess. Skipped if your `way-of-working.md` already names one.
 - **Which tech stack?** — normally read straight from `package.json`, lockfiles and config. Only asked on a genuinely empty repository, where there is nothing to read.
 
+One rarer third case can ask: `/pair-capability-map-contexts`, composed in Phase 3.5, stops on a relationship that is both unbalanced and volatile when neither a mitigation nor an explicit acceptance is on offer. Quick mode deliberately keeps that gate — recording a coupling risk nobody judged would be worse than one more question.
+
+
 Everything else — project categorization, the per-section architecture/infrastructure/way-of-working decisions, the testing and AI sections that follow from your stack, the adoption documents, the standard quality-gate pipeline — is resolved from defaults and reported, not asked.
 
 The `assess-*` skills bootstrap composes do not add confirmations of their own either: in quick mode their resolved values are accepted as-is and listed in the final summary, instead of being confirmed one skill at a time (there are eight of them).
diff --git a/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md b/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
index 6d96fc28..ccc531bb 100644
--- a/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
+++ b/packages/knowledge-hub/dataset/.skills/process/bootstrap/SKILL.md
@@ -219,6 +219,8 @@ Runs after architecture and tech-stack are adopted (Step 3.1) — both are prere
 3. **Act**: Compose `/map-contexts` with `$scope: all` — the only caller allowed a full-catalog run. Uses the subdomain catalog (Step 3.5.1) plus architecture.md and tech-stack.md (Step 3.1).
 4. **Verify**: Bounded context catalog created/updated, or fallback noted. Domain modeling never blocks bootstrap completion — proceed to Phase 4 regardless of outcome.
 
+**Quick mode**: both composed `map-*` skills carry their own **unconditional** developer-approval round (`/map-subdomains` Step 3 "Approve or adjust?", `/map-contexts` Step 4 the same), so composing them plainly would emit two more questions inside a depth that asks none — the same collision as the assess-\* family in Step 2.2, in a different surface. Quick mode therefore **accepts each proposed delta as-is** and reports the catalogs once in the Step 4.3 summary; every entry stays an ordinary adoption file the developer can edit afterwards. This is a **disclosed per-adopter deviation** — see [quick-mode-defaults.md](quick-mode-defaults.md) § Disclosed deviations. **One exception survives**: `/map-contexts` HALTs on an unbalanced + volatile relationship offered with neither mitigation nor acceptance, and quick mode does **not** suppress that — accepting it silently would write a domain model recording a coupling risk nobody judged. That single gate is the one place Phase 3.5 can still ask in quick mode.
+
 ## Phase 4: Finalization
 
 ### Step 4.1: Consistency Verification
@@ -302,7 +304,7 @@ Phase completion is detected via output file existence — never re-does complet
 
 See [graceful degradation](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/graceful-degradation.md) (optional skill not installed → skip that phase/step with a warning, never blocks) and [record-decision contract](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/record-decision-contract.md) (`/record-decision` not installed → proposals cannot be persisted, document manually) for the standard scenarios. Additional cases (bootstrap's per-phase optional dependencies):
 
-- **assess-\* skills not installed**: Skip assessment phase, reference guideline files directly, ask developer for manual decisions. Log: "assess-\* skills not installed — using manual assessment."
+- **assess-\* skills not installed**: Skip assessment phase, reference guideline files directly, ask developer for manual decisions **in guided mode only** — in quick mode the manual path asks nothing either, taking the same per-project-type defaults and reporting them (Step 2.2). Log: "assess-\* skills not installed — using manual assessment."
 - **/specify-prd not installed**: HALT at Phase 0 if PRD is missing (a required dependency, not optional). Suggest creating PRD manually using how-to-01.
 - **/setup-pm not installed**: Skip PM configuration in Phase 4. Warn: "PM tool not configured — /setup-pm not installed."
 - **Bootstrap checklist asset not found**: Use Phase 2 section questions as fallback — they cover the same areas.
diff --git a/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md b/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
index 7e6b8e62..63cde723 100644
--- a/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
+++ b/packages/knowledge-hub/dataset/.skills/process/bootstrap/quick-mode-defaults.md
@@ -13,10 +13,11 @@ Disclosed from [SKILL.md](SKILL.md) — the `$mode` selector and its two resolut
 
 ## Disclosed deviations
 
-Two, both deliberate and both scoped to bootstrap. They are listed here rather than left implicit because the conventions they deviate from are shared.
+Three, all deliberate and all scoped to bootstrap. They are listed here rather than left implicit because the conventions they deviate from are shared.
 
 1. **`$mode: guided` is accepted as a loud no-op** — see § Selector above. The convention fixes only that an explicit signal must select the **non-default** depth; naming the default is bootstrap's addition.
-2. **In quick mode, Path A's confirmation round is not run on composed `assess-*` skills.** The [resolution cascade](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/resolution-cascade.md) defines Path A as `$choice` **plus** a confirmation round (steps 3-4: "Confirm the override with the developer" / "Developer confirms"), and each assess-\* skill declares its own prompt for it. Bootstrap sequences up to eight of them (`assess-orchestration.md`), so running that round would emit up to eight questions inside a depth whose whole point is asking none — and no assess-\* skill currently has a non-interactive signal of its own. Quick mode therefore accepts each resolved `$choice` **as-is** and reports the whole set once, in the Step 4.3 summary; every value stays an ordinary adoption file the developer can edit afterwards (§ Same files, same format as guided). Guided is untouched — it runs Path A exactly as written. The cleaner long-term shape is a first-class non-interactive signal on the assess-\* family itself; that changes eight skills plus the cascade convention, so it belongs to its own story, and this deviation is what bootstrap does until then.
+2. **In quick mode, Path A's confirmation round is not run on composed `assess-*` skills.** The [resolution cascade](../../../.pair/knowledge/guidelines/technical-standards/ai-development/skill-conventions/resolution-cascade.md) defines Path A as `$choice` **plus** a confirmation round (steps 3-4: "Confirm the override with the developer" / "Developer confirms"), and each assess-\* skill declares its own prompt for it. Bootstrap sequences up to eight of them (`assess-orchestration.md`), so running that round would emit up to eight questions inside a depth whose whole point is asking none — and no assess-\* skill currently has a non-interactive signal of its own. Quick mode therefore accepts each resolved `$choice` **as-is** and reports the whole set once, in the Step 4.3 summary; every value stays an ordinary adoption file the developer can edit afterwards (§ Same files, same format as guided). Guided is untouched — it runs Path A exactly as written. The cleaner long-term shape is a first-class non-interactive signal on the assess-\* family itself; that changes eight skills plus the cascade convention, so it belongs to its own story (#410), and this deviation is what bootstrap does until then.
+3. **In quick mode, the composed `map-*` skills' approval round is not run.** `/map-subdomains` (Step 3) and `/map-contexts` (Step 4) each end in an unconditional "Approve or adjust?" — neither has a non-interactive signal of its own, so composing them plainly would add two questions to a depth that asks none. Quick mode accepts each proposed delta as-is and reports the catalogs once in the Step 4.3 summary; every entry stays an ordinary adoption file (§ Same files, same format as guided). Guided is untouched. **One gate survives deliberately**: `/map-contexts` HALTs on an unbalanced + volatile relationship offered with neither mitigation nor acceptance, and quick mode does not suppress it — writing a domain model that records a coupling risk nobody judged would be worse than asking. Same long-term shape as deviation 2: a first-class non-interactive signal on the composed families, tracked as its own story (#410).
 
 ## Cascade tiers, as bootstrap fills them
 
@@ -45,7 +46,7 @@ The convention's precedence, highest wins, with bootstrap's source named per tie
 | Step 2.3     | way-of-working section (flow, branching, release)                    | not asked — § `Quick-Mode Per-Project-Type Defaults` rows `Way of Working — …`. The PM tool is excluded from this row and still asked (Step 4.2) | fallback          |
 | Step 3.1     | adoption documents                                                   | generated and written without the per-document presentation or approval round, for every document (Step 3.1 items 3-4 skipped) | fallback          |
 | Step 3.2     | quality gate setup                                                   | standard pipeline only (type check, test, lint, format), no custom gates — same registry entries guided writes  | fallback          |
-| Phase 3.5    | domain model (subdomains, bounded contexts)                          | runs when `/map-subdomains` / `/map-contexts` are installed, skipped with a warning otherwise — never blocking  | project state     |
+| Phase 3.5    | domain model (subdomains, bounded contexts)                          | runs when `/map-subdomains` / `/map-contexts` are installed, skipped with a warning otherwise. Both skills' approval round is **not run** (§ Disclosed deviations 3). Non-blocking **except** one case: `/map-contexts` HALTs on an unbalanced + volatile relationship with no mitigation or acceptance, and quick mode keeps that gate | project state     |
 | Step 4.2     | PM tool                                                              | **still asked** unless project state already names one (see below)                                              | explicit argument |
 | Step 4.3     | final summary                                                        | printed, not gated on approval                                                                                 | —                 |
 
@@ -65,4 +66,4 @@ Every file quick mode writes is a normal adoption file, in the same location and
 
 ## Already-configured project
 
-Unchanged from guided mode: each phase checks its own output first, so quick mode confirms rather than overwriting an existing PRD, categorization ADL, adoption file, gate registry, or PM configuration. Detection is the composed capability's own (`/setup-gates`, `/setup-pm`), never a second implementation here.
+Unchanged from guided mode: each phase checks its own output first, so quick mode confirms rather than overwriting an existing PRD, categorization ADL, adoption file, gate registry, or PM configuration. Detection belongs to whoever performs it: the PM configuration check is the composed `/setup-pm`'s own, while the **gate registry check is Step 3.2's**, because bootstrap does not compose `/setup-gates` (it is absent from the Composed Skills table). Either way it is never a second implementation of a check that already exists.
diff --git a/packages/knowledge-hub/src/conformance/bootstrap.test.ts b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
index 7b8ca0b1..c617c780 100644
--- a/packages/knowledge-hub/src/conformance/bootstrap.test.ts
+++ b/packages/knowledge-hub/src/conformance/bootstrap.test.ts
@@ -238,6 +238,37 @@ describe('quick mode is declared where the questions are (AC1)', () => {
     expect(defaults.toLowerCase()).toMatch(/loud no-op/)
   })
 
+  // Review round 3 on PR #408: the SAME defect class as the assertion above,
+  // recurring in a surface that assertion structurally cannot see. Phase 3.5
+  // composes /map-subdomains and /map-contexts, and BOTH end in an unconditional
+  // "Approve or adjust?" — so "quick mode asks nothing" was false again, two
+  // questions further on. Pinning the composed-family suppression per surface is
+  // a stopgap; the real fix is a non-interactive signal on the families (#410).
+  it('suppresses the composed map-* approval rounds in quick mode, as a disclosed deviation', () => {
+    const step = sections.get('3.5.2') ?? sections.get('3.5') ?? datasetSkill()
+    expect(step).toMatch(
+      /map-\\?\*[\s\S]{0,600}approval round|approval round[\s\S]{0,600}map-\\?\*/i,
+    )
+    expect(step.toLowerCase()).toMatch(/deviation/)
+
+    const defaults = datasetDefaults()
+    // Three deviations now, not two — the count is stated in prose, so a fourth
+    // surface cannot be added without updating the disclosure.
+    expect(defaults).toMatch(/Three, all deliberate/i)
+    expect(defaults).toMatch(/map-\\?\*[\s\S]{0,600}approval round is not run/i)
+  })
+
+  // The one gate quick mode deliberately KEEPS. Asserted so a future "make quick
+  // mode ask nothing at all" change cannot silently swallow it: accepting an
+  // unbalanced + volatile relationship without a judgement would write a domain
+  // model recording a coupling risk nobody approved.
+  it('keeps the unbalanced+volatile HALT even in quick mode, and says so', () => {
+    const defaults = datasetDefaults()
+    expect(defaults).toMatch(/unbalanced \+ volatile/i)
+    expect(defaults.toLowerCase()).not.toMatch(/phase 3\.5[^|\n]*never blocking\s*\|/)
+    expect(defaults).toMatch(/quick mode (does not suppress it|keeps that gate)/i)
+  })
+
   it('qualifies the approval-round HALT conditions as guided-only', () => {
     const halt = datasetSkill().split('## HALT Conditions')[1] ?? ''
     expect(halt).toMatch(/Adoption file generation rejected[^\n]*guided only/i)
diff --git a/qa/release-validation/CP9-quickstart-onboarding.md b/qa/release-validation/CP9-quickstart-onboarding.md
index 30082357..1d2888fe 100644
--- a/qa/release-validation/CP9-quickstart-onboarding.md
+++ b/qa/release-validation/CP9-quickstart-onboarding.md
@@ -95,7 +95,7 @@
 ### Expected Result
 
 - Total elapsed under **10 min**, with both splits recorded
-- **Bootstrap asked no question outside the two still-asked decisions** — no categorization confirmation, no per-section interview, no per-document approval round, no custom-gate question, and **no `assess-*` Path A override confirmation** (the disclosed deviation in `quick-mode-defaults.md` § Disclosed deviations: with eight composable assess-\* skills, that round alone would be up to eight questions). This assertion is scoped to bootstrap (the `T0 → T1` window); the planning/refinement turns in step 5 are interactive and not covered by it
+- **Bootstrap asked no question outside the two still-asked decisions** — no categorization confirmation, no per-section interview, no per-document approval round, no custom-gate question, and **no `assess-*` Path A override confirmation** (the disclosed deviation in `quick-mode-defaults.md` § Disclosed deviations: with eight composable assess-\* skills, that round alone would be up to eight questions), and **no `map-*` approval round** (deviation 3 — `/map-subdomains` and `/map-contexts` each end in an unconditional "Approve or adjust?"). **The one admissible exception** is `/map-contexts` halting on an unbalanced + volatile relationship with no mitigation or acceptance: if that fires, record it and it does NOT fail this assertion — quick mode keeps that gate by design. This assertion is scoped to bootstrap (the `T0 → T1` window); the planning/refinement turns in step 5 are interactive and not covered by it
 - The completion summary reports `Mode: quick — N questions asked` with `N` matching what was actually asked
 - `.pair/adoption/tech/architecture.md`, `tech-stack.md` and `way-of-working.md` are populated
 - One user story exists and is workable (it has acceptance criteria, so `/pair-process-implement` can start on it)