@gemmein/sdk 0.4.6 → 0.5.0

package/REFERENCE.md

@@ -21,10 +21,15 @@ The browser client. `appKey` is your public `pk_...` key. `options` (optional):
 
 ### `gemmeinServer(secretKey, options?) → GemmeinServer`
 Server-only client for a `sk_...` secret key — **never ship this to the
-browser.** Exposes read/update on collections without a signed-in user,
+browser.** `options` (optional): `{ apiUrl?: string }` — **the option is
+`apiUrl`**, not `baseUrl`. An unknown option is ignored silently, so a script
+that passes `baseUrl` to reach a local or staging server quietly talks to
+production instead. Exposes read/update on collections without a signed-in user,
 `notify()` to email one of your app's own verified people (see **Notify**),
-plus `testSession()` for CI self-tests (dev environments only — see
-**Reaffirm**).
+the gate — `verifySession()` / `holdings()` / `grantAccess()` /
+`revokeAccess()`, for code of yours running on your own host (see **Server
+gate**) — plus `testSession()` for CI self-tests (dev environments only —
+see **Reaffirm**).
 
 The client has two layers. **Your app's collections** — `g.collection(name)`
 (the canonical spelling; `g.storage.collection(name)` is the same client). And
@@ -79,6 +84,8 @@ deleted, subscription row removed. Irreversible: put a real confirm in front.
 `name` must be **lowercase letters, numbers, and underscores** (`saved_games`,
 never `savedGames` — a bad name throws synchronously). Collections are created
 by the app owner in the dashboard, never by the SDK.
+Names JavaScript owns (`constructor`, `toString`, `__proto__`…) are refused as
+collection and field names — a plain object inherits them.
 
 `options.intent` — one sentence: what the collection is for and who should
 access it. It rides every call as a hint; against a **local `gemmein dev`
