@shaykec/bridge 0.4.25 → 0.4.26

package/modules/clean-code/workshop.yaml

@@ -0,0 +1,149 @@
+scenarios:
+  - id: naming-refactor
+    title: "Fix Bad Variable and Function Names"
+    difficulty: beginner
+    xp: 25
+    setup:
+      - "mkdir -p workshop && cd workshop"
+    files:
+      - name: utils.js
+        content: |
+          function d(x) {
+            return x * 2;
+          }
+          function t(a, b) {
+            return a + b;
+          }
+          let a = [1, 2, 3];
+          let r = a.map(i => i * 3);
+          let m = r.reduce((p, c) => p + c, 0);
+          module.exports = { d, t };
+        language: javascript
+        readonly: false
+    task: "Rename all variables and functions to be meaningful and self-documenting. A reader should understand what the code does from names alone."
+    validations:
+      - label: "utils.js was refactored with clear names"
+        check: file-changed
+        pattern: "utils.js"
+    hints:
+      - "What does 'd' do? What would you call a function that doubles a number?"
+      - "Consider: inputValue, doubledValue, numbers, tripledNumbers, sum."
+      - "Names like double, add, numbers, tripledNumbers, total improve readability."
+    agent_prompts:
+      on_start: "When you look at this code, what story do the names tell? What would a new teammate guess each function does?"
+
+  - id: extract-functions
+    title: "Extract a Long Function into Smaller Ones"
+    difficulty: intermediate
+    xp: 30
+    setup:
+      - "mkdir -p workshop && cd workshop"
+    files:
+      - name: processOrder.js
+        content: |
+          function processOrder(order) {
+            if (!order || typeof order !== 'object') {
+              throw new Error('Invalid order');
+            }
+            if (!order.items || !Array.isArray(order.items) || order.items.length === 0) {
+              throw new Error('Order must have at least one item');
+            }
+            if (!order.customerId || typeof order.customerId !== 'string') {
+              throw new Error('Valid customerId required');
+            }
+            let subtotal = 0;
+            for (const item of order.items) {
+              if (!item.price || !item.quantity || item.quantity < 1) {
+                throw new Error('Each item must have price and quantity >= 1');
+              }
+              subtotal += item.price * item.quantity;
+            }
+            const taxRate = 0.08;
+            const tax = subtotal * taxRate;
+            const total = subtotal + tax;
+            const summary = `Order for customer ${order.customerId}: ${order.items.length} items, subtotal $${subtotal.toFixed(2)}, tax $${tax.toFixed(2)}, total $${total.toFixed(2)}`;
+            return { subtotal, tax, total, summary };
+          }
+          module.exports = { processOrder };
+        language: javascript
+        readonly: false
+    task: "Break this 40-line function into 4-5 smaller, focused functions. Each function should do one thing. The main processOrder should orchestrate them."
+    validations:
+      - label: "processOrder.js was refactored into smaller functions"
+        check: file-changed
+        pattern: "processOrder.js"
+    hints:
+      - "Can you identify distinct responsibilities? Validation, calculation, formatting are often separate."
+      - "Functions like validateOrder, calculateSubtotal, calculateTax, formatSummary could each handle one concern."
+      - "The main function becomes a sequence of calls—easier to read and test."
+    agent_prompts:
+      on_start: "What different jobs does this function perform? How might splitting them make the code easier to reason about and test?"
+
+  - id: remove-duplication
+    title: "Apply DRY—Remove Duplication in Handlers"
+    difficulty: intermediate
+    xp: 35
+    setup:
+      - "mkdir -p workshop && cd workshop"
+    files:
+      - name: handlers.js
+        content: |
+          function handleCreate(req, res) {
+            const body = JSON.parse(req.body || '{}');
+            if (!body.name || typeof body.name !== 'string') {
+              res.status(400).json({ error: 'Name is required' });
+              return;
+            }
+            const trimmed = body.name.trim();
+            if (trimmed.length === 0) {
+              res.status(400).json({ error: 'Name cannot be empty' });
+              return;
+            }
+            const item = { id: Date.now(), name: trimmed };
+            res.status(201).json(item);
+          }
+
+          function handleUpdate(req, res) {
+            const body = JSON.parse(req.body || '{}');
+            if (!body.name || typeof body.name !== 'string') {
+              res.status(400).json({ error: 'Name is required' });
+              return;
+            }
+            const trimmed = body.name.trim();
+            if (trimmed.length === 0) {
+              res.status(400).json({ error: 'Name cannot be empty' });
+              return;
+            }
+            const item = { id: req.params.id, name: trimmed };
+            res.status(200).json(item);
+          }
+
+          function handlePatch(req, res) {
+            const body = JSON.parse(req.body || '{}');
+            if (!body.name || typeof body.name !== 'string') {
+              res.status(400).json({ error: 'Name is required' });
+              return;
+            }
+            const trimmed = body.name.trim();
+            if (trimmed.length === 0) {
+              res.status(400).json({ error: 'Name cannot be empty' });
+              return;
+            }
+            const item = { id: req.params.id, name: trimmed };
+            res.status(200).json(item);
+          }
+
+          module.exports = { handleCreate, handleUpdate, handlePatch };
+        language: javascript
+        readonly: false
+    task: "Extract the shared validation and logic. The three handlers have nearly identical validation and trimming. Create a helper and reduce duplication."
+    validations:
+      - label: "handlers.js was refactored to remove duplication"
+        check: file-changed
+        pattern: "handlers.js"
+    hints:
+      - "What lines appear in all three handlers? Validation and trimming are identical."
+      - "A function like parseAndValidateName(body) could return { valid, error, name }."
+      - "Each handler would call the helper and branch on valid/invalid—one place to fix validation bugs."
+    agent_prompts:
+      on_start: "If the product owner changes the rules for a valid name, how many places would you update today? What would make that number smaller?"

