@geekyants/think-before 0.2.0 → 0.4.0

package/README.md

@@ -38,15 +38,15 @@ think-before                           # the installed command is just `think-be
 
 | Mode | What it's for |
 | --- | --- |
-| `quick` *(default)* | The "I'm about to touch the big app" moment. ~16 sharp questions about blast radius, data, contracts, your safety net, and timing. |
-| `full` | A team-level pre-development discovery sweep: problem, users, scope, risks, plus role sections for designers, engineers, and developers. |
+| `quick` *(default)* | The "I'm about to touch the big app" moment. Blast radius, data, contracts, your safety net, and timing. |
+| `full` | A team-level pre-development discovery sweep: problem, users, scope, risks, plus the questions specific to your role. |
 
-In `full` mode you can focus on one role (shared sections are always included):
+Both modes ask **at most 10 questions** — the ones most relevant to *you*. Every question is tagged with the roles it applies to and a priority; pick a role and you get your fundamentals plus your own specialty, never a wall of questions meant for someone else:
 
 ```bash
-think-before full --role designer
-think-before full --role engineer
-think-before full --role developer
+think-before --role designer        # quick check, design-focused
+think-before full --role engineer   # discovery, architecture-focused
+think-before full --role developer  # discovery, implementation-focused
 ```
 
 ## Smart, stack-aware questions
@@ -72,7 +72,7 @@ Skip the scan anytime with `--no-detect`.
 
 ## Your role & saved config
 
-The first time you run it in a project, it asks **what your role is** (designer / engineer / developer) and tailors the stack questions to you. Your answer — plus the detected stack — is remembered per project in:
+The first time you run it in a project, it asks **what your role is** (designer / engineer / developer) and tailors the whole question set to you. Your answer — plus the detected stack — is remembered per project in:
 
 ```
 ~/.config/think-before/config.json      # honors $XDG_CONFIG_HOME
@@ -84,6 +84,33 @@ So next time it doesn't ask again. To change it: `--role <r>` to set explicitly,
 think-before config
 ```
 
+## Full-screen mode
+
+By default, in an interactive terminal `think-before` takes over the screen like a classic text-mode installer — one boxed question at a time, no scrollback noise, so you can actually *think* about each one:
+
+```
+╔══════════════════════════════════════════════════╗
+║                think-before · quick                ║
+╠══════════════════════════════════════════════════╣
+║                                                    ║
+║  Question 5 / 10  ·  Blast radius                  ║
+║                                                    ║
+║  Could this change behavior in flows you are NOT   ║
+║  going to manually test?                           ║
+║                                                    ║
+║  ↳ The side-effects you don't test for are exactly ║
+║    the ones that reach production.                 ║
+║                                                    ║
+║              ‹ Yes ›   ‹ No ›   ‹ Skip ›           ║
+║                                                    ║
+╚══════════════════════════════════════════════════╝
+  y yes  n no  s skip  ? why  q quit   [█████░░░░░] 5/10
+```
+
+It uses the terminal's alternate screen buffer (like `vim` or `less`), so when you're done — or quit with `q`/`Ctrl-C` — your terminal is restored exactly as it was, and the summary + report prompt print into your normal scrollback.
+
+When input is piped or it's not a real terminal (CI, `| node …`), it automatically falls back to the classic scrolling line mode — so scripting and pipelines still work. Force either mode with `--no-tui` / `--tui`.
+
 ## How to answer
 
 Single keypress, no Enter needed:
@@ -106,6 +133,8 @@ Answers that point at risk get **flagged** with a one-line reason. At the end yo
 --role <r>       Set your role: designer | engineer | developer (remembered per project)
 --reset-role     Forget the saved role and ask again
 --no-detect      Skip the project scan and stack-specific questions
+--no-tui         Use the classic scrolling line mode instead of full-screen
+--tui            Force full-screen mode
 --save [file]    Save a Markdown report (optionally to <file>) without asking
 --no-save        Don't save and don't ask
 --list           Print the checklist and exit (no prompts)
@@ -122,14 +151,15 @@ The report is plain Markdown — drop it into a PR description, a ticket, or you
 
 ```ts
 import {
-  quick, full, filterSections, runSession, buildMarkdown,
+  quick, full, filterSections, selectSections, runSession, buildMarkdown,
   detectProject, stackSection,
 } from "@geekyants/think-before";
 
 const detection = detectProject(process.cwd()); // { kind: "fullstack", frameworks: [...] }
 const extra = stackSection(detection, "engineer");
 
-const sections = [...filterSections(full, "engineer"), ...(extra ? [extra] : [])];
+const all = [...filterSections(full, "engineer"), ...(extra ? [extra] : [])];
+const sections = selectSections(all, "engineer"); // role-tailored, capped at 10
 const result = await runSession(full, sections);
 const markdown = buildMarkdown(full, result, new Date());
 ```
