@shaykec/bridge 0.4.24 → 0.4.26

package/modules/running-effective-standups/exercises.md

@@ -0,0 +1,79 @@
+# Running Effective Standups — Exercises
+
+## Exercise 1: Diagnose and Fix
+
+**Task:** You join a team whose standup runs 25 minutes. People go person-by-person; the manager asks follow-up questions; problem-solving happens live. Write a diagnosis (what's wrong) and a 3-step fix.
+
+**Validation:**
+- [ ] At least 2 anti-patterns identified
+- [ ] Fix includes a format change and a "take it offline" rule
+- [ ] Fix is specific (e.g., "blockers first, 2 min each")
+
+**Hints:**
+1. Manager asking follow-ups → status report; consider manager observing vs participating
+2. Problem-solving live → "Let's grab X and Y after standup for 15 min"
+3. 25 min → timebox 15, strict; move discussions offline
+
+---
+
+## Exercise 2: Format Comparison
+
+**Task:** For each scenario, recommend a standup format and justify in 1–2 sentences: (A) 6-person colocated team, lots of pairing; (B) 4-person distributed across 3 time zones; (C) 3-person team, mostly independent work.
+
+**Validation:**
+- [ ] Each scenario has a format recommendation
+- [ ] Justification references coordination needs
+- [ ] Async considered where relevant
+
+**Hints:**
+1. Colocated + pairing → walk the board or blockers first; high coordination
+2. Distributed + time zones → async or shortened sync with recorded updates
+3. Small + independent → consider skipping or 2–3×/week
+
+---
+
+## Exercise 3: Async Template
+
+**Task:** Create an async standup template for a Slack channel. Include: what each person posts, format (bullets? emoji?), deadline (e.g., 9am local), and how to escalate a blocker.
+
+**Validation:**
+- [ ] Template has clear fields (yesterday, today, blockers)
+- [ ] Deadline and timezone specified
+- [ ] Blocker escalation path defined
+
+**Hints:**
+1. Keep it short: 1–2 bullets per section
+2. Blockers: "@channel" or DM to lead? Define it
+3. Consider timezone: "9am in your timezone" vs "9am PT"
+
+---
+
+## Exercise 4: Anti-Pattern Role-Play
+
+**Task:** Write a 30-second "bad standup" script where one person delivers a status report instead of a coordination update. Then rewrite it as a 30-second "good" update (same person, same work). What changed?
+
+**Validation:**
+- [ ] Bad script includes status-report language (long list, no asks)
+- [ ] Good script focuses on focus + blockers + coordination
+- [ ] Difference is clear and teachable
+
+**Hints:**
+1. Bad: "I worked on X, Y, Z, then did A, B, and I'm almost done with C..."
+2. Good: "Focus today: finishing the auth merge. Blocked on QA env—can someone from DevOps help? Otherwise I'll pair with Jess on the API."
+3. Good = shorter, has a clear "ask" or "offer"
+
+---
+
+## Exercise 5: Remote Standup Checklist
+
+**Task:** Create a 5-item checklist for running a great remote standup. Each item should be concrete and actionable (e.g., "Cameras on for first 2 minutes").
+
+**Validation:**
+- [ ] 5 items, each actionable
+- [ ] Covers tech (video, audio), facilitation, and engagement
+- [ ] Usable by any facilitator
+
+**Hints:**
+1. Tech: cameras, mute when not speaking, screen share board
+2. Facilitation: timebox, "take it offline" rule
+3. Engagement: rotate facilitator, start with energy ("one word for how you're feeling")

package/modules/running-effective-standups/module.yaml

@@ -0,0 +1,40 @@
+slug: running-effective-standups
+title: "Running Effective Standups — Beyond Status Reports"
+version: 1.0.0
+description: "Transform standups from status reports into coordination events: formats, timeboxing, async options, and anti-patterns."
+category: leadership
+tags: [standups, daily-scrum, meetings, team-lead, communication, agile]
+difficulty: beginner
+
+xp:
+  read: 10
+  walkthrough: 30
+  exercise: 20
+  quiz: 15
+  quiz-perfect-bonus: 10
+
+time:
+  quick: 5
+  read: 10
+  guided: 35
+
+prerequisites: []
+related: [sprint-planning, stakeholder-communication]
+
+triggers:
+  - "How do I run a good standup?"
+  - "Our standups are boring status reports, how do I fix them?"
+  - "Should we do async standups?"
+  - "How long should a standup be?"
+
+visuals:
+  diagrams: [diagram-flow]
+  quiz-types: [quiz-drag-order, quiz-timed-choice]
+  slides: true
+
+sources:
+  - url: "https://scrumguides.org"
+    label: "Scrum Guide"
+    type: docs
+  - label: "Agile Retrospectives by Derby & Larsen"
+    type: book

package/modules/running-effective-standups/quick-ref.md

@@ -0,0 +1,61 @@
+# Running Effective Standups — Quick Reference
+
+## Purpose
+
+**Coordination, not reporting.** Align the team, surface blockers, decide who talks to whom.
+
+## Formats
+
+| Format | How It Works | Best For |
+|--------|--------------|----------|
+| Three questions | What I did, what I'll do, blockers | Traditional Scrum |
+| Walk the board | Column by column, work-focused | Kanban, visual teams |
+| Blockers first | "Anyone blocked?" then optional focus | High-dependency teams |
+| Async | Post by deadline (Slack, doc, video) | Distributed, flex schedules |
+
+## Timeboxing
+
+- **Max 15 minutes** — preferably 10 or less
+- **Take it offline:** "Let's sync on that after standup"
+- Use a timer; when someone drones, gently redirect
+
+## Anti-Patterns
+
+| Avoid | Do Instead |
+|-------|------------|
+| Status report to manager | Facilitate for team; manager observes or skips |
+| Problem-solving in standup | "Grab 2–3 people after" |
+| Running long | Timebox; move discussions offline |
+| Low energy / no one listening | Change format; make it interactive |
+
+## Async Template
+
+```
+Yesterday: [1–2 bullets]
+Today: [1–2 bullets]
+Blockers: [none / describe]
+```
+
+**Tools:** Slack, Loom, Geekbot, Standuply, shared doc.
+
+## Remote Tips
+
+1. Cameras on
+2. Screen share the board
+3. Rotate facilitators
+4. Use chat for follow-ups
+5. Stable video/audio
+
+## When to Skip
+
+- Work is highly independent
+- Team is very small (2–3) and in constant contact
+- No one finds value after trying formats
+
+## Sync vs Async
+
+| Sync | Async |
+|------|-------|
+| Real-time coordination | Flexibility, no meeting |
+| Good for: high coordination | Good for: independent work |
+| Requires same-time availability | Post by deadline |

package/modules/running-effective-standups/quiz.md

@@ -0,0 +1,73 @@
+# Running Effective Standups — Quiz
+
+## Question 1
+
+What is the primary purpose of a daily standup?
+
+A) Report status to the manager
+B) Coordinate the team and surface blockers
+C) Update the backlog
+D) Assign tasks for the day
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Standups are for coordination—helping the team align, surface blockers, and decide who needs to talk to whom. Status reporting to a manager is an anti-pattern that undermines the standup's value. -->
+
+## Question 2
+
+Why do the "three questions" often fail?
+
+A) They're too hard to answer
+B) They encourage monologues and status reporting
+C) They take too long
+D) They don't align with Scrum
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: "What did I do, what will I do, any blockers?" often leads to long recitations of work. People stop listening; the focus shifts from coordination to reporting. Alternative formats (walk the board, blockers first) keep the focus on coordination. -->
+
+## Question 3
+
+What is the recommended maximum time for a standup?
+
+A) 5 minutes
+B) 15 minutes
+C) 30 minutes
+D) 1 hour
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: 15 minutes is the upper bound; many effective teams do 10 or less. If standups run longer, take detailed discussions offline and enforce a strict timebox. -->
+
+## Question 4
+
+When do async standups work best?
+
+A) When the team is colocated
+B) When work is highly independent and schedules are flexible
+C) When there are many blockers
+D) When the manager wants daily updates
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Async works best for distributed teams, flexible schedules, or when work is mostly independent. It saves meeting time but loses real-time discussion—less ideal when lots of coordination is needed. -->
+
+## Question 5
+
+Which is an anti-pattern in standups?
+
+A) Walking the board
+B) Starting with blockers
+C) Problem-solving in the standup
+D) Timeboxing to 15 minutes
+
+<!-- ANSWER: C -->
+<!-- EXPLANATION: Problem-solving in standup turns a short coordination meeting into a long discussion. The fix: "Let's grab 2–3 people and discuss after standup." Keep the standup short; take deep dives offline. -->
+
+## Question 6
+
+When might you skip standup altogether?
+
+A) Never—standup is mandatory in Scrum
+B) When the team is small and in constant contact, or work is low-coordination
+C) When the manager is on vacation
+D) Only on Fridays
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Standup is a tool, not a religion. Skip or reduce frequency when work is highly independent, the team is very small, or no one finds value after trying different formats. -->

