Quorum - Epic Breakdown

As a developer, I want the Quorum web app initialized per architecture decisions, So that all subsequent stories build on a consistent stack.

Maps to: ARCH-1, ARCH-2 (schema shell), ARCH-3 (auth placeholder).

Acceptance Criteria:

Given a clean repository
When the scaffold is applied per architecture.md
Then the app runs locally (dev server) with TypeScript, App Router, and Tailwind baseline
And ESLint (or configured linter) passes on CI or npm run lint
And DATABASE_URL can point at Postgres with Prisma client generation succeeding

As a signed-in user, I want to create and name a workspace, So that I have an isolated place for my product effort.

Maps to: FR1, FR5 (initial row scoping).

Acceptance Criteria:

Given an authenticated user
When they submit a valid workspace name
Then a workspace is created and they are redirected or focused into it
And all new records created in-session are scoped with that workspace_id
And validation prevents empty names and handles duplicate name policy (document chosen policy in UI)

As a user, I want to authenticate and see workspaces I belong to, So that I can access my product work securely.

Maps to: FR2.

Acceptance Criteria:

Given valid credentials (per chosen auth provider)
When the user completes sign-in
Then they land on a workspace list or last-used workspace
And session handling follows NFR-S3 baseline (secure cookies/tokens, no secrets in client)

As a workspace owner, I want to invite members and assign roles, So that my team can collaborate with appropriate permissions.

Maps to: FR3, FR4 (invitation acceptance flow).

Acceptance Criteria:

Given a user with owner (or delegated) permission
When they invite by email and pick a role
Then the invitee can accept and join with that role
And role labels match RBAC matrix intent from PRD (owner/member/contributor/viewer as implemented)

As a workspace member, I want the UI and API to prevent actions outside my role, So that I cannot bypass governance.

Maps to: FR4.

Acceptance Criteria:

Given users with different roles
When a viewer attempts a mutating action (e.g. override filter, change billing)
Then the API returns forbidden and the UI shows disabled control + tooltip (UX-DR10 pattern)
And permitted roles succeed for the same action

As a platform, I want strict workspace isolation, So that no tenant can read another’s data.

Maps to: FR5, NFR-S1.

Acceptance Criteria:

Given two workspaces A and B with test data
When a user authenticated to A requests B’s resource IDs
Then all such requests return 404 or 403 with no data leakage
And automated test covers representative read/write paths

As a member or owner, I want to leave or remove someone per rules, So that access stays current.

Maps to: FR6.

Acceptance Criteria:

Given role rules (owner cannot remove sole owner without transfer, etc.)
When leave/remove is triggered
Then membership updates and the user loses access immediately on next request
And destructive actions require confirmation

As a user, I want the left rail to show the entire Quorum pipeline (PRD steps) while I work, So that I always see the real process—not a dumbed-down mystery track.

Maps to: UX-DR1, UX-DR12, UX-DR14, FR7 (container for interaction).

Acceptance Criteria:

Given a desktop viewport (≥1280px)
When I open a workspace
Then I see pipeline rail (~256px), team room (fluid), artifacts (~360px) per Figma/wireframe alignment
And the pipeline rail lists all canonical steps from ux-design-specification.md §4.2.1 (1 → 2a → 2b → 2c → 3 → … → 12), scrollable or grouped-expandable, with completed / current / upcoming states
And step 3 is labeled per PRD (Three-pillar analysis, not “Filter” alone) and expands to show Desirability → Feasibility → Viability as nested items while in that phase
And there are no top-level rail steps invented outside the PRD (e.g. not “Conflict resolution” or “Sync” as fake methodology)
And below 1024px, rail is reachable via drawer/tab without losing access to the same full step list
And Figma file link is referenced for visual QA

As a user, I want to see which agents are active for this step, So that the team feels real and legible.

Maps to: FR8, UX-DR2.

Acceptance Criteria:

Given a pipeline step configuration
When the session loads
Then active personas are highlighted and inactive ones are subdued with tooltip “Joins in [step]”
And avatars + role labels match PRD roster naming policy

As a user, I want to read and send messages in the team room, So that I can run sessions with my AI team.

Maps to: FR7, NFR-P2 (streaming indicators).

Acceptance Criteria:

Given an active session
When I send a message
Then it appears in the transcript with correct ordering
When an agent responds with latency >2s
Then a streaming or step label indicator appears before full content (UX-DR3)

As a user, I want to list and open workspace artifacts next to chat, So that I can context-switch without losing the conversation.

Maps to: FR9, FR32.

Acceptance Criteria:

Given artifacts of multiple types exist
When I select an artifact
Then preview or detail opens without leaving the team room layout
And artifact list reflects a single underlying scope version; version chip when viewing non-current snapshot (if implemented)

