Skip to content

Eefje Feedback Intake

Sinds 2026-05-06 melden bugs en feature-wensen via een aparte private repo: Voorman/freezedesign-feedback. Deze runbook beschrijft het volledige intake-proces vanuit Ivar's perspectief.

Architectuur

Eefje → Issue Form (NL, dropdowns, screenshot)
          ▼ (auto-labels: type:bug|feature, status:needs-triage, reporter:eefje)
   freezedesign-feedback#<N>
          ▼ (notify-discord workflow → #eefje-feedback channel)
   Ivar triage: status:needs-triage → status:ready (of needs-clarification, etc.)
          ▼ (agent of Ivar leest: gh issue list -l status:ready)
   PR in webshop_freeze_design met "Feedback: Voorman/freezedesign-feedback#<N>"
          ▼ (PR merge → staging)
   feedback-retest-comment workflow:
     - Comment op issue met staging-sha + retest-checklist
     - Label naar status:retest-pending
          ▼ (Eefje retest)
   OK → Eefje sluit issue zelf
   Niet OK → Eefje comment "still broken" → vervolg-PR

Triage werkwijze

Wanneer een nieuwe issue binnenkomt (Discord-melding in #eefje-feedback):

  1. Lees de hele issue body. Ga niet direct fixen — Eefje's beschrijving bevat soms detail dat in agent-context verloren gaat.
  2. Beoordeel of de scope duidelijk is:
  3. Duidelijk + actionable → label status:ready, eventueel severity: aanpassen.
  4. Onduidelijk wat ze precies bedoelt → label status:needs-clarification, comment met je vraag in NL.
  5. Eefje moet kiezen tussen opties → status:awaiting-decision + opties listen.
  6. Wacht op content (foto's, teksten) → status:blocked-on-content.
  7. Vereist designsessie of grotere scoping → status:needs-scoping.
  8. Severity correctie: Eefje gebruikt vooral nice-to-have en important. Override naar blocker of minor als haar inschatting niet matcht met productimpact.
  9. Reporter label: blijft reporter:eefje voor haar issues. Voor je eigen issues (intern werk) gebruik reporter:ivar + label status:ready.

Werken op een issue (handmatig)

# Pak een ready issue:
gh issue list -R Voorman/freezedesign-feedback -l status:ready \
  --json number,title,labels

# Bekijk volledige inhoud + comments:
gh issue view <N> -R Voorman/freezedesign-feedback --comments

# Markeer als in-progress:
gh issue edit <N> -R Voorman/freezedesign-feedback \
  --add-label "status:in-progress" --remove-label "status:ready"

# Branch aanmaken:
git checkout staging && git pull
git checkout -b fix/feedback-<N>-<korte-slug>

# ... werk ...

# PR aanmaken (PR-template heeft het Feedback:-veld al):
gh pr create --base staging --title "fix(<area>): <korte beschrijving>" \
  --body "Feedback: Voorman/freezedesign-feedback#<N>

  ## Verify on staging
  - [ ] <stap 1>
  - [ ] <stap 2>"

Bij merge naar staging plaatst feedback-retest-comment.yml automatisch een retest-comment op de issue.

Werken op een issue (via agent)

CLAUDE.md beschrijft dit. Korte versie:

"Pak issue #<N> op uit Voorman/freezedesign-feedback. Lees de form-velden,
zet status:in-progress, branch fix/feedback-<N>-<slug>, PR tegen staging
met de juiste Feedback-referentie en Verify-on-staging checklist."

De agent doet de rest. Bij PR-review check je dat: - Branch-naam matcht met issue. - Body bevat exact Feedback: Voorman/freezedesign-feedback#<N>. - Verify-checklist is concreet en uitvoerbaar door Eefje (niet "test alle CRUD").

Discord notifications

#eefje-feedback channel toont:

  • 📥 Nieuwe issue (blauw)
  • 💬 Nieuwe comment (paars) — incl. retest-comments van de bot
  • 🔄 Heropende issue (rood) — als Eefje "still broken" comment voorzien van reopen, of bij vervolg-PR
  • ✅ Gesloten issue (groen) — Eefje retest succesvol

Webhook secret: DISCORD_WEBHOOK_EEFJE_FEEDBACK in zowel Voorman/freezedesign-feedback (voor de notify workflow) als Voorman/webshop_freeze_design (legacy — kan weg na verificatie dat hier niets meer mee gebeurt).

Cross-repo PAT

FEEDBACK_REPO_TOKEN in Voorman/webshop_freeze_design is een fine-grained PAT met: - Resource owner: Voorman - Repository access: alleen Voorman/freezedesign-feedback - Permissions: Issues read & write

Vervaldatum: jaarlijks rollen. Set reminder.

Migratie van oude todos

Pre-2026-05-06 todos in .planning/todos/pending/ blijven daar tot Eefje ze opnieuw meldt of Ivar ze handmatig migreert. Niet automatisch syncen — veel daarvan zijn al achterhaald.

.planning/todos/ blijft bestaan voor intern Ivar/agent-werk dat niet voor Eefje zichtbaar hoeft te zijn (dependabot triage, refactors, infra-werk).

End-to-end testing

Geverifieerd op 2026-05-06 via test-issue #2:

  • Issue Form auto-labels werken (status:needs-triage, type:bug, reporter:ivar).
  • Notify-Discord workflow triggert op issues:opened en plaatst embed in #eefje-feedback.
  • Cross-repo retest-comment workflow triggert op PR-merge naar staging, parset Feedback:-regel, comment + label switch op gelinkte issue.
  • Label-cleanup edge case (issue #3, PR #74): bij retest-pending switch worden alle bestaande status:* labels gestript, niet alleen status:in-progress.