@shaykec/bridge 0.4.24 → 0.4.26

package/modules/solid-principles/quick-ref.md

@@ -0,0 +1,50 @@
+# SOLID Quick Reference
+
+## The Five Principles
+
+| Letter | Principle | One-Liner |
+|--------|-----------|-----------|
+| S | Single Responsibility | One reason to change |
+| O | Open/Closed | Extend, don't modify |
+| L | Liskov Substitution | Subtypes replace base types |
+| I | Interface Segregation | Small, focused interfaces |
+| D | Dependency Inversion | Depend on abstractions |
+
+## SRP — How to Split
+
+| Signal | Action |
+|--------|--------|
+| "And" in class description | Split by responsibility |
+| Multiple axes of change | Separate modules |
+| Unrelated tests | Different concerns |
+
+## OCP — Extension Patterns
+
+| Pattern | Use When |
+|---------|----------|
+| Strategy | Pluggable algorithms |
+| Template Method | Skeleton with hooks |
+| Plugin/Registry | Runtime-extensible |
+
+## LSP — Substitution Checklist
+
+- [ ] Subtype honors base type's contract
+- [ ] No stronger preconditions
+- [ ] No weaker postconditions
+- [ ] No surprising side effects
+
+## ISP — Interface Design
+
+| Bad | Good |
+|-----|------|
+| One big interface | Multiple small interfaces |
+| Implementers add no-ops | Clients depend only on what they use |
+| God interface | Role-specific interfaces |
+
+## DIP — Dependency Direction
+
+```
+High-level ──depends on──> Abstraction <──implements── Low-level
+```
+
+Inject abstractions via constructor; avoid `new` for collaborators.

package/modules/solid-principles/quiz.md

@@ -0,0 +1,102 @@
+# SOLID Quiz
+
+## Question 1
+
+What does the Single Responsibility Principle state?
+
+A) Every function should have one line
+B) A class should have only one reason to change
+C) Every project should have one main file
+D) A module should export one thing
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: SRP means each class/module should have one axis of change — one reason why it might need to be modified. This keeps changes localized and reduces coupling. -->
+
+## Question 2
+
+How does the Open/Closed Principle suggest adding new behavior?
+
+A) By editing existing code
+B) By extending (new classes, plugins) without modifying existing code
+C) By copying the entire module
+D) By using configuration only
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: OCP says software should be open for extension, closed for modification. Add new behavior via new code (inheritance, composition, plugins) rather than editing working code. -->
+
+## Question 3
+
+A Square class extends Rectangle but overrides setWidth to set both width and height. Why is this a Liskov violation?
+
+A) Squares are not rectangles
+B) Code that expects Rectangle's setWidth to only change width will get unexpected behavior
+C) Square is slower
+D) It uses more memory
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: LSP requires subtypes to be substitutable. Callers of Rectangle.setWidth expect only width to change. Square breaks that contract by also changing height, causing subtle bugs. -->
+
+## Question 4
+
+What problem does Interface Segregation address?
+
+A) Too many small interfaces
+B) Clients forced to depend on methods they don't use
+C) Interfaces that are too generic
+D) Slow interface resolution
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: ISP says clients shouldn't depend on interfaces they don't use. Fat interfaces force implementers to add no-op methods and create unnecessary coupling. -->
+
+## Question 5
+
+In Dependency Inversion, what should high-level modules depend on?
+
+A) Low-level modules directly
+B) Abstractions (interfaces)
+C) Concrete implementations
+D) Global singletons
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: DIP says both high-level and low-level modules should depend on abstractions. High-level modules define interfaces; low-level modules implement them. This enables swapping implementations and testing. -->
+
+## Question 6
+
+Which principle most directly enables easy unit testing with mocks?
+
+A) SRP
+B) OCP
+C) LSP
+D) DIP
+
+<!-- ANSWER: D -->
+<!-- EXPLANATION: DIP enables dependency injection. When a class receives its dependencies (e.g., a database or logger) via constructor, you can inject mocks in tests. Without DIP, hard-coded dependencies make testing hard. -->
+
+## Question 7
+
+<!-- VISUAL: matching -->
+
+Match each SOLID letter to its principle name:
+
+A) S → 1) Open/Closed Principle
+B) O → 2) Dependency Inversion Principle
+C) L → 3) Single Responsibility Principle
+D) I → 4) Liskov Substitution Principle
+E) D → 5) Interface Segregation Principle
+
+<!-- ANSWER: A3,B1,C4,D5,E2 -->
+<!-- EXPLANATION: S = Single Responsibility, O = Open/Closed, L = Liskov Substitution, I = Interface Segregation, D = Dependency Inversion. -->
+
+## Question 8
+
+<!-- VISUAL: matching -->
+
+Match each principle to a code example that violates it:
+
+A) SRP violated → 1) A class that both sends emails and formats PDFs
+B) OCP violated → 2) Adding a new payment method by editing the PaymentProcessor class
+C) LSP violated → 3) A Bird subclass that overrides fly() to throw (penguin can't fly)
+D) ISP violated → 4) A Worker interface with eat(), sleep(), and work() — Robot implements work() but must implement no-op eat() and sleep()
+
+<!-- ANSWER: A1,B2,C3,D4 -->
+<!-- EXPLANATION: SRP: one class with multiple unrelated responsibilities (1). OCP: modifying existing class instead of extending (2). LSP: subtype not substitutable (3). ISP: client forced to implement unused methods (4). -->

