SluijsensandClaude Sonnet 5
cfb06b28b6
Implements Unit 2 "Offerings" (backend module, admin CRUD UI with drag-and-drop reordering, public GET /api/v1/offerings endpoint) and executes the feature's D-15 CI/CD cutover, switching the deploy pipeline's build/publish target from SlpModularCms.Api to SlpModularCms.Api.SlpSoftware. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
3.6 KiB
Functional Design Questions — Unit: Offerings
Vraag 1 — Drag-and-drop is een nieuwe frontend-dependency
frontend/package.json bevat vandaag geen enkele drag-and-drop-library (geen @dnd-kit/*, react-beautiful-dnd, of vergelijkbaar). US-08 (drag-and-drop herordenen) zou dus een nieuwe dependency betekenen, terwijl US-09 (omhoog/omlaag-knoppen) de functionele eis al volledig dekt zonder nieuwe dependency.
Hoe wil je dit voor de eerste versie aanpakken?
A) Beide bouwen zoals in de Inception-fase besloten — nieuwe dependency toevoegen (@dnd-kit/core + @dnd-kit/sortable, de huidige de-facto standaard voor React) voor drag-and-drop, plús de knoppen als toegankelijke fallback
B) Nu alleen de omhoog/omlaag-knoppen bouwen (US-09) — geen nieuwe dependency; drag-and-drop (US-08) wordt een latere, aparte toevoeging
X) Anders (beschrijf hieronder na de Answer:-tag)
Vraag 2 — Pagina-structuur admin-CRUD
De bestaande cms-feature (Master-module) gebruikt het patroon: één lijstpagina (CmsPage.tsx + CmsInstanceList.tsx) met een modal-dialoog voor "toevoegen" (AddCmsInstanceDialog.tsx) en een aparte modal voor statuswijziging.
Moet de Offerings-admin-UI hetzelfde patroon volgen?
A) Ja — één lijstpagina met rij-acties (bewerken/verwijderen/omhoog/omlaag), en een modal-dialoog die zowel voor "aanmaken" als "bewerken" hergebruikt wordt (met de featured-toggle erin) B) Aparte pagina's/routes voor aanmaken en bewerken in plaats van modals X) Anders (beschrijf hieronder na de Answer:-tag)
Answer: X, het hoeft niet hetzelfde patroon te zijn. Voor consistentie wel mooi, maar het CMS-stuk is vooral voor de master en zal niet bij andere websittes komen. Dus Optie B is prima
Vraag 3 — Validatiegrenzen (SECURITY-05)
Requirements.md vereist lengtebeperkingen op tekstvelden, maar noemt geen concrete getallen. Op basis van de bestaande content (langste titel "Landingspagina" = 14 tekens, langste description ≈ 70 tekens) stel ik ruime maar begrensde limieten voor.
Welke bovengrenzen wil je hanteren?
A) Title 100, Description 500, Price 50, PriceNote 100, CtaLabel 50 tekens; Features: min 1, max 10 items, elk item max 200 tekens — ruim genoeg voor toekomstig hergebruik (fotografie-pakketten etc.), maar begrensd tegen misbruik B) Strakkere limieten, dicht bij de huidige content (Title 50, Description 200, Features max 6 items van elk 100 tekens) X) Anders (geef zelf de getallen op na de Answer:-tag)
Vraag 4 — Bevestiging bij verwijderen
Verwijderen is een soft delete (D-Q5=B), maar er is geen "herstel"-functie in de admin-UI voorzien (buiten scope, FR-7 noemt alleen create/edit/delete/reorder). Vanuit het perspectief van de CMS Administrator is verwijderen dus onomkeerbaar.
Moet de admin-UI een bevestigingsdialoog tonen vóór het verwijderen van een offering?
A) Ja — een bevestigingsdialoog ("Weet je zeker dat je '[titel]' wilt verwijderen?") vóór de delete-aanroep B) Nee — direct verwijderen zonder bevestiging X) Anders (beschrijf hieronder na de Answer:-tag)
Vraag 5 — UI-trigger voor de featured-vlag
US-10 beschrijft dat het systeem "precies 0 of 1 featured offering" afdwingt, maar niet hoe de CMS Administrator dat instelt in de UI.
A) Een checkbox/toggle "Meest gekozen" in het aanmaak-/bewerkformulier van elke offering — bij opslaan met deze toggle aan wordt de vorige featured-offering automatisch uitgezet B) Een aparte actie in de lijst-view zelf (bijv. een ster-icoon per rij om direct featured te maken, los van het bewerkformulier) X) Anders (beschrijf hieronder na de Answer:-tag)
Answer: kan A en B beide?