@@ -143,7 +173,7 @@ npm run build      # compile to dist/
 npm start          # run the built CLI
 ```
 
-Want to add or tweak questions? They live in [`src/checklists.ts`](src/checklists.ts) — each question declares which answer (`yes`/`no`) is the risky one, plus an optional `why`. PRs welcome.
+Want to add or tweak questions? They live in [`src/checklists.ts`](src/checklists.ts) — each question declares which answer (`yes`/`no`) is the risky one, an optional `why`, the `roles` it applies to, and a `priority` (higher = asked first when the 10-question cap kicks in). PRs welcome.
 
 ## License
 

package/dist/checklists.d.ts

@@ -1,19 +1,36 @@
 import type { Checklist } from "./types.js";
+/**
+ * Roles & priority
+ * ----------------
+ * Every question carries the `roles` it's relevant to (omit = everyone) and a
+ * `priority` (higher = asked first). Sections are now purely thematic grouping
+ * (`roles: ["shared"]`); the real tailoring happens per-question. A session
+ * keeps only the questions matching the user's role and, when more than the cap
+ * (see `MAX_QUESTIONS`) are eligible, the highest-priority ones. The aim: every
+ * role gets ~5 shared fundamentals + ~5 of their own specialty, never a wall of
+ * questions that don't apply to them.
+ *
+ * Priority bands (rough guide):
+ *   90-95  the question you should never skip (problem, scope, blast radius)
+ *   80-89  high-severity / role-defining
+ *   70-79  important safety nets
+ *   50-69  good to consider
+ *   <50    situational
+ */
 /**
  * QUICK — the blast-radius check.
  *
- * For the "I'm about to make a small change to a big app" moment. Fast,
- * sharp, and focused on the side-effects people overlook. Most questions
- * are phrased so that the *risky* answer surfaces something to double-check
- * before you touch the code.
+ * For the "I'm about to make a small change to a big app" moment. Fast, sharp,
+ * and focused on the side-effects people overlook.
  */
 export declare const quick: Checklist;
 /**
  * FULL — the pre-development discovery checklist.
  *
- * The team-level questions to ask *before* starting any workflow, reframed
- * as yes/no so you can sweep them quickly. A "no" here usually means a gap
- * worth closing, not a blocker — log it as an open question.
+ * The questions to ask *before* starting any work, reframed as yes/no. A "no"
+ * usually means a gap worth closing, not a blocker — log it as an open question.
+ * Tailored per role: shared fundamentals plus the discovery questions that role
+ * most needs to answer.
  */
 export declare const full: Checklist;
 /** All built-in checklists, keyed by id. */

package/dist/checklists.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"checklists.d.ts","sourceRoot":"","sources":["../src/checklists.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,YAAY,CAAC;AAE5C;;;;;;;GAOG;AACH,eAAO,MAAM,KAAK,EAAE,SA0InB,CAAC;AAEF;;;;;;GAMG;AACH,eAAO,MAAM,IAAI,EAAE,SAiJlB,CAAC;AAEF,4CAA4C;AAC5C,eAAO,MAAM,UAAU,EAAE,MAAM,CAAC,MAAM,EAAE,SAAS,CAGhD,CAAC"}
+{"version":3,"file":"checklists.d.ts","sourceRoot":"","sources":["../src/checklists.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,YAAY,CAAC;AAE5C;;;;;;;;;;;;;;;;;GAiBG;AAEH;;;;;GAKG;AACH,eAAO,MAAM,KAAK,EAAE,SA2MnB,CAAC;AAEF;;;;;;;GAOG;AACH,eAAO,MAAM,IAAI,EAAE,SAiJlB,CAAC;AAEF,4CAA4C;AAC5C,eAAO,MAAM,UAAU,EAAE,MAAM,CAAC,MAAM,EAAE,SAAS,CAGhD,CAAC"}

package/dist/checklists.js

@@ -1,10 +1,26 @@
+/**
+ * Roles & priority
+ * ----------------
+ * Every question carries the `roles` it's relevant to (omit = everyone) and a
+ * `priority` (higher = asked first). Sections are now purely thematic grouping
+ * (`roles: ["shared"]`); the real tailoring happens per-question. A session
+ * keeps only the questions matching the user's role and, when more than the cap
+ * (see `MAX_QUESTIONS`) are eligible, the highest-priority ones. The aim: every
+ * role gets ~5 shared fundamentals + ~5 of their own specialty, never a wall of
+ * questions that don't apply to them.
+ *
+ * Priority bands (rough guide):
+ *   90-95  the question you should never skip (problem, scope, blast radius)
+ *   80-89  high-severity / role-defining
+ *   70-79  important safety nets
+ *   50-69  good to consider
+ *   <50    situational
+ */
 /**
  * QUICK — the blast-radius check.
  *
- * For the "I'm about to make a small change to a big app" moment. Fast,
- * sharp, and focused on the side-effects people overlook. Most questions
- * are phrased so that the *risky* answer surfaces something to double-check
- * before you touch the code.
+ * For the "I'm about to make a small change to a big app" moment. Fast, sharp,
+ * and focused on the side-effects people overlook.
  */
 export const quick = {
     id: "quick",
@@ -16,18 +32,20 @@ export const quick = {
             title: "Understand the change",
             roles: ["shared"],
             questions: [
-                {
-                    id: "understand-current",
-                    text: "Do you understand what this code does today — not just the line you're editing?",
-                    risky: "no",
-                    why: "Editing code you don't fully understand is the #1 source of surprise side-effects.",
-                },
                 {
                     id: "one-sentence",
                     text: "Can you describe the change and its intended effect in one sentence?",
                     risky: "no",
+                    priority: 92,
                     why: "If you can't state it simply, the scope isn't clear yet — and unclear scope hides risk.",
                 },
+                {
+                    id: "understand-current",
+                    text: "Do you understand what this code/area does today — not just the line you're editing?",
+                    risky: "no",
+                    priority: 90,
+                    why: "Editing something you don't fully understand is the #1 source of surprise side-effects.",
+                },
             ],
         },
         {
@@ -39,22 +57,67 @@ export const quick = {
                     id: "shared-code",
                     text: "Is this in shared/global code (a util, base component, hook, config, middleware) used in many places?",
                     risky: "yes",
+                    roles: ["engineer", "developer"],
+                    priority: 88,
                     why: "Shared code multiplies the blast radius — one edit ripples everywhere it's imported.",
                 },
                 {
                     id: "found-callers",
                     text: "Have you searched for every caller / usage of what you're changing?",
                     risky: "no",
+                    roles: ["engineer", "developer"],
+                    priority: 82,
                     why: "Unknown callers are unknown breakage. Grep for usages before you edit, not after.",
                 },
                 {
                     id: "untested-flows",
                     text: "Could this change behavior in flows you are NOT going to manually test?",
                     risky: "yes",
+                    roles: ["engineer", "developer"],
+                    priority: 76,
                     why: "The side-effects you don't test for are exactly the ones that reach production.",
                 },
             ],
         },
+        {
+            id: "design-impact",
+            title: "Design impact",
+            roles: ["shared"],
+            questions: [
+                {
+                    id: "ds-shared-ui",
+                    text: "Is this a change to a shared component, pattern, or design token reused across many screens?",
+                    risky: "yes",
+                    roles: ["designer"],
+                    priority: 86,
+                    why: "One tweak to a shared UI primitive shows up everywhere it's used.",
+                },
+                {
+                    id: "ds-states",
+                    text: "Have you covered the states this touches — empty, loading, error, long text, large lists?",
+                    risky: "no",
+                    roles: ["designer"],
+                    priority: 82,
+                    why: "The states you didn't draw are the ones that ship broken.",
+                },
+                {
+                    id: "ds-a11y",
+                    text: "Will contrast, focus order, keyboard use, and screen-reader output still work after this?",
+                    risky: "no",
+                    roles: ["designer"],
+                    priority: 78,
+                    why: "Accessibility regressions are invisible until someone who relies on them hits them.",
+                },
+                {
+                    id: "ds-consistency",
+                    text: "Does this stay consistent with the existing design system, rather than quietly forking it?",
+                    risky: "no",
+                    roles: ["designer"],
+                    priority: 74,
+                    why: "A one-off divergence becomes the pattern everyone copies next.",
+                },
+            ],
+        },
         {
             id: "data-contracts",
             title: "Data & contracts",
@@ -64,18 +127,24 @@ export const quick = {
                     id: "data-touch",
                     text: "Does it touch persisted data — schema, migrations, stored formats, or cached values?",
                     risky: "yes",
+                    roles: ["engineer", "developer"],
+                    priority: 86,
                     why: "Data changes are the hardest to roll back; old data outlives your deploy.",
                 },
                 {
                     id: "public-contract",
                     text: "Does it change a public API, response shape, event, or contract others depend on?",
                     risky: "yes",
+                    roles: ["engineer", "developer"],
+                    priority: 84,
                     why: "Consumers you can't see — other teams, mobile apps, integrations — may break silently.",
                 },
                 {
                     id: "backward-compat",
                     text: "Have you accounted for backward compatibility and in-flight / old-shaped data?",
                     risky: "no",
+                    roles: ["engineer", "developer"],
+                    priority: 72,
                     why: "Queues, caches, and old clients may still hold the previous shape after you deploy.",
                 },
             ],
@@ -89,18 +158,24 @@ export const quick = {
                     id: "tests-cover",
                     text: "Do existing automated tests cover this path, and do they still pass?",
                     risky: "no",
+                    roles: ["engineer", "developer"],
+                    priority: 80,
                     why: "No test means no safety net. Add or run one before the change, not after the incident.",
                 },
                 {
                     id: "rollback",
                     text: "Is there a fast way to undo this (revert, feature flag, kill switch)?",
                     risky: "no",
+                    roles: ["engineer", "developer"],
+                    priority: 78,
                     why: "If you can't roll back quickly, the cost of being wrong is much higher.",
                 },
                 {
                     id: "observability",
                     text: "If this breaks in production, will you find out (logs, metrics, alerts)?",
                     risky: "no",
+                    roles: ["engineer", "developer"],
+                    priority: 76,
                     why: "Silent failures are the worst kind — you learn about them from angry users.",
                 },
             ],
@@ -114,12 +189,16 @@ export const quick = {
                     id: "security",
                     text: "Does it touch auth, permissions, security, or anything handling PII / secrets?",
                     risky: "yes",
+                    roles: ["engineer", "developer"],
+                    priority: 84,
                     why: "These failures are high-severity and often invisible until they're exploited.",
                 },
                 {
                     id: "performance",
                     text: "Could it affect performance at scale (N+1, large lists, hot path, extra network calls)?",
                     risky: "yes",
+                    roles: ["engineer", "developer"],
+                    priority: 74,
                     why: "What's fine with 10 rows can melt down at 10 million. Side-effects scale too.",
                 },
             ],
@@ -129,18 +208,20 @@ export const quick = {
             title: "Timing & gut check",
             roles: ["shared"],
             questions: [
-                {
-                    id: "timing",
-                    text: "Are you shipping at a risky time (Friday, right before a release, peak traffic, on-call gap)?",
-                    risky: "yes",
-                    why: "Bad timing turns a small bug into a long incident with nobody around to fix it.",
-                },
                 {
                     id: "gut",
                     text: "Be honest — do you actually understand the side-effects of this change?",
                     risky: "no",
+                    priority: 60,
                     why: "Your gut is data. If it says 'not sure', pause and dig before you commit.",
                 },
+                {
+                    id: "timing",
+                    text: "Are you shipping at a risky time (Friday, right before a release, peak traffic, on-call gap)?",
+                    risky: "yes",
+                    priority: 55,
+                    why: "Bad timing turns a small bug into a long incident with nobody around to fix it.",
+                },
             ],
         },
     ],
@@ -148,9 +229,10 @@ export const quick = {
 /**
  * FULL — the pre-development discovery checklist.
  *
- * The team-level questions to ask *before* starting any workflow, reframed
- * as yes/no so you can sweep them quickly. A "no" here usually means a gap
- * worth closing, not a blocker — log it as an open question.
+ * The questions to ask *before* starting any work, reframed as yes/no. A "no"
+ * usually means a gap worth closing, not a blocker — log it as an open question.
+ * Tailored per role: shared fundamentals plus the discovery questions that role
+ * most needs to answer.
  */
 export const full = {
     id: "full",
@@ -162,12 +244,12 @@ export const full = {
             title: "1. Problem & Goals",
             roles: ["shared"],
             questions: [
-                { id: "problem-statement", text: "Can you state the problem you're solving in one sentence?", risky: "no" },
-                { id: "why-now", text: "Do you know why now — and what happens if you don't build it?", risky: "no" },
-                { id: "success-metric", text: "Is success defined with a metric, a target, and a timeframe?", risky: "no" },
-                { id: "change-type", text: "Are you clear whether this is a new capability, an improvement, or a fix?", risky: "no", why: "It changes the risk profile and how much process it needs." },
-                { id: "decision-maker", text: "Is the final decision-maker on scope identified?", risky: "no" },
-                { id: "attempted-before", text: "Do you know whether this was attempted before, and what happened?", risky: "no" },
+                { id: "problem-statement", text: "Can you state the problem you're solving in one sentence?", risky: "no", priority: 95 },
+                { id: "success-metric", text: "Is success defined with a metric, a target, and a timeframe?", risky: "no", priority: 90 },
+                { id: "why-now", text: "Do you know why now — and what happens if you don't build it?", risky: "no", priority: 66 },
+                { id: "decision-maker", text: "Is the final decision-maker on scope identified?", risky: "no", priority: 64 },
+                { id: "change-type", text: "Are you clear whether this is a new capability, an improvement, or a fix?", risky: "no", priority: 50, why: "It changes the risk profile and how much process it needs." },
+                { id: "attempted-before", text: "Do you know whether this was attempted before, and what happened?", risky: "no", priority: 40 },
             ],
         },
         {
@@ -175,12 +257,12 @@ export const full = {
             title: "2. Users & Stakeholders",
             roles: ["shared"],
             questions: [
-                { id: "primary-users", text: "Do you know who the primary (and secondary) users are?", risky: "no" },
-                { id: "job-to-be-done", text: "Is the user's job-to-be-done clearly understood?", risky: "no" },
-                { id: "current-workflow", text: "Do you understand the current workflow without this feature?", risky: "no" },
-                { id: "signoff-stages", text: "Are the stakeholders who must review or sign off identified, with stages?", risky: "no" },
-                { id: "internal-users", text: "Have you considered internal users (support, ops, admins) and their needs?", risky: "no" },
-                { id: "discovery", text: "Is there a plan for how users will find out this exists?", risky: "no" },
+                { id: "primary-users", text: "Do you know who the primary (and secondary) users are?", risky: "no", priority: 68 },
+                { id: "job-to-be-done", text: "Is the user's job-to-be-done clearly understood?", risky: "no", priority: 62 },
+                { id: "current-workflow", text: "Do you understand the current workflow without this feature?", risky: "no", priority: 55 },
+                { id: "signoff-stages", text: "Are the stakeholders who must review or sign off identified, with stages?", risky: "no", priority: 48 },
+                { id: "internal-users", text: "Have you considered internal users (support, ops, admins) and their needs?", risky: "no", priority: 45 },
+                { id: "discovery", text: "Is there a plan for how users will find out this exists?", risky: "no", priority: 42 },
             ],
         },
         {
@@ -188,12 +270,12 @@ export const full = {
             title: "3. Scope & Requirements",
             roles: ["shared"],
             questions: [
-                { id: "in-scope", text: "Is what's IN scope for this iteration written down?", risky: "no" },
-                { id: "out-of-scope", text: "Is what's OUT of scope written down?", risky: "no", why: "Explicit non-goals are what actually prevent scope creep." },
-                { id: "mvp-cut", text: "Is the MVP cut — the minimum that delivers value — defined?", risky: "no" },
-                { id: "acceptance-criteria", text: "Are the acceptance criteria for 'done' defined?", risky: "no" },
-                { id: "requirements-stability", text: "Do you know whether requirements are fixed or expected to evolve?", risky: "no" },
-                { id: "unvalidated-assumptions", text: "Have you listed the assumptions you're making but haven't validated?", risky: "no" },
+                { id: "out-of-scope", text: "Is what's OUT of scope written down?", risky: "no", priority: 84, why: "Explicit non-goals are what actually prevent scope creep." },
+                { id: "mvp-cut", text: "Is the MVP cut — the minimum that delivers value — defined?", risky: "no", priority: 78 },
+                { id: "acceptance-criteria", text: "Are the acceptance criteria for 'done' defined?", risky: "no", priority: 76 },
+                { id: "unvalidated-assumptions", text: "Have you listed the assumptions you're making but haven't validated?", risky: "no", priority: 72 },
+                { id: "in-scope", text: "Is what's IN scope for this iteration written down?", risky: "no", priority: 70 },
+                { id: "requirements-stability", text: "Do you know whether requirements are fixed or expected to evolve?", risky: "no", priority: 50 },
             ],
         },
         {
@@ -201,12 +283,12 @@ export const full = {
             title: "4. Constraints & Logistics",
             roles: ["shared"],
             questions: [
-                { id: "deadline", text: "Is the deadline known, and whether it's hard or soft (and why)?", risky: "no" },
-                { id: "capacity", text: "Is the available budget / capacity (people, hours) known?", risky: "no" },
-                { id: "ownership", text: "Is long-term ownership after launch assigned?", risky: "no" },
-                { id: "dependencies", text: "Are dependencies on other teams, vendors, or releases mapped?", risky: "no" },
-                { id: "legal-deadlines", text: "Are any legal / contractual / regulatory deadlines identified?", risky: "no" },
-                { id: "fallback-plan", text: "Is there a rollback / fallback plan if it goes wrong?", risky: "no" },
+                { id: "fallback-plan", text: "Is there a rollback / fallback plan if it goes wrong?", risky: "no", priority: 70 },
+                { id: "dependencies", text: "Are dependencies on other teams, vendors, or releases mapped?", risky: "no", priority: 64 },
+                { id: "deadline", text: "Is the deadline known, and whether it's hard or soft (and why)?", risky: "no", priority: 60 },
+                { id: "capacity", text: "Is the available budget / capacity (people, hours) known?", risky: "no", priority: 52 },
+                { id: "ownership", text: "Is long-term ownership after launch assigned?", risky: "no", priority: 50 },
+                { id: "legal-deadlines", text: "Are any legal / contractual / regulatory deadlines identified?", risky: "no", priority: 46 },
             ],
         },
         {
@@ -214,62 +296,62 @@ export const full = {
             title: "5. Risks & Unknowns",
             roles: ["shared"],
             questions: [
-                { id: "biggest-risk", text: "Do you know the single biggest risk to this project?", risky: "no" },
-                { id: "riskiest-assumption", text: "Have you identified the riskiest assumption — and can you test it cheaply first?", risky: "no" },
-                { id: "known-unknowns", text: "Are the known unknowns to research before committing listed?", risky: "no" },
-                { id: "three-x", text: "Do you know what could make this take 3x longer than estimated?", risky: "no" },
-                { id: "spof", text: "Have you checked for single points of failure (one person, one system, one vendor)?", risky: "no" },
+                { id: "biggest-risk", text: "Do you know the single biggest risk to this project?", risky: "no", priority: 82 },
+                { id: "riskiest-assumption", text: "Have you identified the riskiest assumption — and can you test it cheaply first?", risky: "no", priority: 79 },
+                { id: "known-unknowns", text: "Are the known unknowns to research before committing listed?", risky: "no", priority: 58 },
+                { id: "three-x", text: "Do you know what could make this take 3x longer than estimated?", risky: "no", priority: 56 },
+                { id: "spof", text: "Have you checked for single points of failure (one person, one system, one vendor)?", risky: "no", priority: 54 },
             ],
         },
         {
             id: "designers",
             title: "6. For Designers",
-            roles: ["designer"],
+            roles: ["shared"],
             questions: [
-                { id: "real-research", text: "Do you have real user research (not guesses) for who you're designing for?", risky: "no" },
-                { id: "existing-patterns", text: "Have you identified the existing patterns, components, or design-system rules that apply?", risky: "no" },
-                { id: "key-flows", text: "Are the key user flows mapped, including error and empty states?", risky: "no" },
-                { id: "a11y", text: "Do you know the accessibility standards to meet (e.g. WCAG AA: contrast, keyboard, screen readers, touch targets)?", risky: "no" },
-                { id: "viewports", text: "Are the supported devices, breakpoints, and viewports defined?", risky: "no" },
-                { id: "copy", text: "Is it clear what copy is needed, who writes it, and any localization?", risky: "no" },
-                { id: "design-edge-cases", text: "Have you considered edge cases: long text, missing data, slow connections, large lists?", risky: "no" },
-                { id: "validation", text: "Is there a plan to validate the design (usability test, prototype, A/B)?", risky: "no" },
-                { id: "handoff", text: "Is the engineering handoff defined (tokens, specs, states, motion)?", risky: "no" },
-                { id: "brand-legal", text: "Have you checked brand, legal, or compliance constraints on the UI?", risky: "no" },
+                { id: "real-research", text: "Do you have real user research (not guesses) for who you're designing for?", risky: "no", roles: ["designer"], priority: 89 },
+                { id: "key-flows", text: "Are the key user flows mapped, including error and empty states?", risky: "no", roles: ["designer"], priority: 87 },
+                { id: "a11y", text: "Do you know the accessibility standards to meet (WCAG AA: contrast, keyboard, screen readers, touch targets)?", risky: "no", roles: ["designer"], priority: 85 },
+                { id: "existing-patterns", text: "Have you identified the existing patterns, components, or design-system rules that apply?", risky: "no", roles: ["designer"], priority: 83 },
+                { id: "handoff", text: "Is the engineering handoff defined (tokens, specs, states, motion)?", risky: "no", roles: ["designer"], priority: 81 },
+                { id: "design-edge-cases", text: "Have you considered edge cases: long text, missing data, slow connections, large lists?", risky: "no", roles: ["designer"], priority: 79 },
+                { id: "viewports", text: "Are the supported devices, breakpoints, and viewports defined?", risky: "no", roles: ["designer"], priority: 75 },
+                { id: "validation", text: "Is there a plan to validate the design (usability test, prototype, A/B)?", risky: "no", roles: ["designer"], priority: 73 },
+                { id: "copy", text: "Is it clear what copy is needed, who writes it, and any localization?", risky: "no", roles: ["designer"], priority: 69 },
+                { id: "brand-legal", text: "Have you checked brand, legal, or compliance constraints on the UI?", risky: "no", roles: ["designer"], priority: 65 },
             ],
         },
         {
             id: "engineers",
             title: "7. For Engineers / Architects",
-            roles: ["engineer"],
+            roles: ["shared"],
             questions: [
-                { id: "nfrs", text: "Are the non-functional requirements (performance, scale, latency, uptime) defined?", risky: "no" },
-                { id: "load", text: "Do you know the expected load at launch and at projected growth?", risky: "no" },
-                { id: "data-ownership", text: "Is it clear what data you read/write, where it lives, and who owns it?", risky: "no" },
-                { id: "external-apis", text: "Are external APIs/services, their rate limits, and SLAs identified?", risky: "no" },
-                { id: "fits-architecture", text: "Do you know whether this fits the current architecture or needs a new pattern?", risky: "no" },
-                { id: "security-reqs", text: "Are the security requirements (authn/authz, encryption, secrets, PII) defined?", risky: "no" },
-                { id: "compliance", text: "Are the applicable privacy/compliance rules known (GDPR, CCPA, HIPAA, SOC 2, residency)?", risky: "no" },
-                { id: "failure-handling", text: "Is there a plan for failures, retries, idempotency, and degraded states?", risky: "no" },
-                { id: "observability-plan", text: "Is the observability plan (logging, metrics, tracing, alerts) defined?", risky: "no" },
-                { id: "deploy-plan", text: "Is the deployment approach clear (CI/CD, feature flags, migrations, zero-downtime)?", risky: "no" },
+                { id: "nfrs", text: "Are the non-functional requirements (performance, scale, latency, uptime) defined?", risky: "no", roles: ["engineer"], priority: 89 },
+                { id: "fits-architecture", text: "Do you know whether this fits the current architecture or needs a new pattern?", risky: "no", roles: ["engineer"], priority: 87 },
+                { id: "security-reqs", text: "Are the security requirements (authn/authz, encryption, secrets, PII) defined?", risky: "no", roles: ["engineer", "developer"], priority: 85 },
+                { id: "data-ownership", text: "Is it clear what data you read/write, where it lives, and who owns it?", risky: "no", roles: ["engineer"], priority: 83 },
+                { id: "failure-handling", text: "Is there a plan for failures, retries, idempotency, and degraded states?", risky: "no", roles: ["engineer"], priority: 81 },
+                { id: "deploy-plan", text: "Is the deployment approach clear (CI/CD, feature flags, migrations, zero-downtime)?", risky: "no", roles: ["engineer"], priority: 77 },
+                { id: "observability-plan", text: "Is the observability plan (logging, metrics, tracing, alerts) defined?", risky: "no", roles: ["engineer"], priority: 75 },
+                { id: "external-apis", text: "Are external APIs/services, their rate limits, and SLAs identified?", risky: "no", roles: ["engineer"], priority: 73 },
+                { id: "load", text: "Do you know the expected load at launch and at projected growth?", risky: "no", roles: ["engineer"], priority: 70 },
+                { id: "compliance", text: "Are the applicable privacy/compliance rules known (GDPR, CCPA, HIPAA, SOC 2, residency)?", risky: "no", roles: ["engineer"], priority: 68 },
             ],
         },
         {
             id: "developers",
             title: "8. For Developers (Implementation)",
-            roles: ["developer"],
+            roles: ["shared"],
             questions: [
-                { id: "first-test", text: "Do you understand the acceptance criteria well enough to write the first test?", risky: "no" },
-                { id: "small-pieces", text: "Can you break this into small, independently shippable pieces?", risky: "no" },
-                { id: "code-location", text: "Do you know where the code lives and what conventions/standards apply?", risky: "no" },
-                { id: "reuse", text: "Have you checked what already exists that you can reuse instead of rewriting?", risky: "no" },
-                { id: "testing-strategy", text: "Is the testing strategy (unit, integration, e2e) and coverage target clear?", risky: "no" },
-                { id: "run-locally", text: "Can you run this locally — is the dev environment / test data ready?", risky: "no" },
-                { id: "edge-inputs", text: "Do you know the edge cases and invalid inputs you must handle?", risky: "no" },
-                { id: "migration", text: "Have you considered backward-compatibility and migration concerns?", risky: "no" },
-                { id: "review-bar", text: "Is it clear how this will be reviewed and what 'ready to merge' means?", risky: "no" },
-                { id: "docs", text: "Do you know what documentation you need to write (README, API docs, runbook)?", risky: "no" },
+                { id: "first-test", text: "Do you understand the acceptance criteria well enough to write the first test?", risky: "no", roles: ["developer"], priority: 89 },
+                { id: "code-location", text: "Do you know where the code lives and what conventions/standards apply?", risky: "no", roles: ["developer"], priority: 87 },
+                { id: "reuse", text: "Have you checked what already exists that you can reuse instead of rewriting?", risky: "no", roles: ["developer"], priority: 85 },
+                { id: "small-pieces", text: "Can you break this into small, independently shippable pieces?", risky: "no", roles: ["developer"], priority: 83 },
+                { id: "testing-strategy", text: "Is the testing strategy (unit, integration, e2e) and coverage target clear?", risky: "no", roles: ["developer"], priority: 81 },
+                { id: "edge-inputs", text: "Do you know the edge cases and invalid inputs you must handle?", risky: "no", roles: ["developer"], priority: 77 },
+                { id: "run-locally", text: "Can you run this locally — is the dev environment / test data ready?", risky: "no", roles: ["developer"], priority: 75 },
+                { id: "migration", text: "Have you considered backward-compatibility and migration concerns?", risky: "no", roles: ["developer", "engineer"], priority: 73 },
+                { id: "review-bar", text: "Is it clear how this will be reviewed and what 'ready to merge' means?", risky: "no", roles: ["developer"], priority: 70 },
+                { id: "docs", text: "Do you know what documentation you need to write (README, API docs, runbook)?", risky: "no", roles: ["developer"], priority: 66 },
             ],
         },
         {
@@ -277,12 +359,12 @@ export const full = {
             title: "9. Quality & Launch Readiness",
             roles: ["shared"],
             questions: [
-                { id: "release-checklist", text: "Is the release checklist — what must be true before shipping — defined?", risky: "no" },
-                { id: "prod-like-test", text: "Is there a plan to test in a production-like environment?", risky: "no" },
-                { id: "monitoring-oncall", text: "Is the monitoring plan and the on-call owner after launch defined?", risky: "no" },
-                { id: "fast-rollback", text: "Is there a fast rollback if something breaks?", risky: "no" },
-                { id: "comms-plan", text: "Is the launch communication plan (internal + users) ready?", risky: "no" },
-                { id: "goal-review", text: "Is there a plan and date to review whether this actually hit its goals?", risky: "no" },
+                { id: "fast-rollback", text: "Is there a fast rollback if something breaks?", risky: "no", priority: 72 },
+                { id: "monitoring-oncall", text: "Is the monitoring plan and the on-call owner after launch defined?", risky: "no", priority: 56 },
+                { id: "release-checklist", text: "Is the release checklist — what must be true before shipping — defined?", risky: "no", priority: 58 },
+                { id: "prod-like-test", text: "Is there a plan to test in a production-like environment?", risky: "no", priority: 52 },
+                { id: "goal-review", text: "Is there a plan and date to review whether this actually hit its goals?", risky: "no", priority: 50 },
+                { id: "comms-plan", text: "Is the launch communication plan (internal + users) ready?", risky: "no", priority: 44 },
             ],
         },
         {
@@ -290,10 +372,10 @@ export const full = {
             title: "10. Final Gut Check",
             roles: ["shared"],
             questions: [
-                { id: "half-value", text: "If you shipped only half of this, do you know which half delivers the most value?", risky: "no" },
-                { id: "alignment", text: "Is everyone aligned on scope, owner, and definition of done?", risky: "no" },
-                { id: "regret", text: "Do you know the one thing you're most likely to regret skipping?", risky: "no" },
-                { id: "real-problem", text: "Are you solving the real problem, not just the requested solution?", risky: "no" },
+                { id: "real-problem", text: "Are you solving the real problem, not just the requested solution?", risky: "no", priority: 80 },
+                { id: "alignment", text: "Is everyone aligned on scope, owner, and definition of done?", risky: "no", priority: 64 },
+                { id: "half-value", text: "If you shipped only half of this, do you know which half delivers the most value?", risky: "no", priority: 60 },
+                { id: "regret", text: "Do you know the one thing you're most likely to regret skipping?", risky: "no", priority: 48 },
             ],
         },
     ],