@@ -189,13 +196,20 @@ type ListOptions = {
 ```
 
 **Options notes.** `key` = create-if-absent (a second writer gets 409
-`conflict`; your own retry returns the record with `existing: true`). `for` =
+`conflict`; your own retry returns the record with `existing: true`). The
+retry doubles as the lookup: there is no separate get-by-key call — re-issue
+the same `create()` with the same key to fetch your own record (it counts
+as a write; a re-fetch idiom, not a read path). `for` =
 recipient id on `addressed`/`direct`. `published: false` = draft on a public
 rule. `ifVersion` = optimistic concurrency. Atomic counters go in *value*
 position: `update(id, { stock: { decrement: 1, floor: 0 } })`. `expand` throws
 on `private`/`public_read`/`admin_write` (no link shape) — join in memory there.
 `since` fixes the order (oldest change first) — pairing it with `sort` is a 400
-`invalid_since`. Deltas are at-least-once: apply by id.
+`invalid_since`. Deltas are at-least-once: apply by id. A field added to a
+sealed shape by a promote run may carry a **default**: records that never wrote
+it read that value, `expand` targets and `where` see it too, and a written value
+wins (writing `null` clears it back to the default) — `search` still matches
+stored text only.
 
 ### Live data — `watch()`
 
@@ -224,6 +238,10 @@ Plans are `g.subscriptions`; one-off things are `g.payments`. `checkout` and
 don't also redirect to the returned `url`, and never build a Stripe URL
 yourself. Gate features on `(await g.subscriptions.mine())?.plan === "pro"`;
 gate one-off fulfilment on the receipt record, never the redirect.
+By-hand grants (trial, promotion, a support comp) are not listed to the
+app — a gated read simply succeeds — so never rebuild the paywall from
+`mine()`; let the server refuse with `entitlement_required`. The two grant
+families and what ends each are in llms.txt, "Two FAMILIES of grant".
 
 ---
 
@@ -253,6 +271,88 @@ honestly, not hidden.)
 
 ---
 
+## Server gate — `gemmeinServer(sk).verifySession` / `holdings` / `grantAccess` / `revokeAccess`
+
+Gemmein hosts no compute. **Your own** function — Vercel, a VPS, a cron box,
+anywhere — asks Gemmein the only three questions it has: *who is this person,
+what do they hold, change what they hold.*
+
+| Method | Signature | Returns |
+|--------|-----------|---------|
+| `verifySession` | `(token)` | `Promise<{ ok: true, person: { id, email, role }, holdings: Holdings }>` — the browser's session token in, identity **and** holdings out. Needs no capability on the key (the caller already holds the person's token) and never touches the session: no extension, no last-seen |
+| `holdings` | `(personId)` | `Promise<{ ok: true, person: { id, email, role, suspended }, holdings: Holdings }>` — for the paths with no token in hand. A **suspended** person is returned, flagged `suspended: true`, with their holdings; `verifySession` refuses them |
+| `grantAccess` | `(personId, { entitlement, source?, expiresAt?, reason? })` | `Promise<{ ok: true, grant: Grant, holdings: Holdings }>` (201) — `holdings` is the state **after**; the owner's audit row carries before→after and the key's name |
+| `revokeAccess` | `(personId, grantId, { reason? }?)` | `Promise<{ ok: true, grant: Grant, holdings: Holdings }>` — the returned grant carries `revokedAt` |
+
+```ts
+type Holdings = {
+  access: string[]                 // the keys they hold NOW — ["access:pro"]
+  grants: Grant[]                  // the LIVE grants behind them (revoked/expired are gone)
+  credits: { balance: number } | null   // reserved — null today; credits are NOT shipped
+}
+
+type Grant = {
+  id: string
+  entitlement: string              // "access:<slug>" — the plan's or product's own key
+  source: "subscription" | "purchase" | "manual" | "trial" | "promotion" | "migration"
+  startsAt: string
+  expiresAt: string | null
+  revokedAt?: string | null        // present on the grant revokeAccess returns
+}
+```
+
+- **Pointing at a non-default server.** `gemmeinServer(sk, { apiUrl })` — the option
+  is **`apiUrl`**. `baseUrl` is not an option name and is ignored in silence, so a
+  test or E2E script that passes it runs against **production** without saying so.
+- **One call per request.** `verifySession` answers identity *and* holdings
+  together — don't call it twice, and don't cache the answer past the request.
+- **Holdings, not billing.** The gate never returns subscription status,
+  amounts, Stripe ids, or a grant's `sourceId` — the source **kind** only. Gate
+  on what a person *holds*, never on what they pay. Person id, never an email.
+- **Two capabilities, ticked by the human.** `verifySession` needs neither.
+  `holdings` needs **"Look up a person's access by id"**; `grantAccess` and
+  `revokeAccess` need **"Grant and revoke access"** — plain-English checkboxes
+  the owner ticks when minting the key. Existing keys have both off, so nothing
+  in production changes.
+- **Manual sources only.** `source` ∈ `manual | trial | promotion | migration`
+  (default `manual`). Purchases and subscriptions come only from Stripe — a key
+  cannot mint paid access. A key *may* end a payment-made grant (the same as the
+  dashboard's "end this access"); the payment itself is untouched.
+- **One grant, one reason.** `reason` (≤ 200 chars) is what the owner reads in
+  their logs and is never edited. `sourceId` is minted per call, so two calls
+  make two grants — call it once and keep your own retry key.
+- **Nothing silent, within a stated bound.** Every `/server/*` call a **resolved
+  secret key** makes, ok or refused, lands in that key's usage ledger — the owner
+  reads the summary on their Keys page and the full day × route × outcome table in
+  the key's own room. A rejected or publishable (`pk_`) key can't be attributed to a
+  key row, so its refusal reaches only the request log. Refusals also write one audit
+  row per key, route and code each hour (exact counts stay in the ledger); grants and
+  revokes write full before→after rows, attributed to the key by name. A refusal
+  counts as *use*: "last used" means last seen, not last worked. In `gemmein dev` the
+  local key already holds both capabilities, and the usage read is cloud-only — the
+  local runtime never mounts the console.
+
+| code | status | meaning · do |
+|------|--------|--------------|
+| `session_invalid` | 401 | No session matches this token — send the person to sign in again; never store or reuse tokens across people |
+| `session_expired` | 401 | The session ended (the message names when) — send them back to sign-in |
+| `session_revoked` | 401 | A newer sign-in, a sign-out, or the owner ended it — send them back to sign-in |
+| `person_suspended` | 403 | The owner suspended this person — access is off until the owner reactivates them in the dashboard |
+| `person_not_found` | 404 | No person with this id in this app and environment — ids come from `verifySession` or the dashboard, never from an email. Existence is never leaked |
+| `capability_required` | 403 | The key's box isn't ticked — mint a key with "Look up a person's access by id" / "Grant and revoke access" ticked (purchases still come only from Stripe) |
+| `invalid_source` | 400 | `purchase` / `subscription` asked for by hand — refused; those come only from Stripe |
+| `invalid_entitlement` | 400 | Not a valid `access:<slug>` key — or drop the key and pass the plan's or product's own NAME, which the gate resolves for you |
+| `unknown_plan` | 400 | No plan or product by that name — the owner adds it on the Payments page. (Checkout's `unknown_plan` is a **404**; the gate's is a **400** — it is a bad argument to a write, not a missing resource) |
+| `grant_not_found` | 404 | Not this person's grant, in this app and environment — re-read `holdings` |
+| `already_revoked` | 409 | A grant ends once (`revokedAt` is set and never edited) — it is already ended |
+| `invalid_body` | 400 | One malformed field, whichever it is — `token` (missing, not a string, over 512 chars), `expiresAt` (unparseable or in the past), `reason` (not text, over 200 chars). Branch on the code, read the **message**: it names the field |
+| `scope_denied` | 403 | Not a secret key — the gate is server-only, never the browser |
+| `invalid_id` | 400 | A prototype name (`__proto__`, `constructor`, `prototype`) was sent as a person id or a grant id. Ids come from `verifySession()` or the dashboard — never from a name |
+| `unknown_route` | 404 | Not one of the gate's four routes — the message lists them all |
+| `method_not_allowed` | 405 | The right route, the wrong verb: `verifySession`, `grantAccess` and `revokeAccess` are POST, `holdings` is GET |
+
+---
+
 ## Reaffirm — prove your app's boundaries in CI
 
 Gemmein enforces the rules **server-side**, so your frontend is never the source
@@ -320,7 +420,10 @@ class GemmeinError extends Error {
 }
 ```
 
-Branch on `err.code`. The stable codes:
+Branch on `err.code`. The gate's own codes (`session_invalid`,
+`session_expired`, `session_revoked`, `person_suspended`, `person_not_found`,
+`capability_required`, `invalid_source`, `unknown_plan`, `grant_not_found`,
+`already_revoked`) are in **Server gate** above, each with its action. The rest:
 
 | code | meaning | do |
 |------|---------|-----|
@@ -333,7 +436,7 @@ Branch on `err.code`. The stable codes:
 | `conflict` | a keyed create / floor / stale `ifVersion` | it's the mechanism — tell the user it's taken |
 | `html_not_allowed` | HTML in a community/addressed/direct field | store plain text |
 | `invalid_publish` | `{ published }` on a non-public rule | drop it |
-| `invalid_shape` | field not in a locked (live) collection's shape — or a file field given the wrong kind (the message names which) | ask the owner to add it / send the kind the field takes |
+| `invalid_shape` | field not in a locked (live) collection's shape — or a file field given the wrong kind (the message names which) | after the field exists in development, one promote run adds it (the owner answers blank or a default) — until then send only the fields the shape has / send the kind the field takes |
 | `unknown_file` | a ref-shaped value points at a file that doesn't exist or isn't yours to hand — every rule, every write | fix the ref — never invent one |
 | `invalid_since` | `since` isn't a strict ISO 8601 timestamp, or came with `sort` | pass the previous answer's watermark; drop `sort` |
 | `not_a_customer` (404) | `notify()`'s recipient isn't a verified person of this app and environment | fix the person id — one code on purpose |

package/dist/index.cjs

@@ -816,6 +816,126 @@ class GemmeinServer {
         }
         return response.json();
     }
+    /**
+     * THE GATE — your compute, our answer. Gemmein runs no code of yours;
+     * your own function runs anywhere and asks the only three questions it
+     * has: who is this person, what do they hold, change what they hold.
+     *
+     *   const { person, holdings } = await g.verifySession(token);
+     *   if (!holdings.access.includes("access:pro")) return deny();
+     *
+     * ONE call per request answers identity AND holdings — don't call it
+     * twice, and don't cache the answer past the request. Verify needs no
+     * capability on the key (the caller already holds the person's token)
+     * and never touches the session: no extension, no last-seen.
+     *
+     * Refusals (`err.code`): `session_invalid` (no session matches this
+     * token — the person signs in again; never reuse tokens across
+     * people) · `session_expired` · `session_revoked` (a newer sign-in,
+     * a sign-out, or the owner) — all three send the person back to
+     * sign-in · `person_suspended` (the owner suspended them; access is
+     * off until the owner reactivates them in the dashboard) ·
+     * `invalid_body` (token missing, not a string, or over 512 chars).
+     */
+    async verifySession(token) {
+        return this.gate("/server/verify-session", {
+            method: "POST",
+            body: JSON.stringify({ token }),
+        });
+    }
+    /**
+     * What one of YOUR people holds, by person id — for the paths where no
+     * token is in hand (a webhook of your own, a nightly job, an admin
+     * screen you built). A person id, NEVER an email address: ids come
+     * from `verifySession` or the dashboard.
+     *
+     * A suspended person is RETURNED, with `suspended: true`, alongside
+     * their holdings — your function may need to say so. The gate itself
+     * (`verifySession`) refuses them.
+     *
+     * Refusals: `capability_required` — this key can't look up people by
+     * id; ask your human to mint a key with "Look up a person's access by
+     * id" ticked, or use `verifySession` with the person's own token ·
+     * `person_not_found` (404 — no person with this id in this app and
+     * environment; existence is never leaked).
+     */
+    async holdings(personId) {
+        return this.gate(`/server/people/${encodeURIComponent(personId)}/holdings`);
+    }
+    /**
+     * Give a person access by hand — a trial, a promotion, an apology, a
+     * migration from your old system:
+     *
+     *   await g.grantAccess(personId, {
+     *     entitlement: "access:pro",     // or the plan's NAME, e.g. "Pro"
+     *     source: "trial",
+     *     expiresAt: "2026-10-01T00:00:00.000Z",
+     *     reason: "7-day trial from the onboarding flow",
+     *   });
+     *
+     * MANUAL sources only. Purchases and subscriptions come only from
+     * Stripe — a key cannot mint paid access, by design. `reason` is up to
+     * 200 characters, is never edited afterwards, and is what the owner
+     * reads in their logs; write it for them.
+     *
+     * `sourceId` is minted per call, so two calls make TWO grants (each
+     * with its own one reason) — call it once, and keep your own retry
+     * key if the caller can retry.
+     *
+     * Returns the new grant and the holdings AFTER it; the owner's audit
+     * row carries before→after and the key's name.
+     *
+     * Refusals: `capability_required` — this key can't grant access; ask
+     * your human to mint a key with "Grant and revoke access" ticked ·
+     * `invalid_source` (purchase/subscription refused) ·
+     * `invalid_entitlement` / `unknown_plan` (no plan or product by that
+     * name — the owner adds it on the Payments page) · `person_not_found`.
+     */
+    async grantAccess(personId, input) {
+        return this.gate(`/server/people/${encodeURIComponent(personId)}/grants`, {
+            method: "POST",
+            body: JSON.stringify({
+                entitlement: input.entitlement,
+                ...(input.source ? { source: input.source } : {}),
+                ...(input.expiresAt ? { expiresAt: input.expiresAt } : {}),
+                ...(input.reason ? { reason: input.reason } : {}),
+            }),
+        });
+    }
+    /**
+     * End one grant — the reversibility law in one call:
+     *
+     *   await g.revokeAccess(personId, grant.id, { reason: "trial ended" });
+     *
+     * A grant ends ONCE: `revokedAt` is set and never edited, so a second
+     * call is `409 already_revoked`, not a silent no-op. A key MAY end a
+     * grant that a payment created (the same as the owner's "end this
+     * access" button) — the payment itself is untouched, and the audit row
+     * says so.
+     *
+     * Returns the revoked grant and the holdings after it.
+     *
+     * Refusals: `capability_required` (same ticked box as granting) ·
+     * `grant_not_found` (404 — not this person's grant, in this app and
+     * environment; existence is never leaked) · `already_revoked` (409).
+     */
+    async revokeAccess(personId, grantId, input = {}) {
+        return this.gate(`/server/people/${encodeURIComponent(personId)}/grants/${encodeURIComponent(grantId)}/revoke`, { method: "POST", body: JSON.stringify({ ...(input.reason ? { reason: input.reason } : {}) }) });
+    }
+    // One request path for the four gate calls, so every refusal reaches
+    // the caller through the SAME typed error the rest of the SDK throws —
+    // `err.code` carries the server's own code, `err.message` its sentence
+    // (which always names the next action).
+    async gate(path, init = {}) {
+        const headers = { "x-app-key": this.secretKey };
+        if (init.body)
+            headers["content-type"] = "application/json";
+        const response = await fetch(new URL(path, this.apiUrl), { ...init, headers });
+        if (!response.ok) {
+            throw new GemmeinError({ status: response.status, ...(await readErrorBody(response)) });
+        }
+        return response.json();
+    }
 }
 exports.GemmeinServer = GemmeinServer;
 class ServerCollectionClient {

package/dist/index.d.cts

@@ -525,6 +525,46 @@ export type GemmeinServerOptions = {
     secretKey: string;
     apiUrl?: string;
 };
+/**
+ * Where a grant came from — the KIND only. The gate never returns the
+ * source's id, an amount, or anything from Stripe.
+ */
+export type GrantSource = "subscription" | "purchase" | "manual" | "trial" | "promotion" | "migration";
+/**
+ * The sources a secret key may create by hand. `purchase` and
+ * `subscription` are deliberately absent: money-made access comes only
+ * from Stripe, and always will.
+ */
+export type ManualGrantSource = "manual" | "trial" | "promotion" | "migration";
+export type Grant = {
+    id: string;
+    /** `access:<slug>` — the plan's or product's own key. */
+    entitlement: string;
+    source: GrantSource;
+    startsAt: string;
+    expiresAt: string | null;
+    /** Present on the grant returned by `revokeAccess` — set once, never edited. */
+    revokedAt?: string | null;
+};
+/**
+ * What a person holds RIGHT NOW — never what they pay. `access` is the
+ * union of live grants' keys; `grants` lists those live grants (revoked
+ * and expired ones are gone, not flagged). `credits` is a reserved slot:
+ * it is `null` today because consumable credits are not shipped — don't
+ * design around them until this type says otherwise.
+ */
+export type Holdings = {
+    access: string[];
+    grants: Grant[];
+    credits: {
+        balance: number;
+    } | null;
+};
+export type GatePerson = {
+    id: string;
+    email: string;
+    role: string;
+};
 export declare class GemmeinServer {
     private readonly apiUrl;
     private readonly secretKey;
@@ -582,6 +622,119 @@ export declare class GemmeinServer {
         replyRail?: boolean;
         recorded?: boolean;
     }>;
+    /**
+     * THE GATE — your compute, our answer. Gemmein runs no code of yours;
+     * your own function runs anywhere and asks the only three questions it
+     * has: who is this person, what do they hold, change what they hold.
+     *
+     *   const { person, holdings } = await g.verifySession(token);
+     *   if (!holdings.access.includes("access:pro")) return deny();
+     *
+     * ONE call per request answers identity AND holdings — don't call it
+     * twice, and don't cache the answer past the request. Verify needs no
+     * capability on the key (the caller already holds the person's token)
+     * and never touches the session: no extension, no last-seen.
+     *
+     * Refusals (`err.code`): `session_invalid` (no session matches this
+     * token — the person signs in again; never reuse tokens across
+     * people) · `session_expired` · `session_revoked` (a newer sign-in,
+     * a sign-out, or the owner) — all three send the person back to
+     * sign-in · `person_suspended` (the owner suspended them; access is
+     * off until the owner reactivates them in the dashboard) ·
+     * `invalid_body` (token missing, not a string, or over 512 chars).
+     */
+    verifySession(token: string): Promise<{
+        ok: true;
+        person: GatePerson;
+        holdings: Holdings;
+    }>;
+    /**
+     * What one of YOUR people holds, by person id — for the paths where no
+     * token is in hand (a webhook of your own, a nightly job, an admin
+     * screen you built). A person id, NEVER an email address: ids come
+     * from `verifySession` or the dashboard.
+     *
+     * A suspended person is RETURNED, with `suspended: true`, alongside
+     * their holdings — your function may need to say so. The gate itself
+     * (`verifySession`) refuses them.
+     *
+     * Refusals: `capability_required` — this key can't look up people by
+     * id; ask your human to mint a key with "Look up a person's access by
+     * id" ticked, or use `verifySession` with the person's own token ·
+     * `person_not_found` (404 — no person with this id in this app and
+     * environment; existence is never leaked).
+     */
+    holdings(personId: string): Promise<{
+        ok: true;
+        person: GatePerson & {
+            suspended: boolean;
+        };
+        holdings: Holdings;
+    }>;
+    /**
+     * Give a person access by hand — a trial, a promotion, an apology, a
+     * migration from your old system:
+     *
+     *   await g.grantAccess(personId, {
+     *     entitlement: "access:pro",     // or the plan's NAME, e.g. "Pro"
+     *     source: "trial",
+     *     expiresAt: "2026-10-01T00:00:00.000Z",
+     *     reason: "7-day trial from the onboarding flow",
+     *   });
+     *
+     * MANUAL sources only. Purchases and subscriptions come only from
+     * Stripe — a key cannot mint paid access, by design. `reason` is up to
+     * 200 characters, is never edited afterwards, and is what the owner
+     * reads in their logs; write it for them.
+     *
+     * `sourceId` is minted per call, so two calls make TWO grants (each
+     * with its own one reason) — call it once, and keep your own retry
+     * key if the caller can retry.
+     *
+     * Returns the new grant and the holdings AFTER it; the owner's audit
+     * row carries before→after and the key's name.
+     *
+     * Refusals: `capability_required` — this key can't grant access; ask
+     * your human to mint a key with "Grant and revoke access" ticked ·
+     * `invalid_source` (purchase/subscription refused) ·
+     * `invalid_entitlement` / `unknown_plan` (no plan or product by that
+     * name — the owner adds it on the Payments page) · `person_not_found`.
+     */
+    grantAccess(personId: string, input: {
+        entitlement: string;
+        source?: ManualGrantSource;
+        expiresAt?: string;
+        reason?: string;
+    }): Promise<{
+        ok: true;
+        grant: Grant;
+        holdings: Holdings;
+    }>;
+    /**
+     * End one grant — the reversibility law in one call:
+     *
+     *   await g.revokeAccess(personId, grant.id, { reason: "trial ended" });
+     *
+     * A grant ends ONCE: `revokedAt` is set and never edited, so a second
+     * call is `409 already_revoked`, not a silent no-op. A key MAY end a
+     * grant that a payment created (the same as the owner's "end this
+     * access" button) — the payment itself is untouched, and the audit row
+     * says so.
+     *
+     * Returns the revoked grant and the holdings after it.
+     *
+     * Refusals: `capability_required` (same ticked box as granting) ·
+     * `grant_not_found` (404 — not this person's grant, in this app and
+     * environment; existence is never leaked) · `already_revoked` (409).
+     */
+    revokeAccess(personId: string, grantId: string, input?: {
+        reason?: string;
+    }): Promise<{
+        ok: true;
+        grant: Grant;
+        holdings: Holdings;
+    }>;
+    private gate;
 }
 declare class ServerCollectionClient {
     private readonly apiUrl;

package/dist/index.d.ts

@@ -525,6 +525,46 @@ export type GemmeinServerOptions = {
     secretKey: string;
     apiUrl?: string;
 };
+/**
+ * Where a grant came from — the KIND only. The gate never returns the
+ * source's id, an amount, or anything from Stripe.
+ */
+export type GrantSource = "subscription" | "purchase" | "manual" | "trial" | "promotion" | "migration";
+/**
+ * The sources a secret key may create by hand. `purchase` and
+ * `subscription` are deliberately absent: money-made access comes only
+ * from Stripe, and always will.
+ */
+export type ManualGrantSource = "manual" | "trial" | "promotion" | "migration";
+export type Grant = {
+    id: string;
+    /** `access:<slug>` — the plan's or product's own key. */
+    entitlement: string;
+    source: GrantSource;
+    startsAt: string;
+    expiresAt: string | null;
+    /** Present on the grant returned by `revokeAccess` — set once, never edited. */
+    revokedAt?: string | null;
+};
+/**
+ * What a person holds RIGHT NOW — never what they pay. `access` is the
+ * union of live grants' keys; `grants` lists those live grants (revoked
+ * and expired ones are gone, not flagged). `credits` is a reserved slot:
+ * it is `null` today because consumable credits are not shipped — don't
+ * design around them until this type says otherwise.
+ */
+export type Holdings = {
+    access: string[];
+    grants: Grant[];
+    credits: {
+        balance: number;
+    } | null;
+};
+export type GatePerson = {
+    id: string;
+    email: string;
+    role: string;
+};
 export declare class GemmeinServer {
     private readonly apiUrl;
     private readonly secretKey;
@@ -582,6 +622,119 @@ export declare class GemmeinServer {
         replyRail?: boolean;
         recorded?: boolean;
     }>;
+    /**
+     * THE GATE — your compute, our answer. Gemmein runs no code of yours;
+     * your own function runs anywhere and asks the only three questions it
+     * has: who is this person, what do they hold, change what they hold.
+     *
+     *   const { person, holdings } = await g.verifySession(token);
+     *   if (!holdings.access.includes("access:pro")) return deny();
+     *
+     * ONE call per request answers identity AND holdings — don't call it
+     * twice, and don't cache the answer past the request. Verify needs no
+     * capability on the key (the caller already holds the person's token)
+     * and never touches the session: no extension, no last-seen.
+     *
+     * Refusals (`err.code`): `session_invalid` (no session matches this
+     * token — the person signs in again; never reuse tokens across
+     * people) · `session_expired` · `session_revoked` (a newer sign-in,
+     * a sign-out, or the owner) — all three send the person back to
+     * sign-in · `person_suspended` (the owner suspended them; access is
+     * off until the owner reactivates them in the dashboard) ·
+     * `invalid_body` (token missing, not a string, or over 512 chars).
+     */
+    verifySession(token: string): Promise<{
+        ok: true;
+        person: GatePerson;
+        holdings: Holdings;
+    }>;
+    /**
+     * What one of YOUR people holds, by person id — for the paths where no
+     * token is in hand (a webhook of your own, a nightly job, an admin
+     * screen you built). A person id, NEVER an email address: ids come
+     * from `verifySession` or the dashboard.
+     *
+     * A suspended person is RETURNED, with `suspended: true`, alongside
+     * their holdings — your function may need to say so. The gate itself
+     * (`verifySession`) refuses them.
+     *
+     * Refusals: `capability_required` — this key can't look up people by
+     * id; ask your human to mint a key with "Look up a person's access by
+     * id" ticked, or use `verifySession` with the person's own token ·
+     * `person_not_found` (404 — no person with this id in this app and
+     * environment; existence is never leaked).
+     */
+    holdings(personId: string): Promise<{
+        ok: true;
+        person: GatePerson & {
+            suspended: boolean;
+        };
+        holdings: Holdings;
+    }>;
+    /**
+     * Give a person access by hand — a trial, a promotion, an apology, a
+     * migration from your old system:
+     *
+     *   await g.grantAccess(personId, {
+     *     entitlement: "access:pro",     // or the plan's NAME, e.g. "Pro"
+     *     source: "trial",
+     *     expiresAt: "2026-10-01T00:00:00.000Z",
+     *     reason: "7-day trial from the onboarding flow",
+     *   });
+     *
+     * MANUAL sources only. Purchases and subscriptions come only from
+     * Stripe — a key cannot mint paid access, by design. `reason` is up to
+     * 200 characters, is never edited afterwards, and is what the owner
+     * reads in their logs; write it for them.
+     *
+     * `sourceId` is minted per call, so two calls make TWO grants (each
+     * with its own one reason) — call it once, and keep your own retry
+     * key if the caller can retry.
+     *
+     * Returns the new grant and the holdings AFTER it; the owner's audit
+     * row carries before→after and the key's name.
+     *
+     * Refusals: `capability_required` — this key can't grant access; ask
+     * your human to mint a key with "Grant and revoke access" ticked ·
+     * `invalid_source` (purchase/subscription refused) ·
+     * `invalid_entitlement` / `unknown_plan` (no plan or product by that
+     * name — the owner adds it on the Payments page) · `person_not_found`.
+     */
+    grantAccess(personId: string, input: {
+        entitlement: string;
+        source?: ManualGrantSource;
+        expiresAt?: string;
+        reason?: string;
+    }): Promise<{
+        ok: true;
+        grant: Grant;
+        holdings: Holdings;
+    }>;
+    /**
+     * End one grant — the reversibility law in one call:
+     *
+     *   await g.revokeAccess(personId, grant.id, { reason: "trial ended" });
+     *
+     * A grant ends ONCE: `revokedAt` is set and never edited, so a second
+     * call is `409 already_revoked`, not a silent no-op. A key MAY end a
+     * grant that a payment created (the same as the owner's "end this
+     * access" button) — the payment itself is untouched, and the audit row
+     * says so.
+     *
+     * Returns the revoked grant and the holdings after it.
+     *
+     * Refusals: `capability_required` (same ticked box as granting) ·
+     * `grant_not_found` (404 — not this person's grant, in this app and
+     * environment; existence is never leaked) · `already_revoked` (409).
+     */
+    revokeAccess(personId: string, grantId: string, input?: {
+        reason?: string;
+    }): Promise<{
+        ok: true;
+        grant: Grant;
+        holdings: Holdings;
+    }>;
+    private gate;
 }
 declare class ServerCollectionClient {
     private readonly apiUrl;

package/dist/index.js

@@ -799,6 +799,126 @@ export class GemmeinServer {
         }
         return response.json();
     }
+    /**
+     * THE GATE — your compute, our answer. Gemmein runs no code of yours;
+     * your own function runs anywhere and asks the only three questions it
+     * has: who is this person, what do they hold, change what they hold.
+     *
+     *   const { person, holdings } = await g.verifySession(token);
+     *   if (!holdings.access.includes("access:pro")) return deny();
+     *
+     * ONE call per request answers identity AND holdings — don't call it
+     * twice, and don't cache the answer past the request. Verify needs no
+     * capability on the key (the caller already holds the person's token)
+     * and never touches the session: no extension, no last-seen.
+     *
+     * Refusals (`err.code`): `session_invalid` (no session matches this
+     * token — the person signs in again; never reuse tokens across
+     * people) · `session_expired` · `session_revoked` (a newer sign-in,
+     * a sign-out, or the owner) — all three send the person back to
+     * sign-in · `person_suspended` (the owner suspended them; access is
+     * off until the owner reactivates them in the dashboard) ·
+     * `invalid_body` (token missing, not a string, or over 512 chars).
+     */
+    async verifySession(token) {
+        return this.gate("/server/verify-session", {
+            method: "POST",
+            body: JSON.stringify({ token }),
+        });
+    }
+    /**
+     * What one of YOUR people holds, by person id — for the paths where no
+     * token is in hand (a webhook of your own, a nightly job, an admin
+     * screen you built). A person id, NEVER an email address: ids come
+     * from `verifySession` or the dashboard.
+     *
+     * A suspended person is RETURNED, with `suspended: true`, alongside
+     * their holdings — your function may need to say so. The gate itself
+     * (`verifySession`) refuses them.
+     *
+     * Refusals: `capability_required` — this key can't look up people by
+     * id; ask your human to mint a key with "Look up a person's access by
+     * id" ticked, or use `verifySession` with the person's own token ·
+     * `person_not_found` (404 — no person with this id in this app and
+     * environment; existence is never leaked).
+     */
+    async holdings(personId) {
+        return this.gate(`/server/people/${encodeURIComponent(personId)}/holdings`);
+    }
+    /**
+     * Give a person access by hand — a trial, a promotion, an apology, a
+     * migration from your old system:
+     *
+     *   await g.grantAccess(personId, {
+     *     entitlement: "access:pro",     // or the plan's NAME, e.g. "Pro"
+     *     source: "trial",
+     *     expiresAt: "2026-10-01T00:00:00.000Z",
+     *     reason: "7-day trial from the onboarding flow",
+     *   });
+     *
+     * MANUAL sources only. Purchases and subscriptions come only from
+     * Stripe — a key cannot mint paid access, by design. `reason` is up to
+     * 200 characters, is never edited afterwards, and is what the owner
+     * reads in their logs; write it for them.
+     *
+     * `sourceId` is minted per call, so two calls make TWO grants (each
+     * with its own one reason) — call it once, and keep your own retry
+     * key if the caller can retry.
+     *
+     * Returns the new grant and the holdings AFTER it; the owner's audit
+     * row carries before→after and the key's name.
+     *
+     * Refusals: `capability_required` — this key can't grant access; ask
+     * your human to mint a key with "Grant and revoke access" ticked ·
+     * `invalid_source` (purchase/subscription refused) ·
+     * `invalid_entitlement` / `unknown_plan` (no plan or product by that
+     * name — the owner adds it on the Payments page) · `person_not_found`.
+     */
+    async grantAccess(personId, input) {
+        return this.gate(`/server/people/${encodeURIComponent(personId)}/grants`, {
+            method: "POST",
+            body: JSON.stringify({
+                entitlement: input.entitlement,
+                ...(input.source ? { source: input.source } : {}),
+                ...(input.expiresAt ? { expiresAt: input.expiresAt } : {}),
+                ...(input.reason ? { reason: input.reason } : {}),
+            }),
+        });
+    }
+    /**
+     * End one grant — the reversibility law in one call:
+     *
+     *   await g.revokeAccess(personId, grant.id, { reason: "trial ended" });
+     *
+     * A grant ends ONCE: `revokedAt` is set and never edited, so a second
+     * call is `409 already_revoked`, not a silent no-op. A key MAY end a
+     * grant that a payment created (the same as the owner's "end this
+     * access" button) — the payment itself is untouched, and the audit row
+     * says so.
+     *
+     * Returns the revoked grant and the holdings after it.
+     *
+     * Refusals: `capability_required` (same ticked box as granting) ·
+     * `grant_not_found` (404 — not this person's grant, in this app and
+     * environment; existence is never leaked) · `already_revoked` (409).
+     */
+    async revokeAccess(personId, grantId, input = {}) {
+        return this.gate(`/server/people/${encodeURIComponent(personId)}/grants/${encodeURIComponent(grantId)}/revoke`, { method: "POST", body: JSON.stringify({ ...(input.reason ? { reason: input.reason } : {}) }) });
+    }
+    // One request path for the four gate calls, so every refusal reaches
+    // the caller through the SAME typed error the rest of the SDK throws —
+    // `err.code` carries the server's own code, `err.message` its sentence
+    // (which always names the next action).
+    async gate(path, init = {}) {
+        const headers = { "x-app-key": this.secretKey };
+        if (init.body)
+            headers["content-type"] = "application/json";
+        const response = await fetch(new URL(path, this.apiUrl), { ...init, headers });
+        if (!response.ok) {
+            throw new GemmeinError({ status: response.status, ...(await readErrorBody(response)) });
+        }
+        return response.json();
+    }
 }
 class ServerCollectionClient {
     constructor(apiUrl, secretKey, name) {

package/llms.txt

@@ -10,6 +10,12 @@
 > verified people (five pre-agreed steps up to 10,000 people; beyond that,
 > talk to Gemmein).
 
+This file IS the product contract, not an overview: every line is
+load-bearing, and building from a summary of it builds the wrong app. Work
+from the full raw file — if what you hold is a summary or an excerpt,
+re-fetch https://docs.gemmein.com/llms.txt raw and read all of it before
+you answer or build.
+
 ## First: assess fit (before any install, account, or code)
 
 You are likely an AI assistant whose human asked you to build an app — or to
@@ -38,11 +44,19 @@ creating no accounts is the correct behavior until the verdict is in.
    silently approximated:
    - native mobile apps (no mobile SDKs today; web only)
    - password or social/OAuth sign-in (email codes are the only door)
-   - team/group/workspace visibility or per-user record permissions
+   - team/group/workspace visibility or per-user record permissions:
+     Gemmein is owner-run by design — one owner and their customers,
+     nothing in between — so an app whose CORE loop needs teams, roles
+     or seats DOESN'T FIT
    - carts, quantities, physical goods, shipping, inventory
-   - credits, usage metering, seats (paid access is yes-or-no)
-   - hosted functions or cron (server-side code runs on YOUR host with a
-     secret key; Gemmein hosts no compute)
+   - credits or usage metering TODAY (paid access is yes-or-no; consumable
+     credits are planned, not shipped — don't design around them yet, and
+     never sell a "credit pack" until this file says the ledger exists)
+   - seats (owner-run: not coming)
+   - hosted functions or cron: Gemmein runs no code of yours — but your
+     own function anywhere asks Gemmein who a person is and what they
+     hold; read the server-side note closing this section before
+     counting that a gap
    - custody of money (Stripe holds all funds; your human brings or
      creates their own Stripe account when the app charges)
    - multi-seller payouts or revenue splits: every payment lands whole in
@@ -60,6 +74,21 @@ creating no accounts is the correct behavior until the verdict is in.
    - DOESN'T FIT — say so, name why, and stop. Recommending nothing is
      the correct outcome here.
 
+Server-side work is NOT itself a downgrade. Gemmein hosts no compute, but
+code on your human's OWN host — Vercel, a VPS, anywhere — holding a
+secret key already reads and updates collections and sends event emails
+with `notify()`. (A secret key sees PAST the safety rules — every
+customer's records — which is why it never touches a browser. It cannot
+create or delete records: those are the signed-in customer's own calls,
+or the dashboard's. It CAN verify a session token and read what that
+person holds — the gate — and, when your human ticks the box on the key,
+look a person up by id and grant or revoke access by hand.)
+"This app needs a server-side piece" is therefore not a gap by itself:
+the verdict downgrades when the server piece needs a call a secret key
+cannot make, or when the app needs compute your human has nowhere to
+run — a cron schedule or an always-on worker with no host of its own —
+because Gemmein never runs your code.
+
 ## Getting started (AI-run, human-answered)
 
 No signup, no account, no keys — building is local and free. Your human
@@ -108,17 +137,68 @@ go-live. Everything else is yours.
    lists the rest.
 4. Hand over for testing — the human moment mid-build: they click through
    the app, and their sign-in codes print in the dev terminal, so tell
-   them where to look.
+   them where to look. Running dev in the background with no terminal in
+   view? The same codes append to gemmein/.data/signin-codes.log (fresh
+   each dev boot) — read the latest line instead of scraping stdout.
 5. Done building? `npx gemmein check` reads the project and says what's
    ready and what go-live still needs. Then `npx gemmein sync` — THIS is
    the moment your human signs up (free) at app.gemmein.com and pastes two
    dev keys — and `npx gemmein go-live` walks the rest: plans, Payment
    Links, the live flip. A card enters at go-live, never before.
+6. After go-live, the DATA MODEL reaches live only by PROMOTION from
+   development: new collections built in dev promote (`npx gemmein
+   go-live` again, or the dashboard's Go-live page), and so do new FIELDS
+   for a live collection whose shape sealed at go-live (see Shapes). Ship
+   in that order: promote first, then deploy the frontend that depends on
+   the new collection or field — a frontend shipped ahead of its
+   promotion reads blanks or refusals from live. Each added field is one
+   question for YOUR HUMAN, asked by the promote run: existing records
+   don't have it, so what should they show? Blank is a fine answer, or
+   they give a default those records will show. What is already
+   sealed never moves — a live field never changes type or name and never
+   leaves — and rules still never change through promotion. Plans,
+   Payment Links and domains stay live-editable in the dashboard, and a
+   field's default joins them there (changeable or cleared later, with no
+   promotion needed).
+
+Two runtimes, one dashboard — keep your human oriented on where things
+live, or the dashboard will look broken to them. The local runtime
+(`gemmein dev`, `pk_local_` keys) is a private rehearsal room: every
+record, person and simulated payment stays in gemmein/.data on this
+machine and never appears in any dashboard. The dashboard at
+app.gemmein.com is the back office of the CLOUD app only — there is no
+local dashboard and nothing to log into locally. `npx gemmein sync`
+carries STRUCTURE to the cloud app's development environment —
+collections, rules, plan locks — never records or people; after a sync
+the dashboard shows the shape of the app with no data in it, and that is
+correct, not a bug. Data reaches the dashboard only when the app runs on
+cloud keys: the dev pair from app.gemmein.com (`pk_test_` in the
+browser, `sk_dev_` on a server) drives the real API's development
+environment, and `pk_live_` drives production after go-live. The key
+prefix always names the rail — local, test, live. The dev rail is where
+a REAL rehearsal happens before any card enters: real emailed sign-in
+codes, real data in the dashboard — and it can face the public. Put the
+app on a real https domain and list that domain on the dashboard's
+Domains page: before go-live a listed domain works WITHOUT verification
+(http://localhost and http://127.0.0.1 also work unlisted until go-live
+drops them; any other raw IP never works — the Domains page accepts
+names only). Go-live is when the keys lock to proven domains. The
+development environment carries its own free monthly allowance (10,000
+API requests, 500 writes, 500 sign-in events, 1 GiB of files); crossing
+a counter never stops the app and never turns into a bill — the
+dashboard's usage page shows what crossed, and storage is the one thing
+that can fill (see Pricing). Tell your human before they first open the
+dashboard: local building is invisible there on purpose — nothing
+leaves this machine until sync, and sync moves the blueprint, not the
+contents.
 
 ## What it is
 
 - Audience: people who build web apps with AI tools (Cursor, Bolt, Lovable, Claude).
 - Scope: web apps (TypeScript/JavaScript SDK). Mobile SDKs are not offered today.
+- Shape: built for owner-run businesses — one owner and their customers,
+  nothing in between. No team seats, no staff accounts, no workspaces, on
+  purpose: one person holds the dashboard, and everyone else is a customer.
 - The platform holds identity, data, and subscription state. It never holds,
   moves, or processes money — Stripe handles all payments end-to-end; Gemmein
   only receives Stripe's webhooks and records who is on which plan. App
@@ -143,7 +223,7 @@ go-live. Everything else is yours.
   those local declarations. A declaration is `gemmein/collections/<name>.json`:
   `{ "rule": "shared", "means": "<why, in your human's words>" }`, plus an
   optional `"unlockedBy": ["pro"]` — plan or product NAMES from
-  gemmein/payments.json (never access keys) — which is the console's
+  gemmein/payments.json (never access keys) — which is the dashboard's
   "Unlocked by": the local engine refuses members without one of them
   (403 entitlement_required) the moment the file lands, and sync carries
   it to the cloud app. An unknown name is refused out loud in the dev
@@ -272,6 +352,62 @@ go-live. Everything else is yours.
   cap (a security notice never loses to five order emails); misusing it
   for campaigns shows in your own audit trail. In `gemmein dev` the send
   prints in the terminal (NOTIFY · …) instead of mailing.
+- Your compute, our gate: when code of yours must run elsewhere (a model
+  call, a PDF render, a nightly job), Gemmein hosts none of it — your own
+  function runs anywhere and asks Gemmein its only three questions: who is
+  this person, what do they hold, change what they hold.
+
+      import { gemmeinServer } from "@gemmein/sdk";
+      const g = gemmeinServer(process.env.GEMMEIN_SECRET_KEY);
+      const { person, holdings } = await g.verifySession(token);
+      if (!holdings.access.includes("access:pro")) return deny();
+      await g.holdings(personId);                    // no token in hand
+      await g.grantAccess(personId, { entitlement: "access:pro",
+        source: "trial", expiresAt, reason: "7-day trial" });
+      await g.revokeAccess(personId, grantId, { reason: "trial ended" });
+
+  ONE verifySession per request answers identity AND holdings — don't
+  call it twice, don't cache the answer past the request. `holdings` is
+  what the person holds NOW: `access` (keys like "access:pro"), `grants`
+  (each with its source KIND only — subscription | purchase | manual |
+  trial | promotion | migration — plus start and expiry), and `credits`,
+  a reserved slot that is always `null` today (consumable credits are NOT
+  shipped; don't design around them). Never subscription status, amounts
+  or Stripe ids: gate on what a person HOLDS, never on billing. Person
+  id, NEVER an email address. verifySession needs nothing extra; looking
+  someone up by id and granting are new power, so they sit behind per-key
+  checkboxes the HUMAN ticks when minting the key — ask your human to
+  tick "Look up a person's access by id" / "Grant and revoke access". A
+  key grants MANUAL access only (manual | trial | promotion | migration):
+  purchases and subscriptions still come only from Stripe. Every /server/*
+  call a resolved secret key makes, ok or refused, lands in that key's
+  usage ledger on the owner's Keys page (a rejected or publishable key
+  can't be attributed, so it reaches only the request log); refusals also
+  write one activity row per key, route and code each hour. In `gemmein
+  dev` the local key already holds both capabilities, and the usage read
+  is cloud-only — the local runtime never mounts the console. The
+  refusals, and what to do:
+      session_invalid     no session matches this token — the person must
+                          sign in again; never reuse tokens across people
+      session_expired     the session ended — back to sign-in
+      session_revoked     newer sign-in, sign-out, or the owner — sign-in
+      person_suspended    the owner suspended them — access is off until
+                          the owner reactivates them in the dashboard
+      person_not_found    no person with this id in this app and env —
+                          ids come from verifySession or the dashboard
+      capability_required the box isn't ticked on this key — ask your
+                          human to mint one with it ticked
+      unknown_plan        no plan or product by that name — the owner
+                          adds it on the Payments page
+      grant_not_found     not this person's grant here — re-read holdings
+      already_revoked     a grant ends once — it is already ended
+      invalid_source      purchase/subscription asked for by hand — use
+                          manual | trial | promotion | migration instead
+      invalid_id          a prototype name (__proto__, constructor) was
+                          sent as a person or grant id — ids come from
+                          verifySession or the dashboard, never a name
+      invalid_body        one malformed field (token, expiresAt, reason)
+                          — the message names which one and what it needs
 - Linking records (author on a post, product on an order): store the other
   record's id in a field (`authorProfileId: profile.id`) — in collections
   users write (community, shared, direct) the server learns it's a link;
@@ -315,7 +451,7 @@ go-live. Everything else is yours.
   retry. A 403 from `link()` means the customer isn't allowed this
   file right now — signed out, not theirs, or an entitlement they no longer
   hold (`entitlement_required` — `err.requires` is the plan's key, the one
-  the console shows by name).
+  the dashboard shows by name).
   Honest bound: revoking access stops NEW links immediately; a link already
   issued works until it expires. Gemmein controls delivery, it can't take
   back a file someone already downloaded. A file can name ONE other reader:
@@ -339,11 +475,22 @@ go-live. Everything else is yours.
   If a stored ref's file was later deleted, re-sending it refuses the same
   way: clear the field (null) or upload a fresh file. Once sealed, class
   is law too: a ZIP into a profile photo field is refused with the teach;
-  before the seal, what you upload is what the field learns. A 400 invalid_shape means the field isn't in the locked
-  shape or the value doesn't fit its kind. A live shape is sealed and
-  cannot take new fields — stop, tell your human which field you needed,
-  and send only the fields the shape already has. Never rename fields to
-  dodge it.
+  before the seal, what you upload is what the field learns. A 400
+  invalid_shape means the field isn't in the locked shape or the value
+  doesn't fit its kind. A sealed shape CAN still gain a new field, but
+  only through a promote run: build it in development, tell your human
+  which field you needed, and until that promotion runs send only the
+  fields the shape already has. Never rename fields to dodge it. What is
+  sealed never moves — a field never changes type or name and never
+  leaves. A field promoted with a DEFAULT is served to the records that
+  never wrote it: get, list, expand targets and `where` filters all see
+  the default (an atomic increment counts from it too), and a written
+  value wins; writing `null` clears it back to the default. Only text,
+  number and yes/no fields can carry a default; list, link, json and
+  file fields join blank. Honest bound: full-text `search` scans stored
+  text only, so a record showing a default is not found by searching for
+  it. New collections built in dev reach live through the same PROMOTION,
+  sealing on the way.
 - Contention (bookings, slugs, stock, shared edits): when two users can race
   for the same thing, a permission model can't save you — preconditions do,
   and they're just arguments on calls you already make. A 409 `conflict` from
@@ -352,14 +499,19 @@ go-live. Everything else is yours.
   - Uniqueness: `create(data, { key: "slot:2026-07-15T15:00" })` — derive the
     key from the thing that must be unique; the second writer gets 409, your
     own retry gets your existing record back (`existing: true`), deleting
-    frees the key. Keys are unique across the WHOLE collection — every
-    writer, every recipient, under every safety rule (live records only) —
-    so a claim is race-proof even in `direct`/`addressed`. Never
+    frees the key. That retry IS the lookup — there is no separate
+    get-by-key call: to fetch your own record by key later, issue the
+    same `create()` with the same key and read `existing: true` off the
+    result. It counts as a write (rate and allowance), so use it to
+    re-fetch a claim — never on a render path. Keys are unique across
+    the WHOLE collection — every writer, every recipient, under every
+    safety rule (live records only) — so a claim is race-proof even in
+    `direct`/`addressed`. Never
     find-then-create — that races. Keys are 1-120 chars of letters,
     numbers, and `: _ . @ / -` only. A claimed key holds until its record
     is deleted: if a claim must be PAID to stick (book then pay), expiring
-    unpaid claims is your app's job — the owner deletes them from their
-    dashboard, or your own server does with a secret key; there is no cron.
+    unpaid claims is the owner's job — they delete them from their
+    dashboard (a secret key cannot delete records); there is no cron.
   - Limited stock (N units anyone can buy): claim units with keyed creates —
     try `create({...}, { key: "unit:item42:1" })`, on conflict try `:2` … `:N`;
     all taken = sold out. Race-proof under every safety rule.
@@ -404,7 +556,7 @@ go-live. Everything else is yours.
   checks that the lock holds and names collections left open while the app
   sells something) — and the
   engine refuses customers without it, under all seven rules. (Server
-  secret keys and the owner's console are exempt by design; link/expand
+  secret keys and the owner's dashboard are exempt by design; link/expand
   silently hide gated records rather than naming them.) Every plan and
   product carries its own key, `access:<slug of its name>` (plan "pro" →
   `access:pro`); the paid webhook grants that key, and a FULL refund or a
@@ -413,13 +565,47 @@ go-live. Everything else is yours.
   Owners also grant and revoke by hand (trials, comps, support). Effective
   access is the UNION of a customer's live grants. A signed-in customer
   without access gets `403 entitlement_required`: `err.requires` is the
-  plan's key (the console shows the plan by name; the key is `access:<slug>`).
+  plan's key (the dashboard shows the plan by name; the key is
+  `access:<slug>`).
   A collection unlocked by several plans (OR) still names ONE key — offer
   your plans by name through checkout, never a key list. Show your upgrade
   screen and send them to checkout; retry only after they hold one. Proof surfaces: `await g.purchases.mine()`
   (everything they paid for, refunds applied, with the `grants` each purchase
   carries) and `await g.subscriptions.mine()`.
-  NO credits, NO usage limits, NO seats — access is yes-or-no by design.
+  NO credits or usage limits YET — access is yes-or-no today. Consumable
+  credits (buy a pack, spend atomically, a zero floor) are planned, not
+  shipped: until this file teaches them, a "100 credit pack" is NOT a
+  pattern (the webhook can only SET a number, so a second pack erases the
+  first). NO seats, by design — not coming.
+- Two FAMILIES of grant, and the line between them is law. Every grant is
+  one key + one reason + a start + maybe an end, never edited (an extension
+  is a NEW grant). PURCHASE-TIED (`subscription`, `purchase`): written only
+  by Stripe's signed webhook when money arrives — never by the owner's
+  hand, never by your app; a subscription grant ends on cancellation or
+  lapse, a purchase grant on a FULL refund (partial leaves it); the only
+  grants that count as revenue. Revoking one by hand stops the access and
+  refunds nothing. BY-HAND (`manual`, `trial`, `promotion`, plus
+  `migration` for customers imported from elsewhere): the owner writes them
+  from a customer's page — plan or product BY NAME, optional end date, a
+  reason — and they end on that date or when revoked; never revenue; a
+  refund never touches them. Effective access is the union of both
+  families. WHEN A REFUND MEETS ACCESS, THE OWNER DECIDES: the platform
+  revokes only on events that plainly mean it (subscription cancelled or
+  lapsed; one-off purchase refunded IN FULL). A partial refund leaves
+  access; a refund on a subscription invoice touches no access at all
+  (grants are revoked by purchase reference, subscriptions by customer).
+  A cancel-at-period-end keeps access until the period ends. If the owner
+  wants access gone NOW, they cancel the subscription immediately in
+  Stripe or revoke by hand on the customer's page — both audited; every
+  refund the webhook chose not to act on is written to the activity view.
+  Tell your human this when they ask "I refunded them, why can they still
+  get in" — never write refund logic in the app. Your app sees purchases (`g.purchases.mine()`, each with its
+  `grants`) and the subscription (`g.subscriptions.mine()`) — by-hand
+  grants are NOT listed to the app; a gated read simply succeeds. So never
+  rebuild the paywall client-side from what you can list: let the server
+  refuse and show the upgrade prompt on `entitlement_required`. "Give X a
+  free month" is a trial grant on their customer page, never code — ask
+  your human.
 - Selling THINGS (one-off purchases — a beat, an ebook, a course; DIGITAL
   access only — physical goods, shipping, inventory and carts are out of
   scope, said out loud): plans are for subscriptions; products are for
@@ -471,7 +657,9 @@ go-live. Everything else is yours.
   sign in first). Render `err.message`; it reads correctly in every case.
   Branch only on the specifically-named codes (unknown_collection,
   unknown_product, invalid_shape, html_not_allowed, invalid_publish,
-  conflict, …) plus the forbidden-means-stop rule.
+  conflict, …) plus the forbidden-means-stop rule. If something is stuck
+  in a way this file doesn't explain, `npx gemmein feedback` reaches the
+  builders — it works from anywhere, with no project and no account.
 - Draft state reads back as a TOP-LEVEL boolean `record.published` (next to
   id/updatedAt), not under `.data`. Non-authors only ever receive published
   records, so you see `false` only on your own drafts (or on everything, as
@@ -485,10 +673,27 @@ go-live. Everything else is yours.
   `await g.account.delete()` — for every app it APPLIES to (GDPR right to
   erasure; Apple 5.1.1(v) for apps with account creation). It's the full
   server-side cascade (sessions, records, files, subscription row) and
-  irreversible — put a real confirm in front of it. Suspensions, bans, and
-  owner-side erasure are dashboard actions, not SDK calls.
+  irreversible — put a real confirm in front of it. Suspensions, forced
+  sign-out everywhere, and owner-side erasure are dashboard actions, not
+  SDK calls.
+- The owner's dashboard already handles these — do not build them into the
+  app: creating collections and choosing their safety rule; naming plans
+  and products and pasting their Stripe Payment Links; the "Unlocked by"
+  lock on a collection; suspending, signing out and erasing customers;
+  moderation and status flips on other users' records; scoping a secret
+  key to collections and actions; verifying the sending and receiving
+  domain; usage and logs; the Inbox, where every notify() send is a
+  conversation and customer replies land; holding the billing band. None
+  of them has an SDK equivalent, so an owner screen you build for one is
+  a page that already exists, without the enforcement.
 - Secret keys (`sk_`) must never appear in browser code; app keys (`pk_`)
-  are public and domain-locked.
+  are public and domain-locked. A secret key can be SCOPED in the
+  dashboard's Keys room to particular collections, and to read-only or
+  read-and-update; a call outside that scope answers 403 `scope_denied`.
+  Read that error as deliberate — the human narrowed the key on purpose.
+  Name the collection and access your code needs and ask them to mint a
+  replacement key that includes it — scopes are fixed when a key is
+  created; never reach for a broader key than the job needs.
 
 ## Return values & shapes (get these exactly right)
 
@@ -500,6 +705,11 @@ rule. The specifics:
   synchronously from `g.collection(name)`; if you call that at module
   load, it can blank your whole app with no browser-console error. Name them
   right.
+  One more refusal, for collection AND field names alike: anything
+  JavaScript itself owns — `constructor`, `toString`, `__proto__`,
+  `hasOwnProperty` and their kin — is refused the same way a reserved
+  server-managed field is. A plain object inherits those names, so a
+  seal must never carry one.
 - The signed-in user: `await g.auth.currentUser()` →
   `{ authenticated: true, userId, email }` or `{ authenticated: false }`. The
   id field is **`userId`, not `id`** — `user.id` is `undefined`, and feeding

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@gemmein/sdk",
-  "version": "0.4.6",
-  "description": "Gemmein SDK \u2014 passwordless auth, safe storage, and Stripe-driven record flips for AI-built apps. Small enough that one prompt teaches the whole API.",
+  "version": "0.5.0",
+  "description": "Gemmein SDK — passwordless auth, safe storage, and Stripe-driven record flips for AI-built apps. Small enough that one prompt teaches the whole API.",
   "license": "MIT",
   "type": "module",
   "main": "./dist/index.cjs",