package/modules/code-review/content.md

@@ -0,0 +1,130 @@
+# Code Review — Giving and Receiving Feedback
+
+<!-- hint:slides topic="Code review: review checklist (correctness, readability, security), giving constructive feedback, and PR lifecycle" slides="5" -->
+
+## Why Code Reviews Matter
+
+Code review is a process where someone other than the author examines code before it merges. It catches bugs, improves design, spreads knowledge, and upholds team standards. Reviews are about the code, not the person.
+
+## What to Look For
+
+### Correctness
+Does the code do what it claims? Are edge cases handled? Could it fail in production?
+
+### Readability
+- **Naming:** Clear, consistent variable and function names
+- **Comments:** Explain *why*, not *what*
+- **Structure:** Logic flows naturally; no magic numbers or deep nesting
+
+### Performance
+- Unnecessary loops or allocations?
+- O(n²) when O(n) is possible?
+- Blocking calls in hot paths?
+
+### Security
+- Input validation and sanitization
+- No hardcoded secrets or credentials
+- Sensitive data handling
+
+```javascript
+// ❌ Security risk: SQL injection
+const query = `SELECT * FROM users WHERE id = ${userId}`;
+
+// ✅ Parameterized query
+const query = 'SELECT * FROM users WHERE id = ?';
+db.execute(query, [userId]);
+```
+
+## Writing Good PR Descriptions
+
+A good description explains **what**, **why**, and **how**:
+
+```markdown
+## What
+Add user profile export as JSON.
+
+## Why
+Product needs GDPR "data portability" compliance by Q2.
+
+## How
+- New `/api/me/export` endpoint
+- Uses existing serialization layer
+- Rate-limited to 1 req/min per user
+```
+
+Include testing notes, screenshots for UI changes, and migration steps when relevant.
+
+## Giving Feedback
+
+### Be Specific
+❌ "This is wrong."  
+✅ "This loop runs O(n²) when the input can be large; consider a Map for O(n) lookups."
+
+### Explain Why
+❌ "Use `const` here."  
+✅ "Using `const` here prevents accidental reassignment and signals immutability to readers."
+
+### Suggest Alternatives
+❌ "Refactor this."  
+✅ "This function is doing three things. Consider extracting validation and formatting into separate helpers."
+
+### Separate Nitpicks
+Mark minor preferences as "nit:" so authors can address them without blocking merge.
+
+## Receiving Feedback
+
+### Don't Take It Personally
+Feedback targets the code, not you. Even senior engineers get thorough reviews.
+
+### Ask Questions
+If a suggestion is unclear, ask: "Can you elaborate on why X would be better here?"
+
+### Disagree Thoughtfully
+It's OK to push back. Explain your reasoning: "I considered X, but chose Y because..."
+
+## Review Checklists
+
+**Before submitting:**
+- [ ] Tests pass locally
+- [ ] PR description is complete
+- [ ] No debug logs or commented code
+- [ ] Changes are scoped to the stated goal
+
+**When reviewing:**
+- [ ] Understand the goal before reading code
+- [ ] Check tests cover the new behavior
+- [ ] Verify no regressions introduced
+- [ ] Approve or request changes promptly
+
+## Common Anti-Patterns
+
+| Anti-Pattern | Problem |
+|--------------|---------|
+| "LGTM" without reading | Rubber-stamping; defeats the purpose |
+| Nitpicking style only | Misses design and correctness |
+| Blocking on opinions | Distinguish "must fix" vs "nice to have" |
+| Delayed feedback | Blocks the author's flow |
+| Dismissive tone | "Obviously wrong" → demoralizes |
+
+## PR Lifecycle
+
+```mermaid
+flowchart TD
+    A[Author writes code] --> B[Author creates PR]
+    B --> C[Reviewer(s) assigned]
+    C --> D{Review passes?}
+    D -->|No| E[Author addresses feedback]
+    E --> C
+    D -->|Yes| F[Approve & merge]
+    F --> G[Post-merge: monitor, document]
+```
+
+---
+
+## Key Takeaways
+
+1. **Correctness first** — then readability, performance, security
+2. **Specific, kind feedback** — explain why, suggest alternatives
+3. **Separate blocking vs nitpicks** — unblock quickly when possible
+4. **PR descriptions matter** — context speeds reviews
+5. **Reviews are for the code** — keep feedback professional and constructive

