# Rules Desk

> Paste a Cloud Firestore security rules file and get three things over one work object: a free
> in-browser parse of what every match path actually grants and to whom, a security audit with a
> posture verdict, a plan for the custom auth claims the rules depend on, and the whole file
> rewritten and hardened with emulator tests to prove it.

URL: https://rules-desk.skillsafe.ai/
Kind: single-page web app, static bundle, no server, strict CSP
Model: gpt-terra (resolves to gpt-5.6-terra), publisher markup 1000 bps
Price: 0 credits to open; the three model stages are metered per run
Free without an account: the whole parser, the coverage table, all twenty-four prescan checks,
the re-read delta, and every prescan export

## What it is for

A developer holding one `firestore.rules` file, about to deploy it. In one sitting they inspect
what it grants, decide what the auth token has to carry, and produce the hardened replacement.

## The work object

One pasted Firestore security rules file. Every stage takes the same file; the stages differ only
in what they add to it (a surface and a sensitivity, a provider list, a posture).

## The free lane, in the browser

`ruleslint.js` is a real parser, not a keyword scan. It masks comments and string bodies so brace
matching cannot be fooled, walks `service` blocks and nested `match` blocks, resolves wildcard
path segments (including the `match /databases/{database}/documents {` case, where three braces
appear on one line and only the last opens the block), reads multi-line `allow` conditions to
their terminating semicolon, and inlines helper function bodies so a condition that delegates its
whole ownership check to `isOwner()` is still recognised as binding the uid.

It reports:

- a coverage table: every granting path, the concrete operations it grants, and whether it is
  gated on nothing at all, on merely being signed in, on a custom claim, or on the caller's uid;
- twenty-four checks (FR-01 to FR-24) across four severities, each with a line number, the match
  path it belongs to, why it matters and the specific fix.

Findings it makes that a reviewer commonly misses:

- **FR-05** `allow create` whose condition reads `resource.data`. On a create there is no stored
  document, so `resource` is null and the rule denies every request — a silent outage that reads
  like an auth bug in the client.
- **FR-03** the console's test-mode rule, open to the world until a hardcoded date and closed to
  everybody including your app after it.
- **FR-08** a helper function called but never defined, which Firestore refuses to deploy.
- **FR-14** an identity hardcoded into a condition, published to the world because rules are
  public and unrevocable without a deploy.

## The three metered stages

Routing is on an explicit `task` field in the run input.

- `task: "audit"` — verdict (`open`, `leaky`, `tighten`, `sound`) with the one deciding factor
  named, a per-path exposure table, findings carrying the concrete attack and the corrected rule,
  and a fixed ten-check status table.
- `task: "claims"` — the identity model in force, every custom claim the rules trust, who must set
  it with the Admin SDK, how long a signed-in client keeps the old token, the blast radius of
  granting one wrongly, and the gaps that no claim can close.
- `task: "harden"` — the complete rewritten rules file (never a diff, never widened, never
  dropping a path), a change log with the attack each change closes, what was deliberately kept,
  and a table of allow/deny assertions to run against the emulator.

Handoff is a button: an audit result offers "harden these rules from this audit" and "plan the
claims this audit assumes", carrying the finding refs into the next stage's input.

## Accountability

Every prescan finding is sent with the run, and the reply must return one `coverage` entry per
finding ref with `confirmed` or `set-aside`. Refs the model never mentioned are rendered as
unanswered rather than dropped. The harden stage can additionally be re-read by the browser's own
parser, for free, so the page can say whether the rewrite actually improved on the original.

## API

`https://api.skillsafe.ai/v1/app-api` — `/estimate` (free), `/run`, `/run-stream`, `/jobs/{id}`,
`/me`, `/guest`. Full tutorial with worked examples per stage in cURL, Python, JavaScript, Go,
Java, Ruby, PHP and C#: https://rules-desk.skillsafe.ai/api.html

## Data

Reviews are stored in a declared `reviews` collection on the user's own SkillSafe account
(`acl_read: owner`), mirrored in `localStorage` for instant paint. Semantic search over past
reviews is available on `title`, `headline`, `verdict` and `lane`.

## Not

Not a Firestore emulator, not a linter you can run in CI without a token (though `ruleslint.js`
itself is dependency-free and runs under Node), not affiliated with Google or Firebase, and not a
substitute for running the generated tests before deploying.

## Source skills

Built from three skills in https://github.com/firebase/agent-skills and crediting all of them:

- @firebase/firebase-security-rules-auditor — the audit stage
- @firebase/firebase-firestore — the harden stage
- @firebase/firebase-auth-basics — the claims stage

This app is a derived work, not a republication of those skills.