Change log

Walkthrough Alignment — Change Log

A single-page reference for every edit made when reconciling the canonical Quorum planning artifacts with quorum-pipeline-walkthrough.md. Organized by pipeline step for scanning; each edit has a short ID (E-##) if you need to reference one in conversation.

At a glance

By artifact

By pipeline step

How to read this document

Each edit block follows the same structure:

E-## · File → Section → Field

Before: (quoted or summarized)

After: (quoted or summarized)

Why: (one-line rationale)

Long passages are summarized with the delta called out rather than quoted verbatim — the git diff is the source of truth for exact text.

Step 1 — Describe Your Idea

Summary: Elevated from PO+Designer session to full-team design-thinking session. Added the Kitchen Sink Discovery Framework (8 categories, ~35 questions with prompts + examples). Replaced single-prompt output with four structured deliverables.

E-01 · prd.md → pipeline YAML → Step 1 leadAgents

Before

John (PO) primary; Kinsley (Product Designer) participates

After

Full team: John (PO), Kinsley (Product Designer), Winston (Dev Lead), Mary (UX Researcher); anyone else relevant joins. Creativity comes from collision.

Why: Walkthrough reframes Step 1 as a full-team session, not a two-agent handoff.

E-02 · prd.md → pipeline YAML → Step 1 detail

Before (delta summary): Described a design-thinking session closing with a single Figma Make prompt.

After (delta summary): Full team runs the Kitchen Sink Discovery Framework across 8 categories — Core Idea · Features & Functionality · Look & Feel · Visual Identity · User & Audience · Reference Examples · Copy & Voice · Constraints. Each question has a conversational prompt + concrete examples. Session closes by packaging learnings into structured deliverables (not a single prompt).

Why: The walkthrough's Step 1 is 295 lines of richly structured discovery. The PRD YAML previously captured only the outer shape.

E-03 · prd.md → pipeline YAML → Step 1 output

Before

Shared problem/solution framing + ideation notes + Figma Make concept prompt (detailed, ready to execute)

After

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).

Why: Walkthrough produces four distinct, templated outputs — not one prompt.

E-04 · prd.md → FR14

Before

FR14: User can participate in a structured ideation session that captures the core idea, problem, users, constraints, and risks.

After (delta summary): Rewritten to name the 8 discovery categories and the four structured deliverables explicitly. Anchors the requirement to the walkthrough.

Why: Existing FR was generic; new FR is testable against the walkthrough's explicit framework.

E-05 · epics.md → Story 3.1 (Structured ideation session UI)

Before (ACs): Guided prompts, structured storage, team-ready empty state, multi-concept labeling.

After (delta summary): All previous ACs retained + new ACs enforcing: (a) full-team engagement, (b) all 8 discovery categories present, (c) conversational prompt + concrete examples per question, (d) four structured deliverables produced at session close.

Why: The story needs to build Step 1 to the walkthrough's specification.

E-06 · ux-design-specification.md → §10.1 Journey 1, step 2

Before (delta summary): Described guided design-thinking prompts with multi-concept direction support.

After (delta summary): Same scaffolding + explicit full-team reference + 8-category Kitchen Sink framing + four structured deliverables named (tool-agnostic Master Design Prompt downloadable as Doc/HTML/PDF).

Why: UX spec journey now matches walkthrough's richer Step 1.

Step 2a — Concept Alignment (Light)

Summary: Tool-agnostic prompt (not Figma-Make-specific). Multi-format downloads.

E-07 · prd.md → pipeline YAML → Step 2a detail

Before (delta summary): Tightens the "Figma Make prompt" with mood, references, aesthetic notes.

After (delta summary): Same tightening, but prompt is explicitly tool-agnostic — works in Figma Make, Claude, v0, Midjourney, whatever.

Why: Walkthrough explicitly genericized the prompt in Round 1 enrichment.

E-08 · prd.md → pipeline YAML → Step 2a output

Before

Finalized concept direction brief + execution-ready Figma Make prompt (exploratory parameters only)

After

Finalized concept direction brief + execution-ready tool-agnostic design prompt — downloadable in user-selected format(s): Doc, HTML, and/or PDF (checkboxes/dropdowns, one or multiple).

Why: New multi-format download capability from walkthrough.