package/modules/code-review/exercises.md

@@ -0,0 +1,95 @@
+# Code Review Exercises
+
+## Exercise 1: Write a PR Description
+
+**Task:** Create a PR description for a hypothetical change: "Add input validation to the login form to reject empty username and password."
+
+**Validation:**
+- [ ] Contains "What" section describing the change
+- [ ] Contains "Why" section explaining the rationale
+- [ ] Contains "How" section with implementation notes
+- [ ] Includes at least one testing note
+
+**Hints:**
+1. What = the concrete change (validation logic, error messages)
+2. Why = security, UX, or compliance reason
+3. How = where validation runs, what gets validated
+
+---
+
+## Exercise 2: Transform Vague Feedback
+
+**Task:** A reviewer wrote: "This could be better." The code in question uses a nested `for` loop to find duplicates in an array. Rewrite this as specific, constructive feedback with a suggested alternative.
+
+**Validation:**
+- [ ] Identifies the specific issue (e.g., O(n²) complexity)
+- [ ] Explains why it matters (performance, scalability)
+- [ ] Suggests an alternative (e.g., Set, Map, or sort-then-compare)
+
+**Hints:**
+1. Vague feedback leaves the author guessing — be concrete
+2. Explain the tradeoff (nested loops vs Set.has)
+3. A code snippet or pseudocode helps
+
+---
+
+## Exercise 3: Prioritize Review Comments
+
+**Task:** You received these five comments on a PR. Order them by priority (highest first) and label each: blocking, should-fix, or nit.
+
+- "Use `const` instead of `let` for `config`"
+- "The password is echoed in logs on line 89"
+- "Consider extracting this into a helper function"
+- "Possible race condition: two requests could overwrite the same file"
+- "Typo: 'recieve' → 'receive'"
+
+**Validation:**
+- [ ] Security issue (password in logs) is highest or second-highest
+- [ ] Race condition is blocking or should-fix
+- [ ] Style (const, extract helper) is nit or lower priority
+- [ ] Typo is nit
+
+**Hints:**
+1. Security and correctness trump style
+2. Race conditions can cause data loss — treat seriously
+3. Nits improve quality but don't block merge
+
+---
+
+## Exercise 4: Respond to Critical Feedback
+
+**Task:** A senior reviewer wrote: "This approach won't scale. We'll have thousands of users and this does a full table scan per request." Your implementation uses `SELECT * FROM users WHERE ...` without an index.
+
+Write a constructive response (2–4 sentences) that:
+1. Acknowledges the concern
+2. Shows you understand the problem
+3. Proposes or asks about a fix (index, caching, or different query)
+
+**Validation:**
+- [ ] No defensive tone ("it works for now")
+- [ ] Demonstrates understanding of the scalability issue
+- [ ] Proposes a concrete next step or asks for guidance
+
+**Hints:**
+1. "You're right" or "Good catch" shows receptiveness
+2. Indexes, caching, or pagination are common fixes
+3. Asking "Should I add an index on X?" is collaborative
+
+---
+
+## Exercise 5: Create a Review Checklist
+
+**Task:** Build a 6-item checklist for code reviews you perform. Include at least one item from each category: correctness, readability, security, tests, and process.
+
+**Validation:**
+- [ ] At least 6 items
+- [ ] Covers correctness (e.g., edge cases, error handling)
+- [ ] Covers readability (naming, structure)
+- [ ] Covers security (inputs, secrets)
+- [ ] Covers tests (new code has tests)
+- [ ] Covers process (PR description, scope)
+
+**Hints:**
+1. "Does the PR description explain the goal?" is a good process item
+2. "Are new code paths covered by tests?" ensures quality
+3. "Any hardcoded secrets or credentials?" is a security staple

