Eefje Bug/Feature Intake Process (v1)¶

Status: proposed Owner: Ivar Created: 2026-04-17

Why this document exists¶

Eefje (the business owner and primary tester) is the only non-technical stakeholder reporting bugs and feature requests on Freeze Design. Historically she has delivered them via PDF files dropped in the repo root (Foutmeldingen nieuw porduct aanmaken..pdf, Nog meer dingetjes.pdf) and via WhatsApp notes. This is fine for occasional input but breaks down at volume:

Items are mixed together (bugs, features, decisions-still-to-make, content)
Nothing is versioned against the staging SHA she tested on
Duplicate reports can't be detected
No audit trail of what was triaged, fixed, or deferred
Agents can't pick up work without manual translation

This document defines the intake process and shows how it maps to the existing GSD workflow.

The layered model¶

 Eefje's reports (WhatsApp, form, PDF)           ← RAW INPUT
           ↓ Ivar triages (usually same day)
 .planning/todos/pending/<slug>.md                ← STRUCTURED INTAKE
           ↓ Ivar groups by theme
 New GSD milestone (v1.26, v1.27, ...)            ← STRATEGIC PLANNING
           ↓ /gsd:new-milestone → /gsd:plan-milestone
 Phases + Plans                                   ← EXECUTION
           ↓ /gsd:execute-phase, optionally parallel agents via Cline Kanban
 PR to staging → deploy → Eefje retests           ← VERIFICATION
           ↓ Eefje confirms OK
 todo moved to .planning/todos/done/              ← CLOSED

Key insight: todos are the intake layer. They don't replace GSD's milestone/phase/plan system — they feed into it. A batch of triaged todos becomes the scope of the next milestone.

How Eefje reports (three channels, in order of preference)¶

Channel 1 — GitHub issue (preferred once onboarded)¶

Template at .github/ISSUE_TEMPLATE/eefje-bug.md (Dutch)
Auto-labelled reporter:eefje + needs-triage
Ivar receives a GitHub mobile notification

Channel 2 — WhatsApp note (fallback)¶

Eefje writes free-form in Dutch, as she does now
Ivar manually translates the batch into todos within 24h
Reply "genoteerd, ik neem het mee" closes her loop

Channel 3 — Email / PDF (legacy)¶

Still accepted but discouraged
Ivar processes identically to WhatsApp

Ivar's rule: within 24 hours, every raw report from any channel MUST produce either a todo file, a clarifying question back to Eefje, or a "deferred — won't do" decision logged in the todo itself.

The triage step (Ivar, 5-10 min per raw report)¶

For each item Eefje mentions, Ivar decides:

Kind	Example	Action
Clear bug	"Footer shows 2025, moet 2026 zijn"	`/gsd:add-todo` → slug-bug.md
Clear small feature	"Logo iets groter"	`/gsd:add-todo` → slug-feature.md
Ambiguous	"De categorie" (incomplete sentence)	Reply to Eefje, block the todo
Decision-in-progress	"Ik moet even kijken wat ik doe met..."	todo with status `awaiting-decision`
Content delivery	"Afbeelding stuur ik per email"	todo with status `blocked-on-content`
Big feature	"Producten van eigen ontwerpen zonder designer"	todo with status `needs-scoping`, plan a `/gsd:discuss-milestone` session
Duplicate	Already in pending/	Append note to existing todo
Already fixed	She missed it	Reply with "dit is al gefixt in vX.YZ"

Todo file format (extends GSD default)¶

GSD's default todo template is minimal. For Eefje intake, add these frontmatter fields so todos carry enough context to become phase plans:

---
title: <short descriptive title>
type: bug | feature | content | decision
status: ready | needs-clarification | awaiting-decision | blocked-on-content | needs-scoping
severity: blocker | important | nice-to-have
area: homepage | designer | product-catalog | admin | checkout | email | other
reporter: eefje | ivar | agent
reported_via: whatsapp | github | email | pdf
reported_date: YYYY-MM-DD
source: "<verbatim quote from Eefje if available>"
staging_sha_when_reported: <short sha or 'unknown'>
related_todos: []
blocked_by: []
---

Body sections: 1. What Eefje said (verbatim) — her exact words, Dutch preserved 2. Ivar's interpretation — what this actually means technically 3. Proposed scope — smallest change that solves the reported problem 4. Open questions — what's unclear, what needs confirmation 5. Definition of done — how we'll know it's fixed (from Eefje's perspective)

From todos to milestones¶

Once .planning/todos/pending/ has ~5–15 ready-status todos that cluster around a theme, run:

/gsd:discuss-milestone

Feed it the todos. The discuss step decides scope. Then /gsd:new-milestone turns them into phases and plans.

Todos that are needs-clarification or awaiting-decision stay in pending/ across milestones — they're not ready yet.

Todos that become part of a milestone stay in pending/ until the associated phase is completed, then move to done/ with a note pointing to the phase that closed them.

Eefje's retest loop¶

After a PR merges to staging:

Staging auto-deploys (new SHA)
Ivar WhatsApps: "Nieuwe versie is online (SHA abc1234). Kun je deze testen: [item 1], [item 2], [item 3]"
Eefje tests on staging.freezedesign.eu
For each item she confirms OK → Ivar moves the todo to done/
For each item she says "still broken" → Ivar reopens, adds her new report to the todo body, cycles it back through

What this costs Ivar daily¶

Morning (5 min): scan new WhatsApp/GitHub/email reports, batch-triage into todos
Anytime (ongoing): when starting a phase, grab the relevant todos
Evening (5 min): if staging deployed today, WhatsApp Eefje with retest list

Total: ~15 minutes/day for intake, not counting execution.

What this costs Eefje¶

First time: 10 min GitHub onboarding, plus bookmarking the issue form
Per report: 2-3 min if she uses the form, ~30 seconds via WhatsApp
Per retest: varies by item

Anti-patterns to avoid¶

❌ Agent creates todos autonomously from Eefje's raw PDF. It will misinterpret ambiguity and create noise. Ivar triages first.
❌ Skipping the "needs-clarification" status to keep things moving. Better to block on a 2-minute reply from Eefje than to build the wrong thing.
❌ Letting WhatsApp/PDF input bypass the todo layer. If it's not in a todo, it doesn't exist.
❌ Creating GSD phases directly from Eefje's raw list. Always batch through todos first — gives time for clarification and grouping.
❌ Moving todos to done/ before Eefje confirms. Done = confirmed on staging, not "merged to staging."