E-09 · prd.md → FR15

Before

FR15: User can receive a documented handoff suitable for external concept-design execution (e.g. structured prompt for a design tool).

After (delta summary): Adds tool-agnostic emphasis and downloadable multi-format selection (Doc/HTML/PDF via checkbox/dropdown).

Why: Walkthrough made both requirements explicit.

E-10 · ux-design-specification.md → §4.2.1 canonical table row

Before

2b | Initial concept visuals — Figma Make

After

2b | Initial concept visuals — generated concepts (tool-agnostic)

Why: Rail label should match walkthrough's genericized framing.

E-11 · epics.md → Story 3.3 (renamed)

Before (title): Story 3.3: Figma Make prompt artifact (per direction)

After (title): Story 3.3: Concept design prompt artifact (tool-agnostic, per direction)

After (ACs delta): Added tool-agnostic requirement + Doc/HTML/PDF download selection.

Why: Story should own the genericization and multi-format export.

Step 2b — Generated Concepts

Summary: Variations must cover all screens, not just landing.

E-12 · prd.md → pipeline YAML → Step 2b detail

Before (delta summary): Multiple variations produced at exploratory fidelity; scroll/select/refine/breakout flow.

After (delta summary): Same scaffolding + explicit "each variation covers all screens — dashboard, core feature screens, settings, onboarding, empty states, error states — the full product surface."

Why: Walkthrough called out the full-product-surface requirement directly. Prior PRD left it implicit.

E-13 · ux-design-specification.md → §11.3 GeneratedConceptsCarousel

Before: Horizontal scroll of concept preview cards.

After: Same + behavior note — each card surfaces the full product surface (dashboard, core features, settings, onboarding, empty/error states), not just a hero screen.

Why: Component spec now encodes the all-screen requirement.

E-14 · epics.md → Story 3.4 (Generated Concepts)

Before (ACs): Two-or-more variations, scrollable preview cards, select + refine + breakout.

After (ACs delta): Adds explicit AC — each variation covers the full product surface; preview card shows all screens per variation (thumbnail strip or inner screen carousel).

Why: Acceptance criteria enforces the walkthrough's all-screen rule.

Step 2c — Organize the Vision

Summary: Full product sitemap joins the themed-groupings output.

E-15 · prd.md → pipeline YAML → Step 2c detail

Before (delta summary): AI clusters features into themed groups with dependencies; user validates before filter.

After (delta summary): Same + new paragraph: "AI produces a full sitemap — every section mapped out, and within each section the screens, capabilities, data flows, and relationships to adjacent sections. Product's table of contents with annotations."

Why: Walkthrough promoted sitemap from implicit to explicit output.

E-16 · prd.md → pipeline YAML → Step 2c output (NEW FIELD)

After (new):

Full product sitemap (every section + per-section contents + relationships) + themed feature groupings with dependencies + concept baseline tether.

Why: Step 2c previously had no output field; walkthrough makes outputs explicit.

E-17 · prd.md → FR19

Before

FR19: System can propose themed groupings of features with dependencies for user confirmation.

After

FR19: System can propose a full product sitemap (every section mapped with per-section contents, capabilities, data flows, and relationships to adjacent sections) alongside themed groupings of features with dependencies for user confirmation.

Why: Adds sitemap as a first-class FR.

E-18 · ux-design-specification.md → §11.3 (NEW component: SitemapView)

After (new row):

SitemapView — Step 2c: full product sitemap — every section mapped with per-section contents (screens, capabilities, data flows) and relationships to adjacent sections. Complements ThemeClusterCard.

Why: New UI surface to render the sitemap output.

E-19 · epics.md → Story 3.7 (renamed + expanded)

Before (title): Story 3.7: Proposed theme groupings

After (title): Story 3.7: Proposed theme groupings and full product sitemap

After (ACs delta): New AC — user sees a full product sitemap (every section + per-section contents + relationships) alongside themed groupings; both tethered to concept baseline and core needs.

Why: Story now covers both outputs.

Step 3 — Three-Pillar Analysis

Summary: Two modes upfront (Collaborate / Let AI handle it). Release allocation output (MVP/V2/V3/deferred). New FR25a. New Story 4.6.