package/modules/code-review/game.yaml

@@ -0,0 +1,83 @@
+games:
+  - type: scenario
+    title: "PR Review Crisis"
+    startHealth: 5
+    steps:
+      - id: start
+        situation: "A teammate opens a 2,000-line PR that touches auth, DB migrations, and 12 files. It's Friday afternoon. You're asked to review. How do you prioritize?"
+        choices:
+          - text: "Triage: skim for high-risk areas (auth, migrations, security), then focus feedback there first."
+            consequence: "Smart. You use risk to prioritize. Auth and migrations deserve careful review; trivial changes can wait."
+            health: 1
+            next: tone
+          - text: "Review every line from top to bottom."
+            consequence: "Thorough but inefficient. A 2000-line PR in one sitting leads to fatigue and missed issues."
+            health: -1
+            next: tone
+          - text: "Approve quickly and say you'll do a deeper pass later."
+            consequence: "Approving without proper review risks merging bugs. Later rarely happens."
+            health: -2
+            next: bad_choice
+      - id: tone
+        situation: "You find a security issue: the new auth path doesn't validate the redirect URL, enabling open redirect. How do you phrase the feedback?"
+        choices:
+          - text: "I noticed the redirect URL isn't validated — could lead to open redirect. Suggest we add a allowlist check."
+            consequence: "Constructive and specific. You state the problem and a concrete fix. Professional tone."
+            health: 1
+            next: disagreement
+          - text: "This is a security hole. Why wasn't this caught before?"
+            consequence: "Accusatory. The author may get defensive. Security matters, but tone affects collaboration."
+            health: -1
+            next: disagreement
+          - text: "LGTM with minor comments."
+            consequence: "Open redirect is not minor. Undermining serious feedback can let bugs slip through."
+            health: -2
+            next: bad_choice
+      - id: disagreement
+        situation: "The author disagrees with your feedback. They say the redirect is 'internal only' and low risk. You believe it's still exploitable. What do you do?"
+        choices:
+          - text: "Share a minimal exploit or reference (e.g. OWASP) and suggest discussing in a call if needed."
+            consequence: "Evidence-based. You back your point with data. Opens constructive discussion."
+            health: 1
+            next: approve_decision
+          - text: "Insist they fix it or you won't approve."
+            consequence: "Standing firm can be right, but escalating without evidence may create friction."
+            health: 0
+            next: approve_decision
+          - text: "Drop it and approve — they own the code."
+            consequence: "Security issues shouldn't be dropped for ownership. You're responsible too as reviewer."
+            health: -2
+            next: bad_choice
+      - id: approve_decision
+        situation: "The author fixed the redirect issue. You've reviewed the high-risk areas. The PR also has some style nitpicks and a few unclear variable names. Do you approve or request changes?"
+        choices:
+          - text: "Approve with a short list of non-blocking suggestions (style, naming) for follow-up."
+            consequence: "Pragmatic. You unblock the author while capturing improvement ideas. Ship and iterate."
+            health: 1
+            next: success
+          - text: "Request changes — insist on fixing every nit before merge."
+            consequence: "Perfectionism can block progress. Critical fixes yes; style nits can be follow-up."
+            health: -1
+            next: success
+          - text: "Approve without any other feedback."
+            consequence: "You could have added value with non-blocking suggestions. Missed a teaching moment."
+            health: 0
+            next: success
+      - id: bad_choice
+        situation: "That choice didn't serve the team. PR review should be constructive, risk-aware, and collaborative. Try to recover."
+        choices:
+          - text: "Restart with a better approach."
+            consequence: "Every review is a chance to improve."
+            health: 0
+            next: start
+          - text: "Accept the consequences."
+            consequence: "Sometimes we learn the hard way."
+            health: 0
+            next: end
+      - id: success
+        situation: "The PR is merged. You provided focused, constructive feedback. The author appreciated the security catch. Well done!"
+        choices:
+          - text: "Continue."
+            consequence: "You navigated the PR review crisis successfully."
+            health: 0
+            next: end