package/modules/running-effective-standups/resources.md

@@ -0,0 +1,36 @@
+# Running Effective Standups — Resources
+
+## Official Guides
+
+- [Scrum Guide](https://scrumguides.org) — The Daily Scrum section defines the event and its purpose.
+- [Scrum Guide — Daily Scrum](https://scrumguides.org/scrum-guide.html#daily-scrum) — Direct link to daily scrum.
+
+## Books
+
+- **Agile Retrospectives** by Esther Derby and Diana Larsen — Covers meeting design, including standups; practical facilitation techniques.
+- **Scrum: The Art of Doing Twice the Work in Half the Time** by Jeff Sutherland — Origins of Scrum and daily standups.
+
+## Articles
+
+- [How to Run Effective Daily Standups](https://www.atlassian.com/agile/scrum/ceremonies/daily-standup) — Atlassian. Format options, tips, anti-patterns.
+- [Why Standups Fail](https://www.mountaingoatsoftware.com/blog/why-daily-stand-ups-fail) — Mountain Goat Software. Common pitfalls.
+- [Async Standups: When and How](https://www.fellow.app/blog/async-standup) — Fellow. Async formats and tools.
+- [Walk the Board — An Alternative to Round-Robin Standups](https://www.scrum.org/resources/blog/walk-board) — Scrum.org. Board-based format.
+
+## Tools
+
+- [Geekbot](https://geekbot.com/) — Async standup bot for Slack, MS Teams.
+- [Standuply](https://standuply.com/) — Async standups, surveys, retros.
+- [Loom](https://www.loom.com/) — Quick video updates for async standups.
+- [Miro](https://miro.com/) — Virtual boards for walking the board remotely.
+- [Slack](https://slack.com/) — Threaded async standups with reminders.
+
+## Videos
+
+- [How to Run a Daily Standup](https://www.youtube.com/results?search_query=daily+standup+scrum) — Search for "daily standup scrum" for short explainers.
+- [Engineering Culture](https://www.infoq.com/podcasts/engineering-culture/) — InfoQ podcast; episodes on meetings and team rituals.
+
+## Podcasts
+
+- [Agile for Humans](https://ryanripley.com/agile-for-humans/) — Episodes on standups and ceremonies.
+- [Scrum Master Toolbox](https://www.scrummastertoolbox.com/) — Daily tips from practicing Scrum Masters.

package/modules/running-effective-standups/walkthrough.md

@@ -0,0 +1,76 @@
+# Running Effective Standups Walkthrough — Learn by Doing
+
+## Before We Begin
+
+**Diagnostic:** What is a standup *for*? If the goal were only "share status," would a Slack thread be enough? What does a standup do that async updates can't?
+
+**Checkpoint:** You can name at least one purpose beyond status—e.g., unblocking, alignment, coordination—and why it might need to be *live*.
+
+---
+
+## Step 1: Diagnose Your Current Standup
+
+**Task:** Reflect on your team's current standup (or one you've observed). List 2–3 things that work and 2–3 things that don't. Is it coordination-focused or status-report-focused?
+
+**Question:** What would "success" look like for your standup? How would you know if it's working?
+
+**Checkpoint:** You've identified at least one concrete problem (e.g., "runs 25 minutes," "no one listens," "manager uses it for status").
+
+---
+
+## Step 2: Choose an Alternative Format
+
+<!-- hint:buttons type="single" prompt="Which format puts the work—not the people—at the center?" options="Walk the board,Blockers first,Topic-based,Round-robin" -->
+<!-- hint:list style="cards" -->
+
+**Task:** Pick one alternative format (walk the board, blockers first, or topic-based). Write a 1-paragraph "standup script" explaining how your team would run it: who speaks when, what questions are asked, how long each part takes.
+
+**Question:** What would need to change for this format to work? (Board? Facilitator? Team habits?)
+
+**Checkpoint:** Script is clear enough that someone could run the standup from it.
+
+---
+
+## Step 3: Design a 10-Minute Timebox
+
+**Task:** Design a 10-minute standup agenda. Allocate time per section (e.g., blockers 3 min, walk the board 5 min, wrap 2 min). What's your rule for "we need to discuss this in detail"?
+
+**Question:** What typically causes standups to run over? How does your design prevent that?
+
+**Checkpoint:** Agenda fits in 10 minutes; you have a clear "take it offline" rule.
+
+---
+
+## Step 4: Create an Async Standup Template
+
+<!-- hint:list style="cards" -->
+
+**Task:** Create an async standup template (Slack, doc, or tool of choice). Include: what each person posts, deadline, how blockers are escalated. Write 2–3 sentences on when async would work for your team and when it wouldn't.
+
+**Question:** What would you lose by going async? What would you gain?
+
+**Checkpoint:** Template is complete; trade-offs are articulated.
+
+---
+
+## Step 5: List Anti-Patterns and Fixes
+
+<!-- hint:card type="warning" title="Standup Anti-Patterns" -->
+
+**Task:** List 3 standup anti-patterns you've seen (in your team or elsewhere). For each, write one concrete fix you could try.
+
+**Question:** Why do these anti-patterns persist? What would make the fix stick?
+
+**Checkpoint:** Anti-patterns are specific; fixes are actionable.
+
+---
+
+## Step 6: Redesign Your Standup
+
+<!-- hint:celebrate -->
+
+**Task:** Produce a one-page "Standup Redesign" for your team. Include: format, timebox, roles (who facilitates, who attends), and one experiment to try for the next 2 weeks (e.g., "walk the board instead of round-robin").
+
+**Question:** How will you know if the redesign worked? What would cause you to revert?
+
+**Checkpoint:** Redesign is practical and includes a testable experiment.

package/modules/solid-principles/content.md

@@ -0,0 +1,154 @@
+# SOLID Principles — Writing Code That Survives Change
+
+SOLID is five principles for object-oriented design that make software more maintainable and extensible.
+
+```mermaid
+mindmap
+  root((SOLID))
+    S
+      Single Responsibility
+    O
+      Open/Closed
+    L
+      Liskov Substitution
+    I
+      Interface Segregation
+    D
+      Dependency Inversion
+```
+
+## S — Single Responsibility Principle (SRP)
+
+**A class should have only one reason to change.**
+
+Each module should own one axis of change. Mixing concerns (e.g., validation + persistence + formatting) means any change to one affects the others.
+
+**Before:**
+```typescript
+class UserService {
+  validate(user: User) { /* ... */ }
+  save(user: User) { /* ... */ }
+  sendWelcomeEmail(user: User) { /* ... */ }
+}
+```
+
+**After:**
+```typescript
+class UserValidator { validate(user: User) { /* ... */ } }
+class UserRepository { save(user: User) { /* ... */ } }
+class EmailNotifier { sendWelcome(user: User) { /* ... */ } }
+```
+
+## O — Open/Closed Principle (OCP)
+
+**Software should be open for extension, closed for modification.**
+
+Add behavior via new code (inheritance, composition, plugins), not by editing existing code.
+
+**Before:** Adding a new shape requires editing a central function.
+```typescript
+function area(shape: any) {
+  if (shape.type === 'circle') return Math.PI * shape.r ** 2;
+  if (shape.type === 'rect') return shape.w * shape.h;
+  // Must edit here for each new shape
+}
+```
+
+**After:** Each shape extends behavior without changing others.
+```typescript
+interface Shape { area(): number; }
+class Circle implements Shape { area() { return Math.PI * this.r ** 2; } }
+class Rect implements Shape { area() { return this.w * this.h; } }
+```
+
+## L — Liskov Substitution Principle (LSP)
+
+**Subtypes must be substitutable for their base types.**
+
+If `B` extends `A`, any code that expects `A` should work with `B` without surprises. Don't weaken preconditions or strengthen postconditions.
+
+**Violation:**
+```typescript
+class Rectangle { setWidth(w: number) { this.w = w; } setHeight(h: number) { this.h = h; } }
+class Square extends Rectangle {
+  setWidth(w: number) { this.w = this.h = w; }  // Surprise: changes both!
+  setHeight(h: number) { this.w = this.h = h; }
+}
+// Code expecting Rectangle gets unexpected behavior
+```
+
+**Better:** Don't make Square extend Rectangle if it can't honor the contract.
+
+## I — Interface Segregation Principle (ISP)
+
+**Clients should not depend on interfaces they don't use.**
+
+Prefer small, focused interfaces over large "god" interfaces. Fat interfaces force implementers to add no-op methods.
+
+**Before:**
+```typescript
+interface Worker {
+  work(): void;
+  eat(): void;
+  sleep(): void;
+}
+class Robot implements Worker {
+  work() { /* ... */ }
+  eat() { /* no-op */ }   // Robot doesn't eat
+  sleep() { /* no-op */ } // Robot doesn't sleep
+}
+```
+
+**After:**
+```typescript
+interface Workable { work(): void; }
+interface Eatable { eat(): void; }
+class Robot implements Workable { work() { /* ... */ } }
+class Human implements Workable, Eatable { work() { /* ... */ } eat() { /* ... */ } }
+```
+
+## D — Dependency Inversion Principle (DIP)
+
+**Depend on abstractions, not concretions.**
+
+High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces).
+
+```mermaid
+flowchart TB
+    subgraph Bad
+        A1[OrderService] -->|depends on| B1[MySqlDatabase]
+    end
+    subgraph Good
+        A2[OrderService] -->|depends on| I[Database Interface]
+        B2[MySqlDatabase] -->|implements| I
+        B3[PostgresDatabase] -->|implements| I
+    end
+```
+
+**Before:** OrderService directly uses MySqlDatabase.
+```typescript
+class OrderService {
+  private db = new MySqlDatabase();
+  save(order: Order) { this.db.insert('orders', order); }
+}
+```
+
+**After:** Both depend on an abstraction.
+```typescript
+interface Database { insert(table: string, data: object): void; }
+class OrderService {
+  constructor(private db: Database) {}
+  save(order: Order) { this.db.insert('orders', order); }
+}
+// Inject MySqlDatabase or PostgresDatabase at runtime
+```
+
+## Summary
+
+| Principle | One-Liner |
+|-----------|-----------|
+| SRP | One reason to change |
+| OCP | Extend, don't modify |
+| LSP | Subtypes replace base types |
+| ISP | Small interfaces |
+| DIP | Depend on abstractions |

package/modules/solid-principles/exercises.md

@@ -0,0 +1,107 @@
+# SOLID Exercises
+
+## Exercise 1: SRP — Split the User Module
+
+**Task:** This class does validation, persistence, and notification. Split it into 3 classes (Validator, Repository, Notifier) and have a service orchestrate them.
+
+```typescript
+class UserService {
+  createUser(data: any) {
+    if (!data.email?.includes('@')) throw new Error('Invalid email');
+    const user = { id: generateId(), ...data };
+    db.save('users', user);
+    emailService.send(user.email, 'Welcome!');
+    return user;
+  }
+}
+```
+
+**Validation:**
+- [ ] At least 3 focused classes
+- [ ] Service orchestrates, doesn't implement validation/DB/email
+- [ ] Each class has one clear responsibility
+
+**Hints:**
+1. UserValidator.validate(data) throws or returns
+2. UserRepository.save(user)
+3. EmailNotifier.sendWelcome(email)
+4. UserService.createUser calls all three
+
+---
+
+## Exercise 2: OCP — Pluggable Exporters
+
+**Task:** You have a Report class that exports to CSV. Add JSON and XML export without modifying the Report class. Use a strategy/exporter interface.
+
+**Validation:**
+- [ ] New exporters added without changing Report
+- [ ] Report depends on an exporter interface
+- [ ] At least 2 exporter implementations
+
+**Hints:**
+1. interface Exporter { export(data: Data): string }
+2. class CsvExporter implements Exporter
+3. class JsonExporter implements Exporter
+4. Report receives Exporter in constructor
+
+---
+
+## Exercise 3: LSP — Fix the Violation
+
+**Task:** This violates LSP. Redesign so Bird subtypes are substitutable, or explain why a different hierarchy is better.
+
+```typescript
+class Bird { fly() { console.log('Flying'); } }
+class Sparrow extends Bird { }
+class Penguin extends Bird { fly() { throw new Error("Can't fly"); } }
+```
+
+**Validation:**
+- [ ] No subtype surprises callers of the base
+- [ ] Either fix hierarchy or use composition
+
+**Hints:**
+1. Penguin shouldn't extend Bird if Bird guarantees fly()
+2. Consider: FlyingBird vs Bird, or Bird has optional fly capability
+3. Composition: Bird has FlyBehavior (strategy)
+
+---
+
+## Exercise 4: ISP — Segregate the Interface
+
+**Task:** This interface forces printers to implement scan/fax. Split it so a simple printer only implements print.
+
+```typescript
+interface Machine {
+  print(doc: string): void;
+  scan(doc: string): void;
+  fax(doc: string): void;
+}
+```
+
+**Validation:**
+- [ ] At least Printer, Scanner, Faxer (or combined) interfaces
+- [ ] SimplePrinter implements only Printer
+- [ ] No no-op methods required
+
+**Hints:**
+1. interface Printer { print(doc: string): void }
+2. interface Scanner { scan(doc: string): void }
+3. MultiFunctionDevice implements both
+4. SimplePrinter implements Printer only
+
+---
+
+## Exercise 5: DIP — Inject the Logger
+
+**Task:** Refactor OrderProcessor to receive its logger via constructor. Define a Logger interface. Create ConsoleLogger and MockLogger implementations.
+
+**Validation:**
+- [ ] OrderProcessor depends on Logger interface
+- [ ] Logger injected in constructor
+- [ ] Easy to test with MockLogger
+
+**Hints:**
+1. interface Logger { log(msg: string): void }
+2. constructor(private logger: Logger)
+3. MockLogger stores messages for assertions

package/modules/solid-principles/module.yaml

@@ -0,0 +1,42 @@
+slug: solid-principles
+title: "SOLID Principles — Writing Code That Survives Change"
+version: 1.0.0
+description: "Master the five SOLID principles for maintainable, extensible object-oriented design."
+category: fundamentals
+tags: [solid, object-oriented, design-principles, clean-code, architecture]
+difficulty: intermediate
+
+xp:
+  read: 15
+  walkthrough: 40
+  exercise: 25
+  quiz: 20
+  quiz-perfect-bonus: 10
+
+time:
+  quick: 5
+  read: 20
+  guided: 50
+
+prerequisites: [clean-code]
+related: [design-patterns, api-design]
+
+triggers:
+  - "What are the SOLID principles?"
+  - "What is the Single Responsibility Principle?"
+  - "How do I write maintainable code?"
+  - "What is dependency inversion?"
+
+visuals:
+  diagrams: [diagram-mermaid, diagram-flow]
+  quiz-types: [quiz-matching, quiz-timed-choice]
+  playground: javascript
+  slides: true
+
+sources:
+  - url: "https://martinfowler.com"
+    label: "Martin Fowler's Blog"
+    type: docs
+  - url: "https://www.oreilly.com/library/view/clean-code-a/9780136083238/"
+    label: "Clean Code by Robert Martin"
+    type: docs