qualia-framework 6.9.2 → 6.22.0

package/skills/qualia-new/SKILL.md

@@ -58,7 +58,7 @@ Use **AskUserQuestion** (interactive UI — never a plain-text prompt):
 - question: "What kind of project is this? Pick one — it drives everything else."
 - options:
   - "Demo" — one shippable milestone, real backend, no mocks. Built to win a client conversation, extensible via `/qualia-milestone` if they sign. 8-question discovery.
-  - "Full project" — the multi-milestone arc to Handoff. 2-5 milestones planned upfront. 14-question discovery.
+  - "Full project" — the full multi-milestone arc to Handoff, sized to the agreed capability set (no fixed milestone cap — the arc spans to done). 15-question discovery.
   - "Quick prototype" — landing page, throwaway, ≤1 day. Skips research and journey. (Equivalent to `--quick` flag.)
 
 Store the answer as `PROJECT_TYPE=demo` | `PROJECT_TYPE=full` | `PROJECT_TYPE=quick`. It drives every downstream step.
@@ -94,7 +94,7 @@ The shape is locked, now capture the content in one sentence:
 
 > **"What are you building? One sentence — a stranger should understand it."**
 
-Accept whatever the user says, even if broad. **Do NOT start an ad-hoc clarification round here.** Depth comes from the structured discovery interview in Step 4, not from free-form questioning. If the answer is "a SaaS platform" — that's fine, write it down, move on. `/qualia-scope` will refine it through its 8 or 14 structured questions.
+Accept whatever the user says, even if broad. **Do NOT start an ad-hoc clarification round here.** Depth comes from the structured discovery interview in Step 4, not from free-form questioning. If the answer is "a SaaS platform" — that's fine, write it down, move on. `/qualia-scope` will refine it through its 8 or 15 structured questions.
 
 This is the ONLY free-text question in the kickoff flow. Everything else is `AskUserQuestion`.
 
@@ -102,7 +102,7 @@ This is the ONLY free-text question in the kickoff flow. Everything else is `Ask
 
 **Hard rule:** This is the next tool call after Step 3. No ad-hoc clarification, no free-form follow-up, no "let me ask a few quick things first." If the one-line pitch was "a SaaS platform", you invoke `/qualia-scope` NOW — that skill's structured questions are how breadth gets refined into depth.
 
-Invoke `/qualia-scope` inline in PROJECT MODE — non-technical kickoff interview. 8 questions for demo, 14 for full project. Pass `PROJECT_TYPE` so the scope skill skips the type question.
+Invoke `/qualia-scope` inline in PROJECT MODE — non-technical kickoff interview. 8 questions for demo, 15 for full project. Pass `PROJECT_TYPE` so the scope skill skips the type question.
 
 This step REPLACES the old free-form "deep questioning" loop. The scope skill captures answers verbatim into `.planning/project-discovery.md`, which seeds PROJECT.md, PRODUCT.md, CONTEXT.md, and (for full projects) JOURNEY.md milestone names.
 
@@ -331,13 +331,13 @@ Read `.planning/research/FEATURES.md` and present the feature landscape. Feature
 For each category, use AskUserQuestion:
 
 - header: "{Category name}"
-- question: "Which {category} features belong to v1 (Milestones 1..N-1 excluding Handoff)?"
+- question: "Which {category} features are part of THIS project (the full agreed scope)? Anything selected must land in a milestone — the arc is sized to fit, no cap."
 - multiSelect: true
-- options: each feature from FEATURES.md + "None for v1"
+- options: each feature from FEATURES.md + "None of these"
 
 Track selections:
-- Selected → v1 scope (roadmapper assigns to specific milestones based on dependency order)
-- Unselected table stakes → Post-Handoff v2 (users expect these)
+- Selected → in scope (roadmapper assigns each to a specific milestone by dependency order; the arc grows to cover all of them)
+- Unselected → only goes to Post-Handoff/Out-of-Scope if the user EXPLICITLY defers it (matches discovery §8). Don't silently drop a table-stakes feature into v2 to keep the arc short.
 - Unselected differentiators → Out of Scope
 
 Gather any additional requirements the user wants that research missed.
@@ -350,12 +350,24 @@ node ${QUALIA_BIN}/qualia-ui.js banner roadmap
 
 **Roadmapper output branches on `PROJECT_TYPE`:**
 
-- **Demo** (`PROJECT_TYPE=demo`): roadmapper produces a 1-milestone JOURNEY.md (the demo milestone, 2-4 phases) plus a matching REQUIREMENTS.md and a fully-detailed ROADMAP.md. No "Handoff" milestone is appended — the demo is its own complete artifact. The journey-tree at Step 14 shows a single rung; the "extend to full project" branch is handled later by `/qualia-milestone` if the client signs.
-- **Full project** (`PROJECT_TYPE=full`): roadmapper produces the standard 2-5 milestone arc ending in Handoff. Milestone 1 fully detailed, M2..M{N-1} sketched (unless `--full-detail`).
+- **Demo** (`PROJECT_TYPE=demo`): roadmapper produces a 1-milestone JOURNEY.md (the demo milestone, 2-4 phases) plus a matching REQUIREMENTS.md and a fully-detailed ROADMAP.md. No "Handoff" milestone is appended — the demo is its own complete artifact. The journey-tree at Step 15 shows a single rung; the "extend to full project" branch is handled later by `/qualia-milestone` if the client signs.
+- **Full project** (`PROJECT_TYPE=full`): roadmapper produces the full milestone arc ending in Handoff (client projects), sized to cover the entire capability inventory from discovery §9 — no fixed milestone count. Milestone 1 fully detailed, M2..M{N-1} sketched (unless `--full-detail`).
 
 Spawn the roadmapper with `<project_type>$PROJECT_TYPE</project_type>` in the prompt. If the user passed `--full-detail`, include `<full_detail>true</full_detail>` so the roadmapper writes complete phase detail for ALL milestones (full project only; demo always has full detail because there's only one milestone). See REFERENCE.md section "Roadmapper prompt" for the verbatim prompt template.
 
-### Step 14. Present the Journey (single view)
+### Step 14. Coverage gate (before presenting — the genesis teeth)
+
+Before showing the journey, verify the arc actually covers the whole agreed scope. This is what stops the framework from generating "milestones that don't finish the project."
+
+1. Read the capability inventory: `.planning/project-discovery.md` §9 (full projects).
+2. Read `.planning/REQUIREMENTS.md` traceability.
+3. Confirm **every §9 capability has a REQ-ID mapped to a milestone** (Unmapped = 0), and the only items in `Post-Handoff (v2)` / `Out of Scope` are the ones the client explicitly deferred in §8.
+
+If any §9 capability is unmapped, or agreed work was pushed to v2 to shorten the arc → **do NOT present for approval.** Re-spawn the roadmapper with the gap list and instruction to extend the arc until coverage is complete. Only proceed to the ladder when coverage is 100%.
+
+(Demo projects skip this — they're a single milestone with no §9 inventory.)
+
+### Step 15. Present the Journey (single view)
 
 Render the branded journey ladder:
 
@@ -367,7 +379,7 @@ This shows M1..M{N} as a vertical ladder: shipped milestones get a green dot, cu
 
 Also narrate the one-glance summary. See REFERENCE.md section "Journey ladder format" for the ASCII template.
 
-### Step 15. Approval Gate (single — for the whole journey)
+### Step 16. Approval Gate (single — for the whole journey)
 
 - header: "Journey"
 - question: "Does this journey work for you?"
@@ -397,7 +409,7 @@ node ${QUALIA_BIN}/qualia-ui.js info "Full phase detail for each later milestone
 
 (Skip this block when `--full-detail` was used — all milestones are already fully planned in that case.)
 
-### Step 16. Environment Setup
+### Step 17. Environment Setup
 
 Supabase project? `supabase link` or create. Vercel project? `vercel link`. Env vars? `.env.local` with placeholders from PROJECT.md stack.
 
@@ -408,7 +420,7 @@ git add .gitignore
 git commit -m "chore: environment setup" 2>/dev/null
 ```
 