package/modules/code-review/module.yaml

@@ -0,0 +1,42 @@
+slug: code-review
+title: "Code Review — Giving and Receiving Feedback"
+version: 1.0.0
+description: "Master code reviews — what to look for, how to give feedback, and how to receive it constructively."
+category: developer-skills
+tags: [code-review, feedback, collaboration, pull-requests, quality]
+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: 40
+
+prerequisites: []
+related: [clean-code, technical-debt]
+
+triggers:
+  - "How do I do a good code review?"
+  - "How do I give constructive code feedback?"
+  - "What should I look for in a code review?"
+  - "How do I handle code review comments?"
+
+visuals:
+  diagrams: [diagram-flow]
+  quiz-types: [quiz-drag-order, quiz-timed-choice]
+  game-types: [scenario]
+  playground: null
+  slides: true
+
+sources:
+  - url: "https://google.github.io/eng-practices/review/"
+    label: "Google's Engineering Practices (Code Review)"
+    type: docs

package/modules/code-review/quick-ref.md

@@ -0,0 +1,77 @@
+# Code Review Quick Reference
+
+## What to Look For
+
+| Area | Questions to Ask |
+|------|------------------|
+| Correctness | Does it work? Edge cases? Error handling? |
+| Readability | Clear names? Comments explain why? Logic easy to follow? |
+| Performance | Unnecessary work? Scalability concerns? |
+| Security | Input validated? No secrets in code? Sensitive data handled safely? |
+| Tests | New behavior covered? Regressions prevented? |
+
+## Giving Feedback
+
+| Do | Don't |
+|----|-------|
+| Be specific ("Rename `x` to `userCount`") | Be vague ("This could be better") |
+| Explain why ("Prevents accidental reassignment") | Assume they know |
+| Suggest alternatives | Only criticize |
+| Mark nits as "nit:" | Block on style preferences |
+| Respond promptly | Let PRs sit for days |
+
+## PR Description Template
+
+```markdown
+## What
+[One-line summary of the change]
+
+## Why
+[Problem being solved, ticket, compliance]
+
+## How
+[Key implementation notes, tradeoffs]
+
+## Testing
+[How you tested, what to verify]
+```
+
+## Receiving Feedback
+
+| Do | Don't |
+|----|-------|
+| Assume good intent | Take it personally |
+| Ask clarifying questions | Get defensive |
+| Disagree with reasoning | Dismiss without discussion |
+| Thank reviewers | Ignore nits rudely |
+
+## Priority Levels
+
+| Level | Meaning | Action |
+|-------|---------|--------|
+| Blocking | Must fix before merge | Address before approval |
+| Should fix | Important but not blocking | Fix if quick; otherwise follow up |
+| Nit | Nice to have | Optional; author decides |
+
+## Common Anti-Patterns
+
+| Anti-Pattern | Fix |
+|--------------|-----|
+| "LGTM" without reading | Actually read and verify |
+| Blocking on opinions | Distinguish must vs nice-to-have |
+| Delayed feedback | Review within 24h when possible |
+| Dismissive tone | Be kind and professional |
+
+## Checklist: Before Submitting PR
+
+- [ ] Tests pass
+- [ ] Description complete (What/Why/How)
+- [ ] No debug logs or commented code
+- [ ] Changes scoped to stated goal
+
+## Checklist: When Reviewing
+
+- [ ] Read description first
+- [ ] Verify tests cover new behavior
+- [ ] Check for regressions
+- [ ] Approve or request changes promptly

package/modules/code-review/quiz.md