E-20 · prd.md → pipeline YAML → Step 3 detail

Before (delta summary): Analysis is a conversation; evidence and transparency; concept visuals update live; argue back.

After (delta summary): Same scaffolding + explicit "Two modes — user chooses upfront: (A) Collaborate — real-time discussion with agents; (B) Let AI handle it — agents run independently, user reviews and overrides." + internal research detail and design discovery analysis (core idea, feature, aesthetic, visual identity, user & audience, reference, copy & voice, constraint validations).

Why: Walkthrough introduced two-mode model and enumerated the internal research topics.

E-21 · prd.md → pipeline YAML → Step 3 internal research detail

(folded into E-20 as a single edit)

E-22 · prd.md → pipeline YAML → Step 3 output (NEW FIELD)

After (new):

Per-pillar rankings (features ranked within Desirability, Feasibility, Viability individually) + overall combined ranking across all three + release allocation recommendations (MVP / V2 / V3 / deferred) with reasoning for each allocation + concept visuals reflecting final scope + full audit trail of what data was considered, weighted, or excluded.

Why: Walkthrough turned an implicit output (filtered features) into explicit structured rankings + release allocation.

E-23 · prd.md → FR21

Before

FR21: User can run structured three-pillar evaluation conversations on feature groups.

After

FR21: User can run structured three-pillar evaluation with two modes upfront: (A) Collaborate — work alongside the AI agents, discuss each evaluation, argue back, and make calls together in real-time; (B) Let AI handle it — agents perform the full analysis independently and user reviews the finished output, overriding where needed.

Why: Two-mode model is now a first-class FR.

E-24 · prd.md → NEW FR25a

After (new):

FR25a: System can produce per-pillar rankings (features ranked within Desirability, Feasibility, Viability individually), an overall combined ranking across all three pillars, and release allocation recommendations (MVP / V2 / V3 / deferred) with reasoning for each allocation.

Why: Release allocation was not a testable FR previously; walkthrough elevates it.

E-25 · ux-design-specification.md → §11.3 PillarColumn + new ReleaseAllocationOutput

Before: PillarColumn — filter step.

After (delta): PillarColumn annotated with "Mode selector at top (Collaborate / Let AI handle it) captures user choice upfront." New row added: ReleaseAllocationOutput — per-pillar rankings, overall combined ranking, MVP/V2/V3 allocation table with reasoning.

Why: Two new UI responsibilities now owned by component inventory.

E-26 · epics.md → Story 4.1 (Pillar path rail + education + three-column board)

Before (title): Story 4.1: Pillar path rail, education, and three-column board

After (title): Story 4.1: Pillar path rail, education, mode selection, and three-column board

After (ACs delta): New ACs — mode selector shown on entry (Collaborate vs Let AI handle it); selection persisted; mode changeable mid-step with confirmation.

Why: Story owns the UX for mode choice.

E-27 · epics.md → NEW Story 4.6 (Release allocation and combined ranking output)

After (new story): Full ACs for per-pillar rankings + overall combined ranking + MVP/V2/V3 allocation with reasoning + concept visual reflection of final scope + override with audit.

Why: New FR25a needs story coverage.

Step 5.25 — Design Refinement

Summary: Refinement pass now updates journeys + refreshes all screens + fix-up design prompt + Doc/HTML exports.

E-28 · prd.md → pipeline YAML → Step 5.25 detail

Before (delta summary): High-fidelity static screens + tokens + design system plan after PRD and journey maps.

After (delta summary): Same + journey maps are updated based on pipeline findings + all screens and content updated against current truth. "Nothing stale survives this step" (stated twice, intentionally).

Why: Walkthrough promoted journey/screen refresh from implicit to explicit.

E-29 · prd.md → pipeline YAML → Step 5.25 output

Before

Refined static designs, token inventory, design system plan, handoff-ready spatial layer

After (delta summary): Same + updated journey maps + detailed design prompt for any visual tool that fixes and updates everything (references previous concepts, reflects all pipeline decisions) + Doc and HTML exports of all contextual material.

Why: Walkthrough made the fix-up design prompt and multi-format exports explicit deliverables.

E-30 · prd.md → FR28

Before

FR28: User can trigger a refinement pass that increases design fidelity and design-system structure after journeys are stable.

