Your authentication setup, roles, resources, and ownership rules.
Sign-in on your app, with each user's tasks open only to them and other requests refused at the server.
Exercise signed-out, owner, other-user, and privileged requests directly against the server.
A sign-in screen tells you who someone is, but it does not stop them reading another person's records. This guides your coding agent through adding accounts to your app, enforcing who can see and change what on the server, and proving it.
You write the access rules first: public, signed-in, owner-only and admin-only actions. Your agent then integrates sign-in using your chosen library's supported server session flow, with signed-out, expired-session, loading and failure states, and enforces permission checks on every read and write. The actor comes from the session, never from a submitted user ID, because hiding a button is not access control.
Finally you test the matrix with separate users and records, including direct requests as well as the interface, and confirm that a signed-out user and a different owner cannot read or change private records.
You need a running app, a persistence layer, an authentication provider or library suited to your stack, and a coding agent. Provider accounts, model weights, GPU compute and hosting are not included.
No reviews yet.
Sign in to rate this Vibe.
Your coding agent adds real storage for one feature, with validation and ownership checked on the server, and proves it survives a restart.