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

flowchart TD
    A[Eefje → Issue Form<br/>NL, dropdowns, screenshot] -->|auto-labels: type:bug/feature,<br/>status:needs-triage, reporter:eefje| B[freezedesign-feedback#N]
    B -->|notify-discord workflow| C[#eefje-feedback channel]
    C --> D[Ivar triage:<br/>status:needs-triage → status:ready<br/>of needs-clarification, etc.]
    D -->|agent of Ivar leest:<br/>gh issue list -l status:ready| E[PR in webshop_freeze_design<br/>met 'Feedback: Voorman/freezedesign-feedback#N']
    E -->|PR merge → staging →<br/>groene CI-run incl. deploy-job| F[feedback-retest-comment workflow<br/>triggert op workflow_run van 'CI',<br/>branch staging, push, success —<br/>dus pas ná de geslaagde staging-deploy]
    F --> G[Comment op issue met gedeployde<br/>staging-sha + link naar de PR<br/>+ label → status:retest-pending]
    G -->|Eefje retest| H{OK?}
    H -->|OK| I[Eefje sluit issue zelf]
    H -->|Niet OK| J[Eefje comment 'still broken'<br/>→ 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>"

Na merge naar staging wacht feedback-retest-comment.yml op de succesvolle CI-run van die push (sinds 2026-06-10 zit de staging-deploy als deploy-job ín de CI-run) en plaatst dan automatisch een retest-comment met de gedeployde SHA 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. (Trigger is sindsdien tweemaal verplaatst: eerst naar deploy-success, sinds 2026-06-10 naar workflow_run van de CI-run op staging — de deploy is nu een job binnen CI. Functioneel gedrag ongewijzigd.)
  • Label-cleanup edge case (issue #3, PR #74): bij retest-pending switch worden alle bestaande status:* labels gestript, niet alleen status:in-progress.