After (delta summary): Adds journey update + screen/content refresh + fix-up design prompt + Doc/HTML exports as explicit requirement components.

Why: FR now testable against full walkthrough scope.

E-31 · epics.md → Story 5.4 (renamed + expanded)

Before (title): Story 5.4: Refinement pass trigger after journeys

After (title): Story 5.4: Refinement pass — journey + screen refresh, tokens, design system, and fix-up prompt

After (ACs delta): New ACs covering journey update, all-screen refresh, token inventory, design system plan, fix-up design prompt, Doc/HTML exports.

Why: Story now carries the walkthrough's full Step 5.25 scope.

Step 5.5 — Motion & Animation Design

Summary: Explicit export formats (text + HTML).

E-32 · prd.md → pipeline YAML → Step 5.5 output

Before

Motion specification documents — per screen, per transition, per interactive element

After

Motion specification documents — per screen, per transition, per interactive element — delivered in two formats: text file (full spec document) and HTML file (formatted, browsable version with visual organization).

Why: Walkthrough called out both formats as deliverables.

E-33 · prd.md → FR29

Before

FR29: System can capture motion and interaction intent specifications after refined design.

After

FR29: System captures motion and interaction intent specifications after refined design — delivered as text and HTML files, with reduced-motion alternatives.

Why: Export formats now part of the FR contract.

E-34 · epics.md → Story 5.5 (Motion intent capture)

Before (ACs): Structured motion spec per screen/transition; reduced-motion alternatives.

After (ACs delta): New AC — output delivered in two formats (text file + HTML file).

Why: Story now enforces the export contract.

Step 8 — Pitch Document

Summary: Refinement loop (not one-shot) + PDF/DOC/HTML exports.

E-35 · prd.md → pipeline YAML → Step 8 detail

Before (delta summary): Executive/investor pitch; includes refined designs + Product Experience motion section.

After (delta summary): Same + "Deck is created, then user gets time to refine — both design (layout, visuals, composition) and content (copy, data points, narrative). Not a one-shot export: user reviews, adjusts, art-directs, iterates until right, then exports."

Why: Walkthrough explicitly added the refinement loop.

E-36 · prd.md → pipeline YAML → Step 8 output (NEW FIELD)

After (new):

Polished user-refined pitch deck exported in PDF (presentation-ready, shareable), DOC (editable, for further refinement outside Quorum), and HTML (web-viewable, linkable).

Why: Walkthrough made the three export formats explicit.

E-37 · prd.md → FR31

Before

FR31: System can produce audience-appropriate pitch or executive narrative outputs.

After

FR31: System produces audience-appropriate pitch or executive narrative outputs — generated, then user refines both design and content (not one-shot), then exported as PDF, DOC, and HTML.

Why: FR encodes both the refinement loop and the three export formats.

E-38 · epics.md → Story 5.7 (Pitch / executive narrative)

Before (title): Story 5.7: Pitch / executive narrative output

After (title): Story 5.7: Pitch / executive narrative output — with refinement and multi-format export

After (ACs delta): New ACs — refinement mode after generation (design + content iteratively); export as PDF + DOC + HTML.

Why: Story now enforces the walkthrough's Step 8 flow.

Step 13 — Portfolio Document (NEW)

Summary: New pipeline step. New FR47. New Epic 9 with three stories. Cross-wiring into revisedPipeline string, UX rail, Journey 1.

E-39 · prd.md → pipeline YAML → NEW Step 13

After (new entry):

step: 13 name: Portfolio document leadAgents: John (PO) + Kinsley (Product Designer) detail: Comprehensive end-to-end process document (problem/hypothesis, discovery insights, concept evolution, design decisions, three-pillar highlights, architecture, build, QA/security, screenshots, metrics, lessons learned). Shows the evolution, not just the result. output: Polished visual process document — HTML, PDF, and Doc.

Why: Step 13 is a new product feature in the walkthrough.

E-40 · prd.md → revisedPipeline string

Before

'...→11(ship)→12(feedback)'

After

'...→11(ship)→12(feedback)→13(portfolio)'

Why: Ordered pipeline string needs Step 13.

E-41 · prd.md → NEW FR47

After (new FR):