@@ -0,0 +1,105 @@
+# Code Review Quiz
+
+## Question 1
+
+What should you prioritize when reviewing code?
+
+A) Style and formatting first
+B) Correctness, then readability, performance, security
+C) Whatever the author asks you to look at
+D) Only security issues
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Correctness is the foundation — does it work? Then readability (can others maintain it?), performance (will it scale?), and security (is it safe?). Style matters but shouldn't block merge for minor nits. -->
+
+## Question 2
+
+A reviewer wrote: "Use a better variable name." What's wrong with this feedback?
+
+A) Nothing — it's clear enough
+B) It's too vague; the author doesn't know what to change or why
+C) Reviewers shouldn't comment on variable names
+D) It should be marked as blocking
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Good feedback is specific and explains why. "Use a better variable name" doesn't say which variable or what "better" means. Something like "Rename `x` to `userCount` for clarity" is actionable. -->
+
+## Question 3
+
+You're about to merge a PR. The tests pass, but you noticed a potential null reference when `data` is undefined. What should you do?
+
+A) Merge anyway — tests pass
+B) Request changes and block merge until it's fixed
+C) Merge and file a follow-up bug
+D) Leave a nit comment and merge
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Potential null references can cause runtime crashes. If tests pass but don't cover the null case, that's a gap. Blocking merge prevents shipping a bug. Nits are style preferences; correctness issues are blocking. -->
+
+## Question 4
+
+Which PR description is most useful for reviewers?
+
+A) "Fixed the bug"
+B) "Updated validation logic per ticket #123"
+C) "What: Add login validation. Why: Prevent empty submissions. How: Client-side check before API call; server re-validates."
+D) "See the code"
+
+<!-- ANSWER: C -->
+<!-- EXPLANATION: A good description explains What (the change), Why (the reason), and How (implementation notes). This gives reviewers context to verify the approach and spot issues. Vague descriptions slow reviews. -->
+
+## Question 5
+
+When receiving critical feedback, what's the most constructive response?
+
+A) "I'll fix it" (no further discussion)
+B) "I disagree because [reason]; can we discuss?"
+C) Ignore the comment and merge anyway
+D) "That's not how we do it here"
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Disagreeing thoughtfully is fine — explain your reasoning and invite discussion. Option A is acceptable but might miss learning. Options C and D are unprofessional and can escalate conflict. -->
+
+## Question 6
+
+Drag these PR lifecycle steps into the correct order:
+
+<!-- VISUAL: quiz-drag-order -->
+<!-- Items: Author addresses feedback, Reviewer approves, Author creates PR, Reviewer requests changes, Merge -->
+
+A) Author creates PR → Reviewer requests changes → Author addresses feedback → Reviewer approves → Merge
+B) Author creates PR → Reviewer approves → Merge → Author addresses feedback
+C) Reviewer requests changes → Author creates PR → Merge
+D) Author addresses feedback → Author creates PR → Reviewer approves → Merge
+
+<!-- ANSWER: A -->
+<!-- EXPLANATION: The standard flow: author creates PR, reviewer reviews and may request changes, author addresses feedback, cycle repeats until reviewer approves, then merge. -->
+
+## Question 7
+
+<!-- VISUAL: quiz-drag-order -->
+
+Put these code review process steps in the correct order:
+
+A) Reviewer reviews code
+B) Author pushes commits addressing feedback
+C) Author requests review
+D) Reviewer approves or requests changes
+E) Merge to main branch
+
+<!-- ANSWER: C,A,D,B,E -->
+<!-- EXPLANATION: Author requests review, reviewer reviews the code, reviewer approves or requests changes. If changes are requested, author pushes updates and the cycle repeats until approval, then merge. -->
+
+## Question 8
+
+<!-- VISUAL: quiz-matching -->
+
+Match each review feedback type to its best practice:
+
+A) Correctness issue → 1) Block merge until fixed; explain the risk
+B) Style nit → 2) Suggest improvement but don't block; explain why it helps
+C) Security concern → 3) Request changes with clear reproduction steps
+D) Performance concern → 4) Flag as blocking; provide remediation guidance
+
+<!-- ANSWER: A3,B2,C4,D2 -->
+<!-- EXPLANATION: Correctness issues need clear reproduction steps and block merge. Style nits are suggestions. Security concerns block merge and need remediation. Performance concerns may block or be suggestions depending on severity. -->