Step 1 of 5
Define the ticket model
Tickets, messages, and statuses need shapes before UI.
Define the support system model: the ticket (id, owner userId, subject, category from a fixed set, status open/in-progress/resolved, createdAt/updatedAt) and its messages (ticket id, author user/admin, body, timestamp) as a thread; the status transition rules and who can change them; visibility rules (owners see theirs, admins see all); and what notifies the user when a reply lands (in-app indicator at minimum).
Expected after this step
A ticket/message model with transitions and visibility rules.
Should not happen
- ✕A contact form that goes nowhere
- ✕Replies stored but never shown to the user
- ✕All users seeing all tickets
- ✕Status dropdowns that reset on reload
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !A contact form that goes nowhere
- !Replies stored but never shown to the user
- !All users seeing all tickets
- !Status dropdowns that reset on reload
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The model has no message thread or status rules. Add the messages collection keyed by ticket and write the allowed status transitions.