FR47: System can produce a Portfolio Document summarizing the end-to-end process the user followed... delivered as HTML, PDF, and Doc. Output shows the evolution, not just the result, and is suitable for portfolio, case-study, or stakeholder-retrospective use.

Why: New pipeline feature needs a first-class FR.

E-42 · ux-design-specification.md → §4.2.1 canonical table

After (new row):

13 | Portfolio document

Why: Rail must show Step 13.

E-43 · ux-design-specification.md → §10.1 Journey 1

After (new final step):

10. Step 13 Portfolio export: After ship + feedback, Maya generates the Portfolio Document... customizes tone and section visibility; exports as HTML / PDF / Doc.

Why: Journey 1 was truncated at step 9; now extends through portfolio.

E-44 · epics.md → NEW Epic 9 with Stories 9.1, 9.2, 9.3

After (new epic): Three stories — Portfolio Document generation, customization (tone/section toggles), and multi-format export (HTML/PDF/Doc).

Why: New FR47 + Step 13 need epic and story coverage.

E-45 · epics.md → FR inventory + FR Coverage Map + Epic list

After (delta):

• FR47 added to functional requirements inventory
• FR Coverage Map row added: FR47 | Epic 9
• Epic List row added: Epic 9: Portfolio document output
• Validation summary updated to FR1–FR47

Why: All index structures must reflect new FR and epic.

Meta / Cross-cutting

E-46 · Genericization of "Figma Make" references

Change: Across UX spec, rail labels previously tied to Figma Make were updated to "generated concepts (tool-agnostic)" to match the walkthrough's direction.

Why: Walkthrough establishes tool agnosticism as a product principle.

E-47 · Step 13 cross-wiring

Change: Step 13 wired through revisedPipeline string (E-40), UX rail table (E-42), Journey 1 (E-43), FR inventory (E-45), and Epic list (E-45).

Why: New step needs coherent representation across all indexes.

E-48 · prd.md → frontmatter keyArtifacts

Before (list): Brief, PRD, executive summary PDF, exports, gen script.

After (delta): Added quorum-pipeline-walkthrough.md (source of truth for pipeline experience design — complements quorumPipeline YAML structural definition) and sprint-change-proposal-2026-04-14.md (walkthrough alignment change log).

Why: Walkthrough is a first-class artifact now; it should be discoverable from the PRD frontmatter.

Personal Build Portfolio (meta-artifact)

E-49 · NEW FILE _bmad-output/james-quorum-build-portfolio.md

After (new): Living document, 9 sections — origin story, BMad setup, custom agents, planning journey, decision log (chronological), design quality review, build phase, lessons learned, acknowledgments. Stubbed skeleton with captured decisions through 2026-04-14.

Why: Distinct from Step 13 (Quorum's feature for its users). This doc is about James building Quorum with BMad.

E-50 · Update cadence documented in the portfolio doc frontmatter

Cadence rule: Append at each meaningful milestone (session wrap, major decision, workflow completion). Never reconstructed after the fact.

Why: A living doc reconstructed at the end loses the texture that makes process documentation valuable.

E-51 · Export plan deferred

Rule: HTML + PDF generation deferred to project-completion-ish. Reuse _gen_prd_exports.py pattern when content stabilizes.

Why: No point building an export script while the document changes weekly.

E-52 · MEMORY.md → Added reference + new memory files

After (delta):

• MEMORY.md — two new lines pointing to project_personal_build_portfolio.md and project_correct_course_2026_04_14.md
• project_personal_build_portfolio.md — new memory file describing the doc's purpose, cadence rule, structure, and how to apply
• project_correct_course_2026_04_14.md — new memory file recording this Correct Course session for future context

Why: Future sessions need to know the portfolio doc exists and must be appended at milestones.

Next steps

1. Re-run implementation-readiness check (bmad-check-implementation-readiness) to verify the updated artifacts pass the readiness gates.
2. Sprint planning (bmad-sprint-planning) against the updated epics.
3. Begin build — Epic 1, Story 1.1 (Application scaffold per architecture) when ready.

End of change log. For the formal Sprint Change Proposal, see sprint-change-proposal-2026-04-14.md. For the source of truth on pipeline experience, see quorum-pipeline-walkthrough.md.