Hassan feedback documentation (#5)

* docs(feedback): add Hassan feedback on StatsBomb case study

Document feedback from Hassan (senior engineer at StatsBomb) on three
key areas:

1. Name attribution: Consider using job titles instead of specific names
2. "Saying thank you" tone: Replace gratitude framing with impact/trust
   - Current feels performative vs. showing tangible outcomes
   - Alternatives: "seeing actual impact", "constructive feedback loops"
3. Two-merge bottleneck unclear: Need concrete workflow example
   - If former team member finds it unclear, external readers will too
   - Action: Add step-by-step scenario with specific collector dialogue

Includes proposed rewrites for gratitude section (line 76) and concrete
two-merge workflow example to clarify bottleneck mechanics.

* refactor(statsbomb): apply Hassan feedback on tone and clarity

Implement 2 of 3 feedback points from Hassan (senior engineer):

1. Name attribution: KEEP NAMES (disagree with feedback)
   - Reasoning: Credits individuals, humanizes story, shows partnership
   - Aligns with CLAUDE.md collaborative framing principle

2. Gratitude → Partnership reframe (line 76): IMPLEMENTED
   - Before: "collector gratitude...saying thank you" (performative)
   - After: "feedback loop...shaping the tool directly" (genuine partnership)
   - Shows trust and impact vs. emotional validation

3. Two-merge bottleneck clarity (lines 148-154): IMPLEMENTED
   - Added explicit post-processing gap between merges
   - Text now stands alone without requiring diagram
   - Explains: Merge 1 → 4h post-processing → Merge 2 (two divergence points)

Text principle: Diagrams are supporting proof (like sketches), not required
reading. If Hassan (former team member) found it unclear, external readers
definitely would.

* refactor(statsbomb): clarify two-merge bottleneck with accurate pairing workflow

Tighten from 155 words to 85 words (-45%) while increasing accuracy.

Before: Implied two sequential merges with post-processing between them
After: Accurate workflow - pairing (same event, different perspectives +
imperfect timestamps) → validate chains → enrich (location, freeze frames)

Key insight: Collectors logged same moment from different team perspectives
(foul-committed vs foul-won) with human timing imprecision. Pairing cost
came from matching which events describe the same thing.

Story flows without bold headers breaking narrative arc.

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: saadshahd

docs/feedback/hassan.md

@@ -0,0 +1,101 @@
+# Hassan Feedback - 2025-11-02
+
+**Context:** Senior engineer who worked briefly at StatsBomb reviewing the case study
+
+## Key Points
+
+### 1. Name Attribution vs. Job Titles
+- **Problem:** Case study mentions specific names throughout (Ali, Adham, Waheed, Hadeel, Abdallah, etc.)
+- **Feedback:** Use job titles instead of names
+- **Impact:** May feel too personal or create privacy concerns
+- **Tension:** Conflicts with narrative style of crediting individuals for their contributions
+- **Current Approach:** "Ali and I sat with VSCode open", "Waheed built claims-based metadata", "Adham advocated for Kafka"
+
+### 2. "Saying Thank You" Feels Performative
+- **Problem (line 76):** "That feeling—collector gratitude—became the foundation for everything we built over four years. Not from management validation or product roadmaps, but from the people doing the actual work saying 'thank you.'"
+- **Feedback:** "Very cringe when you say 'saying thank you'"
+- **Alternative Suggestions:**
+  - "Seeing actual impact"
+  - "Constructive feedback"
+  - "They trusted that the feedback will make a change"
+- **Why:** Focus on tangible outcomes and trust rather than emotional validation
+- **Core Issue:** Gratitude sounds self-congratulatory vs. showing actual collector impact
+
+### 3. Two-Merge Bottleneck Unclear
+- **Problem:** Section at lines 140-149 and diagram at lines 173-210
+- **Feedback:** "The two-merge bottleneck is not clear to me"
+- **Current Explanation:**
+  - First merge: Align on what events happened during collection
+  - Second merge: Reconcile how events were validated, positioned, and tagged
+- **Impact:** If a former team member finds it unclear, external readers definitely will
+- **Missing:** Step-by-step walkthrough of why two merges were necessary
+
+## Decision
+
+**Point #1 (Names vs. Job Titles):** **KEEP NAMES** - Disagree with Hassan's feedback
+- Reasoning: Credits individuals for their work, humanizes the story, shows genuine partnership
+- Aligns with CLAUDE.md "Collaborative framing — Team credit, not individual genius"
+- No action taken
+
+**Point #2 (Gratitude → Partnership):** **AGREE** - Implement feedback loop framing
+- Action: Rewrite line 76 to show genuine collector partnership vs. self-congratulatory tone
+
+**Point #3 (Two-Merge Bottleneck):** **AGREE** - Text must stand alone without diagram
+- Action: Clarify workflow with explicit post-processing gap between merges
+- Principle: Diagrams are supporting proof (like sketches), text should be self-sufficient
+
+## Action Items
+
+- [x] **Decision made:** Keep names for narrative credit (disagree with point #1)
+- [ ] Rewrite line 76 to focus on feedback loops instead of "saying thank you"
+- [ ] Clarify two-merge bottleneck by explaining post-processing gap between merges
+- [ ] Ensure text stands alone without requiring diagram for comprehension
+
+## Proposed Rewrites
+
+### Before (line 76):
+> "That feeling—collector gratitude—became the foundation for everything we built over four years. Not from management validation or product roadmaps, but from the people doing the actual work saying 'thank you.' When you ship for people who thank you, architecture stops being abstract."
+
+### After (Option 1 - Impact Focus):
+> "That feedback loop—seeing collectors save 9 minutes per frame, watching hands stop cramping—became the foundation for everything we built over four years. Not from management validation or product roadmaps, but from the people doing the actual work telling us what mattered. When you ship for people who trust their feedback will shape the tool, architecture stops being abstract."
+
+### After (Option 2 - Trust Focus):
+> "That trust—collectors believing their feedback would directly change the tool—became the foundation for everything we built over four years. Not from management validation or product roadmaps, but from the people doing the actual work showing us what slowed them down. When you ship for people who see their input reflected in the next build, architecture stops being abstract."
+
+## Two-Merge Bottleneck Clarification
+
+**Add Concrete Example (after line 149):**
+
+> **Why Two Merges?**
+>
+> **First Merge (Event Agreement):**
+> - Collector A: "That's a recovery at 23:45"
+> - Collector B: "That's an interception at 23:45"
+> - Merge question: What actually happened?
+>
+> **Post-Processing (4 hours each):**
+> - Both collectors add positioning data, freeze frames, validation tags
+> - Different interpretations lead to different enrichments
+>
+> **Second Merge (Enrichment Agreement):**
+> - Same event, now with conflicting metadata
+> - Merge question: How should this event be tagged/positioned?
+>
+> The tool allowed ambiguous interpretations during collection. Collectors paid the cost afterward in two separate reconciliation phases.
+
+## Writing Philosophy Considerations
+
+**Name Attribution Trade-off:**
+- **Pro (keeping names):** Credits individuals for their work, humanizes the story, follows "team attribution" pattern from CLAUDE.md
+- **Con (removing names):** More professional, privacy-conscious, focuses on roles over individuals
+- **Decision needed:** This is a philosophical choice about narrative style
+
+**Gratitude vs. Impact:**
+- **Problem:** "Thank you" feels self-serving
+- **Solution:** Reframe around trust, feedback loops, and measurable impact
+- **Pattern:** Show → don't tell (9 minutes saved > "they thanked me")
+
+**Technical Clarity:**
+- **Lesson:** If someone who worked on the project finds it unclear, external readers definitely will
+- **Fix:** Add concrete examples with specific dialogue/scenarios
+- **Principle:** Abstract concepts need concrete instantiation

src/pages/portfolio/statsbomb.mdx

@@ -73,7 +73,7 @@ _"This saved me 9 minutes per frame."_
 _"My hand doesn't cramp anymore."_
 _"Eyes stay on video, not the mouse."_
 
-That feeling—collector gratitude—became the foundation for everything we built over four years. Not from management validation or product roadmaps, but from the people doing the actual work saying "thank you." When you ship for people who thank you, architecture stops being abstract.
+That feedback loop—collectors telling us what slowed them down, seeing it fixed the next day—became the foundation for everything we built over four years. Not from management validation or product roadmaps, but from the people doing the actual work shaping the tool directly. When you ship for people who trust their feedback will change tomorrow's build, architecture stops being abstract.
 
 **The Partnership: Domain Expertise Meets Systems Thinking**
 
@@ -145,7 +145,9 @@ Two collectors, same match. Hours after the final whistle, they're still arguing
 "No, interception—he anticipated the pass."
 "But possession hadn't transferred yet."
 
-Collectors spent 2 hours post-match reconciling across two merge points. First merge: align on what events happened during collection. Second merge: reconcile how those events were validated, positioned, and tagged. The tool allowed ambiguous interpretations during the match. Collectors paid the cost afterward.
+Same foul—collector A logs "foul-committed, 0.01s." Collector B logs "foul-won, 0.011s." Same moment, different perspectives, imperfect timestamps. Hours spent pairing: which events describe the same thing? Then validate chains. Then location, freeze frames.
+
+The tool allowed perspective-based collection. Collectors paid the pairing cost afterward.
 
 {/* Workflow Comparison: Before vs. After */}