@ritualai/cli 0.24.0 → 0.36.8

package/skills/codex/ritual/references/build-flow.md

@@ -25,7 +25,8 @@ When the user says "tighten the scope," call `generate_problem_statement(...)` w
 
 Before running this flow, apply `references/cli-output-contract.md` and `references/async-polling.md`. Keep raw recon internal, pass the `codebase_context_packet` downstream, and show the user only the compact `recon_digest`.
 
-**Build rail is load-bearing.** Every top-level user-facing message below MUST begin with the 6-stage build rail per `references/cli-output-contract.md` § Build progress anchor. Examples in this file show the rail in context; the canonical stage table + `progressHeader(stage)` spec lives in the output contract. Do not drop the rail to save space.
+<!-- skill-options:no-gate-change: deliverable-named rail — stage labels + conditional Implementation stage only; no pause or option changes -->
+**Build rail is load-bearing.** Every top-level user-facing message below MUST begin with the build rail per `references/cli-output-contract.md` § Build progress anchor — SIX stages for development jobs, FIVE for non-development jobs (no `Implementation` stage), with stage 5 named for the job's deliverable (`deliverableTemplate` from the Job gate). The literal `Build brief` in this file's examples is the generic-build label; substitute the confirmed job's deliverable name. Examples in this file show the rail in context; the canonical stage table + `progressHeader(stage)` spec lives in the output contract. Do not drop the rail to save space.
 
 For narrow/mobile chat surfaces, use the **compact progress anchor** defined in `references/cli-output-contract.md` § Build progress anchor (the `Ritual build · 2/6 Scope` chip) instead of forcing the full six-stage rail to wrap. Same contract, different rendering.
 
@@ -105,6 +106,58 @@ If the user types `always audit for this build` mid-flow at the Step 9.6 prompt,
 
 Persist `auditMode` to `Exploration.metadata.auditMode` at `create_exploration` time (additive JSONB key — no schema migration) so `/ritual resume <exploration-id>` picks up the same mode the original build started with, and `/ritual lineage <exploration-id>` can render which gates ran + their outcomes.
 
