Rules and kinds of user

Kinds of user

A kind of user is someone your app treats differently: a customer, a teammate on the same account, an admin, a guest who is not signed in. Stableship finds them in your code and database during setup, and you confirm them. Every test runs as each one.

Rules

A rule says who may see, create, change or delete a kind of record, in plain words: "An invoice can be opened by the company it belongs to and its admins. Everyone else gets not found." Rules cover access to records, data, money, sign-in and your critical flows. Each test checks the result against them, and a problem names the rule it breaks.

Critical flows

Flows are the journeys that must always work, such as signup and checkout. Stableship clicks through them as every kind of user who does them. Each flow is set to Hold the release (it holds a release when it can't be completed) or Only warn. To add one, describe it in a sentence under Add something to test on the Flows page; Stableship drafts it into a flow for you to review. Or ask your agent to add it (add_flow).

Changing the rules

Open Access to edit a rule or add one. Stableship also suggests rules, and you accept, edit or dismiss each suggestion. Suggestions come from:

• Tables, kinds of user and sensitive routes Stableship finds without a rule.
• Your coding agent, with propose_rule.
• Edits to .gate/rules.md pushed to your default branch.
• Your team.

When you remove a kind of user, a rule or a flow, Stableship remembers it: reading your app again leaves it out. The removed ones are listed under Not true of your app in Access, where Undo lets a later read suggest one again.

A change that lets more people see or change something, weakens a rule or drops one needs an approval. By default owners and admins approve; your project's policy can add others.

Product notes

Notes tell the tests what the code cannot: "invoices are shared with the whole team". Add them in the app, or have your agent save one with add_context_note (stableship note "<fact>") and take one out with remove_context_note (stableship note --remove "<words>"). Notes hold 4,000 characters in total.

Keep the rules in your repository

Stableship never writes to your repository, so your agent commits these files. Ask it to call get_repo_files after the rules change, then write and commit what it returns:

• .gate/rules.md: the rules as sentences grouped by area, then a json block with the full rules. The block is what Stableship reads; editing only a sentence changes nothing.
• .gate/context.md: your product notes.
• A Stableship section in AGENTS.md, between <!-- stableship:start --> and <!-- stableship:end -->. Nothing outside the markers changes. Put the same section in CLAUDE.md or replit.md if your repository has them.

Edit .gate/rules.md and push to your default branch, and the change comes back as a suggestion. It is never applied directly when it lets more people in. Edited notes in .gate/context.md replace the stored ones.

Your agent and the rules

A connected agent should read the rules (get_rules) before it changes sign-in, data access, payments or migrations, give every new table row level security that matches them, and keep the service-role key out of browser code. In Claude Code the plugin does this for you: it shows Claude the rules for a file before Claude edits it.