As a user, I want structured conflict presentation when agents disagree, So that I can decide with clarity.

Maps to: FR10, UX-DR4 (reuse card visual language).

Acceptance Criteria:

Given orchestration emits a conflict structure
When the UI receives it
Then a trade-off panel shows positions, evidence links, and recommended resolution path
And the user can acknowledge or proceed to decision capture

As a user, I want to ask for clarification on agent reasoning, So that I trust the analysis.

Maps to: FR11.

Acceptance Criteria:

Given an agent message with expandable rationale
When I use “Clarify” (or equivalent)
Then the orchestration requests deeper explanation and renders it in-thread
And rate limiting or empty responses are handled gracefully (NFR-P2)

As a user, I want decisions on contested recommendations stored, So that audit and resume are possible.

Maps to: FR12, FR25 (feeds override/decision log).

Acceptance Criteria:

Given a contested recommendation
When I choose accept / reject / override with rationale
Then the decision is persisted with actor, timestamp, workspace, and references to messages
And the decision appears in a filterable Decision log minimal view or export hook

As a returning user, I want to resume from my last meaningful checkpoint, So that I don’t redo work.

Maps to: FR13, UX-DR6, ARCH-4.

Acceptance Criteria:

Given a saved checkpoint exists
When I reopen the workspace
Then a resume banner shows what is already complete and a CTA “Continue here”
And orchestration state reloads from persisted checkpoint without corrupting scope

As a user, I want a full-team guided ideation session that runs the Kitchen Sink Discovery Framework and produces four structured deliverables, So that my idea is captured comprehensively before visuals, and every downstream step has a tethered source of intent.

Maps to: FR14.

Acceptance Criteria:

Given step 1 active and the full team (John, Kinsley, Winston, Mary) engaged
When the user progresses through prompts across the 8 discovery categories (Core Idea, Features & Functionality, Look & Feel, Visual Identity, User & Audience, Reference Examples, Copy & Voice, Constraints)
Then each question surfaces with its conversational prompt and concrete examples so the user is never staring at a blank field
And inputs are validated and stored as structured session data
And at session close the system produces four structured deliverables: (1) Problem & Solution Framing (problem, users, why-now, NOT, hypothesis, JTBDs, friction, delight, key insight), (2) Features & Capabilities (core / supporting / delight / deferred + personalization + error/empty-state + accessibility), (3) Master Design Prompt (tool-agnostic), (4) per-Screen Prompts (onboarding, home/dashboard, core features, empty state, error state, settings/profile)
And empty states use "team ready" tone per UX principles
And when the team proposes more than one concept direction, each is labeled and distinguishable in the transcript or summary (feeds FR46)

As a user, I want several concept options, the ability to work in another tab or window, and a clear way to bring results back into Quorum, So that I can explore freely without losing the team room or methodology state.

Maps to: FR46, FR15 (handoff), UX-DR15, NFR-I3.

Acceptance Criteria:

Given ideation has produced one or more concept directions (prompts / briefs)
When the user views the handoff area
Then each direction appears as a distinct card or row (title, short rationale, status: Not started / Exploring externally / Brought back)
And each has Open in new tab (or Copy link + open) for the external surface (e.g. Figma Make) without navigating away from Quorum as the only option
When the user returns from external work
Then they can attach URL, paste link, or upload (per product policy) to that direction and mark Brought back
And Quorum persists workspace session; returning to the Quorum tab does not lose pipeline position (FR13 alignment)
And at least two concurrent “exploring” directions can show in-progress state without corrupting each other’s attachments

As a user, I want tool-agnostic design prompts tied to each concept direction, downloadable in my choice of formats, So that I can generate concept frames in any design tool I use (Figma Make, Claude, v0, Midjourney, etc.).

Maps to: FR15, NFR-I3 (stable link field).

Acceptance Criteria:

Given ideation outputs exist
When the step completes
Then each concept direction has copy/export for its prompt artifact
And the prompt is tool-agnostic — not locked to Figma Make, usable in any generative design tool
And the user can download the prompt in any combination of Doc, HTML, and PDF formats via checkbox or dropdown selection
And the user can paste a returned link from any tool back per direction (feeds Stories 3.4, 3.6)

As a user, I want to scroll through concept variations, select a baseline, and refine the chosen direction (including in a breakout window), So that 2c Organize and step 3 start from tangible designs—not a blank list.

Maps to: FR46 (2b surface), FR15, FR17–FR18 (link/update), UX-DR16, NFR-I3.

Acceptance Criteria:

Given Kinsley (or workflow) has produced two or more concept variations for the workspace
And each variation covers the full product surface — not just a landing/hero page — including dashboard, core feature screens, settings, onboarding, empty states, and error states
When step 2b is active
Then the center surface shows Generated Concepts with a horizontally scrollable (or equivalent) series of preview cards, each labeled (e.g. direction name) and showing all screens per variation (e.g. thumbnail strip or screen carousel within each card)
When the user selects a card
Then a Refine region appears for that selection: natural-language input (placeholder guides concrete tweaks), Breakout window (opens external design surface in new tab/window), and submit to send refinement instructions
And the user can attach / paste link / import carried-back updates without losing Quorum session state
And baseline selection (and any retained alternates) is persisted and passed to Organize as part of the handoff bundle with concept labels and core needs from ideation

As a user, I want to align on aesthetics early without DS overhead, So that concepts match my intent.

Maps to: FR16.

Acceptance Criteria:

Given concept direction fields (mood, references)
When saved
Then they appear on concept artifact and feed orchestration context

As a user, I want to link concept visuals to features/flows and update them, So that the vision stays tangible.

Maps to: FR17, FR18.

Acceptance Criteria:

Given a Figma URL or attachment policy
When user adds or updates links/thumbnails
Then artifact panel shows Concept with last updated metadata
And broken link state is visible with retry guidance

As a user, I want the system to propose a full product sitemap AND themed feature groups with dependencies, So that I can review both the overall structure (every section + contents + relationships) and the thematic clustering before the filter.

Maps to: FR19, ARCH-4 (job may be async).

Acceptance Criteria:

Given vision data including the 2b handoff bundle (designs, concept framing, core needs)
When organize job completes
Then user sees a full product sitemap — every section of the product mapped out, each with per-section contents (screens, capabilities, data flows) and relationships to adjacent sections (think product's table of contents with annotations)
And user sees grouped themes with dependency hints alongside the sitemap
And both outputs are tethered to the baseline concept set and core needs so the filter starts from tangible context
And job states show queued/running/failed (NFR-P3)

As a user, I want to edit and lock organization, So that the filter runs on my approved structure.

Maps to: FR20.

Acceptance Criteria:

Given proposed groups
When user drags/edits or accepts
Then lock action enables next step
And checkpoint triggers celebration microcopy (UX principles §5)

As a user, I want the left rail to show Desirability → Feasibility → Viability as my path through the filter, with a way to learn why those pillars matter, a way to choose Collaborate vs Let-AI-handle-it mode upfront, and a three-column board in the team room, So that the UI matches Quorum's methodology—not a generic "filter" black box—and I can pick how much I want to participate in the analysis.

Maps to: FR21, UX-DR4, UX-DR12, UX-DR13, UX-DR14 (ux-design-specification.md §4.2.1–§4.2.2).

Acceptance Criteria:

Given the workspace is in step 3 (Three-pillar analysis)
When I view the app shell
Then the full pipeline remains visible in the left rail (§4.2.1), and step 3 is expanded to show Desirability → Feasibility → Viability as nested items (each with Not started / In progress / Complete, optional Needs revisit)
And the current pillar is visually highlighted and drives the session context (header / orchestration hook)
And no invented top-level methodology steps appear (not "Filter" as the only label for step 3, not "Conflict resolution" or "Sync" as rail spine)

Given entering step 3 for the first time
When I am prompted to choose a mode
Then I see two options: Collaborate (work alongside agents, discuss each evaluation, argue back) and Let AI handle it (agents run full analysis independently, I review output and override)
And mode selection is persisted and visible throughout the step
And mode can be changed mid-step if I choose to, with clear confirmation

Given I am in the filter
When I open “Why these pillars?” (or equivalent ⓘ)
Then I see concise copy explaining Desirability (user/value), Feasibility (build/operate), Viability (should we / business & strategy) and why all three together matter
And optional per-pillar short blurbs are available without blocking progress

Given filter step active
When I view the team room
Then three columns render — Desirability | Feasibility | Viability — with groupings from Epic 3
And layout matches updated Figma / figma-handoff-brief.md Frame 4

As a user, I want evidence, sources, and rationale visible, So that nothing feels like a black box.

Maps to: FR22, NFR-P1 (expand/collapse performance).

Acceptance Criteria:

Given pillar results
When I expand an evidence card
Then I see source titles, links, snippets, confidence
And keyboard-accessible expand (NFR-A1)

As a user, I want to dispute a conclusion and get deeper analysis, So that I can argue with the team.

Maps to: FR23.

Acceptance Criteria:

Given a pillar item
When I choose dispute with comment
Then orchestration runs follow-up and threads results
And agent backbone tone respected (non-sycophantic copy templates)

As a user, I want concept views to reflect filter-driven scope changes, So that visuals match decisions.

Maps to: FR24.

Acceptance Criteria:

Given scope changes from filter
When items are cut or merged
Then concept artifact or preview updates or shows diff callout
And fidelity badge remains Concept until refinement epic

As a user, I want to finalize recommendations or override with reason, So that I stay accountable.

Maps to: FR25, FR25d, UX-DR5, NFR-S6.

Acceptance Criteria:

Given finalization action
When user overrides a gate verdict (pass → fail, fail → pass, or needs-revisit → forced resolution)
Then modal collects reason and shows audit notice
And decision stored append-only for audit (FR45 alignment, FR25d)
And both the original verdict and the override remain visible on the record — the override does not rewrite history
And override remains visible in filter context, not buried
And downstream artifacts (release allocation, PRD narrative) display an override marker against affected features

As a user, I want per-pillar rankings, an overall combined ranking, and MVP/V2/V3 release recommendations with reasoning, So that I leave the filter with a defensible, release-allocated feature set — not just a sorted list.

Maps to: FR25a, FR25c (allocation consumes only gate-cleared features).

Acceptance Criteria:

Given step 3 has completed (mode: Collaborate or Let-AI-handle-it) and every feature has a terminal verdict on all three gates (pass, fail, or user-override-with-audit)
When the output view loads
Then I see three per-pillar rankings (features ranked within Desirability, Feasibility, Viability individually, most-important to least)
And I see an overall combined ranking across all three pillars
And I see release allocation recommendations: MVP / V2 / V3 / deferred, with reasoning shown per allocation (what data was weighted, which gate verdicts drove the call)
And features that failed any gate without override are listed in a "did not clear" group with the failing gate(s) named — not hidden
And features that were overridden carry an explicit override marker in the output
And concept visuals reflect the final scope (features not in MVP are visually marked or filtered)
And the output is exportable alongside other planning artifacts
And the user can override any allocation with audit trail (FR25 alignment)

Given any feature still sits in needs revisit on any gate
When the user attempts to advance to release allocation
Then the system blocks advancement and lists the unresolved gates, prompting the user to either resolve each gate (via dispute loop, more evidence, or accept-as-is) or override (FR25c enforcement)

As a user, I want each pillar evaluation to produce a terminal verdict — pass, fail, or needs revisit — against documented pass criteria, So that I know whether a feature cleared the gate, not just where it ranked.

Maps to: FR25b, FR25c. Informs FR23 (dispute keeps a feature in needs-revisit).

Acceptance Criteria:

Given a feature under pillar evaluation
When the agent(s) complete the assessment
Then the feature receives a terminal verdict (pass / fail / needs revisit) on that pillar
And the verdict is paired with a confidence level (low / moderate / high)
And the evidence snippets, sources, and rationale that drove the verdict are attached and viewable (Story 4.2)
And the verdict is stored with the feature record (not just displayed)

Given a pillar card in the three-column board
When I view a feature on that card
Then I see the verdict badge (pass / fail / needs revisit) on the feature
And color and copy are distinct enough to read at a glance — pass, fail, and needs-revisit are never ambiguous (NFR-A4 contrast applies)
And hovering / focusing reveals the pass criteria tested for that pillar and how this feature scored against them

Given a feature in needs revisit on any pillar
When I attempt to finalize step 3 / advance to allocation
Then the system surfaces every unresolved feature-gate pair and blocks advancement (Story 4.6 alignment)
And I can resolve by: (a) running a dispute / deeper analysis (Story 4.3), (b) accepting as-is (forces pass), or (c) overriding with rationale (Story 4.5)

Given I am reviewing pillar verdicts
When I open a "Why this verdict?" affordance on any pillar card
Then I see the pass criteria for that pillar (what the agent tested for), the evidence collected, and the call — transparent not a black box (FR22 alignment)

As a system, I want a single canonical PRD representation, So that HTML and DOCX never drift.

Maps to: FR26, ARCH export pipeline.

Acceptance Criteria:

Given post-filter scope state
When PRD is generated
Then one source feeds both HTML render and DOCX generation
And generation shows job progress and handles failure gracefully (NFR-P4)

As a user, I want to preview PRD in-app and download Word, So that I can share professionally.

Maps to: FR26.

Acceptance Criteria:

Given generated PRD
When user opens artifact
Then HTML preview loads in sandboxed viewer
And DOCX download uses same source checksum/version id

As a user, I want journey maps for user and customer flows, So that flows are visual, not only text.

Maps to: FR27.

Acceptance Criteria:

Given agreed scope
When journeys generate
Then diagram or structured visual renders in artifact viewer
And links to concept references where applicable

As a user, I want the refinement pass to update journey maps, refresh all screens and their content, establish tokens + design system, and produce a fix-up design prompt plus Doc/HTML exports of all contextual material, So that nothing stale survives this step and I leave with implementation-ready design plus a prompt that updates my previous concept designs rather than replacing them from scratch.

Maps to: FR28.

Acceptance Criteria:

Given journeys marked stable and the filter output allocated to releases
When user triggers refinement
Then the workflow updates journey maps based on pipeline findings (three-pillar analysis, PRD, journey mapping) — no stale journeys survive
And the workflow updates all screens and their content against current truth — correct features per section, correct content, correct hierarchy — no stale screens survive
And the workflow produces refined high-fidelity static designs, a formal token inventory, and a design system plan (components, patterns, vocabulary)
And the workflow produces a detailed design prompt for any visual tool (Figma Make, Claude, etc.) that references the previous concept designs and fixes and updates everything — correct content, correct placement, correct hierarchy, reflecting all pipeline decisions
And the workflow produces Doc and HTML exports for all contextual material: token inventory, design system plan, screen-by-screen specs, updated journey maps
And UI shows Refined fidelity badge when complete

As a user, I want motion/interaction specs captured post-refinement, So that Luca’s layer attaches to stable screens.

Maps to: FR29, NFR-A2.

Acceptance Criteria:

Given refined artifacts exist
When motion capture step runs
Then structured motion spec artifact is created per screen/transition
And reduced-motion alternatives captured as required fields
And the output is delivered in two formats: a text file (full motion specification document) and an HTML file (formatted, browsable version with visual organization)

As a user, I want roadmap and cost estimates with confidence bands, So that I can plan releases.

Maps to: FR30, PRD success criteria on confidence ranges.

Acceptance Criteria:

Given scope + motion scope inputs
When generated
Then roadmap artifact shows phases; cost shows ranges not false precision
And exports available as artifacts

As a user, I want an audience-appropriate pitch deck generated, then time to refine both design and content, then exportable as PDF, DOC, and HTML, So that I can fundraise or align leadership with a polished artifact I have shaped to my voice, not a one-shot export.

Maps to: FR31.

Acceptance Criteria:

Given upstream artifacts
When pitch generates
Then output includes product experience section hook for motion (per PRD)
And solo vs enterprise tone adapts without separate "mode" if following unified model
And after generation, the user enters a refinement mode where they can adjust design (layout, visuals, slide composition) and content (copy, data points, narrative arc) iteratively — not one-shot
And when ready, the user can export the refined pitch deck to PDF (presentation-ready, shareable), DOC (editable), and HTML (web-viewable, linkable)

As a user, I want stories generated from approved scope, So that build work is legible.

Maps to: FR33.

Acceptance Criteria:

Given approved scope state
When sprint planning runs
Then stories include Given/When/Then ACs
And stories are workspace-scoped and versioned

As a user, I want stories to reference design and motion artifacts, So that implementers have context.

Maps to: FR34, NFR-I3.

Acceptance Criteria:

Given story records
When user or system links artifacts
Then links are stable URLs or internal IDs with metadata
And missing link surfaces “blocked” hint for implementer

As a user, I want to export stories for Cursor/Claude Code-style workflows, So that external tools can implement.

Maps to: FR35, NFR-I1.

Acceptance Criteria:

Given a story
When export is triggered
Then bundle includes AC, links, architecture excerpt, file path hints per PRD buildArchitecture
And export JSON validates against published schema version field

As a user, I want to update story status in Quorum, So that the board reflects reality.

Maps to: FR36, UX-DR9.

Acceptance Criteria:

Given board columns
When user drags or sets status
Then persistence updates and audit-friendly history optional for later
And Blocked requires reason field

As a user, I want backend tasks when the definition demands infra, So that Damien-path work is explicit.

Maps to: FR37.

Acceptance Criteria:

Given product definition flags backend need
When planning completes
Then backend stories are generated with same rigor as frontend
And conditional activation matches PRD (Damien)

As a user, I want to run or record QA against story ACs, So that quality is traceable.

Maps to: FR38.

Acceptance Criteria:

Given stories with ACs
When QA flow executes
Then pass/fail per AC is stored and visible on story
And links to test artifacts or runs optional

As a workspace, I want security audit before release declaration, So that shipping meets policy.

Maps to: FR39, NFR-S4 alignment.

Acceptance Criteria:

Given build complete milestone
When user requests release
Then Cipher audit must be completed or explicitly waived with record
And findings carry severity + remediation state

As a user, I want to compare delivery to design and motion intent, So that UAT is structured.

Maps to: FR40.

Acceptance Criteria:

Given linked design/motion artifacts
When UAT session runs
Then checklist captures spatial and temporal checks (checkboxes + notes)
And reduced-motion behavior verified if applicable

As a user, I want to mark release blocked or unblocked, So that policy gates are explicit.

Maps to: FR41.

Acceptance Criteria:

Given QA + security + UAT states
When user toggles release status
Then blocked reasons are required and visible on dashboard/shell
And unblocked requires all policies satisfied or waiver recorded

As an administrator, I want to configure tier limits and seats, So that billing matches the org.

Maps to: FR42.

Acceptance Criteria:

Given admin role
When settings saved
Then limits persist and enforce invite/usage rules per policy
And UI matches Settings density (UX-DR10)

As an administrator, I want to connect Jira or Notion (V1 policy), So that enterprise onboarding isn’t manual-only.

Maps to: FR43, NFR-I2.

Acceptance Criteria:

Given OAuth or API key flow (document choice)
When connection succeeds
Then status badge shows Connected; errors show Degraded with retry
And webhook handlers idempotent where applicable

As a user, I want to see usage against limits, So that I understand consumption.

Maps to: FR44, NFR-R3.

Acceptance Criteria:

Given metering data
When user opens usage panel
Then sessions/tokens (per product definition) display vs tier caps
And approaching limit shows non-alarming warning

As an administrator, I want append-only audit history for sensitive changes, So that we meet enterprise expectations.

Maps to: FR45, NFR-S6.

Acceptance Criteria:

Given security-sensitive events (integration, override, role, release waiver)
When they occur
Then audit entries capture actor, timestamp, workspace, payload summary
And entries cannot be edited by normal admins

As a user, I want a comprehensive document that summarizes my entire product evolution from idea to shipped product, So that I can use it as a portfolio piece, case study, or stakeholder retrospective — showing the evolution, not just the result.

Maps to: FR47.

Acceptance Criteria:

Given the workspace has completed at least step 11 (Ship); post-ship metrics from step 12 are optional inputs
When the user triggers Portfolio Document generation
Then the system produces a single structured document covering: original problem & hypothesis, discovery insights & key decisions (from step 1 Kitchen Sink framework), concept evolution (before/after at each stage — step 2b concepts → step 5.25 refined designs), design decisions & rationale, three-pillar analysis highlights (per-pillar rankings + release allocation reasoning), architecture choices, the build process, QA & security findings, final product screenshots, key post-ship metrics (if available), and lessons learned
And the document shows the evolution, not just the result — emphasizing how the product evolved through the structured process
And lead agents are John (PO) and Kinsley (Product Designer) per pipeline assignment

As a user, I want to adjust tone, audience framing, and which sections appear in my Portfolio Document, So that the same source produces the right artifact for a portfolio reviewer vs internal retrospective vs case study.

Maps to: FR47.

Acceptance Criteria:

Given an initial Portfolio Document has generated
When the user enters customization mode
Then the user can toggle section visibility, adjust tone (portfolio-friendly / retrospective / case-study), and edit content inline
And the source data remains untouched — customization is a view over the source

As a user, I want to export my Portfolio Document as HTML, PDF, and Doc, So that I can share it on any platform my audience uses.

Maps to: FR47.

Acceptance Criteria:

Given a finalized Portfolio Document
When the user exports
Then the system produces HTML (web-viewable, linkable), PDF (presentation-ready, shareable), and Doc (editable)
And all three formats render from the same source so content does not drift

As a user, I want to generate a Case Study that is shorter and more polished than the Portfolio Document, So that I have a shareable artifact for portfolio reviewers, prospective clients, or a public audience without sending them a long retrospective.

Maps to: FR60.

Acceptance Criteria:

Given the workspace has completed step 11 (Ship) at minimum
When the user triggers Case Study generation
Then the system produces a single-narrative document covering: one-line positioning, the problem, the approach, key decisions (with brief rationale), the team (agents involved), build stats (days, stories, ship date), what worked, what was hard, takeaways
And output is distinct from the Portfolio Document: shorter, polished, and externally shareable
And both documents pull from the same source of truth (audit trail, filter decisions, rationale log) so they stay consistent
And the Case Study can be generated before the Portfolio Document is finalized (they are independent)

As a user, I want the system to proactively offer to generate my Portfolio Document and Case Study at the end of the pipeline, So that I do not leave value on the table by forgetting to produce these artifacts after shipping.

Maps to: FR61.

Acceptance Criteria:

Given the user has completed pipeline step 12 (post-ship feedback)
When the system detects step 12 completion
Then the system surfaces a prompt asking: "Generate Portfolio Document, Case Study, or both?"
And the prompt offers tone options: Portfolio reviewer (short, polished), Internal retrospective (longer, candid), Public case study (mid-length, shareable)
And the user can dismiss the prompt and return to it later from the pipeline view
And declining does not block access to the final step (Portfolio); user can always generate manually

As a user, I want my generated Portfolio and Case Study to look like the product I built, So that every artifact carries my product's visual identity instead of a generic default.

Maps to: FR62.

Acceptance Criteria:

Given the workspace has an established visual identity (design tokens from step 5.25 and/or a brand palette)
When the user generates the Portfolio Document or Case Study
Then the output applies the user's project color palette, typography, and logo
And HTML, PDF, and Doc versions all reflect the same brand identity
And a fallback neutral theme is used if no brand identity is defined (e.g., early ship before design refinement)
And Quorum's own meta case study (case-study.md in this planning repo) serves as a worked example of the pattern

As a user, I want to publish my Case Study to my own portfolio endpoint, So that I can share a canonical live URL that updates as my product evolves, instead of mailing a PDF each time.

Maps to: FR63.

Acceptance Criteria:

Given a finalized Case Study
When the user selects "Publish to portfolio"
Then the user can choose an endpoint: Quorum-hosted share link (default), Connected portfolio website (V1 integration list TBD, e.g., personal site, GitHub Pages, Notion), or Copy published URL for manual publishing
And the published URL is canonical: updates to the source Case Study propagate to the live page on republish
And published case studies carry a visible "last updated" timestamp
And user can unpublish at any time
And publishing requires no additional user credentials beyond Quorum auth for the default Quorum-hosted option

As a Quorum team member, I want a Tauri shell project that wraps the Quorum web app in a native macOS window, So that we have a runnable .app showing the existing web experience with zero UI rebuild.

Maps to: FR52.

Acceptance Criteria:

Given a fresh dev machine with Rust + Node toolchains installed
When developer runs npm run tauri dev from the desktop-wrapper project
Then a native macOS window opens showing the Quorum web app served from localhost:3000
And webview uses system WKWebView (not bundled Chromium)
And window chrome includes standard macOS traffic-light buttons (close / minimize / maximize)
And production builds point webview at https://quorum.app (environment-switchable via tauri.conf.json)
And release-build app size is under 20 MB

As a macOS user, I want Quorum to install past Gatekeeper cleanly and update itself automatically, So that I never see "unidentified developer" warnings and stay on the latest version without manual downloads.

Maps to: FR52, FR53.

Acceptance Criteria:

Given an Apple Developer ID certificate is configured in the build environment
When CI runs a release build
Then the resulting .app is signed with the Developer ID Application certificate
And the .app passes Apple notarization and is stapled with the notarization ticket
And hardened runtime is enabled on the signed binary
And installed app passes Gatekeeper on a clean Mac running current macOS (no right-click-open bypass needed)

Given a newer signed version is available on the update feed
When user launches Quorum.app
Then app checks the update manifest at a known URL on quorum.app
And if a newer version is available, app prompts the user to update with release notes visible
And user can accept or defer; deferred updates re-prompt on next launch
And update manifest is signed; unsigned or tampered manifests are rejected

As a Quorum team member, I want a GitHub Actions pipeline that produces signed, notarized .dmg artifacts on tagged releases, So that shipping a new macOS version is a one-command operation.

Maps to: FR54.

Acceptance Criteria:

Given a git tag matching pattern desktop-v* is pushed
When GitHub Actions macOS runner picks up the tag
Then pipeline builds the Tauri app in release mode
And pipeline signs, notarizes, and staples the binary using repository secrets for Apple Developer credentials
And pipeline produces a .dmg artifact with the app pre-staged to drag-install to /Applications
And pipeline publishes the .dmg + signed update manifest to the quorum.app distribution endpoint (S3, R2, or equivalent)
And pipeline fails loudly if any step in the sign/notarize chain fails — no partial releases

As a macOS user, I want Quorum to look like a real Mac citizen from first sight — icon in dock, polished installer window, So that trust is established before I've even opened the app.

Maps to: FR51.

Acceptance Criteria:

Given Quorum's brand system (visual tokens, logo)
When icon and installer visuals are produced
Then app icon exists as 1024×1024 PNG master plus full .icns size set (16, 32, 64, 128, 256, 512, 1024 at @1x and @2x)
And icon reads well at 16×16 (dock when minimized) without pixel mud
And DMG installer window shows a background image with an arrow from the Quorum icon to an /Applications alias
And installer window size, icon positions, and background are version-controlled in the build pipeline (not hand-set per release)
And visual treatment matches web-app brand system — no standalone aesthetic drift

As a prospective Quorum user, I want a clear download page that gives me the right Mac build for my machine, So that I can install Quorum without reading release notes or guessing architectures.

Maps to: FR51.

Acceptance Criteria:

Given a user lands on quorum.app/download from marketing or in-app prompts
When page loads
Then page detects the user's OS and highlights the Mac build as primary if on macOS
And page serves the latest signed .dmg (Universal binary — Apple Silicon + Intel)
And page shows current version number, release date, and minimum macOS version required
And page links to a changelog with release notes for the current and previous 5 versions
And page copy follows Quorum voice/tone guide — short, clear, action-first
And page meets WCAG 2.2 AA (heading structure, alt text on screenshots, keyboard-nav friendly, sufficient color contrast)

As a Quorum team member, I want an explicit security review of the macOS distribution before public release, So that we ship with minimum-necessary permissions and no unreviewed attack surface.

Maps to: FR55, NFR-S1, NFR-S6.

Acceptance Criteria:

Given a release-candidate build of Quorum.app is available
When security review runs (Cipher)
Then entitlements file is reviewed — every requested entitlement has a documented reason
And no excess entitlements are present (no com.apple.security.get-task-allow, no arbitrary network exceptions)
And hardened runtime is confirmed enabled
And network traffic from the running app is captured and reviewed — all outbound hosts are Quorum-owned or documented third parties
And no credentials, tokens, or workspace content leak to logs, disk caches, or crash reports in unexpected places
And signed update-manifest mechanism is reviewed for tampering resistance (signature verification, rollback protection)
And findings are logged; release is blocked until all high-severity findings are resolved

As a poll creator, I want a browsable library of ready-to-use poll templates organized by vote type, So that I can start from a proven, accessibility-compliant question pattern instead of writing from scratch.

Maps to: FR56.

Acceptance Criteria:

Given user is in the poll-creation flow
When user opens the template library
Then library shows templates grouped by category (Yes/No, Ranked Choice, Approval Voting, Sentiment, Multiple Choice, Free Response)
And each template shows a preview (question text + answer options) before applying
And user can search by keyword across template content
And applying a template populates the poll draft with pre-filled question, options, and recommended settings
And user can modify any template field after applying

Given a template is authored or reviewed
When it is published to the library
Then template content meets WCAG 2.2 AA — reading level at or below grade 9, plain language, no leading phrasing, clear answer options
And all templates are reviewed by the content strategist before publication

As a poll creator, I want real-time feedback while I write a poll question, So that I catch unclear wording, leading phrasing, or accessibility issues before publishing — not after the first confused response.

Maps to: FR57.

Acceptance Criteria:

Given user is drafting a poll question
When user types or edits the question text
Then system runs checks in near-real-time (debounced, under 500 ms)
And checker flags: leading phrasing, loaded language, jargon or rare vocabulary, reading level above grade 9, ambiguous answer options, and missing alt text on attached images
And flags appear as non-blocking inline indicators (icon + hover/tap for detail), not interrupting modals
And each flag shows severity (info / warning / critical) and a one-sentence explanation
And user can dismiss individual flags per draft

Given user is ready to publish
When user initiates publish
Then if any critical flags remain, system shows a single consolidated review dialog
And user can publish anyway (with critical flags logged to the workspace audit trail) or return to edit
And full review dialog is screen-reader accessible and keyboard navigable

As a poll creator, I want the system to suggest better phrasings when my question is flagged, So that I have a concrete alternative to consider rather than having to reinvent from scratch.

Maps to: FR58.

Acceptance Criteria:

Given a poll question has a flagged issue (leading, jargon, reading level, or similar)
When user clicks "Suggest alternative" on the flag
Then system presents 1–3 rewording candidates that address the flag
And suggestions preserve the original question's intent and answer options
And each suggestion shows what issue it resolves (e.g., "Neutral phrasing" or "Grade 7 reading level")
And user can accept a suggestion (replaces the original), edit a suggestion inline, or dismiss
And suggestions render within 3 seconds of request

Given suggestions are generated via an LLM backend
When user-drafted question content is sent
Then content is transmitted over an authenticated encrypted channel only
And no user-drafted content is retained beyond the generation request (per privacy policy)
And data handling is reviewed by Cipher before general availability

As a poll creator, I want contextual tips about question design and accessibility while I draft, So that I learn patterns as I work, not by reading docs upfront.

Maps to: FR59.

Acceptance Criteria:

Given user is drafting a poll
When user reaches a drafting moment where a tip applies (e.g., adding a 6th answer option, writing a negatively-framed question, attaching an image without alt text)
Then system surfaces a single contextual tip inline — short (1–2 sentences) and dismissible
And tips cover both question-design patterns and accessibility considerations
And tips are non-blocking — draft flow continues if user ignores
And user can dismiss a tip for the current draft or permanently mute it via a gear icon
And full tip library is accessible via a help panel at any time

Given tip content is authored
When content strategist reviews
Then all tips follow Quorum voice/tone guide, stay under 30 words, and cite a WCAG success criterion where accessibility-specific