-### Step 17. Auto-Apply Gate (or stop here)
+### Step 18. Auto-Apply Gate (or stop here)
 
 If invoked with `--auto`, skip straight into building Milestone 1:
 
@@ -465,10 +477,10 @@ Do NOT use `--quick` for: client projects, anything with compliance stakes, anyt
 1a. **One stack question, then a real scaffold.** Step 5a asks exactly ONE stack-preset question (`landing-page` / `full-app` / `ai-agent` / `internal-tool`) and then instantiates it: copies `scaffold/` into the project (never clobbering existing files), copies `env.required.json` → `.planning/env.required.json`, and copies `phases.md` → `.planning/phases.md`. The project starts from a runnable skeleton, not an empty folder. Skip this step on `--quick`. Record the choice as `config.json.stack_id`.
 2. **AskUserQuestion for every discrete-choice question.** Project type, brownfield gate, design vibe, client type, approval gate, auto-chain — all use the interactive UI. The ONLY free-text question in the kickoff flow is the Step 3 one-line pitch. No plain-text prompts for anything that has a closed set of answers.
 3. **No ad-hoc clarification questioning.** After Step 3 (one-line pitch), the next tool call is `/qualia-scope`. No "let me ask a few quick things first", no "that's too broad, can you clarify". Depth is the scope skill's job — not yours.
-4. **Discovery interview is mandatory.** Step 4 always invokes `/qualia-scope` in PROJECT MODE. No free-form questioning loop, no "I'll just sketch PROJECT.md from the user's first message." The interview is 8 questions for demo, 14 for full project.
+4. **Discovery interview is mandatory.** Step 4 always invokes `/qualia-scope` in PROJECT MODE. No free-form questioning loop, no "I'll just sketch PROJECT.md from the user's first message." The interview is 8 questions for demo, 15 for full project.
 5. **Research runs automatically.** No permission ask. Only `--quick` skips it. Demo path uses `<scope>quick</scope>` (3-call budget per researcher); full project uses standard 8-call budget.
 6. **Demo design philosophy is non-negotiable.** Real backend always (Supabase, real auth), DESIGN.md mandatory, slop-detect hard-block, 1 milestone, focus on real agent/platform functionality + design quality. No mock data, no lorem ipsum, no broken flows. Speed comes from skipping multi-milestone planning, never from skipping design quality, mocking the backend, or cutting corners on the core flow. A demo that uses mock data is not a Qualia demo.