package/modules/solid-principles/resources.md

@@ -0,0 +1,39 @@
+# SOLID — Resources
+
+## Videos
+
+- [SOLID Principles in 5 Minutes](https://www.youtube.com/watch?v=rtmFCcjEgEw) — Web Dev Simplified. Quick overview.
+- [SOLID Principles — Uncle Bob](https://www.youtube.com/watch?v=TMuno5RZNeE) — Robert Martin explains each principle.
+- [Clean Architecture](https://www.youtube.com/watch?v=o_TH-Y78e4s) — Uncle Bob. SOLID in architecture context.
+
+## Articles and Readings
+
+- [SOLID — Wikipedia](https://en.wikipedia.org/wiki/SOLID) — Overview and history.
+- [Martin Fowler — Refactoring](https://refactoring.com/) — Patterns that align with SOLID.
+- [Dependency Injection Principles](https://martinfowler.com/articles/injection.html) — Fowler on DI and DIP.
+
+## Books
+
+- **Clean Code** by Robert C. Martin — SRP, naming, and more.
+- **Clean Architecture** by Robert C. Martin — SOLID in architecture.
+- **Design Patterns** by Gang of Four — Patterns that support SOLID.
+
+## Tools
+
+- [Dependency injection (TypeScript)](https://www.npmjs.com/package/tsyringe) — Lightweight DI container.
+- [Testing with mocks](https://jestjs.io/docs/mock-functions) — Jest mocks enabled by DIP.
+
+## Podcasts
+
+- [Coding Blocks — SOLID Principles](https://www.codingblocks.net/) — Multi-episode breakdown of each SOLID principle with real code examples.
+- [Software Engineering Radio — SOLID](https://www.se-radio.net/) — Deep discussions on applying SOLID in enterprise codebases.
+
+## Interactive and Visual
+
+- [Refactoring Guru — SOLID](https://refactoring.guru/design-patterns) — Visual examples showing how patterns implement SOLID principles.
+- [SOLID Principles Illustrated](https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898) — Comic-style illustrations of each principle with before/after code.
+
+## Courses
+
+- [Coursera — SOLID Principles (University of Alberta)](https://www.coursera.org/learn/design-patterns) — Free to audit course, first modules cover SOLID foundations.
+- [freeCodeCamp — SOLID Principles Explained](https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/) — Free article with practical JavaScript/TypeScript examples.

package/modules/solid-principles/walkthrough.md

@@ -0,0 +1,84 @@
+# SOLID Walkthrough — Learn by Doing
+
+## Before We Begin
+
+<!-- hint:slides topic="The five SOLID principles: SRP, OCP, LSP, ISP, DIP — what each means, when to apply, and real-world examples" slides="6" -->
+
+SOLID is an acronym for five principles that help design maintainable, flexible systems: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. They're guides, not laws—understanding when to apply them matters more than rigid adherence.
+
+**Diagnostic question:** Think of a class or module you've had to change recently. Did you modify it to add one thing or many? What would have made that change easier or safer?
+
+**Checkpoint:** You can name at least one SOLID principle you've heard of and one situation where design made changes harder.
+
+---
+
+## Step 1: Identifying Responsibility Violations
+
+<!-- hint:diagram mermaid-type="flowchart" topic="Single Responsibility Principle" -->
+<!-- hint:card type="concept" title="SRP: One reason to change" -->
+
+**Task:** Find a class or module in your codebase that does more than one kind of thing (e.g., fetches data, formats it, and sends emails). List each distinct responsibility.
+
+**Question:** What would happen if the email provider API changed? Would you have to touch code that fetches data? What does that tell you about responsibility boundaries?
+
+**Checkpoint:** The user can identify multiple responsibilities and explain why separating them helps.
+
+---
+
+## Step 2: Extracting by SRP
+
+<!-- hint:code language="javascript" highlight="1,5" -->
+
+**Task:** Take the module from Step 1 (or a simplified version). Extract one responsibility into a separate class or module. Ensure the original delegates to it.
+
+**Question:** How did you decide the boundary? Could you have split differently? What would "too granular" look like?
+
+**Checkpoint:** The user has at least one extracted component with a single, clear responsibility.
+
+---
+
+## Step 3: Open/Closed in Practice
+
+<!-- hint:card type="concept" title="Open/Closed: Open for extension, closed for modification" -->
+
+**Task:** Design a small discount calculator. Instead of a big if/else for each discount type, use a strategy-like approach: each discount type is a separate implementation that can be added without editing existing code.
+
+**Question:** What would you need to change to add a "buy 2 get 1 free" discount? Would you edit old code or add new code?
+
+**Checkpoint:** The user has a design where new behavior is added by extension, not modification.
+
+---
+
+## Step 4: Interface Segregation
+
+<!-- hint:card type="concept" title="ISP: Clients shouldn't depend on methods they don't use" -->
+
+**Task:** Imagine an interface with 5 methods. Two different clients each need only 2 of those methods. Split the interface so each client depends only on what it uses.
+
+**Question:** What problems arise when a client is forced to depend on methods it never calls?
+
+**Checkpoint:** The user understands ISP and has created smaller, focused interfaces.
+
+---
+
+## Step 5: Dependency Inversion
+
+<!-- hint:card type="concept" title="DIP: Depend on abstractions, not concretions" -->
+
+**Task:** Take a class that directly instantiates a dependency (e.g., `new HttpClient()`). Refactor so the dependency is injected via the constructor. The class should depend on an interface, not a concrete implementation.
+
+**Question:** How does injection make testing easier? What would you pass in a unit test?
+
+**Checkpoint:** The user can apply DIP with constructor injection and explain testability benefits.
+
+---
+
+## Step 6: Applying Multiple Principles
+
+**Task:** Review a small feature you've built. Apply at least 2 SOLID principles: perhaps SRP (split a mixed class) and DIP (inject a dependency). Describe the before/after.
+
+**Question:** When might strict SOLID adherence be overkill? How do you balance principles with pragmatism?
+
+**Checkpoint:** The user can articulate tradeoffs and apply principles selectively.
+
+<!-- hint:celebrate -->

package/modules/sprint-planning/content.md

@@ -0,0 +1,142 @@
+# Sprint Planning — Estimation, Capacity, and Commitment
+
+<!-- hint:slides topic="Sprint planning: two parts, estimation techniques, velocity vs capacity, Definition of Ready, and common pitfalls" slides="5" -->
+
+## What Is Sprint Planning?
+
+**Sprint planning** is the Scrum ceremony where the team decides what work to do in the upcoming sprint and how to do it. It's a timeboxed event (typically 2–4 hours for a 2-week sprint) that produces two outcomes: a **sprint goal** and a **sprint backlog**.
+
+Scrum defines sprint planning as having two parts:
+
+1. **What** — What can we achieve this sprint? (Product Owner presents the goal; team selects work.)
+2. **How** — How will we build it? (Team plans tasks and approach.)
+
+## The Two Parts of Sprint Planning
+
+| Part | Who Leads | Output |
+|------|-----------|--------|
+| **What** | Product Owner | Sprint goal, selected backlog items |
+| **How** | Development Team | Tasks, breakdown, approach |
+
+The Product Owner explains the objective and proposed backlog items. The Development Team estimates capacity, selects items, and defines how they'll deliver them. The Scrum Master facilitates but doesn't make content decisions.
+
+## The Sprint Goal
+
+A sprint goal is a **single, cohesive objective** for the sprint. It answers: "Why are we doing this work together?"
+
+**Weak:** "Complete user stories from the backlog."
+
+**Strong:** "Enable users to reset their password without calling support."
+
+The sprint goal creates focus. When trade-offs arise during the sprint, the team asks: "Does this support the goal?"
+
+## Estimation Techniques
+
+### Story Points
+
+Story points measure **relative complexity**, not hours. A 3-point story is roughly 1.5× a 2-point story. Teams calibrate over time.
+
+**Fibonacci sequence (common):** 1, 2, 3, 5, 8, 13, 21
+
+Larger numbers = more uncertainty. If a story feels bigger than 13, split it.
+
+### T-Shirt Sizing
+
+Fast, non-numeric: **XS, S, M, L, XL**. Good for backlogs where precise points aren't needed. Map to points later if required (e.g., S=1, M=3, L=5, XL=8).
+
+### Planning Poker
+
+1. Product Owner reads the story.
+2. Everyone privately picks a card (story point value).
+3. Reveal simultaneously.
+4. Discuss outliers—why did someone pick 2 and someone 8?
+5. Re-vote until consensus.
+
+Planning poker surfaces assumptions and promotes conversation. The estimate is a byproduct; the discussion is the value.
+
+## Velocity vs Capacity
+
+| Term | Meaning |
+|------|---------|
+| **Velocity** | Historical throughput—how many points the team typically completes per sprint. Measured *after* the sprint. |
+| **Capacity** | Available person-hours (or person-days) for the sprint. Planned *before* the sprint. |
+
+**Capacity** = Team size × Working days × Hours per day × (1 − % meetings/admin)
+
+**Velocity** = Average points completed over last 2–3 sprints (or team's best guess for new teams).
+
+Use velocity to **forecast** how much work *might* get done. Use capacity to sanity-check that you haven't over-committed.
+
+## Commitment vs Forecast
+
+- **Commitment** — The team commits to the sprint goal. They'll do everything in their power to achieve it. Scope may be adjusted if the goal changes or becomes invalid.
+- **Forecast** — The selected backlog items are a *forecast*, not a promise. The team will rebalance as they learn.
+
+In practice: commit to the *goal*; treat the *product backlog items* as a best-effort forecast.
+
+## Definition of Ready
+
+Items must be **ready** before sprint planning. Definition of Ready (DoR) might include:
+
+- [ ] Clear acceptance criteria
+- [ ] Sized (or at least discussed)
+- [ ] Dependencies identified
+- [ ] Technical feasibility understood
+
+If items aren't ready, the team spends planning time clarifying instead of committing. Define your DoR as a team.
+
+## Sprint Planning Flow
+
+```mermaid
+flowchart TD
+  A[Product Owner presents goal + proposed items] --> B[Team discusses capacity]
+  B --> C[Team selects items for sprint]
+  C --> D[Team breaks down into tasks]
+  D --> E[Sprint goal agreed]
+  E --> F[Sprint backlog complete]
+  F --> G[Sprint starts]
+```
+
+## Common Anti-Patterns
+
+1. **Over-commitment** — Loading the sprint to 100%+ of velocity. Leave buffer for unknowns; 80–90% is often healthier.
+2. **No sprint goal** — A list of unrelated stories with no unifying purpose.
+3. **Estimating in hours** — Hours are precise but mislead; complexity and uncertainty matter more. Story points keep the focus on relative effort.
+4. **Skipping the "how"** — Only selecting stories without tasking. The team discovers blockers mid-sprint.
+5. **Stakeholders dictating scope** — Sprint planning is a team decision. External pressure to "fit more in" undermines ownership.
+
+## Tips for Remote Sprint Planning
+
+- **Async prep:** Share proposed items and context 24–48 hours before. Let people read ahead.
+- **Break into two sessions:** Part 1 (what) and Part 2 (how) on different days if attention wanes.
+- **Use shared boards:** Miro, FigJam, or Jira/Linear so everyone can see and edit.
+- **Timebox rigorously:** 15-min chunks per topic; move on even if not "perfect."
+- **Cameras on for key decisions:** When voting or agreeing the goal, visibility helps.
+- **Document decisions:** Capture sprint goal and key assumptions in a shared doc immediately.
+
+## Sprint Goal Template
+
+```markdown
+## Sprint Goal
+
+**Sprint:** [Sprint X — dates]
+
+**Goal:** [One sentence: what outcome we're aiming for]
+
+**Success looks like:** [2–3 concrete outcomes or demos]
+
+**Out of scope this sprint:** [What we're explicitly NOT doing]
+```
+
+## Capacity Calculation Example
+
+```markdown
+Team: 5 developers, 2-week sprint
+Working days: 10
+Hours per developer per day: 6 (after meetings)
+Meeting/admin overhead: ~15%
+
+Capacity = 5 × 10 × 6 × 0.85 ≈ 255 developer-hours
+```
+
+Use velocity (e.g., 45 points last sprint) to forecast how many points to pull. If capacity is lower (holidays, PTO), pull fewer points.

package/modules/sprint-planning/exercises.md

@@ -0,0 +1,79 @@
+# Sprint Planning — Exercises
+
+## Exercise 1: Write a Sprint Goal
+
+**Task:** Your team is working on a "v2 search" release. The backlog has: basic keyword search, filters, search suggestions, export results, save searches. Write a sprint goal that focuses on one outcome (e.g., "Users can find products by keyword and filter by category") and explicitly excludes 1–2 items.
+
+**Validation:**
+- [ ] Goal is one sentence, outcome-focused
+- [ ] At least one item is explicitly out of scope
+- [ ] Success could be demoed or measured
+
+**Hints:**
+1. "Enable users to..." or "Reduce time to..." are good openings
+2. "Complete X, Y, Z features" is output—rewrite as outcome
+3. Out-of-scope prevents "why didn't we do export?" surprises
+
+---
+
+## Exercise 2: Story Point Calibration
+
+**Task:** You have a "baseline" story: "Add a 'Forgot password' link to the login screen" = 2 points. Estimate these relative to it: (A) "Implement OAuth login with Google," (B) "Add form validation to 5 fields," (C) "Replace legacy auth service with new API." Assign points and explain the ratios.
+
+**Validation:**
+- [ ] Each story has a point value
+- [ ] Ratio to baseline is explained (e.g., "3× the complexity")
+- [ ] Uncertainty is reflected (larger = more unknown)
+
+**Hints:**
+1. OAuth = new integration, multiple flows → 5 or 8
+2. Form validation = repetitive but known → 2 or 3
+3. Replace legacy = high risk, unknowns → 8 or 13
+
+---
+
+## Exercise 3: Capacity vs Velocity
+
+**Task:** Team of 4, 2-week sprint. Each person has 6 productive hours/day. Last 3 sprints: 32, 28, 35 points. Calculate capacity in person-hours. What's average velocity? How many points would you forecast, and why?
+
+**Validation:**
+- [ ] Capacity = 4 × 10 × 6 = 240 person-hours (or similar)
+- [ ] Velocity ≈ 31–32 points
+- [ ] Forecast is justified (e.g., "slightly under velocity for buffer")
+
+**Hints:**
+1. Don't assume 100% utilization
+2. Velocity varies—use average or trend
+3. Consider pulling 85–90% of velocity for safety
+
+---
+
+## Exercise 4: Planning Poker Scenario
+
+**Task:** Run a "mental" planning poker for "Add real-time notifications when a teammate comments on your PR." List 3 reasons someone might vote 2, and 3 reasons someone might vote 8. What discussion would resolve the gap?
+
+**Validation:**
+- [ ] Reasons for low estimate (simplicity, existing infra)
+- [ ] Reasons for high estimate (integration, edge cases, unknowns)
+- [ ] Discussion topics that would align the team
+
+**Hints:**
+1. Low: "We have a notification service already"
+2. High: "Real-time means WebSockets, testing, browser support"
+3. Resolve by: defining "real-time," checking existing systems, splitting scope
+
+---
+
+## Exercise 5: Definition of Ready Checklist
+
+**Task:** Create a 4-item Definition of Ready. Apply it to: "As a user, I want to see my order history, so I can track past purchases." Score each criterion (ready / not ready) and list what's missing.
+
+**Validation:**
+- [ ] DoR has 4 concrete, testable criteria
+- [ ] Each criterion is scored for the story
+- [ ] Gaps are listed with specific next steps
+
+**Hints:**
+1. Example criteria: acceptance criteria, dependencies identified, sized, technically feasible
+2. "Order history" might need: API exists? UI design? Pagination?
+3. Missing = "Need to confirm API contract," "Design not final"

package/modules/sprint-planning/game.yaml

@@ -0,0 +1,84 @@
+games:
+  - type: speed-round
+    title: "Story Point Sprint"
+    rounds:
+      - question: "As a user, I can log in with email and password. (Existing auth; simple form.)"
+        options:
+          - "1"
+          - "2"
+          - "3"
+          - "5"
+        answer: 0
+        timeLimit: 14
+      - question: "As a user, I can export my data to CSV. (New feature; one API, one UI button.)"
+        options:
+          - "1"
+          - "2"
+          - "3"
+          - "5"
+        answer: 1
+        timeLimit: 16
+      - question: "As a user, I can see a dashboard with 5 charts. (New charts; integrate with existing APIs; some UI work.)"
+        options:
+          - "2"
+          - "3"
+          - "5"
+          - "8"
+        answer: 2
+        timeLimit: 16
+      - question: "As a user, I can pay with credit card. (New payment provider integration; PCI considerations; error handling.)"
+        options:
+          - "3"
+          - "5"
+          - "8"
+          - "13"
+        answer: 1
+        timeLimit: 18
+      - question: "As a user, I can reset my password via email. (Standard flow; email service exists.)"
+        options:
+          - "1"
+          - "2"
+          - "3"
+          - "5"
+        answer: 1
+        timeLimit: 14
+      - question: "As a user, I can invite teammates and manage permissions. (New permission model; UI; edge cases.)"
+        options:
+          - "3"
+          - "5"
+          - "8"
+          - "13"
+        answer: 1
+        timeLimit: 18
+      - question: "As a developer, we need to add unit tests for the checkout module. (Module has 8 functions; no tests yet.)"
+        options:
+          - "2"
+          - "3"
+          - "5"
+          - "8"
+        answer: 2
+        timeLimit: 16
+      - question: "As a user, I can search products by name, category, and price range. (New search; backend + filter UI.)"
+        options:
+          - "3"
+          - "5"
+          - "8"
+          - "13"
+        answer: 2
+        timeLimit: 18
+      - question: "As a user, I can change my profile picture. (Image upload; resize; storage integration.)"
+        options:
+          - "2"
+          - "3"
+          - "5"
+          - "8"
+        answer: 1
+        timeLimit: 16
+      - question: "As an admin, I can view audit logs for all user actions with filters and export. (New feature; logging infra exists but not for this.)"
+        options:
+          - "5"
+          - "8"
+          - "13"
+          - "21"
+        answer: 1
+        timeLimit: 18

package/modules/sprint-planning/module.yaml

@@ -0,0 +1,44 @@
+slug: sprint-planning
+title: "Sprint Planning — Estimation, Capacity, and Commitment"
+version: 1.0.0
+description: "Master sprint planning: estimation techniques, velocity vs capacity, commitment vs forecast, and common anti-patterns."
+category: project-management
+tags: [sprint-planning, agile, scrum, estimation, story-points, capacity]
+difficulty: beginner
+
+xp:
+  read: 10
+  walkthrough: 30
+  exercise: 20
+  quiz: 15
+  quiz-perfect-bonus: 10
+  game: 20
+  game-perfect-bonus: 10
+
+time:
+  quick: 5
+  read: 15
+  guided: 45
+
+prerequisites: []
+related: [prioritization-frameworks, risk-management]
+
+triggers:
+  - "How do I run sprint planning?"
+  - "How do I estimate story points?"
+  - "How much work should we commit to in a sprint?"
+  - "What's the difference between velocity and capacity?"
+
+visuals:
+  diagrams: [diagram-flow, diagram-mermaid]
+  quiz-types: [quiz-drag-order, quiz-timed-choice]
+  game-types: [speed-round]
+  slides: true
+
+sources:
+  - url: "https://scrumguides.org"
+    label: "Scrum Guide"
+    type: docs
+  - url: "https://www.mountaingoatsoftware.com"
+    label: "Mountain Goat Software"
+    type: site