+<!-- lite:keep-start -->
+#### Step 0.7 — The Job gate: classify the job to be done
+
+**The FIRST tool call of a fresh build.** The server — not you — classifies the user's raw ask into
+one canonical job-to-be-done (the full catalog: development, product, marketing, prototyping). Your
+job is to relay the result and get an explicit confirmation before ANYTHING else happens. This is the
+`Job` stage of the build rail (see `references/cli-output-contract.md`).
+
+When this gate runs:
+- `/ritual build <ask text>` → run it IMMEDIATELY, before the workspace pick.
+- Bare `/ritual build` (no ask) → proceed to Step 1/1.5 first; the moment a FRESH ask is captured
+  (the user describes what they want to build), run this gate before continuing.
+- Resume paths (Step 1.5 → resume) → skip this gate entirely; the exploration's job is already set.
+
+1. **Call `mcp__ritual__classify_work_item`** with `raw_input` = the user's ask, verbatim. Do NOT
+   classify yourself, do NOT pre-filter to development jobs. It returns
+   `{ jtbd, workItemLabel, deliverableTemplate, why, personaCoverage }`.
+
+2. **Render the validation prompt** (rail stage `Job`):
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ {Deliverable}  ○ Implementation (Your agent)
+
+   You're looking to: {restate the ask in one short clause}
+   The job to be done: {workItemLabel} — {why}
+   Deliverable: {deliverableTemplate}
+
+   Reply `proceed` to frame the problem (sub-problems + problem statement), or tell me what the
+   job actually is.
+   ```
+
+   Do not render `personaCoverage` — persona representation is handled server-side now; only surface
+   it if the user explicitly asks who's involved.
+
+   Rail naming (deliverable-named rail, 2026-06-11): render `{Deliverable}` as the PROPOSED job's
+   `deliverableTemplate` (e.g. `Launch Brief`, `PRD`, `Service Build Brief`; `Build brief` for the
+   generic `build-feature`), and OMIT the `Implementation (Your agent)` stage entirely when the
+   proposed job is not a development job — non-dev rails have FIVE stages ending at the deliverable.
+   A correction that changes the job updates the rail on the next render. Spec:
+   `references/cli-output-contract.md` § Canonical stage table.
+
+3. **[USER PAUSE]** — wait for the user's actual reply. Never infer confirmation from the original
+   ask, auto-mode, or silence. `proceed` / `yes` / `ok` confirms. ANY other substantive reply is a
+   correction: call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input`, plus
+   `correction` (the user's words) and `previous_jtbd` (the rejected slug), then re-render step 2.
+   Loop until the user proceeds.
+
+4. **Remember the confirmed `jtbd`** — you pass it to `create_exploration` at Step 6. Only after the
+   user proceeds does the flow enter the `Scope` stage (workspace pick onward).
+<!-- lite:keep-end -->
+
 #### Step 1 — Pick a workspace
 
 <!-- skill-options:no-gate-change: connection-freshness ping check is a non-interactive warn, adds no user-facing gate or option -->
@@ -135,7 +188,17 @@ Resolution order:
    > Override with `workspace: list`.
 
    Pause only if the file is missing/malformed, the workspace cannot be accessed (validation failed above), or the user explicitly asks to switch.
-2. **List existing project workspaces.** If no `.ritual/config.json`, call `mcp__ritual__list_workspaces` — this returns project-type workspaces (the General workspace is excluded by default; agents never use it). Present as a numbered list (id, name). **[USER PAUSE]** for selection.
+2. **List existing project workspaces.** If no `.ritual/config.json`, call `mcp__ritual__list_workspaces` — this returns project-type workspaces (the General workspace is excluded by default; agents never use it). This path is usually a first-time user who has never been told what a workspace IS — open the render with the one-line explainer (same register as the CLI's `ritual init`), then the numbered list (id, name):
+
+   <!-- skill-options:no-gate-change: adds explainer prose to the existing workspace-pick gate; options and pause unchanged -->
+
+   > No `.ritual/config.json` found — this repo isn't bound to a workspace yet.
+   > A workspace is Ritual's memory for this codebase: the context and reasoning behind every build lands there, so the next build (by you, a teammate, or an agent) starts from what's already known.
+   >
+   > Which workspace should this exploration live in?
+   > {numbered list}
+
+   **[USER PAUSE]** for selection.
 3. **Create a new one if none exist or user wants a fresh one.** Call `mcp__ritual__create_workspace` with a name — convention is to name it after the repo (basename of cwd, or origin remote). Confirm the name with the user first. **[USER PAUSE]**
 
 Store `workspace_id` for the rest of the flow.
@@ -159,6 +222,7 @@ When you later see `.ritual/config.json` in `git status` output (modified or unt
 
 #### Step 1.1 — No-arg `/ritual build` entry
 
+<!-- skill-options:no-gate-change: ask-copy gains example asks + the granularity teaching line; no pause or option changes -->
 If the user invokes `/ritual build` with no problem statement, set `raw_input = null` and **do not ask for a problem statement before checking the workspace**. A no-arg build is often a continuation or next-work discovery intent, so `resume` and `suggest high-leverage work` must remain available.
 
 After workspace selection, proceed into the existing-exploration check below. User-facing copy should avoid internal step labels and should offer these paths when applicable:
@@ -173,13 +237,16 @@ Reply with:
 - `suggest` to have me look for high-leverage candidates from repo + workspace history
 - a feature/problem description to start fresh
 - `none` to exit
+
+e.g. "audit log for admin actions" — a few words works; discovery extracts
+the detail. Constraints and exclusions you type become binding scope.
 ```
 
 If there are **zero existing explorations** and `raw_input = null`, do not say "starting fresh" and do not advance to template selection yet. Ask for the feature/problem first:
 
 ```text
 Ritual build
-● Context  ○ Scope  ○ Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
+✓ Job  ● Scope  ○ Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
 Heads-up: Ritual's build flow needs ~5 real decisions from you (workspace,
 scope, discovery picks, rec acceptance, implementation approval). If your
@@ -193,6 +260,15 @@ No Ritual history here yet.
 
 Next: start with a feature, or let Ritual suggest high-leverage work from the repo.
 
+Any granularity works, and any job — not just code:
+  "audit log for admin actions"
+  "Add soft-delete for projects. Restorable 30 days, then purge via the
+   existing background-job system. Don't touch billing records; exports
+   must exclude deleted data."
+  "draft the launch brief for the new pricing tier"
+A few words → discovery extracts the detail. Constraints and exclusions
+you type become binding scope.
+
 Reply with a feature/problem description, `suggest`, `pulse <ask>`, or `none`.
 ```
 
@@ -480,7 +556,7 @@ Steps:
 
 #### Step 2 — Template selection (server-side, silent)
 
-> **Rewritten 2026-05-21 (CLI 0.9.0+).** Previously this section had three branches (persona-pinned / legacy-pinned / list-and-pick) that the SKILL had to navigate, and could optionally call `mcp__ritual__list_templates`. That tool is gone from the agent-facing MCP surface as of CLI 0.9.0. Template selection is now entirely server-side: when `create_exploration` is called without an explicit `template_id`, the server resolves the right SYSTEM template from `user.persona` (set by `ritual init` FTUE) → `workspace.defaultTemplateId` (team override) → system default, then forks it into a per-exploration Template atomically inside the same `create_exploration` request.
+> **Rewritten 2026-05-21 (CLI 0.9.0+), chain updated 2026-06-11 (JTBD-first entry).** Previously this section had three branches (persona-pinned / legacy-pinned / list-and-pick) that the SKILL had to navigate, and could optionally call `mcp__ritual__list_templates`. That tool is gone from the agent-facing MCP surface as of CLI 0.9.0. Template selection is now entirely server-side: when `create_exploration` is called without an explicit `template_id`, the server resolves the right SYSTEM template from the exploration's `jtbd` (the job confirmed at the Step 0.7 Job gate) → `workspace.defaultTemplateId` (team override) → `user.persona` (legacy — the FTUE picker is gone; set only via `ritual init --persona`) → a designated generic fallback → system default, then forks it into a per-exploration Template atomically inside the same `create_exploration` request.
 
 **For the agent: there is no template-selection step. Skip this Step entirely and go to Step 3.** Don't read `.ritual/config.json` for persona, don't try to call `list_templates` (it's not registered), don't render a "Using persona X" confirmation.
 
@@ -491,9 +567,12 @@ Why no user-visible confirmation: a "do you want to continue with your persona?"
 ```
 1. Resolve PARENT template from the chain:
      explicit dto.templateId
+     → jtbd → the picked job's deliverable template
      → workspace.defaultTemplateId
-     → user.persona via schema.id-matching SYSTEM template
-     → first SYSTEM template by createdAt
+     → user.persona via schema.id-matching SYSTEM template (legacy)
+     → designated generic fallback (build-feature → Backend Service
+       (Implementation Brief); produce-deliverable → Product Brief)
+     → first SYSTEM template by createdAt (last resort)
 2. FORK the parent into a per-exploration Template row
    (type='EXPLORATION', parentTemplateId set, schema copied)
 3. CREATE the Exploration pointing at the forked template
@@ -508,317 +587,28 @@ All atomic in one HTTP request. See `apps/api/src/modules/explorations/explorati
 
 Recognized roles (use the role keyword the API returns, not a paraphrase): `engineering`, `product`, `design`, `marketing`, `delivery`, `operations`.
 
-If the user corrects the role mid-flow ("actually I'm building a PRD"), update internal role tracking. **Do not** re-pick the template — that requires re-creating the exploration, which is bigger than a mid-flow correction warrants. If the user genuinely wants a different template for this exploration, ask them to start over: `/ritual build` again, or `ritual init --persona <slug>` to change their default first.
+If the user corrects the role mid-flow ("actually I'm building a PRD"), update internal role tracking. **Do not** re-pick the template — that requires re-creating the exploration, which is bigger than a mid-flow correction warrants. If the user genuinely wants a different template for this exploration, ask them to start over with `/ritual build` and correct the job at the Job gate (the jtbd drives the template now; `ritual init --persona <slug>` only changes the legacy personal default).
 
 Proceed to Step 3.
 
-#### Step 3 — Code reconnaissance
-
-**Skip only if the user explicitly asks ("just generate, don't read the code") OR if you're operating outside a codebase context.**
-
-Before generating considerations, gather codebase context so the sub-problems land specific to *this* code, not generic. The goal is not to show the user every fact you found; the goal is to ground downstream MCP calls and expose only decision-relevant findings in the CLI.
-
-**Capability Boundary Check (load-bearing):** If recon detects a mismatch between the user's ask and what THIS repo can actually implement — typically because the feature spans systems (backend service, mobile app, billing provider, email worker, schema migrations) that aren't present in the current checkout — DO NOT invent the missing systems and DO NOT continue as if the repo is complete. Run the boundary-check pause described in § 3.2 below before proceeding to scope. Frame the missing half as a normal architecture boundary, not a failure: *"This repo looks like the frontend side of a larger feature,"* not *"I could not find backend dependencies."* The user has not done anything wrong; the agent is asking how to scope the work.
-
-Common boundary mismatches to detect:
-
-- Full-stack feature ask + frontend-only repo (UI present, no API/service code)
-- Mobile feature ask + no API client contract or backend
-- Billing/payments feature + no payment service / subscription code
-- Email/notification feature + no worker / job / email-provider integration
-- Auth/session feature + no user mutation / session backend
-- Data/analytics feature + no schema, migration, or storage layer
-
-##### 3.0 — Check for a pre-build context seed
-
-Before doing fresh recon, check whether the user already seeded one via `/ritual context-pulse`. Glob for `CONTEXT-*.md` at the repo root.
-
-If a `CONTEXT-<slug>.md` is found AND its `## The ask` section close-matches the current `raw_input`:
-
-- **Use it to seed `codebase_context_packet`.** Parse the file's `## Candidate files` list — those become the seed for `sources[]`. Parse `## Prior KG context` as evidence inside the packet, not as final prioritization.
-- **Skip fresh recon** unless the seed is stale or obviously incomplete. If you skip fresh recon, still normalize the seed into the packet structure below before calling MCP tools.
-- **Surface a compact note**:
-  > Code recon
-  > Found `CONTEXT-<slug>.md` from `/ritual context-pulse`.
-  > Using {N} candidate files + {M} related prior exploration{s} as the recon base. Override with `recon: refresh`.
-- Proceed directly to 3.2.
-
-If no seed file is found, OR the seed's `## The ask` doesn't match the current `raw_input`, do fresh recon. For mismatch, mention the ignored seed in one line and do not delete it.
-
-##### 3.1 — Fresh recon
-
-1. **Read the README + top-level project structure.** Use `ls` / Glob to see top-level files. Identify the language, framework, key directories, and likely entry points.
-
-2. **Glob for relevance.** Derive patterns from the user's problem. Examples:
-   - User says "auth flow" → `**/auth/**`, `**/login*`, `**/user*`, `**/session*`
-   - User says "checkout" → `**/checkout/**`, `**/cart/**`, `**/order/**`, `**/payment*`
-   - User says "notifications" → `**/notif*`, `**/email/**`, `**/sms/**`, `**/push/**`
-   Cap at ~15 hits per pattern.
-
-3. **Skim 3–5 most-relevant files.** For each, read the first ~100 lines + scan for class/function names. Triangulate whether the behavior lives there or calls into another area.
-
-4. **Build three recon artifacts.**
-
-   A. `raw_recon_notes` — internal evidence only
-   - files read and why they were selected
-   - symbols/classes/functions inspected
-   - relevant comments, schema details, tests, migrations, and config
-   - KG hits, prior deferrals, and prior implementation references
-   - uncertain observations, false leads, and things not found
-   - do **not** show this by default and do **not** pass it as the main MCP planning input
-
-   B. `codebase_context_packet` — downstream planning input
-   - this is the synthesized artifact passed into `raw_input`, context pulses, and any MCP field named `recon_context`
-   - it helps MCP understand what the coding agent observed locally without deciding the final considerations itself
-   - separate factual observations from agent hypotheses
-   - include confidence levels for hypotheses
-   - use neutral labels like `agent_observed_scope_pressure` or `candidate_scope_pressure`, not `priority_considerations`
-   - never present the packet as authoritative; MCP/tooling decides final sub-problems, recommendations, and scope
-
-   C. `recon_digest` — user-visible, compact
-   - 3–6 bullets max
-   - key surfaces, hard constraints, scope corrections, and next action
-   - avoid quoting code comments unless they are load-bearing
-   - avoid listing every file read
-
-   `codebase_context_packet` structure:
-
-   ```markdown
-   --- Codebase context packet ---
-
-   ## User intent
-   {verbatim or lightly normalized ask}
-
-   ## Observed relevant surfaces
-   - `path` — observed role in this feature or constraint
-   - `path` — observed extension point, lifecycle, model, or integration seam
-
-   ## Evidence
-   - `path:symbol` — factual observation from code
-   - Prior Ritual signal: {exploration / PR / RB / deferral}, if available
-   - Missing or not-found evidence when it corrects the user's framing
-
-   ## Agent hypotheses
-   - This may make {candidate area} important because {evidence-backed reason}
-     Confidence: low / medium / high
-
-   ## Agent-observed scope pressure
-   - Privacy / lifecycle / migration / compatibility / async / ownership / testing risk
-   - Only include pressure that intersects with the feature intent and code evidence
-
-   ## Scope corrections
-   - The ask says X, but the code suggests Y
-   - Missing fields, renamed concepts, or assumptions the code contradicts
-
-   ## Open questions for discovery
-   - Questions the code cannot answer and the user/Ritual exploration should resolve
-   ```
-
-   Example `codebase_context_packet` excerpt:
-
-   ```markdown
-   ## Observed relevant surfaces
-   - `apps/conversions/abstract_models.py` — append-only conversion event model; lifecycle changes are modeled as follow-up rows.
-   - `apps/conversions/outbox.py` — async publish/retry surface; payload shape may affect erasure semantics.
-   - `apps/order/models.py` — raw guest email appears to live on the order side, not in conversion events.
-
-   ## Agent hypotheses
-   - Erasure semantics may need to cover both mutable raw PII and append-only pseudonymous digests.
-     Confidence: high; supported by model fields and schema comments.
-   - Outbox purge/replay behavior may be a scope pressure because retries can outlive the original conversion write.
-     Confidence: medium; verify worker idempotency before scoping implementation.
-
-   ## Scope corrections
-   - No `guest_session_id` column was found in the inspected conversion models; scope may need to use the actual guest attribution identifiers.
-   ```
-
-   Example `recon_digest` — single-path case (low ambiguity):
-
-   ```text
-   Code recon
-
-   Repo signals:
-   - `apps/conversions/abstract_models.py` — append-only conversion events.
-   - `apps/conversions/outbox.py` — async publish/retry lifecycle.
-   - `apps/order/models.py` — raw guest email surface.
-
-   Constraint:
-   - Erasure likely needs to handle mutable raw PII separately from pseudonymous conversion digests.
-
-   Scope correction:
-   - I did not find `guest_session_id` in the inspected models.
-
-   Pulse: Reasoning Readiness ~55% · Context Debt 45% (initial ask + code recon)
-
-   Next: attach PRDs/tickets if they should shape scope, or `proceed` to continue.
-   ```
-
-   Example `recon_digest` — ambiguity case (multiple plausible interpretations):
-
-   When recon surfaces two materially different product/implementation paths for the same ask, name them both, **mark one as recommended with a one-line reason**, and pause with a concrete reply syntax. Do not expose raw tier labels (use the translations from `references/cli-output-contract.md`).
-
-   ```text
-   Code recon
-
-   Repo signals:
-   - `GatewayForm` already supports "create account before checkout," but
-     redirects away from checkout to `customer:register`. There is no inline
-     or post-order account path today.
-   - Guest checkout is already wired through order placement:
-     `CheckoutSessionData.set_guest_email()`, `AbstractOrder.guest_email`, and
-     `build_submission()` preserve guest identity.
-   - `RegisterUserMixin` is the reusable account-creation surface:
-     user creation, `user_registered`, login, and registration email.
-   - `OrderPlacementMixin` and `post_checkout` are the clean hooks for
-     creating or claiming an account at order placement.
-
-   Constraint:
-   - Oscar's dynamic class loading via `get_class()` is the extension
-     pattern here. Implement with subclass-overridable views/mixins, not
-     monkey-patches.
-
-   Ambiguity to resolve:
-   "Join while booking" maps to two plausible features.
-
-     1. Inline registration at checkout
-        Let new customers register on the checkout page itself instead of
-        being redirected to `/accounts/register/`.
-
-     2. Post-order account creation — recommended
-        Let guests place the order as today, then claim the order by
-        setting a password on the thank-you page. Preserves guest checkout
-        and fits Oscar's `OrderPlacementMixin` / `post_checkout` hooks.
-
-   Pulse: Reasoning Readiness ~35% · Context Debt 65% (scope not locked yet)
-
-   Next: reply `2` for the recommended post-order path, `1` for inline
-   registration, or describe a different intent. Reply `pause` to stop here.
-   ```
-
-   Notes on the ambiguity-case shape:
-   - **"Repo signals"** (not "Found" or "Key surfaces") signals these are the evidence behind the recommendation.
-   - **Recommendation goes after the option name on the SAME line**, with a single concise reason on the line below. This keeps the options scannable in a decision moment.
-   - **`Next:` is a single line** ending in a concrete reply syntax (`reply N`), not an open-ended question. Lead with the recommended default; the escape hatch comes last.
-   - **The pulse line uses the user-facing label**, never the raw tier identifier.
-
-   Example `recon_digest` — Capability Boundary Check (feature spans systems not in this repo):
-
-   When the user's ask requires capabilities that aren't present in this repo (frontend-only repo asked for full-stack feature, mobile repo with no API contract, etc.), surface the boundary as a normal architecture fact and name the three scoping options as **informational** context. **Do not pause on this.** The boundary information is folded into the `codebase_context_packet` so the downstream `generate_considerations` call produces boundary-aware sub-problems against the repo's actual capability surface. The user's first real gate is the problem statement in Step 5 — they can reshape scope there if the default narrowing was wrong. NEVER continue as if the repo can implement the missing half; NEVER invent the missing systems.
-
-   ```text
-   Code recon
-
-   Action needed
-
-     This feature likely spans another repo or service.
-     Add the backend/API context, or choose a narrower scope.
-
-   Repo boundary:
-   - This repo contains the checkout UI and guest checkout flow.
-   - I found no backend account-creation endpoint, user/order linking
-     mutation, email job, or migration layer.
-   - So the full "join while booking" feature likely spans this repo plus
-     an API/backend service.
-
-   Can build here:
-   - Checkout/thank-you page UI
-   - Password capture or account-claim form
-   - API client integration point
-   - Mocked frontend tests
-   - Empty/error/success states
-
-   Needs outside context:
-   - Endpoint that creates or claims the account
-   - Contract for linking a guest order to a user
-   - Auth/session behavior after claim
-   - Email/verification behavior, if required
-
-   Scoping inferred: contract-first (default for unsettled API)
-
-     This repo can build: UI integration, API client surface, mocked tests
-     This repo cannot build: account-creation endpoint, order-linking, email job
-     Considerations will be scoped to what this repo can ship.
-
-   Pulse: Reasoning Readiness ~30% · Context Debt 70% (repo boundary unresolved)
-
-   Continuing to problem statement. You can reshape scope there in plain
-   English (e.g. "frontend-only", "add the backend service contract",
-   or paste API docs to widen the recon).
-   ```
-
-   Notes on the boundary-check shape:
-   - **No pause.** Surface the boundary as compact info inside the recon digest, then proceed to `generate_considerations`. The user's first gate is the problem statement (Step 5) where they can reshape scope in plain English. Pausing here was load-bearing in the old SKILL, but it gated FTUE users behind a 1/2/3 menu before they'd seen any product output. The boundary information is preserved — both in user-facing recon (the "Scoping inferred:" block) and in the `codebase_context_packet` that feeds downstream MCP calls.
-   - **"Scoping inferred:" not "How should I scope this?"** — the agent makes the default narrowing (contract-first when API unsettled; repo-side-only when the missing half is clearly out-of-tree) and names what it picked. The user corrects at Step 5 if it was wrong.
-   - **"This repo can build:" + "This repo cannot build:"** are paired one-liners — they document the IN/OUT split so the inferred scoping is auditable. Keep them compact (one line each); the full lists live in `codebase_context_packet`.
-   - **Default narrowing logic:** if the user's ask names a backend/API endpoint, choose **contract-first**. If the user's ask is clearly UI/UX-shaped or the missing systems are obviously out-of-tree (mobile app, separate billing service), choose **repo-side only**. If ambiguous, default to **contract-first** — it preserves more of the user's intent in the downstream artifacts than narrowing to repo-side does.
-   - **The pulse line stays parenthetical** with a user-facing reason (`repo boundary unresolved`), per the Pulse tier labels rule in `references/cli-output-contract.md`.
-   - **Internal classification (not user-facing):** track each candidate piece against the boundary as `in_repo_buildable`, `external_dependency_known`, `external_dependency_unknown`, `needs_additional_repo`, or `contract_first_candidate`. These shape how downstream scoring + build-brief generation handle the missing half. Stamp the inferred default scope as `inferred_scope` in the packet so `generate_considerations` / `generate_problem_statement` see it. None of these labels should appear in user-facing copy.
-
-##### 3.2 — Surface the digest and continue
-
-Surface only `recon_digest` by default. Do **not** dump `raw_recon_notes` or the full `codebase_context_packet` to the CLI unless the user asks for detail.
-
-Pause only if:
-- recon contradicts the user's stated scope,
-- there are multiple plausible implementation areas and choosing wrong would waste work (use the ambiguity-case `recon_digest` shape above),
-- a legal/product/business constraint is required before generation,
-- the user explicitly asked to review recon before continuing.
-
-**Capability boundary detection does NOT pause.** When recon shows the feature spans systems not in this repo, render the Capability Boundary Check digest from § 3.1 (it's informational), pick the default scope per the "Default narrowing logic" rule, and proceed to Step 3.5. The user reshapes scope at Step 5 (problem-statement gate) if the default narrowing was wrong.
-
-If no pause is needed, proceed to Step 3.5. The user still has a cheap escape hatch: `recon: detail`, `recon: refresh`, or a correction in plain English.
-
-**Pulse (Step 3 done):** Emit a pulse line — repo grounding just moved meaningfully (sources collected, agent inspected files, possibly KG hits). Compute per `/ritual context-pulse` § Step CP3 and render compact unless this is the FIRST pulse of the build flow, in which case use full.
+#### Step 3 — Code reconnaissance moved (no step here)
 
-##### 3.3 — Compose augmented `raw_input`
-
-Compose the augmented `raw_input` for Step 4 from:
-- the user's original problem (verbatim, top)
-- the full `codebase_context_packet`, under `--- Codebase context packet ---`
-- any user correction or added constraint from code recon
-
-Do not pass unsynthesized `raw_recon_notes` as the primary planning input. Step 3 is the difference between generic considerations and considerations grounded in actual code, patterns, risks, and open questions. Keep `raw_recon_notes` internally for auditability; pass the packet downstream for planning.
-
-##### 3.4 — Collect the `sources` array
-
-Collect the file paths you actually read and consider load-bearing for this problem — exactly as they appear in the repo (e.g. `"apps/checkout/views.py"`, not `"./apps/checkout/views.py"` or absolute paths). This list is passed alongside `raw_input` to `generate_considerations`, `generate_problem_statement`, `query_knowledge_graph`, context pulses, and `generate_build_brief` so the API can anchor priorContext consistently.
-
-Keep the list focused. 5–10 is the sweet spot; >20 dilutes the KG signal.
+> **Relocated 2026-06-11 (context-at-create).** Recon no longer runs before sub-problem
+> generation — it runs AFTER the user locks the problem frame, as **Step 5.7**, so the first
+> product output (sub-problems + frame) lands seconds after the Job gate instead of waiting on
+> repo reads. Step 4 generates sub-problems from the user's ask alone; grounding arrives at
+> discovery via the `additional_context` persisted at create. Nothing to do here — continue to
+> Step 3.5.
 
 #### Step 3.5 — Stage knowledge sources (PRDs / tickets / transcripts / etc.)
 
-The codebase recon you just did handles the *code* grounding. Most real features ALSO have non-code context — PRDs, Jira/Linear tickets, design specs, meeting transcripts, Slack threads, customer-research notes — that get paraphrased into the problem statement and lose detail. Step 3.5 ingests those as first-class **knowledge sources** attached to the exploration BEFORE generating sub-problems, so the priorContext you'll see in Step 4 (`generate_considerations`) and downstream is grounded in what the user actually brought, not the paraphrase.
-
-##### 3.5.1 — Prompt the user only when useful
-
-Knowledge sources are a feature multiplier, not a mandatory gate. Ask for PRDs/tickets/designs/transcripts only when at least one of these is true:
-
-- the ask is ambiguous or cross-functional,
-- context-pulse / Reference Grounding is low,
-- the user mentioned a PRD, ticket, design, chat, customer request, or meeting,
-- the feature has legal, privacy, billing, permissions, enterprise, analytics, migration, or compliance constraints,
-- code recon found implementation surfaces but not product intent.
-
-When triggered, frame references as an optional booster, not a mandatory phase. The happy path is to continue. Keep the prompt tight — the user's decision here is simply "attach context or continue":
-
-```text
-Optional: add non-code context before scope generation.
-
-Because this touches {constraint}, PRDs, tickets, designs, incidents, or
-customer requests may change what we prioritize.
-
-Reply `go` to continue with code context only.
-Or paste files/text/URLs to attach context first.
-Reply `pause` to stop here.
-```
+Code grounding happens silently after the frame locks (Step 5.7). Most real features ALSO have non-code context — PRDs, Jira/Linear tickets, design specs, meeting transcripts, Slack threads, customer-research notes — that get paraphrased into the problem statement and lose detail. Step 3.5 ingests those as first-class **knowledge sources** attached to the exploration BEFORE generating sub-problems, so the priorContext you'll see in Step 4 (`generate_considerations`) and downstream is grounded in what the user actually brought, not the paraphrase.
 
-Accept (alias) `go`, `g`, `generate`, `continue`, `skip`, `next`, or `none` as proceed. Per `references/cli-output-contract.md` § Surface-aware continuation prompts, do NOT treat empty input as proceed inside agent chat — chat surfaces can't reliably observe an empty message. Wait only if the user provides refs, asks a question, or types `pause` / `stop`.
+##### 3.5.1 — Reactive only — do NOT prompt for non-code context
 
-Process language like *"Next: we'll generate a list of suggested problems to pick from"* used to live here — removed because the decision at this moment is "attach context or continue," not a preview of what comes next. The follow-up step's framing belongs in the follow-up step, not stacked on this prompt.
+**Do NOT proactively ask the user to attach PRDs/tickets/designs/transcripts.** This is a pure capability, not a gate — surfacing an "Optional: add non-code context" prompt before the user has even framed the problem is front-of-flow friction we deliberately removed (it also tends to over-justify *why* it matters, which is internal reasoning the user doesn't need). There is **no pause here.**
 
-If none of the triggers apply, do **not** block. Print a non-blocking line and proceed:
-
-> Proceeding with codebase context only. Paste a PRD/ticket anytime before discovery if it should shape the scope.
+Handle knowledge sources **only reactively**: if the user *spontaneously* pastes a file/URL/text or says "use this PRD/ticket," ingest it via 3.5.2–3.5.4 below. Otherwise say nothing and proceed silently to Step 4 with code context only. The user can always attach context later via `/ritual context-pulse <exploration>` or by dragging refs in mid-flow.
 
 ##### 3.5.2 — Read the content
 
@@ -896,54 +686,14 @@ If the user says "skip" / "none" / "later", proceed silently to Step 4. Do NOT p
 
 The user can always come back later with `/ritual context-pulse <exploration>` to see the current Reference Grounding score, OR drag refs in mid-flow (e.g. at Step 8 if the agentic run surfaces a question that a PRD would have answered).
 
-#### Step 3.9 — Classify the work item + pick the lead persona
-
-Before generating sub-problems, settle **what job this is** and **whose lens leads it** — both shape
-everything downstream, so they come first. **You** classify the job (you have the repo open — you're the
-best-informed classifier, and doing it here saves a backend LLM call); the server returns the lenses.
-
-1. **Classify the request** into ONE development work-item slug, using the user's raw ask + your code
-   recon:
-
-   ```text
-   understand-codebase-area · design-technical-approach · create-implementation-plan ·
-   build-frontend-feature · build-backend-service · integrate-api · create-docs-site ·
-   refactor-code · debug-production-issue · improve-performance · add-tests · prepare-release
-   ```
+#### Step 3.9 — Work item settled at the Job gate (no step here)
 
-   (Use `build-feature` only when the ask is a generic build that none of the specific jobs fit.) Pick the
-   single best match — e.g. "add OAuth to the dashboard" → `build-backend-service`; "the checkout page is
-   slow" → `improve-performance`; "clean up the payments module" → `refactor-code`.
-
-2. **Call `mcp__ritual__work_item`** with that `jtbd` (and `entry_use_case` if known). It returns
-   `{ workItemLabel, deliverableTemplate, recommended, options: [{ persona, label, whenToChoose }] }` —
-   deterministic, no LLM, already biased by the user's `ritual init` persona.
-
-3. **Present the work item + lens options** as a `(label + description)` bottom-drawer choice picker
-   (same shape as discovery picks, per `references/cli-output-contract.md`), recommended lens first and
-   marked:
-
-   ```text
-   This looks like: Build backend service / API → Service Build Brief
-   Who's leading it? (recommended: Backend Developer)
-
-   1. Backend Developer — Best when you care about API contracts, data, transactions, scaling.  ← recommended
-   2. Developer — Best when you care about feasibility, implementation correctness, shippability.
-   3. Eng Lead — Best when you care about technical approach, risk, sequencing, review.
-
-   Reply `use` to lead as Backend Developer, a number to switch, or name a lens.
-   ```
-
-4. **Default = the recommended lens.** An ambiguous reply (`use`/`ok`/`go`) accepts it. If the user says
-   the *work item* is wrong ("no, this is a refactor"), re-classify and call `work_item` again. If they
-   switch the *lens*, that's a change → run the change pre-flight (`references/change-preflight.md`) to
-   confirm before adopting it.
-
-5. **Remember the chosen `persona` slug** — you pass it through to `create_exploration` as `lead_persona`
-   at Step 6. (It also carries into the generation prompts once persona-aware generation ships; for now
-   it's persisted + surfaced.)
-
-Keep this light — one drawer, recommended pre-selected; most users accept. Don't belabour it.
+> **Removed 2026-06-11 (JTBD-first entry).** Classification moved to the front of the flow — the
+> Job gate at Step 0.7 (server-side `classify_work_item`, user-confirmed). The lead-persona PICKER
+> that used to live here is gone with it: persona is no longer a user choice. The server resolves
+> the job's full persona set (lead + contributors, weighted) and guarantees balanced representation
+> in what it generates — discovery questions first. Nothing to render and nothing to ask here;
+> continue to Step 4 with the `jtbd` confirmed at Step 0.7.
 
 #### Step 4 — Generate sub-problems
 
@@ -951,14 +701,12 @@ Keep this light — one drawer, recommended pre-selected; most users accept. Don
 
 Call `mcp__ritual__generate_considerations` with:
 - `workspace_id`
-- `raw_input` (the user's problem + the Step 3 `codebase_context_packet` + any reference context, concatenated as described above)
+- `raw_input` — the user's problem/ask, **verbatim** (plus any reference context the user spontaneously supplied). **Recon does NOT feed this call (2026-06-11, context-at-create):** sub-problems are deliberately generated from the ask alone so the first product output lands fast; repo grounding enters at Step 5.7 and reaches discovery via the persisted `additional_context`.
 - `template_id` — **OPTIONAL.** Per Step 2 (server-side template resolution), the agent does NOT pick a template_id. Omit this field unless the user explicitly passed `--template-id` on the CLI; the server resolves the right template from `user.persona` → `workspace.defaultTemplateId` → system default and uses the same resolution chain `create_exploration` will use at Step 6. Passing it explicitly only matters when overriding the default.
-- `sources` (the file path list from Step 3 step 7 — file-path strings only, e.g. `["apps/checkout/views.py", ...]`)
+- `sources` — **OMIT** (recon hasn't run yet; it happens at Step 5.7 after the frame locks).
 
 LLM call, ~5–10s. Returns 5–6 sub-problems — different framing axes the system should investigate. Track each one as `{ text, version: 1 }` in your working memory.
 
-The coding agent's packet is context, not authority. Do not pre-rank or collapse the generated sub-problems based only on the agent hypotheses. Let MCP/template/KG output determine the candidate considerations; use the packet to make them specific, evidenced, and grounded.
-
 **If the response includes `kg_context_used` with `implementationCount > 0`:** surface this to the user BEFORE presenting the considerations. It's the visible signal that prior shipped work shaped this draft.
 
 > Reading the codebase I overlapped with 3 prior Ritual explorations on these files:
@@ -976,7 +724,7 @@ If `implementationCount === 0`: don't mention the KG check (silent — would jus
 
 ```text
 Ritual build
-✓ Context  ● Scope  ○ Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
+✓ Job  ● Scope  ○ Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
 Solving for these sub-problems
 
@@ -1086,11 +834,242 @@ When the user locks the frame, store the final text as `problem_statement` for S
 
 **Pulse (Step 5 done):** Emit a pulse — feature clarity just jumped. Compute per `/ritual context-pulse` § Step CP3. Render full if this crosses Raw ask → Under-specified, else compact. Translate raw tier labels into user-facing copy per `references/cli-output-contract.md` § Pulse tier labels — never expose `RAW_ASK` / `UNDER_SPECIFIED` / etc. directly.
 
+#### Step 5.7 — Ground the exploration (silent recon — runs AFTER the frame locks)
+
+**Skip only if the user explicitly asks ("just generate, don't read the code") OR if you're operating outside a codebase context.**
+
+**When this runs (relocated 2026-06-11, context-at-create):** AFTER the user locks the problem frame at Step 5 and BEFORE `create_exploration` at Step 6 — the natural "creating your exploration…" beat, so the user never waits on repo reads before seeing product output. Sub-problems (Step 4) were deliberately generated from the ask alone; THIS step is where grounding enters: the `codebase_context_packet` you build here is passed to `create_exploration` as `additional_context`, persisted on the exploration, and injected by the server into discovery-question generation (the questions surface the most important tradeoffs the context implies) and the build-brief fallback. The goal is not to show the user what you found; the goal is to ground downstream generation.
+
+**Capability Boundary Check (load-bearing):** If recon detects a mismatch between the user's ask and what THIS repo can actually implement — typically because the feature spans systems (backend service, mobile app, billing provider, email worker, schema migrations) that aren't present in the current checkout — DO NOT invent the missing systems and DO NOT continue as if the repo is complete. Apply the boundary heads-up rule in § 5.7.1 below (one line, no pause) before creating the exploration. Frame the missing half as a normal architecture boundary, not a failure: *"This repo looks like the frontend side of a larger feature,"* not *"I could not find backend dependencies."* The user has not done anything wrong; the agent is asking how to scope the work.
+
+Common boundary mismatches to detect:
+
+- Full-stack feature ask + frontend-only repo (UI present, no API/service code)
+- Mobile feature ask + no API client contract or backend
+- Billing/payments feature + no payment service / subscription code
+- Email/notification feature + no worker / job / email-provider integration
+- Auth/session feature + no user mutation / session backend
+- Data/analytics feature + no schema, migration, or storage layer
+
+##### 5.7.0 — Check for a pre-build context seed
+
+Before doing fresh recon, check whether the user already seeded one via `/ritual context-pulse`. Glob for `CONTEXT-*.md` at the repo root.
+
+If a `CONTEXT-<slug>.md` is found AND its `## The ask` section close-matches the current `raw_input`:
+
+- **Use it to seed `codebase_context_packet`.** Parse the file's `## Candidate files` list — those become the seed for `sources[]`. Parse `## Prior KG context` as evidence inside the packet, not as final prioritization.
+- **Skip fresh recon** unless the seed is stale or obviously incomplete. If you skip fresh recon, still normalize the seed into the packet structure below before calling MCP tools.
+- **Surface a compact note**:
+  > Code recon
+  > Found `CONTEXT-<slug>.md` from `/ritual context-pulse`.
+  > Using {N} candidate files + {M} related prior exploration{s} as the recon base. Override with `recon: refresh`.
+- Proceed directly to 5.7.2.
+
+If no seed file is found, OR the seed's `## The ask` doesn't match the current `raw_input`, do fresh recon. For mismatch, mention the ignored seed in one line and do not delete it.
+
+##### 5.7.1 — Fresh recon
+
+1. **Read the README + top-level project structure.** Use `ls` / Glob to see top-level files. Identify the language, framework, key directories, and likely entry points.
+
+2. **Glob for relevance.** Derive patterns from the user's problem. Examples:
+   - User says "auth flow" → `**/auth/**`, `**/login*`, `**/user*`, `**/session*`
+   - User says "checkout" → `**/checkout/**`, `**/cart/**`, `**/order/**`, `**/payment*`
+   - User says "notifications" → `**/notif*`, `**/email/**`, `**/sms/**`, `**/push/**`
+   Cap at ~15 hits per pattern.
+
+3. **Skim 3–5 most-relevant files.** For each, read the first ~100 lines + scan for class/function names. Triangulate whether the behavior lives there or calls into another area.
+
+4. **Build three recon artifacts.**
+
+   A. `raw_recon_notes` — internal evidence only
+   - files read and why they were selected
+   - symbols/classes/functions inspected
+   - relevant comments, schema details, tests, migrations, and config
+   - KG hits, prior deferrals, and prior implementation references
+   - uncertain observations, false leads, and things not found
+   - do **not** show this by default and do **not** pass it as the main MCP planning input
+
+   B. `codebase_context_packet` — downstream planning input
+   - this is the synthesized artifact passed into `raw_input`, context pulses, and any MCP field named `recon_context`
+   - it helps MCP understand what the coding agent observed locally without deciding the final considerations itself
+   - separate factual observations from agent hypotheses
+   - include confidence levels for hypotheses
+   - use neutral labels like `agent_observed_scope_pressure` or `candidate_scope_pressure`, not `priority_considerations`
+   - never present the packet as authoritative; MCP/tooling decides final sub-problems, recommendations, and scope
+
+   C. `recon_digest` — **internal-only by default; NOT surfaced to the user.** Recon
+      is silent plumbing at the lock→create boundary: we do NOT dump repo signals /
+      constraints / a recon summary back to the user. Keep a compact digest in
+      working memory for your own use (and to render ONLY if the user explicitly
+      asks "what did you find?"), but by default show nothing — the only render is
+      the one-line boundary heads-up (§ 5.7.1) on a hard capability mismatch. The
+      `codebase_context_packet` feeds `create_exploration.additional_context`
+      silently.
+   - keep it tight if ever shown: key surfaces, hard constraints, scope corrections
+   - never list every file read; never quote non-load-bearing comments
+
+   `codebase_context_packet` structure:
+
+   ```markdown
+   --- Codebase context packet ---
+
+   ## User intent
+   {verbatim or lightly normalized ask}
+
+   ## Observed relevant surfaces
+   - `path` — observed role in this feature or constraint
+   - `path` — observed extension point, lifecycle, model, or integration seam
+
+   ## Evidence
+   - `path:symbol` — factual observation from code
+   - Prior Ritual signal: {exploration / PR / RB / deferral}, if available
+   - Missing or not-found evidence when it corrects the user's framing
+
+   ## Agent hypotheses
+   - This may make {candidate area} important because {evidence-backed reason}
+     Confidence: low / medium / high
+
+   ## Agent-observed scope pressure
+   - Privacy / lifecycle / migration / compatibility / async / ownership / testing risk
+   - Only include pressure that intersects with the feature intent and code evidence
+
+   ## Scope corrections
+   - The ask says X, but the code suggests Y
+   - Missing fields, renamed concepts, or assumptions the code contradicts
+
+   ## Open questions for discovery
+   - Questions the code cannot answer and the user/Ritual exploration should resolve
+   ```
+
+   Example `codebase_context_packet` excerpt:
+
+   ```markdown
+   ## Observed relevant surfaces
+   - `apps/conversions/abstract_models.py` — append-only conversion event model; lifecycle changes are modeled as follow-up rows.
+   - `apps/conversions/outbox.py` — async publish/retry surface; payload shape may affect erasure semantics.
+   - `apps/order/models.py` — raw guest email appears to live on the order side, not in conversion events.
+
+   ## Agent hypotheses
+   - Erasure semantics may need to cover both mutable raw PII and append-only pseudonymous digests.
+     Confidence: high; supported by model fields and schema comments.
+   - Outbox purge/replay behavior may be a scope pressure because retries can outlive the original conversion write.
+     Confidence: medium; verify worker idempotency before scoping implementation.
+
+   ## Scope corrections
+   - No `guest_session_id` column was found in the inspected conversion models; scope may need to use the actual guest attribution identifiers.
+   ```
+
+   Example `recon_digest` — single-path case (low ambiguity):
+
+   ```text
+   Code recon
+
+   Repo signals:
+   - `apps/conversions/abstract_models.py` — append-only conversion events.
+   - `apps/conversions/outbox.py` — async publish/retry lifecycle.
+   - `apps/order/models.py` — raw guest email surface.
+
+   Constraint:
+   - Erasure likely needs to handle mutable raw PII separately from pseudonymous conversion digests.
+
+   Scope correction:
+   - I did not find `guest_session_id` in the inspected models.
+
+   Pulse: Reasoning Readiness ~55% · Context Debt 45% · +12% (initial ask + code recon)
+
+   (lift bridge — renders right above the next action) Most of the gap left is
+   unsettled design decisions — that's exactly what the next step, discovery, resolves.
+
+   Next: attach PRDs/tickets if they should shape scope, or `proceed` to continue.
+   ```
+
+   **No explore-directions picker here (removed 2026-06-11).** The problem frame is already
+   locked — direction ambiguity was resolved by the user's own framing at Step 5. If recon
+   contradicts the locked frame outright, use the boundary heads-up rule below; never re-open
+   a picker.
+
+   Capability Boundary Check (feature spans systems not in this repo) — **internal/packet-only; NOT displayed:**
+
+   When the user's ask requires capabilities that aren't present in this repo (frontend-only repo asked for full-stack feature, mobile repo with no API contract, etc.), capture the boundary + the inferred default scope **into the `codebase_context_packet`**, then surface exactly ONE heads-up line (no pause — see below). The persisted packet drives discovery-question generation to probe the boundary; the locked frame stays as-is unless the user reacts. NEVER continue as if the repo can implement the missing half; NEVER invent the missing systems. The block below is a **reference for what to capture in the packet**, not something to print.
+
+   ```text
+   Code recon
+
+   Action needed
+
+     This feature likely spans another repo or service.
+     Add the backend/API context, or choose a narrower scope.
+
+   Repo boundary:
+   - This repo contains the checkout UI and guest checkout flow.
+   - I found no backend account-creation endpoint, user/order linking
+     mutation, email job, or migration layer.
+   - So the full "join while booking" feature likely spans this repo plus
+     an API/backend service.
+
+   Can build here:
+   - Checkout/thank-you page UI
+   - Password capture or account-claim form
+   - API client integration point
+   - Mocked frontend tests
+   - Empty/error/success states
+
+   Needs outside context:
+   - Endpoint that creates or claims the account
+   - Contract for linking a guest order to a user
+   - Auth/session behavior after claim
+   - Email/verification behavior, if required
+
+   Scoping inferred: contract-first (default for unsettled API)
+
+     This repo can build: UI integration, API client surface, mocked tests
+     This repo cannot build: account-creation endpoint, order-linking, email job
+     Considerations will be scoped to what this repo can ship.
+
+   Pulse: Reasoning Readiness ~30% · Context Debt 70% (repo boundary unresolved)
+
+   (lift bridge) The plan isn't grounded in your code yet — scoping to what this
+   repo can actually ship is what the next step settles.
+
+   ```
+
+   With the frame already locked, the user-facing output of a boundary hit is ONE line, no pause:
+
+   > Heads-up: this repo covers {the in-repo half} — I've scoped the exploration's context
+   > accordingly. Say `re-frame` to widen the scope, or just continue.
+
+   Notes on the boundary-check shape:
+   - **No pause.** One heads-up line, then continue to Step 6. The boundary information is preserved in the `codebase_context_packet` (persisted as `additional_context`), where discovery-question generation reads it; the user can say `re-frame` to reopen the frame, and discovery itself will probe the boundary.
+   - **"Scoping inferred:" not "How should I scope this?"** — the agent makes the default narrowing (contract-first when API unsettled; repo-side-only when the missing half is clearly out-of-tree) and names what it picked. The user corrects at Step 5 if it was wrong.
+   - **"This repo can build:" + "This repo cannot build:"** are paired one-liners — they document the IN/OUT split so the inferred scoping is auditable. Keep them compact (one line each); the full lists live in `codebase_context_packet`.
+   - **Default narrowing logic:** if the user's ask names a backend/API endpoint, choose **contract-first**. If the user's ask is clearly UI/UX-shaped or the missing systems are obviously out-of-tree (mobile app, separate billing service), choose **repo-side only**. If ambiguous, default to **contract-first** — it preserves more of the user's intent in the downstream artifacts than narrowing to repo-side does.
+   - **The pulse line stays parenthetical** with a user-facing reason (`repo boundary unresolved`), per the Pulse tier labels rule in `references/cli-output-contract.md`.
+   - **Internal classification (not user-facing):** track each candidate piece against the boundary as `in_repo_buildable`, `external_dependency_known`, `external_dependency_unknown`, `needs_additional_repo`, or `contract_first_candidate`. These shape how downstream scoring + build-brief generation handle the missing half. Stamp the inferred default scope as `inferred_scope` in the packet so discovery generation and the build brief see it. None of these labels should appear in user-facing copy.
+
+##### 5.7.2 — Recon is silent
+
+**Recon runs silently.** Do NOT surface the recon digest, repo signals, constraints, or the `codebase_context_packet` to the user by default — recon is plumbing at the lock→create boundary. The packet feeds `create_exploration.additional_context` (Step 6); the user sees nothing here.
+
+**There is no explore-directions picker (removed 2026-06-11)** — the frame the user just locked IS the direction. For a crisp single-direction repo read: render nothing and go straight to Step 6.
+
+**Capability boundary detection does NOT pause.** When recon shows the feature spans systems not in this repo, fold the boundary + the inferred default scope into the `codebase_context_packet` (see § 5.7.1 internal classification), pick the default per the "Default narrowing logic" rule, surface the ONE-line heads-up from § 5.7.1, and proceed to Step 6.
+
+If the user explicitly asks "what did you find?", you may show a tight digest then — otherwise stay silent.
+
+**Pulse (recon done):** Emit a pulse line — repo grounding just moved meaningfully (sources collected, agent inspected files, possibly KG hits). Compute per `/ritual context-pulse` § Step CP3 and render compact unless this is the FIRST pulse of the build flow, in which case use full.
+
+##### 5.7.3 — Collect the `sources` array
+
+Collect the file paths you actually read and consider load-bearing for this problem — exactly as they appear in the repo (e.g. `"apps/checkout/views.py"`, not `"./apps/checkout/views.py"` or absolute paths). This list is passed to `create_exploration` (Step 6) — persisted on the exploration so the answer engine, context pulses, and `generate_build_brief` anchor priorContext consistently without you re-passing it.
+
+Keep the list focused. 5–10 is the sweet spot; >20 dilutes the KG signal.
+
+
 #### Step 6 — Create the exploration
 
 Generate a short name (≤60 chars) from the scope — typically the noun phrase, not the full HMW. E.g. "Reduce T2 customer churn in Q3" → name `T2 churn reduction (Q3)`.
 
-Create the exploration immediately once the frame is locked — the work item + lead persona were already settled at Step 3.9, so do not add a *further* confirmation here. If a name is ambiguous, **choose the shortest clear noun phrase and continue without pausing** — the name is editable later and shouldn't become a decision gate. Do NOT rely on "proceed on Enter" or empty input in agent chat (see `references/cli-output-contract.md` § Surface-aware continuation prompts).
+Run the silent Step 5.7 recon first, then create the exploration — the job was already confirmed at the Step 0.7 Job gate, so do not add a *further* confirmation here. If a name is ambiguous, **choose the shortest clear noun phrase and continue without pausing** — the name is editable later and shouldn't become a decision gate. Do NOT rely on "proceed on Enter" or empty input in agent chat (see `references/cli-output-contract.md` § Surface-aware continuation prompts).
 
 User-visible before the call, if needed:
 
@@ -1104,21 +1083,23 @@ Call `mcp__ritual__create_exploration` with:
 - `problem_statement` (the scope from Step 5)
 - `template_id` — **OPTIONAL.** Per Step 2, omit by default. The server resolves from `explicit dto.templateId → workspace.defaultTemplateId → user.persona → first SYSTEM template`, then forks the resolved template into a per-exploration Template row atomically inside this same `create_exploration` request. Pass `template_id` ONLY when the user explicitly overrides on the CLI (`/ritual build --template-id <id>`). If you passed `template_id` to Step 4's `generate_considerations`, pass the same value here so the LLM prompt context the considerations were generated under matches the exploration's stamped template. Do NOT read `.ritual/config.json` or invent a `template_id` from persona — the server does the resolution.
 - `agentic: false` — **do NOT** pass `agentic: true`. We want explicit per-step control so the user gets to pick discovery questions in Step 7. Auto-agentic skips that.
-- `jtbd` — **REQUIRED for `/ritual build`.** The work-item slug you classified at **Step 3.9** (e.g. `'build-backend-service'`, `'refactor-code'`, or `'build-feature'` for a generic build). Tags the exploration's job-to-be-done so the workflow surfaces the build-brief → code-plan → implement → PR deliverable phase across every surface (the Spark panel, etc.), not the generic produce-deliverable flow. Omit only if this is a non-build exploration (defaults to `produce-deliverable`).
-- `lead_persona` — the lens slug the user chose at **Step 3.9** (e.g. `'backend-developer'`). Pass the chosen `persona` from `work_item`. Omit only if Step 3.9 was skipped — the server then resolves the jtbd's canonical lens. Unknown slugs are ignored server-side.
+- `additional_context` — the full `codebase_context_packet` from Step 5.7 (omit only if recon was skipped). Persisted on the exploration; the server injects it into discovery-question generation as evidence (the questions cover the important tradeoffs it implies) and uses it as the build-brief recon fallback — so it survives `/ritual resume`.
+- `sources` — the file-path list from Step 5.7.3.
+- `jtbd` — **REQUIRED for `/ritual build`.** The slug the user CONFIRMED at the **Step 0.7 Job gate** (e.g. `'build-backend-service'`, `'refactor-code'`). Tags the exploration's job-to-be-done so the workflow surfaces the build-brief → code-plan → implement → PR deliverable phase across every surface (the Spark panel, etc.), not the generic produce-deliverable flow. Omit only if this is a non-build exploration (defaults to `produce-deliverable`).
+- `lead_persona` — **OMIT (2026-06-11, JTBD-first entry).** Persona is no longer a user pick: the server resolves the job's canonical lead and owns balanced persona REPRESENTATION across the job's full persona set (lead + contributors, weighted) in generation. Do not call `work_item` to pick a lens and do not pass this field.
 
 Store `exploration_id`. Move the progress header from Scope to Discovery:
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
+✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
-Exploration created. Track progress at https://app.ritualapp.cloud/e/{exploration_id}
+Exploration created.
 
 Next: generate discovery questions to resolve the implementation trade-offs.
 ```
 
-##### 6.1 — Promote the pre-build seed (if one was consumed in Step 3.0)
+##### 6.1 — Promote the pre-build seed (if one was consumed in Step 5.7.0)
 
 If Step 3.0 consumed a `CONTEXT-<slug>.md` seed file, promote it into the exploration's artifact trail now that an exploration id exists. Move + rename the file from `CONTEXT-<slug>.md` to `.ritual/exploration-notes/<exploration-id>.md` using the Bash tool:
 
@@ -1200,21 +1181,21 @@ Longest phase because generation is async + the user picks per-Area. (Internally
 1. Call `mcp__ritual__suggest_discovery_questions(exploration_id)` (Step 7.1) — no user input needed; just kick it off.
 2. Poll `mcp__ritual__get_discovery_state(exploration_id)` until `ready: true` (Step 7.2).
 3. Render the **Area rail + Area 1's questions together** and walk Area-by-Area per § 7.3.1 (the rail orients; a rail with NO questions under it — a bare index — is the failure mode).
-4. `[USER PAUSE]` — the user picks questions across Areas (**floor: 6 to run; aim for 15–20; no cap**), or types `accept shortlist`.
+4. `[USER PAUSE]` — the suggested-12 landing (§ 7.3.1): the user replies `proceed` (commit the 12), `expert` (walk + adjust; floor 6 to run, aim 15–20, no cap), or `pause`.
 5. Commit all picked Areas in ONE `mcp__ritual__accept_discovery_questions_batch` call (Step 7.4) — never one parallel call per Area.
 6. Optionally capture anti-goals (Step 7.5), then proceed to Step 8 and render the *"Reply `run` to continue"* CTA.
 
 **Picking is a deliberate step-through, not a bulk action (load-bearing):** the user going Area by Area and choosing the questions that matter IS the value of discovery — that per-question judgment shapes the whole downstream chain. So **nudge the user to step through and pick**; don't lead with bulk shortcuts.
 - **Nudge to step through.** Walk the user Area-by-Area (drop into Area 1, `next`/`prev`) and invite deliberate picks per Area, with `show more` to expand an Area. The framing is "which of these should we dig into?", not "want all of them?".
 - **Floor (HARD): at least 6 questions** across any Areas — below this, do NOT commit or proceed (tell them how many more to pick and keep them in the picker). There is NO "skip discovery" path — the agentic run needs a real question set to develop answers against. **Good coverage (SOFT): 15–20 questions** — nudge toward it on the Summary, but never block once ≥6. **No upper cap** — picking many (or all) is a legitimate explicit choice, never a default or fallback. (Uncovered scope is handled downstream when recommendations + requirements are generated and audited, so a thin set is the failure mode to prevent.)
-- **The default is the shortlist, never "all."** For a user who doesn't want to step through every Area, **`accept shortlist` (the 6–10 highest-leverage questions)** is the convenience default. An ambiguous reply (`proceed`, `go`, `ok`) at this gate means **accept the shortlist** — never silently accept everything.
+- **The default is the suggested 12 on screen, never "all."** The landing shows exactly what `proceed` commits. An ambiguous reply (`proceed`, `go`, `ok`) at this gate means **accept the suggested 12 the user is looking at** — never silently accept everything.
 - **Taking all IS allowed — but only as an explicit user choice, never the default or a fallback.** If the user genuinely says "take all" / "all of them", honor it and commit them; that's a legitimate choice, not an error. Just never *offer* "I'll take all" as the default, and never auto-fall-back to it. (Worth mentioning once, not as a gate: every accepted question is answered individually in the agentic run, so accepting all of them across every Area means many more questions to answer and a much longer run — but it's the user's call.)
 
 **Forbidden behaviors:**
 
 - Calling `start_agentic_run` before at least 6 discovery picks have been committed for this exploration (via `accept_discovery_questions_batch`, or `accept_discovery_questions`). There is no skip-discovery exception.
 - Silently auto-picking all generated questions and proceeding to Step 8 — observed in agent output 2026-05-15 as "the engineering-mode default is to run, which skips the per-question picker." There is no such default; the picker is mandatory.
-- **Offering "or I'll default to taking all of them" (or any accept-all fallback), then committing the full set on an ambiguous reply** — observed 2026-06-05 (a `proceed` at this gate → `accept_discovery_questions_batch` with all 68 questions → a ~25-min run the user never chose). Accept-all is a legitimate choice **only when the user explicitly asks for it** — it is NEVER the default you offer, and NEVER the fallback. The default you offer + fall back to is always **`accept shortlist`** (6–10). An ambiguous reply (`proceed`/`go`/`ok`) at the pick gate means **accept the shortlist**, not the full set. Lead by nudging the user to step through Areas and pick deliberately.
+- **Offering "or I'll default to taking all of them" (or any accept-all fallback), then committing the full set on an ambiguous reply** — observed 2026-06-05 (a `proceed` at this gate → `accept_discovery_questions_batch` with all 68 questions → a ~25-min run the user never chose). Accept-all is a legitimate choice **only when the user explicitly asks for it** — it is NEVER the default you offer, and NEVER the fallback. The default you offer + fall back to is always **the suggested 12 rendered on the landing**. An ambiguous reply (`proceed`/`go`/`ok`) at the pick gate means **accept those 12**, not the full set — structurally safe because the 12 are on screen in full.
 - Rendering "Next: run discovery through recommendations / Reply `run` to continue" anywhere in the chat before Step 7.4 has completed.
 
 The picker is **not** a UI suggestion — it's the load-bearing decision gate where the user expresses what to investigate. Skipping it converts the agentic run into an automated "answer everything" pass and erases the user's judgment.
@@ -1225,7 +1206,7 @@ Call `mcp__ritual__suggest_discovery_questions(exploration_id)`. Returns immedia
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
+✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
 Generating discovery questions for each area…
 ```
@@ -1239,11 +1220,11 @@ Loop:
 
 Don't poll faster than every 10 seconds (matches the Spark UI's 10s discovery cadence). Follow the global polling rule above: single `Bash sleep 10` per iteration and a one-line update every ~2 polls (~20s). Polling heartbeats are exempt from the Build rail rule per `references/cli-output-contract.md` § Build progress anchor — does NOT apply to.
 
-##### 7.3 — Matter-walk picker (Area rail + selected Area's questions → walk with `next`/`prev` → Summary)
+##### 7.3 — Question picking: the suggested-12 landing (default) + the expert walk (on request)
 
 The state contains `matters[]`, each with `id`, `name`, and `questions[]`. Internally these are `matter`s; user-facing copy ALWAYS calls them **Areas**.
 
-This MIRRORS the Spark `/discover` picker exactly: Spark shows a **tab bar of all Areas with one tab selected AND that tab's questions already rendered below it**. The CLI does the same in text — every render shows a compact **Area rail** (all Areas, the current one marked, with running picked counts) **and, directly beneath it, the current Area's questions**. The user picks questions, then moves between Areas with `next`/`prev`, and finally lands on a **Summary** grouped by Area before committing. Seeing each Area's questions and choosing deliberately IS the value of discovery.
+**Landing-first (2026-06-12).** The default render is NOT the Area walk — it is the **suggested-12 landing**: Ritual's 12 suggested questions across all Areas, listed IN FULL (never truncated), grouped by Area, pre-selected. One word (`proceed`) commits them; `expert` opens the Area-by-Area walk with the 12 already selected (toggle to adjust). The walk MIRRORS the Spark `/discover` picker (Area rail + current Area's questions + Summary before commit) and remains the place to push toward the 15–20 good-coverage range — it's just opt-in now instead of mandatory.
 
 The two failure modes this contract prevents:
 - **A bare Area index** — the rail (or a "pick an Area" menu) with **no questions under it**. The rail without its current Area's questions is exactly the removed model; always render the questions inline. (This is the failure d3 caught on 2026-06-07: the agent rendered the Area list alone.)
@@ -1251,14 +1232,14 @@ The two failure modes this contract prevents:
 
 **Turn boundaries (load-bearing — this is a multi-turn walk, not a one-shot render).** Render the rail + **exactly ONE Area's questions per turn**. After rendering, **STOP and end your turn** — wait for the user's reply (`numbers` / `next` / `prev` / `skip` / `done`). Each of `next` / `prev` / `done` produces the **next render in a NEW turn**, never appended to the current message. You already hold every Area's questions from `get_discovery_state` — that is NOT license to render the whole walk or multiple Areas' questions in a single message. The rail lists Area *names + counts* (cheap orientation); only the current Area's *questions* render. One Area → STOP → reply → next Area. The Summary (§ 7.3.3) is likewise its own turn.
 
-###### 7.3.0 — Compute per-Area recommendations + the global shortlist (internal, not user-facing)
+###### 7.3.0 — Compute the suggested 12 + per-Area recommendations (internal, not user-facing)
 
-Three things surface, **none auto-applied**:
-- **(a) The Area rail** — every Area's name + its running picked count. Cheap orientation (names + counts, NOT their questions), shown above the current Area's questions from the very first render. This is the legitimate, always-visible "tab bar" — it is NOT the forbidden bare index, *because the current Area's questions always render beneath it*.
-- **(b) The per-Area ★ recommended set** (3–4 questions) — computed for the Area you are currently showing.
-- **(c) The global shortlist** (6–10 across all Areas) — computed only when the user types `accept shortlist`.
+Three things are computed up front, **none auto-committed**:
+- **(a) The suggested 12** — 12 questions TOTAL across all Areas, the landing's content. Selection rubric (a rule, not vibes): start from the server's ranked/recommended flags; guarantee at least one question from every Area that contains a genuinely hard question; fill the rest by leverage, biased toward questions that probe **tradeoffs, constraints, and the scope-pressure/boundary items** the exploration's additional context surfaced. If fewer than 12 questions clear the bar, suggest fewer (floor 6) — never pad to hit the number.
+- **(b) The Area rail** (expert mode) — every Area's name + its running picked count, shown above the current Area's questions.
+- **(c) The per-Area ★ recommended set** (3–4 questions, expert mode) — computed for the Area currently showing.
 
-The user always picks; nothing is auto-committed.
+The user always confirms; nothing is committed without their reply.
 
 **Per-Area recommended set** (the ★ set, for the Area currently shown):
 
@@ -1267,30 +1248,58 @@ The user always picks; nothing is auto-committed.
 - Area has **4–7 questions**: top 3 are recommended.
 - Area has **8+ questions**: top 4 are recommended.
 
-**Global shortlist** (what `accept shortlist` accepts — available from any Area or the Summary):
+**Legacy token:** `accept shortlist` (the old 6–10 power path) is retired as a displayed option — the suggested 12 IS the landing now. If a user types it anywhere, treat it as the landing's `proceed` (commit the suggested 12) and note in one line that the landing already covers it.
 
-- Pick **6–10 questions TOTAL across all Areas**, biased toward questions most likely to change recommendations.
-- Preserve Area diversity by default — at least one question from each Area where the per-Area recommended set was non-empty, unless the scope is clearly concentrated (e.g. one Area dominates the recon evidence).
-- Cap at 10 even when the per-Area recommended sets sum to more. The point of the shortlist is to give the user a clean "the highest-signal triage set across the whole space" — picking 24–32 questions because 8 Areas each have 3–4 recommended brings back the "no triage signal" problem under a new name.
-- If the per-Area recommended sets sum to ≤10, the shortlist IS just the union (no further trimming).
+###### 7.3.1 — First render: the suggested-12 landing (the default)
 
-Neither set is auto-applied. The user still picks per Area, or uses `accept shortlist` as a power path that bypasses the area-by-area drill.
+Render ALL 12 suggested questions IN FULL, grouped by Area — never truncate, elide, or "(… N more)" this list; the whole point is that the user reads exactly what one word will commit. Full phase rail on this message (we just entered Discovery).
 
-###### 7.3.1 — First render: Area rail + Area 1's questions (the walk begins)
+```text
+Ritual build
+✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ {Deliverable}  ○ Implementation (Your agent)
+
+Discovery questions ready — {M} generated across {N} areas.
+
+These 12 questions target where this problem is hardest — the tradeoffs,
+constraints, and unknowns that decide the design. When you proceed, Ritual
+dispatches its research agents to answer them against this codebase and your
+sources; those answers become the spine of the {Deliverable}.
+
+{Area name 1}
+  ✓ 1. {question, full text, wrapped readably}
+  ✓ 2. {question}
 
-Open ON Area 1 with the **rail above and Area 1's questions below it** — never the rail alone. The rail lists every Area (current one marked, picked count per Area); the questions are Area 1's ★ recommended set. Full phase rail on this first message (we just entered Discovery); subsequent Area messages use the in-phase chip.
+{Area name 2}
+  ✓ 3. {question}
+  ✓ 4. {question}
+
+{…every suggested question, grouped by Area, all 12 visible…}
+
+Next: reply `proceed` to run discovery with these 12 (commits the set;
+the run confirmation follows) · `expert` to review all {M} questions and
+adjust the selection · `pause` to stop here.
+```
+
+Branch on reply:
+- **`proceed`** (or an ambiguous `ok`/`go`): commit exactly the 12 on screen via § 7.4's single batch call (grouped per Area), then continue to § 7.5 → Step 8. The ambiguous-reply rule is now structurally safe: what gets accepted is exactly what the user is looking at.
+- **`expert`**: enter the Area walk below with the suggested 12 **pre-selected** (`picked so far: 12`, ✓ on each suggested row). Numbers TOGGLE in expert mode — typing a selected question's number unselects it.
+- **`pause`**: stop here; nothing committed.
+
+###### 7.3.1b — Expert mode: the Area walk (entered via `expert`)
+
+Open ON Area 1 with the **rail above and Area 1's questions below it** — never the rail alone. The rail lists every Area (current one marked, picked count per Area); the questions are Area 1's ★ recommended set, with ✓ already on rows that are in the suggested 12. Subsequent Area messages use the in-phase chip. The 15–20 soft nudge lives here: the user arrives with 12 — the walk is where they push toward broader coverage (floor 6 HARD if they unselect).
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
+✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
-Question picking · Area 1 of {N} · {Area name}          picked so far: 0
+Question picking · Area 1 of {N} · {Area name}          picked so far: 12
 
 Areas   ● {Area name 1}   ○ {Area name 2}   ○ {Area name 3}   ○ {Area name 4}   ○ {Area name 5}
         ● current · ✓N after a name = picked in that Area · move with `next` / `prev`
 
-Ritual generated questions across {N} areas for {M} locked sub-problems.
-I'll walk you through each — aim for 15–20 total (6 minimum to run, no cap).
+Expert mode — the suggested 12 are pre-selected (✓). Numbers toggle;
+aim for 15–20 total (6 minimum to run, no cap).
 
 Showing the {k} most likely to change the plan ({total} in this Area):
 
@@ -1299,19 +1308,21 @@ Showing the {k} most likely to change the plan ({total} in this Area):
   3. {recommended question 3, wrapped readably}
 
 pick   numbers (e.g. `1,3`)  ·  `suggested` (these ★)  ·  `add <your question>`  ·  `show more` ({total−k} more)
-walk   `next`  ·  `prev`  ·  `skip`  ·  `done` (≥6)  ·  `accept shortlist`
+walk   `next`  ·  `prev`  ·  `skip`  ·  `done` (≥6)
 ```
 
 **Single numbering stream — number the QUESTIONS only; the rail Areas are NOT numbered.** The 2026-05-15 failure numbered Areas AND question previews in one view, so a reply of `5` was ambiguous. Here the rail uses `●`/`○` markers + names (no numbers) and you move it with `next`/`prev` — the only numbered list is the current Area's questions, so a bare number is never ambiguous. Wrap long question text readably. The `picked so far` count, the rail markers/`✓N` counts, and the `Area i of N` breadcrumb all update on every render of the walk.
 
-**Why `accept shortlist`, not `accept recommended`:** "recommended" is ambiguous (per-Area? global?). The picker uses **shortlist** for the global 6–10 power path (§ 7.3.0), keeping a clean vocabulary split: **discovery = `accept shortlist`** (questions), **recommendation review = `proceed`** (Step 9). The ★ marks the per-Area recommended set; `suggested` picks it.
+**Vocabulary split:** the landing's `proceed` commits the suggested 12 (questions); Step 9's `proceed` continues recommendation review. Inside expert mode, the ★ marks the per-Area recommended set and `suggested` picks it; `accept shortlist`/`accept recommended` are legacy aliases for the landing's `proceed`.
+
+###### 7.3.2 — Within an Area (pick → auto-advance)
 
-###### 7.3.2 — Within an Area (pick, then move)
+**Picking IS progress (2026-06-12).** A pick reply (`numbers` or `suggested`) ADVANCES to the next Area — never re-render the same Area and wait for `next` (that costs two replies per Area and stalls the walk; observed live: users picked, then were shown the same Area again). `prev` is the way back if they want to adjust; `next` still exists for moving WITHOUT picking.
 
 **Every render in this section keeps the `Areas …` rail line on top** (current Area marked, `✓N` counts updated) — it's omitted from the snippets below only for brevity. Never re-render an Area's questions without the rail above them.
 
-- **`numbers`** (e.g. `1,3` or `1,2,5`): add those questions to the picked set, re-render this Area (rail + questions) with `✓` on the picked rows + the updated `picked so far`, then prompt `next` / `prev` / `done`.
-- **`suggested`**: pick this Area's recommended (★) set in one go.
+- **`numbers`** (e.g. `1,3` or `1,2,5`): TOGGLE those questions — unselected ones join the picked set, already-✓ ones (including pre-selected suggested-12 rows) leave it. Then **ADVANCE: render the NEXT Area** (rail + its questions), opening with a one-line ack of the Area just left — `{Area name}: {n} picked ✓` — and the updated `picked so far`. On the LAST Area, a pick advances to the Summary (§ 7.3.3). Do NOT re-render the same Area after a pick; `prev` returns if the user wants to adjust.
+- **`suggested`**: pick this Area's recommended (★) set in one go — then advance exactly like `numbers`.
 - **`show more`**: reveal the rest, grouped Recommended / More (lazy per-Area expansion — never a global dump):
 
 ```text
@@ -1353,9 +1364,11 @@ Question picking · Summary                              {T} picked
   ...
 
 {if T < 15}   A good set is usually 15–20 — you've picked {T}. Reply an Area
-              number to add more, `more` to suggest new Areas, or `commit`.
-{if T ≥ 15}   Reply `commit` to run discovery on these {T} questions, an Area
-              number to adjust, `more` for new Areas, or `pause` to stop.
+              number to add more, `more` to suggest new Areas, or `commit`
+              (run discovery → recommendations).
+{if T ≥ 15}   Reply `commit` to run discovery on these {T} questions
+              (answers → recommendations, ~a few minutes), an Area number
+              to adjust, `more` for new Areas, or `pause` to stop.
 ```
 
 **The minimum model — floor 6 HARD, good 15–20 SOFT, no cap:**
@@ -1371,7 +1384,7 @@ Question picking · Summary                              {T} picked
 
 ###### 7.3.4 — Power paths (available from any Area or the Summary)
 
-- **`accept shortlist`**: accept the 6–10-question global shortlist computed in § 7.3.0 — the fast path for a user who doesn't want to walk every Area. Group those by their owning Area, commit them in ONE `accept_discovery_questions_batch` call (§ 7.4 — one entry per Area), and proceed to Step 7.5. Intentionally NOT "top 3–4 of every Area" (which would scale to 24–32 picks and reintroduce the "no triage signal" problem). The shortlist is the quick minimal set; the walk is how a user reaches the 15–20 good-coverage range.
+- **`accept shortlist`** (legacy alias): treat as the landing's `proceed` — commit the suggested 12 via ONE `accept_discovery_questions_batch` call (§ 7.4, one entry per Area) and continue to Step 7.5. The walk is how a user reaches the 15–20 good-coverage range; the suggested 12 is the quick high-signal set.
 - **`show all`**: accepted as a reply but NOT advertised on the CTA line. Expands every Area's questions into one long list. Use only when the user explicitly asks — the per-Area `show more` is the default.
 - **`done`**: jump to the Summary from any Area to review + `commit`.
 - **Below the floor** (fewer than 6 picked on `commit`): do NOT proceed. Reply with how many more are needed and return to the Summary — e.g. *"Pick at least 6 to run discovery — you've picked 3, choose 3 more."* There is no skip path. (6–14 is allowed with the soft nudge; ≥15 is the good-coverage target — see § 7.3.3.)
@@ -1386,7 +1399,7 @@ Question picking · Summary                              {T} picked
 ###### Legacy alias notes
 
 - `suggest` (legacy per-Area shortcut) is now spelled **`suggested`** — picks the current Area's recommended (★) set. If a user types `suggest` inside an Area, treat it the same.
-- `accept recommended` (legacy global shortcut): at the DISCOVERY stage, if a user types this, treat it as `accept shortlist` and surface a one-line note that the discovery-stage token is `accept shortlist` (questions). (At Step 9 the recommendation-review CTA is `proceed`, not `accept recommended`.)
+- `accept recommended` (legacy global shortcut): treat as the landing's `proceed` (commit the suggested 12) with a one-line note. (At Step 9 the recommendation-review CTA is `proceed` for continuing review.)
 - `all` (legacy fourth option) remains removed (see § Removed below).
 
 ###### Removed: `all` (the old fourth option)
@@ -1478,14 +1491,14 @@ For `engineering`, `delivery`, and `operations` roles, show:
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
+✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
 Run discovery
 
 Ritual will source answers for the picked questions, then generate
 recommendations. This usually takes a few minutes.
 
-Reply `run` to continue.
+Reply `run` to source answers → generate recommendations.
 Reply `pause` to stop here.
 ```
 
@@ -1499,7 +1512,7 @@ For `product`, `design`, or explicitly PRD-style flows, answer review may be use
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
+✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
 Run discovery
 
@@ -1576,8 +1589,16 @@ Then print progress only when `progress_pct` or `current_step` changes, or every
 
 > Agentic run: {progress_pct}% — {current_step}
 
-When `status` is `COMPLETED`: continue to Step 9.
-When `status` is `COMPLETED_WITH_ERRORS`: tell the user, but proceed — partial recommendations may still be useful.
+When `status` is `COMPLETED`: **wait for recommendation ROWS before Step 9.** The run reporting
+`completed` does NOT mean recommendations exist yet — rec generation is a separate queued job that
+lands MINUTES later (the 2026-06-05 premature-accept incident class; observed again live 2026-06-12:
+an agent rendered "0 recommendations across 0 categories" and vacuously proceeded). Poll
+`mcp__ritual__get_recommendations_preview(exploration_id)` on the standard cadence (`Bash sleep 20`
+per iteration, "still generating recommendations…" line every ~3 polls) until the preview returns
+**at least one recommendation**, then continue to Step 9. NEVER render the Step 9 landing — and
+never call `accept_recommendations` — from a zero-rec read. If 10+ minutes pass with zero rows,
+surface that as an anomaly instead of proceeding.
+When `status` is `COMPLETED_WITH_ERRORS`: tell the user, then apply the same wait-for-rows rule — partial recommendations may still be useful.
 When `status` is `FAILED`: surface the error message, ask if they want to retry (`start_agentic_run` again with same exploration_id) or stop.
 When `status` is `PAUSED_FOR_REVIEW` (product/design answer-review mode only): continue to Step 8.5.
 
@@ -1595,7 +1616,7 @@ Landing (first question, full rail + intro):
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
+✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
 Run Agentic Exploration
 
@@ -1669,11 +1690,11 @@ For each question's loop:
 
 <!-- lite:keep-start -->
 
-#### Step 9 — Review recommendations (category walk)
+#### Step 9 — Review recommendations (landing + drill)
 
 This is the most-read screen in the build flow, and — as of 2026-06-08 — a **non-blocking review**. Recommendations are **auto-accepted at generation** (created `approved`); the artifacts that depend on them (requirements, the deliverable doc, and — for developer-function jobs — the build brief) are **already being generated** the moment rec-gen completes. Step 9 is the user's chance to **read and refine** the set, not an accept-or-reject gate. Replying `proceed` records that a human reviewed it (stamps `reviewedAt` / `reviewedBy`) and continues to the build brief — it never blocks, and there is **no reject path here**.
 
-The review is a **category walk**, mirroring Spark's recommendation drawer: the user moves through one **category** at a time, sees each recommendation in that category in full (title, description, and the "Why this" reasoning), and can refine any one of them in place before continuing.
+**Landing-first (2026-06-12) — the same shape as the suggested-12 discovery landing:** the default render is ONE screen showing EVERY recommendation grouped by category — title + one truncated description line each — so the user sees the whole set at a glance and can `proceed` immediately. Depth is opt-in: `drill R{N}` opens a single recommendation in full (complete description, "Why this", pass criteria); `edit R{N}` refines one in place. The goal is the shortest honest path to the {Deliverable}: scan, optionally drill or refine, proceed.
 
 **Data source.** Use `mcp__ritual__get_recommendations(exploration_id)` (the raw array) — the walk shows full per-rec content, so you need the fields a titles-only preview omits:
 
@@ -1691,64 +1712,66 @@ Assign stable `R1..RN` IDs **globally across all categories** in page order (NOT
 
 **Action set — load-bearing (exactly three, no freelancing):**
 
-- `edit R{N} <your change>` — refine one recommendation: regenerate its title / description / reasoning from a plain-language ask, **preview** the change, then **apply** it. (§ 9.2)
-- `next` — move to the next category. (§ 9.3)
-- `proceed` — mark the set reviewed and continue to the build brief, from any category. (§ 9.3)
+- `drill R{N}` — open ONE recommendation in full: complete description, "Why this", pass criteria. (§ 9.1b)
+- `edit R{N} <your change>` — refine one recommendation: regenerate its title / description / reasoning from a plain-language ask, **preview** the change, then **apply** it. Works from the landing or from a drill view. (§ 9.2)
+- `proceed` — mark the set reviewed and generate the {Deliverable} (the job's deliverable — render its rail name, e.g. `Service Build Brief`). Available everywhere. (§ 9.3)
 
-**Do NOT freelance other actions.** There is **no `drop` / reject** (recs are auto-accepted and the review is non-blocking — a rec the user dislikes is refined with `edit`, or simply left as-is), **no `comment`**, and **no separate `drill` / `detail`** (full content is already on screen). Reject none of these by inventing compounds either (`dedupe`, `accept the survivors`, `merge similar`, `open the admin UI` — all forbidden). If the rec set itself looks wrong (e.g. apparent duplicates), surface the anomaly explicitly and consult `mcp__ritual__get_recommendation_attestation` (`duplicateTitlePrefixes`) — don't paper over it with an invented action.
+**Do NOT freelance other actions.** There is **no `drop` / reject** (recs are auto-accepted and the review is non-blocking — a rec the user dislikes is refined with `edit`, or simply left as-is), **no `comment`**, and **no `next`** (there is no pagination — the landing already shows everything). Reject invented compounds too (`dedupe`, `accept the survivors`, `merge similar`, `open the admin UI` — all forbidden). If the rec set itself looks wrong (e.g. apparent duplicates), surface the anomaly explicitly and consult `mcp__ritual__get_recommendation_attestation` (`duplicateTitlePrefixes`) — don't paper over it with an invented action.
 
-##### 9.1 — The walk: one category per turn
+##### 9.1 — The landing: every recommendation, one screen
 
-**[USER PAUSE]** Render the **current category only**, then stop and wait for the user's reply. One category per turn — never dump every category's full content in a single message (that's the wall-of-text failure mode; the walk is what keeps a 13-rec set readable). The first render opens with the full rail; subsequent categories use the in-phase chip.
+**Zero-rec guard (load-bearing):** if `get_recommendations` returns an empty array, do NOT render this landing and do NOT call `accept_recommendations` — you arrived before rec generation finished. Go back to the Step 8 wait-for-rows polling. A "0 recommendations across 0 categories" render is always a bug, never a state to present.
 
-First category (rail shown):
+**[USER PAUSE]** Render ALL recommendations grouped by category — every title visible, each with ONE truncated description line. This is a scan surface, not a reading surface: titles carry the signal; `drill` carries the depth. Never omit a category or a rec ("… N more" is forbidden — the user must see exactly what `proceed` reviews); never expand to multi-line descriptions here (that's the wall-of-text failure mode the landing exists to prevent).
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ✓ Discovery  ● Recommendations  ○ Build brief  ○ Implementation (Your agent)
+✓ Job  ✓ Scope  ✓ Discovery  ● Recommendations  ○ {Deliverable}  ○ Implementation (Your agent)
 
 Scope:
 {one-line compressed scope — ~80-120 chars; truncate at a clause boundary, no ellipsis}
 
-{N} recommendations across {K} categories. They're accepted by default —
-review and refine any, or proceed anytime.
+{N} recommendations across {K} categories. Scan the set, drill into any,
+or proceed to your {Deliverable}.
 
-Category 1/{K} — {category name}
+{Category name 1}
+  R1  {title} — {description truncated ~90 chars at a word boundary…}
+  R2  {title} — {truncated description…}
 
-  R1  {title}
-      {content — the description, wrapped at terminal width, 1-3 lines}
-      Why this: {one-line Problem→Discovery→Tradeoff distillation, plain prose}
+{Category name 2}
+  R3  {title} — {truncated description…}
+  R4  {title} — {truncated description…}
 
-  R2  {title}
-      {description}
-      Why this: {...}
+{…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% (implementation-ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
 
-Reply  edit R{N} <your change>   ·   next (Category 2/{K})   ·   proceed (build brief)
+A few assumptions are still unverified — the build brief is what locks them down.
+Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})
 ```
 
-Subsequent categories (in-phase chip, no full rail):
+Notes:
+
+- **Global `R{N}` IDs** in page order across categories. The R-ID is how the user references a rec in `drill R{N}` / `edit R{N}`; never restart numbering per category.
+- **Title + one truncated description line per rec** — truncate at a word boundary with `…`. No "Why this" at the landing; that lives in the drill view.
+- **`proceed` is the primary CTA** — the user never has to drill anything to continue.
+
+##### 9.1b — `drill R{N}`: one recommendation in full
+
+**[USER PAUSE]** Render the single recommendation completely, then wait:
 
 ```text
-Recommendations · Category 2/{K} — {category name}
+Recommendations · R{N} — {title}
 
-  R3  {title}
-      {description}
-      Why this: {...}
+{content — the full description, wrapped at terminal width}
 
-  ...
+Why this: {one-line Problem→Discovery→Tradeoff distillation, plain prose}
+Pass: {acceptance_criteria, one line each — omit the block if empty}
 
-Reply  edit R{N} <your change>   ·   next (Category 3/{K})   ·   proceed (build brief)
+Reply  edit R{N} <your change>   ·   back (all recommendations)   ·   proceed (generate the {Deliverable})
 ```
 
-Notes:
-
-- **Global `R{N}` IDs** continue across categories (Category 2 starts at R3 if Category 1 held R1–R2). The R-ID is how the user references a rec in `edit R{N}`; never restart numbering per category.
-- **`content` (the description) and "Why this" ARE shown** at the walk — unlike the old titles-only landing. That's deliberate: the user reads and refines in place. Keep each rec to title + 1–3 description lines + one "Why this" line. If a rec's `acceptance_criteria` are short and genuinely useful you may add a single `Pass: {...}` line, but don't pad — the walk must stay scannable.
-- **One blank line between recs**; indent rec bodies under their `R{N}` so the eye lands on the title first.
-- **`proceed` is the primary CTA** and is offered on every category — the user never has to walk all categories to continue.
-- **On the last category**, the action line drops `next`; if the user types `next` there, reply: "That was the last category — reply `proceed` to continue, or `edit R{N}` to refine one."
+`back` re-renders the landing (§ 9.1, unchanged). Drilling is read-only — nothing advances or persists.
 
 ##### 9.2 — `edit R{N} <ask>`: preview, then apply
 
@@ -1781,19 +1804,18 @@ Reply  apply (save this revision)   ·   discard (keep the original)
    - Render ONLY the `diff` fields that are present. Map `field: "title"` → `Title`, `"description"` → `Description`, `"chain.<idx>"` → `Why this — step {idx+1}`.
    - If the proposal's `diff` is empty (the LLM found no meaningful change), say so plainly and return to the category view unchanged — don't fabricate a diff.
 
-4. On `apply`: call `mcp__ritual__apply_recommendation_proposal({ recommendation_id, proposal_id })`. It persists a new version, replays the reasoning chain, and returns the applied proposal. Re-fetch the rec (`get_recommendations`) and **re-render the current category with R{N} updated in place**, then continue the walk (action line `edit R{N} <change> · next · proceed`).
-   On `discard`: return to the current category unchanged — nothing was persisted.
+4. On `apply`: call `mcp__ritual__apply_recommendation_proposal({ recommendation_id, proposal_id })`. It persists a new version, replays the reasoning chain, and returns the applied proposal. Re-fetch the rec (`get_recommendations`) and **re-render the view the user came from** — the landing (§ 9.1) or the drill view (§ 9.1b) — with R{N} updated in place.
+   On `discard`: return to that view unchanged — nothing was persisted.
 
-Editing is non-destructive and does not advance the flow — the user can `edit` several recs, across categories, before `proceed`.
+Editing is non-destructive and does not advance the flow — the user can `edit` several recs before `proceed`.
 
-##### 9.3 — `next` and `proceed`
+##### 9.3 — `proceed`
 
-- **`next`** → render the next category per § 9.1 (in-phase chip). After the last category, prompt `proceed`.
-- **`proceed`** (from any category) → call `mcp__ritual__accept_recommendations({ exploration_id })`. Under the non-blocking model this **records the human review** (stamps `reviewedAt` / `reviewedBy`) and advances; it is NOT a draft→approved promotion (the recs are already `approved`). The downstream artifacts were queued at rec-gen time, so this returns fast. Then show the completion rail and continue to Step 9.5:
+- **`proceed`** (from the landing or any drill view) → call `mcp__ritual__accept_recommendations({ exploration_id })`. Under the non-blocking model this **records the human review** (stamps `reviewedAt` / `reviewedBy`) and advances; it is NOT a draft→approved promotion (the recs are already `approved`). The downstream artifacts were queued at rec-gen time, so this returns fast. Then show the completion rail and continue to Step 9.5:
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ✓ Discovery  ✓ Recommendations  ● Build brief  ○ Implementation (Your agent)
+✓ Job  ✓ Scope  ✓ Discovery  ✓ Recommendations  ● Build brief  ○ Implementation (Your agent)
 
 Reviewed {N} recommendations.
 
@@ -1873,7 +1895,7 @@ Run a constraint-survival audit on the typed Recommendation + Requirement substr
 ```text
 Recommendations + requirements are ready. Optional constraint-survival audit available.
 
-Reply `audit` to run, or `proceed` to skip to brief generation.
+Reply `audit` to run, or `proceed` to skip the audit and generate the {Deliverable}.
 ```
 
 **For `--audited` mode:**
@@ -1884,7 +1906,7 @@ Recommendations + requirements are ready.
 Recommended: run constraint-survival audit before brief generation.
 This checks whether anti-goals survived into the recs + requirements.
 
-Reply `audit`, `proceed`, or `always audit for this build`.
+Reply `audit` to run, `proceed` to skip and generate the {Deliverable}, or `always audit for this build`.
 ```
 
 **For `--audit=strict` mode:** SKIP the prompt; jump directly to Step 9.6.2 (run the audit).
@@ -2078,6 +2100,13 @@ Steps:
    - `contradicted` — brief claim is wrong; the code does something different.
    - `not_found` — symbol couldn't be located.
 
+   **Narrating a finding (if you surface one before the summary): frame it as resolving drift, not as an error report.** Lead with *resolving drift between the brief and the codebase*, then ONE plain sentence describing the drift and where the real pattern lives. Do **not** lead with "X doesn't exist" / "references a function that doesn't exist" — a `not_found` / `contradicted` verdict is the verification working as intended (it caught a brief-vs-code gap before you shipped), not a failure to alarm the user about.
+
+   ❌ `get_core_apps is not in the codebase — the brief's RB-1 references a function that doesn't exist. The actual pattern is direct INSTALLED_APPS manipulation (index + replace), as seen in tests/settings.py.`
+   ✅ `Resolving drift between the brief and the codebase: RB-1 cites get_core_apps, but the repo edits INSTALLED_APPS directly (index + replace — see tests/settings.py). Noting it in the verification.`
+
+   This is a progress line, not a gate — keep it to one sentence and continue; the structured findings land in `BUILD-BRIEF-VERIFICATION.md` and the Step 10d gate.
+
 5. **Write `BUILD-BRIEF-VERIFICATION.md`** to disk alongside `BUILD-BRIEF.md` using the schema in `references/brief-verification-checklist.md`. Cite file + line range + actual code snippet on every contradiction. Do not fabricate evidence.
 
 6. **Sync the verification to Ritual's KG** — call `mcp__ritual__sync_brief_review` with:
@@ -2194,7 +2223,7 @@ End Step 10 with a single recommended action plus a cheap escape hatch — never
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ✓ Discovery  ✓ Recommendations  ● Build brief  ○ Implementation (Your agent)
+✓ Job  ✓ Scope  ✓ Discovery  ✓ Recommendations  ● Build brief  ○ Implementation (Your agent)
 
 Build brief ready
 
@@ -2300,7 +2329,7 @@ Steps:
 
    ```text
    Reply `go` to start implementation with the UX review as plan-mode input,
-   or `refine` / `drill {N}` / `pause` per the earlier options.
+   or `drill {N}` / `pause` per the earlier options.
    ```
 
    When the user replies `go`, continue to Step 11 with the explicit instruction (passed to plan mode) to read both `BUILD-BRIEF.md` AND `UX-REVIEW.md`, and to use the "Plan Mode Prompt" block at the bottom of `UX-REVIEW.md` as its first numbered list — not a generic plan.
@@ -2324,7 +2353,7 @@ The Implementation phase landing — full rail (the rail moves to Implementation
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ● Implementation (Your agent)
+✓ Job  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ● Implementation (Your agent)
 
 Implementation (Your agent)
 
@@ -2650,7 +2679,7 @@ Before asking for permission, frame the call in language the user can act on. `s
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ● Implementation (Your agent)
+✓ Job  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ● Implementation (Your agent)
 
 Log implementation
 
@@ -2693,7 +2722,7 @@ When sync_implementation succeeds, the response includes:
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ✓ Implementation (Your agent)
+✓ Job  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ✓ Implementation (Your agent)
 
 ✓ Logged implementation for {exploration name}
 
@@ -2728,7 +2757,7 @@ User-visible (full rail — sync failure is a top-level state):
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ● Implementation (Your agent)
+✓ Job  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ● Implementation (Your agent)
 
 Sync failed (recoverable)
 
@@ -2766,7 +2795,7 @@ If stale, surface to the user with the full rail (top-level decision gate):
 
 ```text
 Ritual build
-✓ Context  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ● Implementation (Your agent)
+✓ Job  ✓ Scope  ✓ Discovery  ✓ Recommendations  ✓ Build brief  ● Implementation (Your agent)
 
 Pending sync is stale