-7. **Demos are 1 milestone, full projects are 2-5.** Demo journeys have no "Handoff" — the demo IS the artifact. Full projects always end in Handoff (fixed 4 phases). The journey-tree adapts to both shapes.
+7. **Demos are 1 milestone; full projects are 2+ (as many as the agreed scope needs — no cap).** Demo journeys have no "Handoff" — the demo IS the artifact. Full client projects end in Handoff (fixed 4 phases); internal/ongoing products may end at their done-state milestone. The journey-tree adapts to any length. A full project's arc must cover every capability from discovery §9 — never trimmed to hit a milestone count.
 8. **The full-project journey includes Handoff.** Every full project's final milestone is literally named "Handoff" with 4 standard phases. The roadmapper enforces this.
 9. **Single approval gate.** One gate for the whole journey. Not per-milestone, not per-phase.
 10. **Milestone 1 is fully detailed (full projects).** M2..M{N-1} are sketched. Detail fills in when each milestone opens. Demos are always fully detailed because they're 1 milestone.

package/skills/qualia-plan/SKILL.md

@@ -27,9 +27,9 @@ Spawn planner to break phase into tasks, validate with checker (max 2 revision c
 
 ## Process
 
-### 0. Codex goal (Codex runtime only)
+### 0. Set the work-unit goal
 
-Per `rules/codex-goal.md` — set the thread goal at plan start with scope `phase`. The objective covers both planning and the subsequent build, so a single goal-set at this stage is enough.
+Per `rules/codex-goal.md` — set the work-unit goal at plan start with scope `phase` (Codex `/goal`; on Claude Code, a tracked task + budget). The objective covers both planning and the subsequent build, so a single goal-set at this stage is enough.
 
 ### 1. Determine Phase & Load Context
 

package/skills/qualia-report/SKILL.md

@@ -123,6 +123,16 @@ if [ "$DRY_RUN" != "true" ] && [ -d .git ]; then
 fi
 ```
 
+### Step 5b — Branch hygiene sweep (clock-out safety net)
+
+Ship integrates every deploy into `main`, but work that was built and never shipped strands on a branch, and review PRs can linger. Surface both before the employee leaves — informational, never blocks:
+
+```bash
+node ${QUALIA_BIN}/branch-hygiene.js
+```
+
+Exit 1 → it lists branches with unshipped commits ahead of `main` (run `/qualia-ship` or merge them, or delete if abandoned) and any stale open PRs. Exit 0 → nothing stranded. Include the summary in the closing message so the OWNER sees it in the report.
+
 ### Step 6 — Upload to ERP
 
 The full payload-builder + 3-attempt-retry logic lives unchanged from v4 — see the **ERP Upload** section below for the canonical implementation. Behavior summary:

package/skills/qualia-scope/SKILL.md

@@ -45,7 +45,7 @@ The non-technical conversation at the start of `/qualia-new`, BEFORE roadmapping
 
 ### P1. Project type (or accept it from `/qualia-new`)
 
-If `/qualia-new` already asked the Demo vs Full gate (its literal first question), it passes `PROJECT_TYPE=demo` | `PROJECT_TYPE=full` via env/arg — **skip the gate, do not re-ask.** Only ask it when invoked standalone, via **AskUserQuestion** (header "Project shape"): "Demo (single shippable milestone, sales conversation)" vs "Full project (multi-milestone arc to Handoff)". Demo runs §1–§8 of the discovery template; Full runs all 14.
+If `/qualia-new` already asked the Demo vs Full gate (its literal first question), it passes `PROJECT_TYPE=demo` | `PROJECT_TYPE=full` via env/arg — **skip the gate, do not re-ask.** Only ask it when invoked standalone, via **AskUserQuestion** (header "Project shape"): "Demo (single shippable milestone, sales conversation)" vs "Full project (multi-milestone arc to Handoff)". Demo runs §1–§8 of the discovery template; Full runs §1–§15 (adds the capability-completeness pass + delivery questions).
 
 ### P2. Open
 
@@ -53,11 +53,11 @@ If `/qualia-new` already asked the Demo vs Full gate (its literal first question
 node ${QUALIA_BIN}/qualia-ui.js banner scope 2>/dev/null || true
 ```
 
-Say **"Eight quick questions for the demo path"** or **"Fourteen questions to shape the full project — we'll move fast."**
+Say **"Eight quick questions for the demo path"** or **"Fifteen questions to shape the full project — we'll move fast. The middle ones map out everything the project needs to be DONE."**
 
 ### P3. One question at a time, from `templates/project-discovery.md`
 
-For each §1..§8 (demo) or §1..§14 (full), ask in plain language:
+For each §1..§8 (demo) or §1..§15 (full), ask in plain language:
 
 ```
 **Question {N}/{total}:** {question text from the template}

package/skills/qualia-ship/SKILL.md

@@ -65,8 +65,11 @@ npx tsc --noEmit          # TypeScript — must pass
 if node -e "const p=require('./package.json');process.exit(p.scripts&&p.scripts.lint?0:1)"; then npm run lint; fi
 if node -e "const p=require('./package.json');process.exit(p.scripts&&p.scripts.test?0:1)"; then npm test; fi
 npm run build             # Build — must succeed
+node ${QUALIA_BIN}/slop-detect.mjs --severity=critical   # Anti-slop — CRITICAL design tells block ship
 ```
 
+The `pre-deploy-gate.js` hook re-runs the anti-slop scan at `vercel --prod` time as the hard, non-bypassable gate (OWNER-only `QUALIA_SKIP_SLOP=1` escape). This step surfaces failures early so they're fixed before the deploy command.
+
 On failure:
 1. Summarize what failed in plain language
 2. Auto-fix
@@ -118,17 +121,37 @@ if [ $SEC_FAIL -ne 0 ]; then
 fi
 ```
 
-### 3. Git
+### 3. Integrate to main (ship IS the merge point)
+
+Ship is the one place feature work lands on `main`, so `main` is always exactly what's in production and no branch lingers. Commit, then fast-forward-integrate into `main` and push. `branch-guard` records the main push (accountability, not a block — see `rules/infrastructure.md`).
 
 ```bash
 git add {specific changed files}
 git commit -m "ship: {project name} production deploy"
-git push
+
+BR=$(git branch --show-current)
+if [ "$BR" != "main" ] && [ "$BR" != "master" ]; then
+  git checkout main
+  git pull --ff-only origin main 2>/dev/null || true   # sync with remote first
+  if git merge --ff-only "$BR"; then
+    : # clean fast-forward
+  else
+    # main moved since the branch started — rebase the feature, then ff.
+    git checkout "$BR" && git rebase main || {
+      node ${QUALIA_BIN}/qualia-ui.js fail "Rebase conflict integrating $BR → main. Resolve, then re-run /qualia-ship."
+      exit 1
+    }
+    git checkout main && git merge --ff-only "$BR"
+  fi
+fi
+git push origin HEAD
 ```
 
-Employee stays on feature branch. Never push to main.
+If anything in this block fails (conflict, push rejected), STOP and surface it — do not deploy a half-integrated tree.
+
+### 4. Deploy (from main)
 
-### 4. Deploy
+Deploy runs on `main` HEAD — what you just integrated — so the deployed artifact and `main` are byte-identical.
 
 ```bash
 vercel --prod              # Website/AI agent
@@ -138,6 +161,16 @@ supabase functions deploy  # Edge functions
 wrangler deploy            # Cloudflare Workers
 ```
 
+### 4b. Close the branch
+
+On a verified successful deploy, delete the integrated feature branch so nothing lingers (skip if you shipped directly from `main`):
+
+```bash
+if [ -n "$BR" ] && [ "$BR" != "main" ] && [ "$BR" != "master" ]; then
+  git branch -d "$BR" 2>/dev/null && git push origin --delete "$BR" 2>/dev/null || true
+fi
+```
+
 ### 5. Post-Deploy Verification
 
 Read the deployed URL from `tracking.json.deployed_url` or from an explicit user-provided URL. Do NOT use a `{domain}` placeholder — that expects the LLM to hallucinate the URL, which is exactly the kind of silent fail the state guard above prevents.

package/skills/qualia-update/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: qualia-update
+description: "Ship one update to a LAUNCHED project (operate lifecycle). The post-launch counterpart to /qualia-milestone — a lean plan → build → verify → ship loop with no milestone-journey or forced-handoff machinery. Triggers: 'ship an update', 'make a change to the live site', 'the project is live, I need to add X', 'operate mode', 'post-launch change', 'patch the launched product'."
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Grep
+  - Glob
+  - Agent
+---
+
+# /qualia-update — ship one update to a launched project
+
+The operate-lifecycle counterpart to `/qualia-milestone`. Once a project has
+**launched** (`state.js launch` flips `lifecycle` from `build` to `operate`), it
+is an **update stream**, not a milestone journey: there is no forced
+polish → ship → **handoff** terminal. `/qualia-update` runs one lean change
+cycle and loops. Each completed update bumps `lifetime.updates_completed`.
+
+## Output contract
+
+```
+Command: /qualia-update {change}
+Scope: {files/routes touched}
+Intent: build
+Mutation: planned → active
+Evidence: state.js check, contract-runner output
+Output: shipped update + deployed URL
+Next: /qualia-update (next change) or done
+```
+
+## Process
+
+### 1. Confirm the project is launched
+
+```bash
+node ${QUALIA_BIN}/state.js check
+```
+
+- `lifecycle: "operate"` → proceed.
+- `lifecycle: "build"` and the product is actually live → launch it first:
+  ```bash
+  node ${QUALIA_BIN}/state.js launch --deployed-url {url} --source manual
+  ```
+  (The ERP can also drive this automatically when it detects the project is live.)
+- Still mid-build (never launched, not live) → this is `/qualia-feature` or a
+  normal phase, not an update. Route there instead.
+
+### 2. Scope the change (one update = one coherent change)
+
+Keep it small and shippable. A bug fix, a copy change, a new section, a single
+feature. If it's larger than ~5 files or needs its own milestone arc, it's a new
+`build`-mode milestone — use `/qualia-milestone`, not an update.
+
+### 2b. Set the work-unit goal
+
+Per `rules/codex-goal.md` — set the work-unit goal with scope `feature` (Codex `/goal`; on Claude Code, a tracked task + budget). An update runs its own lean loop without `/qualia-plan`, so set the objective + budget here so the change stays one coherent, bounded unit.
+
+### 3. Run the lean loop
+
+Reuse the real lifecycle skills, scoped to this one change:
+
+```
+/qualia-plan {N}     # compile the change into a phase + machine contract
+/qualia-build {N}    # builders execute, atomic commits
+/qualia-verify {N}   # contract-runner evidence + goal-backward check (must PASS)
+```
+
+Verification evidence is mandatory exactly as in build mode — a contract runs and
+its evidence must be clean before PASS. On the final phase, a `verified(pass)`
+in operate routes here again (`next_command: /qualia-update`) and increments
+`lifetime.updates_completed`.
+
+### 4. Ship
+
+```bash
+/qualia-ship        # quality gates → commit → deploy → verify live
+```
+
+No handoff. No "final milestone." The deploy is just this update going live. Then
+`/qualia-report` as usual — the report carries `lifecycle: operate` and the
+updated `updates_completed` so the ERP counts updates, not milestones.
+
+### 5. Loop or stop
+
+```bash
+node ${QUALIA_BIN}/qualia-ui.js end "UPDATE SHIPPED" "/qualia-update"
+```
+
+Run `/qualia-update` again for the next change, or stop — an operate project has
+no terminal state to reach.
+
+## Why this exists
+
+Hard-coding "every project ends in Handoff" forced launched products and
+retainers into a state machine that fought them. `/qualia-update` + the `operate`
+lifecycle make "this project is live and keeps shipping" explicit state instead
+of a milestone the team is forced to mislabel. See `templates/journey.md` rule 3.

package/skills/qualia-verify/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: qualia-verify
-description: "Goal-backward verification of a built phase — fresh verifier agent greps code against acceptance criteria, scores design rubric, optional adversarial second pass. Triggers: 'verify this phase', 'check if it works', 'run verification', 'did the build pass'."
+description: "Goal-backward verification of a built phase — a parallel verifier PANEL (one lens each) greps code against acceptance criteria, per-finding adversarial skeptics vote majority-survives, and verify-panel.js aggregates a deterministic verdict. Triggers: 'verify this phase', 'check if it works', 'run verification', 'did the build pass'."
 allowed-tools:
   - Bash
   - Read
@@ -19,7 +19,7 @@ Spawn verifier to check phase goal. Does NOT trust build summaries; greps codeba
 `/qualia-verify` — verify current built phase
 `/qualia-verify {N}` — verify specific phase
 `/qualia-verify {N} --auto` — verify + auto-chain: PASS → next phase/milestone; FAIL → gap closure; gap limit → halt
-`/qualia-verify {N} --adversarial` — second verifier in fresh context with adversarial prompt. Union findings. Recommended for high-stakes phases (Handoff, payment/auth/migration).
+`/qualia-verify {N} --adversarial` — deepen the panel: 5 skeptics per finding instead of 3. Recommended for high-stakes phases (Handoff, payment/auth/migration).
 
 ## Process
 
@@ -44,25 +44,39 @@ node ${QUALIA_BIN}/contract-runner.js .planning/phase-{N}-contract.json
 
 If it fails, the phase cannot PASS. Still spawn the verifier to explain the failure and identify the smallest gap-closure tasks. If it passes, pass the evidence file into the verifier prompt.
 
-### 3. Spawn Verifier (Fresh Context)
+### 3. Spawn Verifier Panel (parallel lenses, fresh context each)
+
+A single LLM judge is adversarially fragile (a lone stray token flips ~35% of verdicts). Replace single-pass review with a **panel**: one verifier per *relevant* lens, spawned in parallel (separate `Agent()` calls in the SAME turn), each scoped to one concern and anchored on the SAME machine evidence (contract-run + harness-eval) as shared ground truth.
 
 ```bash
 node ${QUALIA_BIN}/qualia-ui.js banner verify {N} "{phase name}"
-node ${QUALIA_BIN}/qualia-ui.js spawn verifier "Goal-backward check..."
 ```
 
+Pick lenses by what the phase touches (scale cost to risk — don't run all four on a one-file change):
+- **correctness** — always.
+- **security** — if the plan touches `auth|payment|rls|service_role|migration|secret|upload`.
+- **performance** — if it touches data fetching, network-in-loop, large lists, or `--perf` is set.
+- **design** — if it touches `.tsx/.jsx/.css/.scss` or `app/|components/|pages/`.
+
+For each chosen lens `L`, spawn (all in one turn, then wait for all):
+
 ```
 Agent(prompt="
 Role: @${QUALIA_AGENTS}/verifier.md
 
+LENS: {L}. Review ONLY through the {L} lens — concerns owned by other lenses have their own reviewer; do not duplicate them.
+
 Project: @.planning/PROJECT.md
 Plan + AC + validation: @.planning/phase-{N}-plan.md
 Machine contract: @.planning/phase-{N}-contract.json
-Contract evidence: @.planning/evidence/phase-{N}-contract-run.json
+Contract evidence (shared ground truth — do not re-derive): @.planning/evidence/phase-{N}-contract-run.json
 {Re-verify → previous gaps: @.planning/phase-{N}-verification.md}
 
-Verify phase. Every finding needs file:line evidence. Severity Rubric for all labels. Output: .planning/phase-{N}-verification.md
-", subagent_type="qualia-verifier", description="Verify phase {N}")
+Verify the {L} concerns of this phase. Every finding needs file:line evidence and a Severity Rubric label.
+Write your findings as a JSON array to .planning/phase-{N}-panel-{L}.json:
+  [{\"file\":\"path\",\"line\":N,\"severity\":\"CRITICAL|HIGH|MEDIUM|LOW\",\"title\":\"one-line claim\"}]
+Empty array [] if the {L} lens is clean. Also append a human '## {L} lens' section to .planning/phase-{N}-verification.md.
+", subagent_type="qualia-verifier", description="Verify phase {N} — {L} lens")
 ```
 
 ### 3b. Browser QA (if phase touched frontend)
@@ -89,34 +103,41 @@ Drive dev server, test routes phase touched. Append '## Browser QA' to verificat
 
 Wait for both verifier + QA before step 3. Playwright MCP unavailable → QA returns BLOCKED (note, not phase failure).
 
-### 3c. Adversarial Second Opinion (--adversarial flag, optional)
+### 3c. Skeptic Pass + Deterministic Aggregation
+
+The panel FINDS; skeptics decide what's REAL; `verify-panel.js` decides the verdict — math, not a vibe.
 
-`--adversarial` in args, OR milestone is `Handoff`, OR plan touches `auth|payment|migration|rls|service_role` → spawn SECOND verifier in fresh context. Mitigates self-grading bias (~70% fewer findings without adversarial pass).
+**1. Assemble** the per-lens finding files into one panel skeleton (votes zeroed):
 
 ```bash
-node ${QUALIA_BIN}/qualia-ui.js spawn verifier "Adversarial pass — find what's wrong"
+node ${QUALIA_BIN}/verify-panel.js assemble {N}   # → .planning/phase-{N}-panel.json
 ```
 
+**2. Skeptic vote** on each CRITICAL/HIGH finding (MEDIUM/LOW auto-survive — they don't flip the C/H verdict; skipping skeptics on them is the documented cost bound, not a silent cap). For each such finding spawn **3 skeptics** (5 if `--adversarial`, Handoff milestone, or the finding's lens is `security`), each in fresh context, each prompted to REFUTE:
+
 ```
 Agent(prompt="
 Role: @${QUALIA_AGENTS}/verifier.md
 
-ADVERSARIAL reviewer. Find what's WRONG. Assume cooperative verifier missed something. Same Severity Rubric + evidence-citation req. Bias toward edge cases:
-  - Untested error paths?
-  - Crash-inducing input?
-  - Unhandled concurrent access?
-  - Downstream breaks if contract changes?
-  - Security assumption (auth, RLS, secrets) implicit not enforced?
+SKEPTIC. A panel verifier claims this finding. Try to REFUTE it: is it actually reachable on a real path, or already handled elsewhere, or a false positive? Default to refuted ONLY with evidence — uncertainty is NOT refutation.
 
-Project: @.planning/PROJECT.md
-Plan: @.planning/phase-{N}-plan.md
-Cooperative report (find what they MISSED): @.planning/phase-{N}-verification.md
+Finding: {severity} — {title}
+Location: {file}:{line}
+Evidence to re-check yourself: @{file}
 
-Append '## Adversarial Findings' to verification file. Empty section fine if nothing found.
-", subagent_type="qualia-verifier", description="Adversarial verify phase {N}")
+Return exactly one line: REAL — {file:line reason}   OR   NOT_REAL — {file:line reason}
+", subagent_type="qualia-verifier", description="Skeptic {i}/3 — {title}")
 ```
 
-Findings merge into main report. Union PASS/FAIL: either pass found CRITICAL/HIGH → phase FAIL.
+Tally each finding's votes into `.planning/phase-{N}-panel.json` (`votes.real` / `votes.notReal`).
+
+**3. Aggregate** deterministically:
+
+```bash
+node ${QUALIA_BIN}/verify-panel.js .planning/phase-{N}-panel.json --write
+```
+
+`verify-panel.js` dedupes findings across lenses, applies **majority-survives** (a finding is killed only when skeptics are a strict majority calling it not-real; ties and unvoted findings survive), computes category scores via the `rules/grounding.md` formula, and exits **0 = PASS / 1 = FAIL** (any surviving CRITICAL/HIGH → FAIL). That exit code IS the panel verdict — carry it into step 4. Artifacts: `.planning/phase-{N}-verification-panel.{json,md}`.
 
 ### 3d. INSUFFICIENT EVIDENCE downgrade (mandatory)
 
@@ -132,7 +153,7 @@ if [ "$IE_COUNT" -gt 0 ]; then
 fi
 ```
 
-The same check runs after the adversarial pass if it executed.
+The same check runs across every lens section the panel wrote.
 
 ### 3. Present Results
 
@@ -175,7 +196,13 @@ Write the deterministic eval artifact before changing state:
 node ${QUALIA_BIN}/harness-eval.js --phase {N} --run --write
 ```
 
-If the eval status is `FAIL`, do not mark the phase PASS. The state machine also refuses PASS when a contract exists but `.planning/evidence/phase-{N}-contract-run.json` is missing/failing, or when the verification report contains `INSUFFICIENT EVIDENCE`.
+Run the zero-token anti-slop scan as a deterministic gate (same role as `migration-guard`/`branch-guard` — the scanner exits non-zero on CRITICAL design tells). A CRITICAL finding is a verification FAIL, not a soft note:
+
+```bash
+node ${QUALIA_BIN}/slop-detect.mjs --severity=critical
+```
+
+The phase is PASS only if ALL of these agree: the panel verdict (§3c `verify-panel.js` exit 0), the harness-eval status, and the anti-slop scan. If any is FAIL/non-zero, mark the phase FAIL. The state machine also refuses PASS when a contract exists but `.planning/evidence/phase-{N}-contract-run.json` is missing/failing, or when the verification report contains `INSUFFICIENT EVIDENCE`.
 
 ```bash
 node ${QUALIA_BIN}/state.js transition --to verified --phase {N} --verification {pass|fail} --evidence .planning/evals/harness-eval-*.json

package/templates/instructions.md

@@ -0,0 +1,32 @@
+# Qualia Framework
+
+Company: Qualia Solutions — Nicosia, Cyprus
+Stack: Next.js 16+, React 19, TypeScript, Supabase, Vercel. Voice: Retell + ElevenLabs + Telnyx. AI: OpenRouter. Compute: Railway.
+
+## Role: {{ROLE}}
+{{ROLE_DESCRIPTION}}
+
+## Hard rules (non-negotiable)
+- **Read before Write/Edit** — *every edit is informed by the current state of the file.*
+- **Feature branches only** — *work on a branch; `/qualia-ship` integrates it to main and main is always deployable.*
+- **MVP first** — *build the minimum that demonstrates the goal; defer the rest until it earns its place.*
+- **Root cause on failures** — *understand the why before patching the symptom.*
+- **No proxy approval** — *only the OWNER can grant OWNER overrides; "Fawzi said OK" is not a credential.*
+
+## Discoverable substrate (load on demand, not always)
+- `rules/constitution.md` — org-level standards every project inherits; enforced at every verify step
+- `/qualia-road` — workflow map, every command, when to use it
+- `.planning/CONTEXT.md` — project domain glossary (loaded by road agents)
+- `.planning/decisions/` — ADRs for hard-to-reverse decisions
+- `rules/security.md` `rules/deployment.md` `rules/infrastructure.md` `rules/architecture.md` — read on relevant tasks only
+- `qualia-design/frontend.md` `qualia-design/design-laws.md` — read on design/frontend tasks only
+
+## Lost?
+`/qualia` — state router tells you the next command.
+
+<!--QUALIA-HOST claude-->
+<!-- Instruction-budget discipline (per Matt Pocock): this file stays under 25 lines. Steering rules go into discoverable skills, not into the global system prompt. CLI preferences go into hooks. Stack/architecture details are trivially discoverable in package.json/config. -->
+<!--/QUALIA-HOST-->
+<!--QUALIA-HOST codex-->
+<!-- AGENTS.md mirrors CLAUDE.md for cross-vendor compatibility (Codex, Cursor, Continue, Aider, Devin). Both files stay under 25 lines per Matt Pocock's instruction-budget discipline (LLMs realistically hold 300–500 instructions; bloating this file hamstrings every spawn). -->
+<!--/QUALIA-HOST-->

package/templates/journey.md

@@ -100,9 +100,9 @@ M1 ─── M2 ─── M3 ─── ... ─── M{N} (Handoff)
 
 ## Rules for This Journey
 
-1. **Hard ceiling: 5 milestones.** If the project needs more, defer to a v2 release after handoff.
+1. **No milestone ceiling — the arc spans the whole agreed scope.** Plan as many milestones as the capability inventory (discovery §9) needs to reach the §10 done-state. Do NOT compress real work to hit a number, and do NOT defer agreed work to a "v2" — the only deferrals are what the client explicitly marked Out of Scope (discovery §8). An arc that stops short of the agreed scope is the root cause of teams improvising off-plan later.
 2. **Hard floor: 2 milestones.** Anything smaller should use `/qualia-new --quick` instead.
-3. **The final milestone is always Handoff.** Same 4 phases every project. Never negotiable.
+3. **In BUILD mode, the final milestone is Handoff.** This is the convention for a one-shot client build that ends with a handoff. It is **not** a universal law: once a project launches and enters the `operate` lifecycle (`state.js launch`), it becomes an *update stream* with no forced Handoff — it ships updates indefinitely. Don't author a Handoff milestone for a product/retainer that will keep shipping; launch it instead.
 4. **Milestones ≥ 2 phases OR are a shipped release gate.** A 1-phase milestone is a phase, not a milestone.
 5. **Numbering is contiguous.** No skipped milestone numbers.
 6. **Progressive detail is OK.** M1 is fully detailed (ready for `/qualia-plan`). M2..M{N-1} have phase names + one-line goals. Full phase detail gets written by roadmapper when the milestone opens.

package/templates/project-discovery.md

@@ -6,9 +6,9 @@ discovery_mode: project
 
 # Project Discovery, {Project Name}
 
-The non-technical kickoff interview output. `/qualia-scope` writes this in PROJECT MODE before `/qualia-new` generates JOURNEY.md. Captures intent, audience, brand, and constraints in the user's own words.
+The non-technical kickoff interview output. `/qualia-scope` writes this in PROJECT MODE before `/qualia-new` generates JOURNEY.md. Captures intent, audience, brand, constraints — and, for full projects, the **complete capability set that defines the project as DONE** so the roadmap can span the whole arc, not a v1 slice.
 
-Demo path: 8 questions. Full-project path: 14 questions.
+Demo path: §1–§8 (8 questions). Full-project path: §1–§15 (adds the completeness pass + delivery questions).
 
 ## 1. The one-line pitch
 
@@ -36,48 +36,55 @@ Demo path: 8 questions. Full-project path: 14 questions.
 
 ## 7. Hard constraints
 
-> {Anything that is non-negotiable: stack, deadline, compliance, integrations, budget.}
+> {Anything non-negotiable: stack, deadline, compliance, integrations, budget.}
 
-## 8. Out of scope
+## 8. Out of scope (explicitly deferred)
 
-> {What is intentionally NOT in this project, even if it would be obvious to add.}
+> {What is intentionally NOT in this project — work the client has consciously deferred, even if obvious to add. This is the ONLY place work leaves the arc; anything not listed here is in-scope and must land in a milestone.}
 
 ---
 
-The remaining six questions only run for `project_type: full`. Demo mode stops here.
+The remaining questions only run for `project_type: full`. Demo mode stops here.
 
-## 9. Milestone arc, in the client's words
+## 9. Capability inventory — the WHOLE project
 
-> {After the demo, what's the next chapter? After that, what's the chapter after? Stop at three to five chapters total. The last chapter is always Handoff.}
+> {List EVERY capability this project must have to be considered finished — not a v1 slice, the whole thing. One bullet per capability, plain language. Push for completeness: "what else does it need before you'd call it done?" Keep asking until the client says "that's everything." This list becomes the REQ-IDs and milestones — anything missing here is what the team is later forced to improvise, so it is the most important answer in the interview.}
 
-## 10. Compliance and legal
+## 10. Definition of done — for the entire project
+
+> {Describe the end state where there is no more agreed work. What is true when the project is finished and the team stops? This anchors the final milestone (Handoff for client projects) and tells the roadmapper how far the arc must reach.}
+
+## 11. Shipping order
+
+> {Roughly what order should the capabilities in §9 ship in? Group them into chapters if natural. We shape milestones from this — as many as the scope needs, no artificial cap. For client projects the last chapter is Handoff; for an internal or ongoing product it may have no Handoff.}
+
+## 12. Compliance and legal
 
 > {Anything regulated: payments, medical, legal, finance, accessibility commitments, data residency.}
 
-## 11. Integrations
+## 13. Integrations
 
 > {Third-party systems this must talk to, in priority order.}
 
-## 12. Content and copy
+## 14. Content and copy
 
 > {Who writes the copy and where does it live, today and after handoff?}
 
-## 13. Team and roles after handoff
+## 15. Ownership, team, and delivery shape
 
-> {Who maintains this after we ship? What can they do, what can't they do?}
-
-## 14. Budget and timeline shape
-
-> {Fixed deadline, fixed scope, or fixed budget? Pick one — the other two flex.}
+> {Who maintains this after we ship — what can they do, what can't they? And: fixed deadline, fixed scope, or fixed budget? Pick one — the other two flex.}
 
 ---
 
 ## How this feeds `/qualia-new`
 
-- §1-§5 seed PROJECT.md (one-line pitch, what we're building) and PRODUCT.md (users, register, voice, anti-references).
+- §1–§5 seed PROJECT.md (one-line pitch, what we're building) and PRODUCT.md (users, register, voice, anti-references).
 - §6 becomes the first row of the success-criteria table in ROADMAP.md.
-- §7-§8 populate PROJECT.md's "Out of Scope" and the constraints section.
-- §9 (full only) seeds JOURNEY.md milestone names + "why now" lines.
-- §10-§14 (full only) feed research scoping and the Handoff milestone checklist.
-
-Demo projects skip §9-§14 because they ARE one milestone — the journey is just that milestone plus an implicit "client signs, we extend" branch handled by `/qualia-milestone`.
+- §7 populates PROJECT.md's constraints section.
+- §8 populates PROJECT.md's "Out of Scope" — the explicit, client-agreed deferrals (the roadmapper must NOT defer anything else here).
+- **§9 (full only) is the capability inventory → every item becomes a REQ-ID in REQUIREMENTS.md, assigned to exactly one milestone. The roadmapper must cover ALL of §9 across the arc — no overflow into an unplanned "v2".**
+- **§10 (full only) defines the arc's endpoint → the roadmapper builds milestones until the whole capability set reaches this done-state.**
+- §11 (full only) seeds JOURNEY.md milestone order + "why now" lines (no milestone cap — the arc is as long as §9 requires).
+- §12–§15 (full only) feed research scoping, integrations, and the Handoff milestone checklist.
+
+Demo projects skip §9–§15 because they ARE one milestone — the journey is just that milestone plus an implicit "client signs, we extend" branch handled by `/qualia-milestone`.