learnship 2.3.3 → 2.3.5

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "learnship",
   "description": "Agentic engineering done right — 57 structured workflows, 17 specialist agent personas, persistent memory across sessions, integrated learning partner, and impeccable UI design system. Works with Claude Code, Windsurf, Cursor, Gemini CLI, OpenCode, and Codex.",
-  "version": "2.3.3",
+  "version": "2.3.5",
   "author": {
     "name": "Favio Vazquez",
     "email": "favio.vazquezp@gmail.com"

package/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "learnship",
   "displayName": "learnship",
   "description": "Agentic engineering done right — 57 structured workflows, 17 specialist agent personas, persistent memory across sessions, integrated learning partner, and impeccable UI design system.",
-  "version": "2.3.3",
+  "version": "2.3.5",
   "logo": "assets/logo.png",
   "author": {
     "name": "Favio Vazquez",

package/README.md

@@ -121,7 +121,7 @@ Every feature ships through a 7-step loop:
 ```mermaid
 flowchart LR
     DP["/discuss-phase N<br/>Capture decisions"]
-    PP["/plan-phase N<br/>Research + plans"]
+    PP["/plan-phase N<br/>Vertical slice plans"]
     EP["/execute-phase N<br/>Build + commit"]
     VW["/verify-work N<br/>UAT + diagnose"]
     RV["/review<br/>Multi-persona review"]
@@ -136,8 +136,8 @@ flowchart LR
 
 | Step | Command | What happens |
 |------|---------|-------------|
-| **1. Discuss** | `/discuss-phase N` | You and the agent align on implementation decisions before any code |
-| **2. Plan** | `/plan-phase N` | Agent researches the domain, creates executable plans, verifies them |
+| **1. Discuss** | `/discuss-phase N` | You and the agent align on implementation decisions before any code. Add `--deep` for extended deep questioning that walks every branch (v2.3.4) |
+| **2. Plan** | `/plan-phase N` | Agent researches the domain, creates vertical slice plans (tracer bullets), verifies them — including horizontal slice detection (v2.3.4) |
 | **3. Execute** | `/execute-phase N` | Plans run in dependency order, one atomic commit per task |
 | **4. Verify** | `/verify-work N` | You do UAT; agent diagnoses any gaps and creates fix plans |
 | **5. Review** | `/review` | Multi-persona code review through 6 lenses (v2.0) |
@@ -252,6 +252,14 @@ It's probably overkill for one-off scripts. Use `/quick` for that.
 
 ## 🆕 What's New
 
+### What's new in v2.3.4
+
+v2.3.4 adds two planning quality features:
+
+**Deep questioning mode** (`--deep` flag or `workflow.discuss_mode: "deep"` in config): Both `/discuss-phase` and `/new-project` now support extended questioning that walks every decision branch until shared understanding is reached. Each question includes a recommended answer. Standard mode (4 focused exchanges) remains the default.
+
+**Vertical slice planning** (enforced in `plan-phase`): Plans are now required to be tracer bullets — thin vertical slices through all integration layers (data → logic → API → UI → test) for one demoable user-facing behavior. The plan-checker flags any plan that covers only one architectural layer across all features. Single-layer phases (migrations, style passes) use `single_layer_justified: true` in the plan frontmatter.
+
 ### What's new in v2.3
 
 v2.3 adds 5 new agent personas, Windsurf-native persona adoption via `model_decision` rules, and inline `<persona_context>` blocks across all 18 persona-aware workflows:
@@ -294,7 +302,7 @@ v2.1 adds 8 new workflows, 5 new references, 3 new templates, and 2 new agents:
 | **Session** | `/note` — zero-friction capture · `/session-report` — stakeholder summaries |
 | **Learning** | `/extract-learnings` — decisions, lessons, patterns, surprises · `/milestone-summary` — team onboarding |
 
-Enhanced: `/discuss-phase` (scope guardrails + domain probes), `/execute-phase` (`--wave` flag + context scaling), `/quick` (`--research --validate --full` composable flags), `/ideate` (`--explore` Socratic mode).
+Enhanced: `/discuss-phase` (scope guardrails + domain probes + `--deep` extended questioning v2.3.4), `/new-project` (`--deep` extended questioning v2.3.4), `/plan-phase` (vertical slice tracer bullets + horizontal slice detection v2.3.4), `/execute-phase` (`--wave` flag + context scaling), `/quick` (`--research --validate --full` composable flags), `/ideate` (`--explore` Socratic mode).
 
 **Optional per-phase:** `/secure-phase N` (STRIDE security), `/extract-learnings N` (meta-knowledge).
 **Recovery:** `/forensics` (post-mortem), `/undo` (safe revert).
@@ -533,13 +541,16 @@ Project settings live in `.planning/config.json`. Set during `/new-project` or e
 ### Workflow Toggles
 
 | Setting | Default | What it controls |
-|---------|---------|-----------------|
+|---------|---------|------------------|
 | `workflow.research` | `true` | Domain research before planning each phase |
-| `workflow.plan_check` | `true` | Plan verification loop (up to 3 iterations) |
+| `workflow.plan_check` | `true` | Plan verification loop (up to 3 iterations), including vertical slice integrity check |
 | `workflow.verifier` | `true` | Post-execution verification against phase goals |
 | `workflow.validation` | `true` | Test coverage mapping during plan-phase |
 | `workflow.review` | `true` | Enable `/review` suggestions after `/verify-work` (v2.0) |
 | `workflow.solutions_search` | `true` | Search `.planning/solutions/` during `/plan-phase` (v2.0) |
+| `workflow.security_enforcement` | `true` | Per-phase STRIDE security verification via `/secure-phase` |
+| `workflow.discuss_mode` | `"discuss"` | Questioning depth: `"discuss"` (4 exchanges) or `"deep"` (extended, walks every branch) (v2.3.4) |
+| `workflow.tdd_mode` | `false` | Instruct planner to apply TDD task ordering to eligible tasks |
 
 ### Review & Ship Settings
 

package/agents/learnship-plan-checker.md

@@ -1,6 +1,6 @@
 ---
 name: learnship-plan-checker
-description: Verifies PLAN.md files for a phase — checks goal coverage, requirement IDs, CONTEXT.md decisions, task completeness, and wave correctness. Spawned by plan-phase on platforms with subagent support.
+description: Verifies PLAN.md files for a phase — checks goal coverage, requirement IDs, CONTEXT.md decisions, task completeness, wave correctness, and vertical slice integrity (each plan must be a demoable tracer bullet). Spawned by plan-phase on platforms with subagent support.
 tools: Read, Bash, Glob, Grep
 color: cyan
 ---
@@ -48,6 +48,11 @@ For every task in every plan, check:
 - Is each plan achievable in a single context window? (~200k tokens, 2-3 tasks)
 - Are there any tasks that are too vague to implement without guessing?
 
+### 7. Vertical Slice (tracer bullet)
+- Does each plan's `objective` describe a **demoable user-facing behavior** delivered end-to-end?
+- Does any plan cover only a single layer (all schema, all API routes, all UI components across the feature)? If yes, flag as **horizontal slice** unless `single_layer_justified: true` is in the frontmatter.
+- The test: "Can someone demo what this plan delivers after it completes, without completing other plans?" If no and `single_layer_justified` is not set → flag it.
+
 ## What NOT to check
 - Code style or implementation approach preferences (that's the planner's job)
 - Research quality (that's already done)

package/agents/learnship-planner.md

@@ -1,6 +1,6 @@
 ---
 name: learnship-planner
-description: Creates executable PLAN.md files for a phase — decomposes goals into wave-ordered tasks with dependency analysis. Spawned by plan-phase on platforms with subagent support.
+description: Creates executable PLAN.md files for a phase — decomposes goals into vertical slice (tracer bullet) tasks with wave-ordered dependency analysis. Each plan delivers one demoable user-facing behavior end-to-end. Spawned by plan-phase on platforms with subagent support.
 tools: Read, Write, Bash, Glob, Grep
 color: green
 ---
@@ -28,11 +28,18 @@ Before planning, load project context:
 
 ## Core Rules
 
-1. **Honor CONTEXT.md first** — locked decisions are non-negotiable. Plans implement decisions, not the other way around.
-2. **Goal-backward** — start from the phase goal, derive the minimum set of must-haves, then build tasks backward from those
-3. **One context window per plan** — each plan must be executable in a single agent session (~200k tokens)
-4. **2-3 tasks per plan** — enough to be a meaningful unit, small enough to verify cleanly
-5. **Observable must-haves** — every must-have must be checkable by reading a file or running a command
+1. **Vertical slices, not horizontal layers** — Each PLAN.md is a **tracer bullet**: a thin vertical slice through all integration layers for one user-facing behavior. A completed plan is demoable without completing other plans. DO NOT create all-schema, all-API, or all-UI plans.
+   ```
+   WRONG: Plan 01 = DB schema   Plan 02 = API routes   Plan 03 = UI
+   RIGHT: Plan 01 = user can log in (schema + route + form + test)
+          Plan 02 = user can reset password (schema + route + form + test)
+   ```
+   Exception: add `single_layer_justified: true` to frontmatter if the phase is legitimately single-layer (migration, style pass).
+2. **Honor CONTEXT.md first** — locked decisions are non-negotiable. Plans implement decisions, not the other way around.
+3. **Goal-backward** — start from the phase goal, derive the minimum set of must-haves, then build tasks backward from those
+4. **One context window per plan** — each plan must be executable in a single agent session (~200k tokens)
+5. **2-3 tasks per plan** — enough to be a meaningful unit, small enough to verify cleanly
+6. **Observable must-haves** — every must-have must be checkable by reading a file or running a command
 
 ## Wave Assignment
 
@@ -52,7 +59,8 @@ files_modified:
   - src/feature.ts
   - tests/feature.test.ts
 autonomous: true
-objective: "One sentence describing what this plan builds and why it matters"
+single_layer_justified: false  # true only for legitimately single-layer phases
+objective: "One sentence describing the demoable user-facing behavior this plan delivers end-to-end"
 must_haves:
   - "src/feature.ts exists and exports FeatureClass"
   - "tests/feature.test.ts has at least 3 test cases"
@@ -113,10 +121,12 @@ Load everything before writing a single plan:
 ## Step 2: Decompose Phase Goal
 
 From the phase goal and requirements:
-1. List all deliverables (what must exist after this phase)
-2. Map each deliverable to a logical implementation unit
-3. Find dependencies between units
-4. Group into 2-4 plans, assign waves
+1. List all user-facing behaviors the phase must deliver (not layers — behaviors)
+2. Each behavior becomes one plan: data schema + logic + API + UI + test
+3. Find dependencies between plans
+4. Group into 2-4 vertical slice plans, assign waves
+
+**Self-check before writing:** For each draft plan, ask: "Can someone demo this plan's deliverable after it completes, without completing other plans?" If no → restructure.
 
 ## Step 3: Write Plans
 

package/bin/install.js

@@ -1438,7 +1438,7 @@ function install(platform, isGlobal) {
     console.log(`  ${yellow}Option 2 (manual):${reset} Copy the rule file into your project:`);
     console.log(`    ${dim}mkdir -p .cursor/rules${reset}`);
     console.log(`    ${dim}cp node_modules/learnship/cursor-rules/learnship.mdc .cursor/rules/${reset}\n`);
-    console.log(`  ${dim}The .mdc rule activates all 42 learnship workflows automatically in every Cursor session.${reset}\n`);
+    console.log(`  ${dim}The .mdc rule activates all 57 learnship workflows automatically in every Cursor session.${reset}\n`);
     return;
   }
 

package/cursor-rules/learnship.mdc

@@ -160,7 +160,7 @@ Set `"parallelization": { "enabled": true|false }` in `.planning/config.json` ba
 
 ## Structured Questions
 
-When workflows include `AskUserQuestion()` blocks, **Cursor has no native structured question tool**. Present each question as a numbered text list with descriptions and ask the user to reply with their choice number or label. Present questions in rounds (Round 1: core settings, Round 2: workflow agents, Round 3: pipeline & git, Round 4: parallelization). **Wait for the user's reply after EACH round before showing the next.** Do NOT present all questions at once.
+When workflows include `AskUserQuestion()` blocks, **Cursor has no native structured question tool**. Present each question as a numbered text list with descriptions and ask the user to reply with their choice number or label. Present questions in rounds (Round 1: core settings — working style, granularity, learning partner, AI models, questioning depth, output profile; Round 2: workflow agents; Round 3: pipeline & git; Round 4: parallelization). **Wait for the user's reply after EACH round before showing the next.** Do NOT present all questions at once.
 
 Example:
 ```
@@ -178,6 +178,8 @@ After all configuration rounds are answered, write `.planning/config.json` with
 - Granularity → `"granularity"`: `"coarse"`, `"standard"`, or `"fine"`
 - Learning Partner → `"learning_mode"`: `"auto"` or `"manual"`
 - AI Models → `"model_profile"`: `"balanced"`, `"quality"`, or `"budget"`
+- Questioning Depth → `"workflow.discuss_mode"`: `"discuss"` (Standard) or `"deep"` (Deep)
+- Output Profile → `"context"`: `"dev"` (Dev), `"research"` (Research), or `"review"` (Review)
 - Research → `"workflow.research"`: `true` or `false`
 - Plan Check → `"workflow.plan_check"`: `true` or `false`
 - Verifier → `"workflow.verifier"`: `true` or `false`

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "learnship",
-  "version": "2.3.3",
+  "version": "2.3.5",
   "description": "Agentic engineering done right — 57 structured workflows, 17 specialist agent personas, persistent memory across sessions, integrated learning partner, and impeccable UI design system.",
   "author": "Favio Vazquez",
   "homepage": "https://faviovazquez.github.io/learnship/",

package/learnship/agents/plan-checker.md

@@ -34,6 +34,11 @@ For every task in every plan, check:
 - Is each plan achievable in a single context window? (~200k tokens, 2-3 tasks)
 - Are there any tasks that are too vague to implement without guessing?
 
+### 7. Vertical Slice (tracer bullet)
+- Does each plan's `objective` describe a **demoable user-facing behavior** delivered end-to-end?
+- Does any plan cover only a single layer across the whole feature (all schema, all API endpoints, all UI components)? If yes, flag it as a **horizontal slice** unless `single_layer_justified: true` is set in the frontmatter.
+- The test: "Can someone demo what this plan delivers after it completes, without completing other plans?" If no and `single_layer_justified` is not set → flag it.
+
 ## What NOT to check
 - Code style or implementation approach preferences (that's the planner's job)
 - Research quality (that's already done)

package/learnship/agents/planner.md

@@ -6,6 +6,18 @@ Plans are precise prompts for an executor — not documents that become prompts.
 
 ## Planning Principles
 
+**Vertical slices, not horizontal layers** — Each PLAN.md is a **tracer bullet**: a thin vertical slice that cuts through all integration layers end-to-end for one user-facing behavior. A completed plan is demoable or verifiable on its own. Do NOT create plans that implement a single layer across the whole feature.
+
+```
+WRONG (horizontal):  Plan 01 = all DB schema   Plan 02 = all API   Plan 03 = all UI
+RIGHT  (vertical):   Plan 01 = user can log in (schema + API endpoint + UI form + test)
+                     Plan 02 = user can reset password (schema + API + UI + test)
+```
+
+**Anti-pattern to avoid:** If someone cannot demo what a completed plan delivers without also completing other plans, the plan is too horizontal. Restructure.
+
+**Exception — single-layer phases:** Some phases are legitimately single-layer (e.g., "migrate all DB tables to new schema", "style all existing components"). In this case, add `single_layer_justified: true` to the plan's YAML frontmatter and note the reason in the objective.
+
 **Atomic tasks** — each task should be completable in one logical unit of work and committed independently.
 
 **Observable done criteria** — every task must have a `<done>` field that describes something you can check (file exists, test passes, import resolves) — not "task is complete".
@@ -36,7 +48,8 @@ files_modified:
   - path/to/file.ts
   - path/to/other.ts
 autonomous: true
-objective: "[One sentence: what this plan builds and why it matters for the phase]"
+single_layer_justified: false  # set true only if this phase is legitimately single-layer (e.g., DB migration, style pass)
+objective: "[One sentence describing the demoable user-facing behavior this plan delivers end-to-end]"
 must_haves:
   truths:
     - "File src/auth/token.ts exists and exports `validateToken`"

package/learnship/references/planning-config.md

@@ -210,7 +210,7 @@ New sections and fields added in v2.1.0 for security, parallelization control, g
 | Option | Default | Description |
 |--------|---------|-------------|
 | `workflow.security_enforcement` | `true` | Enable per-phase security verification via `/secure-phase` |
-| `workflow.discuss_mode` | `"discuss"` | Discussion mode for discuss-phase |
+| `workflow.discuss_mode` | `"discuss"` | Discussion depth for `discuss-phase` and `new-project` questioning. `"discuss"` = standard (4 focused exchanges). `"deep"` = extended questioning, walks every decision branch until shared understanding — equivalent to passing `--deep` flag |
 | `workflow.tdd_mode` | `false` | Instruct planner to apply `type: tdd` to eligible tasks |
 
 ### Parallelization Section (replaces flat boolean)

package/learnship/templates/plan.md

@@ -113,6 +113,14 @@ Phases execute in numeric order: 2 → 2.1 → 2.2 → 3 → 3.1 → 4
 - Progress table updated by execute workflow
 - Plan count can be "TBD" initially, refined during planning
 
+**Vertical slice planning (enforced by plan-phase and plan-checker):**
+- Each PLAN.md is a tracer bullet — one user-facing behavior, all layers (data → logic → API → UI → test)
+- A completed plan is demoable without completing other plans
+- Plan descriptions in this roadmap should reflect what users experience, not which layer is being built
+  - ✗ "01-01: Create database schema" — horizontal, not demoable alone
+  - ✓ "01-01: User can register and receive confirmation email" — vertical, demoable
+- Exception: `single_layer_justified: true` in PLAN.md frontmatter for legitimately single-layer phases
+
 **Success criteria:**
 - 2-5 observable behaviors per phase (from user's perspective)
 - Cross-checked against requirements during roadmap creation

package/learnship/workflows/discuss-phase.md

@@ -7,6 +7,7 @@ description: Capture implementation decisions for a phase before planning starts
 Extract implementation decisions that downstream planning needs. Analyze the phase to identify gray areas, let the user choose what to discuss, then deep-dive each selected area until satisfied.
 
 **Usage:** Run `discuss-phase [N]` before `plan-phase [N]`.
+**Usage:** Run `discuss-phase [N] --deep` for extended deep questioning — walks every decision branch until shared understanding is reached, with a recommended answer for each question.
 
 **You are a thinking partner, not an interviewer.** The user is the visionary — you are the builder. Your job is to capture decisions that will guide research and planning, not to figure out implementation yourself.
 
@@ -28,6 +29,12 @@ Extract implementation decisions that downstream planning needs. Analyze the pha
 
 ## Step 1: Load Phase
 
+**Detect mode:** Check for `--deep` flag in the command. If not present, check `workflow.discuss_mode` in `.planning/config.json` — if it is `"deep"`, activate deep mode. Otherwise, use standard mode.
+
+```
+DEEP_MODE = "--deep" flag present OR config.workflow.discuss_mode == "deep"
+```
+
 Read `.planning/ROADMAP.md` and find the requested phase number. If not found, stop and show available phases.
 
 Read prior context to avoid re-asking decided questions:
@@ -175,7 +182,7 @@ If "All clear" → skip to Step 6.
 **For each selected area, discuss:**
 
 1. Announce: "Let's talk about [Area]."
-2. Ask focused questions with concrete options using structured questions where possible:
+2. Ask focused questions with concrete options using structured questions where possible. **Always include a recommended answer** — state which option you'd pick and why:
 
 ```
 AskUserQuestion([
@@ -184,7 +191,7 @@ AskUserQuestion([
     question: "[Specific implementation question]",
     multiSelect: false,
     options: [
-      { label: "[Option A] (Recommended)", description: "[Why, with code context if relevant]" },
+      { label: "[Option A] (Recommended)", description: "[Why this is recommended, with code context if relevant]" },
       { label: "[Option B]", description: "[Why]" },
       { label: "[Option C]", description: "[Why]" }
     ]
@@ -194,13 +201,23 @@ AskUserQuestion([
 
 > 🛑 STOP. Wait for the user's reply before continuing.
 
-3. After 4 questions, ask: "More questions about [area], or move to next?"
+**Standard mode** (default):
+3. After 4 questions per area, ask: "More questions about [area], or move to next?"
 4. If more → ask 4 more, then check again
 
+**Deep mode** (`--deep` or `discuss_mode: "deep"`):
+3. After each answer, analyze: what is the single biggest remaining unknown in this area that could change how it's implemented? Ask that next. Provide your recommended answer.
+4. Continue drilling down each decision branch — if an answer opens a sub-branch, follow it. Do NOT move on until the branch is fully resolved.
+5. Only move to the next area when you judge that the current area has no remaining decision branches that would change the implementation.
+6. If you can explore the codebase to answer a question yourself, do so instead of asking the user.
+
+> **Deep mode intent:** Walk the full decision tree. Resolve every fork. The CONTEXT.md produced should leave no ambiguity that downstream agents would need to guess about.
+
 After all selected areas:
 - Summarize decisions captured
 - Present final check:
 
+**Standard mode:**
 ```
 AskUserQuestion([
   {
@@ -215,6 +232,22 @@ AskUserQuestion([
 ])
 ```
 
+**Deep mode:**
+```
+AskUserQuestion([
+  {
+    header: "Shared Understanding Check",
+    question: "I've walked through every decision branch I can identify. Do you feel we've reached shared understanding on how to implement this phase?",
+    multiSelect: false,
+    options: [
+      { label: "Yes — write CONTEXT.md", description: "All key decisions are captured" },
+      { label: "There's still [area] to discuss", description: "Keep going on a specific area" },
+      { label: "Let me add something", description: "I have context to add before you write" }
+    ]
+  }
+])
+```
+
 > 🛑 STOP. Wait for the user's reply before continuing.
 
 <scope_guardrail>
@@ -256,6 +289,7 @@ Write `.planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-CONTEXT.md`:
 # Phase [X]: [Name] - Context
 
 **Gathered:** [date]
+**Mode:** [standard | deep]
 **Status:** Ready for planning
 
 <domain>
@@ -368,6 +402,7 @@ Created: .planning/phases/[padded_phase]-[slug]/[padded_phase]-CONTEXT.md
 
 💡 Ambitious scope? `/challenge` — stress-test the approach before planning
 💡 Made important decisions? `/compound` — capture them while context is fresh
+💡 Want to go deeper? Re-run `discuss-phase [X] --deep` for relentless branch-walking until full shared understanding
 ```
 
 ---

package/learnship/workflows/new-project.md

@@ -125,9 +125,9 @@ Note the tech stack, key directories, and any README content internally. Use thi
 >
 > **🛑 FORBIDDEN:** Do NOT present all questions at once as a text wall. Do NOT skip any question. Do NOT invent answers. Do NOT proceed to the config.json write step until ALL 4 rounds have been answered by the user.
 
-**Round 1 — Core settings (4 questions):**
+**Round 1 — Core settings (6 questions):**
 
-> Present these 4 questions as a SINGLE blocking `AskUserQuestion` call. STOP and wait for the user's reply before proceeding to Round 2.
+> Present these 6 questions as a SINGLE blocking `AskUserQuestion` call. STOP and wait for the user's reply before proceeding to Round 2.
 
 ```
 AskUserQuestion([
@@ -168,6 +168,25 @@ AskUserQuestion([
       { label: "Quality", description: "Large-tier models for all agents (highest cost, best results)" },
       { label: "Budget", description: "Medium for code, small for research/verification (lowest cost)" }
     ]
+  },
+  {
+    header: "Questioning Depth",
+    question: "How deep should discuss-phase and new-project question you?",
+    multiSelect: false,
+    options: [
+      { label: "Standard (Recommended)", description: "4 focused exchanges per area — fast and sufficient for most projects" },
+      { label: "Deep", description: "Extended questioning: walks every decision branch until shared understanding is reached. Produces richer CONTEXT.md and PROJECT.md. Good for complex or unfamiliar domains." }
+    ]
+  },
+  {
+    header: "Output Profile",
+    question: "How verbose should agent responses be?",
+    multiSelect: false,
+    options: [
+      { label: "Dev (Recommended)", description: "Concise, action-oriented — code first, brief rationale. Low verbosity." },
+      { label: "Research", description: "Detailed explanations, alternatives, and context. High verbosity." },
+      { label: "Review", description: "Audit-focused — findings, severity, recommendations. Medium verbosity." }
+    ]
   }
 ])
 ```
@@ -289,6 +308,8 @@ AskUserQuestion([
 - Granularity → `"granularity"`: `"coarse"`, `"standard"`, or `"fine"`
 - Learning Partner → `"learning_mode"`: `"auto"` or `"manual"`
 - AI Models → `"model_profile"`: `"balanced"`, `"quality"`, or `"budget"`
+- Questioning Depth → `"workflow.discuss_mode"`: `"discuss"` (Standard) or `"deep"` (Deep)
+- Output Profile → `"context"`: `"dev"` (Dev), `"research"` (Research), or `"review"` (Review)
 - Research → `"workflow.research"`: `true` or `false`
 - Plan Check → `"workflow.plan_check"`: `true` or `false`
 - Verifier → `"workflow.verifier"`: `true` or `false`
@@ -308,6 +329,7 @@ Create `.planning/config.json` with all settings:
   "granularity": "coarse|standard|fine",
   "model_profile": "quality|balanced|budget",
   "learning_mode": "auto|manual",
+  "context": "dev|research|review",
   "test_first": false|true,
   "planning": {
     "commit_docs": true|false,
@@ -322,7 +344,7 @@ Create `.planning/config.json` with all settings:
     "review": true|false,
     "solutions_search": true|false,
     "security_enforcement": true|false,
-    "discuss_mode": "discuss",
+    "discuss_mode": "discuss|deep",
     "tdd_mode": false|true
   },
   "parallelization": {
@@ -380,6 +402,8 @@ try{
   if(!['auto','manual'].includes(c.learning_mode)) errs.push('learning_mode must be auto|manual');
   if(typeof c.test_first!=='boolean') errs.push('test_first must be boolean');
   if(!c.planning||!['auto','manual'].includes(c.planning.commit_mode)) errs.push('planning.commit_mode must be auto|manual');
+  if(c.context&&!['dev','research','review'].includes(c.context)) errs.push('context must be dev|research|review');
+  if(c.workflow&&c.workflow.discuss_mode&&!['discuss','deep'].includes(c.workflow.discuss_mode)) errs.push('workflow.discuss_mode must be discuss|deep');
   if(!c.workflow||typeof c.workflow.research!=='boolean') errs.push('workflow.research must be boolean');
   if(!c.workflow||typeof c.workflow.plan_check!=='boolean') errs.push('workflow.plan_check must be boolean');
   if(!c.workflow||typeof c.workflow.verifier!=='boolean') errs.push('workflow.verifier must be boolean');
@@ -424,7 +448,25 @@ Display:
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
-This step is **strictly sequential**. You must complete each numbered exchange fully before moving to the next. Do not batch questions. Do not skip exchanges. Do not proceed to Step 4 until Exchange 4 is complete.
+**Detect questioning mode:** Check for `--deep` flag in the `/new-project` command. If not present, ask the user:
+
+```
+AskUserQuestion([
+  {
+    header: "Questioning Depth",
+    question: "How deep do you want me to go with questions before writing PROJECT.md?",
+    multiSelect: false,
+    options: [
+      { label: "Standard (Recommended)", description: "4 focused exchanges — enough for a sharp PROJECT.md" },
+      { label: "Deep", description: "Grill-me style — I walk every open branch until we reach shared understanding. Takes longer, produces a richer PROJECT.md" }
+    ]
+  }
+])
+```
+
+> 🛑 STOP. Wait for the user's reply. Record mode as `QUESTIONING_MODE = standard | deep`.
+
+This step is **strictly sequential**. You must complete each numbered exchange fully before moving to the next. Do not batch questions. Do not skip exchanges. Do not proceed to Step 4 until the gate check passes.
 
 **Exchange 1 — Opening question:**
 
@@ -465,6 +507,8 @@ Based on all previous answers, ask a third follow-up that clarifies scope, edge
 >
 > If any count is wrong, go back and complete the missing exchanges. Do NOT proceed with fewer than 4 exchanges under any circumstances — even if the user's first answer was extremely detailed.
 
+**If `QUESTIONING_MODE = standard`:**
+
 Verify internally: do you have `ANSWER_1`, `ANSWER_2`, `ANSWER_3`, and `ANSWER_4` recorded? If any is missing, go back and ask it. Only after all four answers are in hand may you ask:
 
 "I think I have a solid picture of what you're building. Ready for me to write PROJECT.md, or is there more you want to cover first?"
@@ -472,6 +516,31 @@ Verify internally: do you have `ANSWER_1`, `ANSWER_2`, `ANSWER_3`, and `ANSWER_4
 - **Write PROJECT.md** → proceed to Step 4
 - **More to cover** → continue asking follow-ups, then re-ask this gate question
 
+**If `QUESTIONING_MODE = deep`:**
+
+After Exchange 4, continue with the extended deep questioning loop:
+- Identify the single biggest remaining unknown that would change the direction, scope, or architecture of PROJECT.md. Ask it. Provide your recommended answer with each question.
+- If an answer opens a new branch (a sub-decision), follow that branch before moving on.
+- If you can explore the codebase to resolve a question yourself, do so instead of asking.
+- Continue until you judge that all major branches are resolved. Then ask:
+
+```
+AskUserQuestion([
+  {
+    header: "Shared Understanding Check",
+    question: "I've walked through every major open question I can identify. Do you feel we have a complete shared picture of what you want to build?",
+    multiSelect: false,
+    options: [
+      { label: "Yes — write PROJECT.md", description: "All key decisions and scope are clear" },
+      { label: "There's still something open", description: "Keep going on a specific area" },
+      { label: "Let me add context", description: "I have something to add before you write" }
+    ]
+  }
+])
+```
+
+> 🛑 STOP. Wait for user reply. If "Yes" → proceed to Step 4. Otherwise continue drilling.
+
 Use the questioning techniques from `@./references/questioning.md` and domain-aware probes from `@./references/domain-probes.md` to shape the follow-up questions. When the user mentions a known domain (auth, real-time, dashboard, API, database, search, file uploads, caching, testing, deployment, AI/ML), use the relevant probes to ask sharper questions.
 
 ## Step 4: Write PROJECT.md
@@ -627,9 +696,19 @@ Task(
     </quality_gate>
 
     <output>
-    Write to: .planning/research/STACK.md
     Required sections: ## Recommended Stack, ## Alternatives Considered, ## What NOT to Use, ## Versions
     </output>
+
+    **WRITE ACTION REQUIRED — You MUST use your file-write tool to write STACK.md to disk. Do NOT output the content to the conversation. Do NOT treat this as done until the file physically exists on disk.**
+
+    Write the research content to `.planning/research/STACK.md` using your write tool now.
+
+    Then verify:
+    ```
+    node -e "const fs=require('fs');const f='.planning/research/STACK.md';if(!fs.existsSync(f)){console.log('STACK_MISSING');process.exit(1);}console.log('STACK_OK — '+fs.readFileSync(f,'utf8').length+' chars');"
+    ```
+
+    If `STACK_MISSING`: write the file and re-run until `STACK_OK`.
   "
 )
 
@@ -675,9 +754,19 @@ Task(
     </quality_gate>
 
     <output>
-    Write to: .planning/research/FEATURES.md
     Required sections: ## Table Stakes, ## Differentiators, ## Anti-Features
     </output>
+
+    **WRITE ACTION REQUIRED — You MUST use your file-write tool to write FEATURES.md to disk. Do NOT output the content to the conversation. Do NOT treat this as done until the file physically exists on disk.**
+
+    Write the research content to `.planning/research/FEATURES.md` using your write tool now.
+
+    Then verify:
+    ```
+    node -e "const fs=require('fs');const f='.planning/research/FEATURES.md';if(!fs.existsSync(f)){console.log('FEATURES_MISSING');process.exit(1);}console.log('FEATURES_OK — '+fs.readFileSync(f,'utf8').length+' chars');"
+    ```
+
+    If `FEATURES_MISSING`: write the file and re-run until `FEATURES_OK`.
   "
 )
 
@@ -723,9 +812,19 @@ Task(
     </quality_gate>
 
     <output>
-    Write to: .planning/research/ARCHITECTURE.md
     Required sections: ## Component Boundaries, ## Data Flow, ## Build Order, ## Integration Points
     </output>
+
+    **WRITE ACTION REQUIRED — You MUST use your file-write tool to write ARCHITECTURE.md to disk. Do NOT output the content to the conversation. Do NOT treat this as done until the file physically exists on disk.**
+
+    Write the research content to `.planning/research/ARCHITECTURE.md` using your write tool now.
+
+    Then verify:
+    ```
+    node -e "const fs=require('fs');const f='.planning/research/ARCHITECTURE.md';if(!fs.existsSync(f)){console.log('ARCH_MISSING');process.exit(1);}console.log('ARCH_OK — '+fs.readFileSync(f,'utf8').length+' chars');"
+    ```
+
+    If `ARCH_MISSING`: write the file and re-run until `ARCH_OK`.
   "
 )
 
@@ -771,9 +870,19 @@ Task(
     </quality_gate>
 
     <output>
-    Write to: .planning/research/PITFALLS.md
     Required sections: ## Common Mistakes, ## Warning Signs, ## Prevention Strategies
     </output>
+
+    **WRITE ACTION REQUIRED — You MUST use your file-write tool to write PITFALLS.md to disk. Do NOT output the content to the conversation. Do NOT treat this as done until the file physically exists on disk.**
+
+    Write the research content to `.planning/research/PITFALLS.md` using your write tool now.
+
+    Then verify:
+    ```
+    node -e "const fs=require('fs');const f='.planning/research/PITFALLS.md';if(!fs.existsSync(f)){console.log('PITFALLS_MISSING');process.exit(1);}console.log('PITFALLS_OK — '+fs.readFileSync(f,'utf8').length+' chars');"
+    ```
+
+    If `PITFALLS_MISSING`: write the file and re-run until `PITFALLS_OK`.
   "
 )
 ```
@@ -811,11 +920,22 @@ Task(
     </downstream_consumer>
 
     <output>
-    Write to: .planning/research/SUMMARY.md
     Required sections: ## Executive Summary, ## Recommended Stack, ## Table Stakes Features, ## Key Architecture Decisions, ## Top Pitfalls, ## Implications for Roadmap, ## Confidence Assessment, ## Gaps
     </output>
 
+    **WRITE ACTION REQUIRED — You MUST use your file-write tool to write SUMMARY.md to disk. Do NOT output the content to the conversation. Do NOT treat this as done until the file physically exists on disk.**
+
+    Write the synthesized content to `.planning/research/SUMMARY.md` using your write tool now.
+
+    Then verify it was written:
+    ```
+    node -e "const fs=require('fs');const f='.planning/research/SUMMARY.md';if(!fs.existsSync(f)){console.log('SUMMARY_MISSING');process.exit(1);}const c=fs.readFileSync(f,'utf8');const secs=['Executive Summary','Recommended Stack','Top Pitfalls','Implications for Roadmap'];const missing=secs.filter(s=>!c.includes(s));if(missing.length){console.log('SUMMARY_INCOMPLETE — missing: '+missing.join(', '));process.exit(1);}console.log('SUMMARY_OK — '+c.length+' chars');"
+    ```
+
+    If `SUMMARY_MISSING` or `SUMMARY_INCOMPLETE`: write the file and re-run until `SUMMARY_OK`.
+
     <quality_gate>
+    - [ ] File physically written to .planning/research/SUMMARY.md (verified by node -e above)
     - [ ] Synthesized, not concatenated — findings are integrated
     - [ ] Opinionated — clear recommendations emerge
     - [ ] Actionable — roadmapper can structure phases from implications

package/learnship/workflows/plan-phase.md

@@ -139,9 +139,19 @@ Task(
     </files_to_read>
 
     <output>
-    Write to: .planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-RESEARCH.md
     Required sections: ## Don't Hand-Roll, ## Common Pitfalls, ## Existing Patterns in This Codebase, ## Recommended Approach
     </output>
+
+    **WRITE ACTION REQUIRED — You MUST use your file-write tool to write [padded_phase]-RESEARCH.md to disk. Do NOT output the content to the conversation. Do NOT treat this as done until the file physically exists on disk.**
+
+    Write the research content to `.planning/phases/[padded_phase]-[phase_slug]/[padded_phase]-RESEARCH.md` using your write tool now.
+
+    Then verify:
+    ```
+    node -e "const fs=require('fs');const files=fs.readdirSync('.planning/phases/').flatMap(d=>fs.readdirSync('.planning/phases/'+d).filter(f=>f.endsWith('-RESEARCH.md')).map(f=>'.planning/phases/'+d+'/'+f));if(!files.length){console.log('RESEARCH_MISSING');process.exit(1);}console.log('RESEARCH_OK — '+files[files.length-1]);"
+    ```
+
+    If `RESEARCH_MISSING`: write the file and re-run until `RESEARCH_OK`.
   "
 )
 ```
@@ -203,14 +213,16 @@ Task(
   prompt="
     <agent_definition>
     You are a learnship planner. Create executable PLAN.md files that an AI agent can follow step-by-step.
-    Each plan covers a single logical unit of work. Tasks use XML format with file, action, verify, done fields.
-    Plans have YAML frontmatter: wave, depends_on, files_modified, autonomous.
+    Each plan is a VERTICAL SLICE (tracer bullet) — a thin end-to-end path through all layers for one user-facing behavior. A completed plan must be demoable or verifiable on its own.
+    DO NOT create plans that cover a single layer across the whole feature (all-schema plan, all-API plan, all-UI plan). Each plan delivers one complete behavior: data + logic + API + UI + test.
+    Exception: add `single_layer_justified: true` to frontmatter only if the phase is legitimately single-layer (e.g., DB migration, style pass).
+    Tasks use XML format with file, action, verify, done fields. Plans have YAML frontmatter: wave, depends_on, files_modified, autonomous, single_layer_justified, objective.
     Be specific — task actions should be concrete instructions, not vague guidance.
     </agent_definition>
 
     <objective>
     Create 2-4 executable PLAN.md files for Phase [phase_number]: [phase_name].
-    Write plans to [phase_dir]/[padded_phase]-NN-PLAN.md.
+    Each plan = one tracer bullet (demoable end-to-end slice). Write plans to [phase_dir]/[padded_phase]-NN-PLAN.md.
     </objective>
 
     <files_to_read>
@@ -223,9 +235,19 @@ Task(
     </files_to_read>
 
     <output>
-    Write to: [phase_dir]/[padded_phase]-01-PLAN.md, [padded_phase]-02-PLAN.md, etc.
     Each plan must have: YAML frontmatter (wave, depends_on, files_modified) + tasks in XML + must_haves section
     </output>
+
+    **WRITE ACTION REQUIRED — You MUST use your file-write tool to write each PLAN.md to disk. Do NOT output plans to the conversation. Do NOT treat this as done until files physically exist on disk.**
+
+    Write each plan to `[phase_dir]/[padded_phase]-NN-PLAN.md` using your write tool now. Write all plans before reporting done.
+
+    Then verify:
+    ```
+    node -e "const fs=require('fs');const plans=fs.readdirSync('.').filter(f=>f.endsWith('-PLAN.md'));if(!plans.length){console.log('PLANS_MISSING');process.exit(1);}console.log('PLANS_OK — '+plans.length+' plan(s): '+plans.join(', '));"
+    ```
+
+    Run that command from inside [phase_dir]. If `PLANS_MISSING`: write the files and re-run until `PLANS_OK`.
   "
 )
 ```
@@ -236,7 +258,10 @@ Wait for agent to complete, then verify PLAN.md files were written.
 
 <persona_context>
 You are now the **learnship planner**. Create implementation plans that are executable in a single context window.
-Each plan covers one logical unit of work. Tasks use XML format. Include YAML frontmatter with wave, depends_on, files_modified.
+Each plan is a VERTICAL SLICE (tracer bullet) — a thin end-to-end path through all layers for one user-facing behavior. A completed plan must be demoable or verifiable on its own.
+DO NOT create plans that cover a single layer across the whole feature (all-schema plan, all-API plan, all-UI plan). Each plan delivers one complete behavior: data + logic + API + UI + test.
+Exception: add `single_layer_justified: true` to frontmatter only if the phase is legitimately single-layer (e.g., DB migration, style pass).
+Tasks use XML format. Include YAML frontmatter with wave, depends_on, files_modified, autonomous, single_layer_justified, objective.
 Right-size plans: too small = overhead, too large = risk. Aim for plans completable in one focused session.
 </persona_context>
 
@@ -253,11 +278,13 @@ Read `@./agents/planner.md` for the full persona definition. Read all available
 - RESEARCH.md (if exists)
 
 Create 2-4 PLAN.md files in the phase directory. Each plan:
-- Covers a single logical unit of work executable in one context window
-- Has YAML frontmatter: `wave`, `depends_on`, `files_modified`, `autonomous`
+- Is a **vertical slice (tracer bullet)** — delivers one demoable user-facing behavior end-to-end (data → logic → API → UI → test). NOT a horizontal layer.
+- Has YAML frontmatter: `wave`, `depends_on`, `files_modified`, `autonomous`, `single_layer_justified`, `objective`
 - Contains tasks in XML format (see `$LEARNSHIP_DIR/templates/plan.md`)
 - Has `must_haves` section with observable verification criteria
 
+**Vertical slice check before writing:** For each plan you draft, ask: "Can someone demo this plan's deliverable after it completes, without completing other plans?" If the answer is no, restructure into proper vertical slices.
+
 **Wave assignment:**
 - Plans with no dependencies → Wave 1 (independent, execute in any order)
 - Plans depending on Wave 1 → Wave 2
@@ -286,13 +313,14 @@ Task(
   prompt="
     <agent_definition>
     You are a learnship plan checker. Verify plans are complete, correct, and executable.
-    Check: phase goal coverage, requirement IDs, CONTEXT.md decisions honored, task completeness, wave/dependency correctness.
-    Be strict — flag missing requirement IDs, vague task actions, incorrect wave assignments.
+    Check: phase goal coverage, requirement IDs, CONTEXT.md decisions honored, task completeness, wave/dependency correctness, AND vertical slice integrity.
+    Vertical slice check: each plan's objective must describe a demoable user-facing behavior delivered end-to-end. Flag any plan that covers only a single layer (all schema, all API, all UI) unless single_layer_justified: true is set in its frontmatter.
+    Be strict — flag missing requirement IDs, vague task actions, incorrect wave assignments, and horizontal slices.
     </agent_definition>
 
     <objective>
     Verify all PLAN.md files in [phase_dir] for Phase [phase_number]: [phase_name].
-    Check: phase goal coverage, requirement IDs, CONTEXT.md decisions, task completeness, wave correctness.
+    Check: phase goal coverage, requirement IDs, CONTEXT.md decisions, task completeness, wave correctness, vertical slice integrity.
     Return: PASS or list of specific issues per plan.
     </objective>
 
@@ -314,8 +342,9 @@ If still failing after 3 iterations: present issues and ask — **Force proceed*
 <persona_context>
 You are now the **learnship plan checker**. Verify plans are complete, correct, and executable.
 Every v1 requirement must map to at least one plan task. Success criteria must be observable and testable.
-Flag gaps, missing coverage, unrealistic estimates, and circular dependencies.
-Check: phase goal coverage, requirement IDs, CONTEXT.md decisions honored, task completeness, wave/dependency correctness.
+Flag gaps, missing coverage, unrealistic estimates, circular dependencies, AND horizontal slices.
+Vertical slice check: each plan's objective must describe a demoable user-facing behavior delivered end-to-end. Flag any plan that covers only a single layer (all schema, all API, all UI) unless `single_layer_justified: true` is in the frontmatter.
+Check: phase goal coverage, requirement IDs, CONTEXT.md decisions honored, task completeness, wave/dependency correctness, vertical slice integrity.
 </persona_context>
 
 > **Announce persona** — print this before proceeding:
@@ -329,6 +358,7 @@ Read `@./agents/plan-checker.md` for the full persona definition. Check the plan
 - CONTEXT.md decisions (are they honored?)
 - Task completeness (files, action, verify, done fields)
 - Wave/dependency correctness
+- Vertical slice integrity (is each plan's objective a demoable user-facing behavior? flag horizontal-only plans)
 
 **Verification loop (max 3 iterations):**
 

package/learnship/workflows/research-phase.md

@@ -109,9 +109,19 @@ Task(
     </files_to_read>
 
     <output>
-    Write to: .planning/phases/[padded_phase]-[slug]/[padded_phase]-RESEARCH.md
     Required sections: ## Don't Hand-Roll, ## Common Pitfalls, ## Existing Patterns in This Codebase, ## Recommended Approach
     </output>
+
+    **WRITE ACTION REQUIRED — You MUST use your file-write tool to write [padded_phase]-RESEARCH.md to disk. Do NOT output the content to the conversation. Do NOT treat this as done until the file physically exists on disk.**
+
+    Write the research content to `.planning/phases/[padded_phase]-[slug]/[padded_phase]-RESEARCH.md` using your write tool now.
+
+    Then verify:
+    ```
+    node -e "const fs=require('fs');const files=fs.readdirSync('.planning/phases/').flatMap(d=>fs.readdirSync('.planning/phases/'+d).filter(f=>f.endsWith('-RESEARCH.md')).map(f=>'.planning/phases/'+d+'/'+f));if(!files.length){console.log('RESEARCH_MISSING');process.exit(1);}console.log('RESEARCH_OK — '+files[files.length-1]);"
+    ```
+
+    If `RESEARCH_MISSING`: write the file and re-run until `RESEARCH_OK`.
   "
 )
 ```

package/learnship/workflows/settings.md

@@ -36,7 +36,7 @@ cp templates/config.json .planning/config.json 2>/dev/null || cat > .planning/co
     "review": true,
     "solutions_search": true,
     "security_enforcement": true,
-    "discuss_mode": "discuss",
+    "discuss_mode": "discuss",    // "discuss" (standard 4-exchange) or "deep" (extended questioning, walks every branch until shared understanding)
     "tdd_mode": false
   },
   "parallelization": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "learnship",
-  "version": "2.3.3",
+  "version": "2.3.5",
   "description": "Learn as you build. Build with intent. — A multi-platform agentic engineering system for Windsurf, Claude Code, Cursor, OpenCode, Gemini CLI, and Codex: 57 spec-driven workflows, 17 specialist agent personas, integrated learning, and production-grade design.",
   "keywords": [
     "agentic",

package/templates/plan.md

@@ -113,6 +113,14 @@ Phases execute in numeric order: 2 → 2.1 → 2.2 → 3 → 3.1 → 4
 - Progress table updated by execute workflow
 - Plan count can be "TBD" initially, refined during planning
 
+**Vertical slice planning (enforced by plan-phase and plan-checker):**
+- Each PLAN.md is a tracer bullet — one user-facing behavior, all layers (data → logic → API → UI → test)
+- A completed plan is demoable without completing other plans
+- Plan descriptions in this roadmap should reflect what users experience, not which layer is being built
+  - ✗ "01-01: Create database schema" — horizontal, not demoable alone
+  - ✓ "01-01: User can register and receive confirmation email" — vertical, demoable
+- Exception: `single_layer_justified: true` in PLAN.md frontmatter for legitimately single-layer phases
+
 **Success criteria:**
 - 2-5 observable behaviors per phase (from user's perspective)
 - Cross-checked against requirements during roadmap creation