@everystack/mcp 0.4.8 → 0.4.9

package/CHANGELOG.md

@@ -4,6 +4,12 @@ All notable changes to `@everystack/mcp` are documented here.
 
 Format based on [Keep a Changelog](https://keepachangelog.com/).
 
+## [0.4.9] - 2026-09-08
+
+### Documentation
+
+- schema-patterns 'how a write compiles' is the shipped rule
+
 ## [0.4.8] - 2026-09-07
 
 ### Added

package/dist/index.cjs

@@ -23764,7 +23764,7 @@ async function runGovernanceCli(argv) {
 }
 
 // src/index.ts
-var version2 = (true ? "0.4.8" : null) ?? "0.3.0-dev";
+var version2 = (true ? "0.4.9" : null) ?? "0.3.0-dev";
 var INSTRUCTIONS = [
   "You govern how any agent builds everystack \u2014 a self-hosted application stack for Expo apps on AWS.",
   "Your job is not only to advise but to keep the build on-script: the architecture the maintainer",

package/dist/schema-patterns.md

@@ -158,24 +158,31 @@ RLS policy, and RLS is on for every model with abilities, so a grant with no pol
 an INSERT fails loudly (`new row violates row-level security policy`), while an UPDATE or
 DELETE with no policy affects **0 rows silently** — no error, nothing changes.
 
-- `owner:` / `via:` writes compile the owner-checked policy (`<t>_insert_own`, `_update_own`,
-  `_delete_own`) for `authenticated`. On such a model a bare `can('create')` or
-  `can('create', { role: 'authenticated' })` is ALSO the owner-checked insert — the example above.
-- `can('manage', { role: 'admin' })` is the admin bypass: one `ALL` policy, `true`/`true`.
-- **Known gap (cli 0.4.80):** a role-scoped or bare write with NO owner on the model and no
-  `where:` — `can('create', { role: 'authenticated' })` on an owner-less table, `can('delete',
-  { role: 'admin' })`, `can('manage', { role: 'editor' })` — compiles the grant and NO policy. It
-  reads as access and grants none. A vacuous `where: sql\`true\`` does NOT help: the compiler
-  discards a `true` predicate and still emits nothing. What compiles today: `owner:` / `via:`
-  for row-scoped writes; `can('manage', { role: 'admin' })` for the admin bypass; and, for
-  `authenticated` only, a real (non-vacuous) `where:` on a `create`/`update`/`delete`, which
-  compiles a predicate-only policy for `authenticated`. There is no in-model spelling for a
-  role-wide write by any other role — and do not try a `where:` on another role's write: the
-  write compiler never reads the declared role, so `can('update', { role: 'editor', where })`
-  grants editor and lands the predicate on the **`authenticated`** policy. Run that write on the
-  trusted admin connection until the write-policy matrix ships.
-- `check:` is the WITH CHECK half verbatim — it REPLACES the owner term, it does not narrow it —
-  so a `check:` on an owner model must carry the owner term itself.
+Every declared write compiles a policy — there is no shape that grants and then leaves the
+role dark. The rule, by who the write is for:
+
+- **`authenticated`** — named `role: 'authenticated'` or the role-less default:
+  - on a **row-scoped model** (some ability declares `owner:` or `via:`) it is ALWAYS
+    owner-checked: `<t>_insert_own` / `_update_own` / `_delete_own`. A bare `can('create')`,
+    `can('create', { role: 'authenticated' })`, or a `create` carrying only a `where:` all
+    compile the owner-checked insert on such a model — the role can never write a row it does
+    not own.
+  - on a model with **no row scope** it compiles `<t>_<verb>_authenticated`: `USING = where`
+    (or `true`), `WITH CHECK = check ?? where` (or `true`). A bare `can('create', { role:
+    'authenticated' })` on an owner-less table is a real `INSERT` policy with `WITH CHECK true`.
+- **any other role** — `admin`, `editor`, a custom role — gets its OWN policy, never folded
+  into `_own`. `can('update', { role: 'editor', where })` compiles `<t>_update_editor` carrying
+  the editor predicate; a `where:` on one role never lands on another's rows.
+- **`can('manage', { role })`** — for `authenticated`/role-less on a row-scoped model it is
+  manage-own (the four `_own` verbs); for any other role, or for `authenticated` with no row
+  scope, it is one `ALL` policy `<t>_<role>`, `true`/`true` (`<t>_admin` is just the first
+  instance of that rule).
+- A vacuous `where: sql\`true\`` is discarded (no `WHERE true` noise), but the policy still
+  exists — the predicate collapses to `true`, it does not delete the policy.
+- `check:` is the WITH CHECK half and it NARROWS: the compiled check is `rowScope AND check`,
+  symmetric with `USING = rowScope AND where`. The owner term is never removable — a `check:`
+  can tighten what a row may BECOME (a state guard the read did not carry) but can never let an
+  owner write a row into someone else's name.
 
 ## Handler Config for Schema
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@everystack/mcp",
-  "version": "0.4.8",
+  "version": "0.4.9",
   "description": "Governance layer that governs how any agent builds everystack — grounding, cheat gates, and Model-aware tooling over MCP",
   "license": "AGPL-3.0-only",
   "author": "Scalable Technology, Inc. <licensing@scalable.technology>",
@@ -42,7 +42,7 @@
     "tsx": "4.21.0",
     "typescript": "5.9.3",
     "zod": "3.25.67",
-    "@everystack/cli": "0.4.80",
+    "@everystack/cli": "0.4.81",
     "@everystack/server": "0.4.30",
     "@everystack/model": "0.4.17"
   },

package/src/resources/schema-patterns.md

@@ -158,24 +158,31 @@ RLS policy, and RLS is on for every model with abilities, so a grant with no pol
 an INSERT fails loudly (`new row violates row-level security policy`), while an UPDATE or
 DELETE with no policy affects **0 rows silently** — no error, nothing changes.
 
-- `owner:` / `via:` writes compile the owner-checked policy (`<t>_insert_own`, `_update_own`,
-  `_delete_own`) for `authenticated`. On such a model a bare `can('create')` or
-  `can('create', { role: 'authenticated' })` is ALSO the owner-checked insert — the example above.
-- `can('manage', { role: 'admin' })` is the admin bypass: one `ALL` policy, `true`/`true`.
-- **Known gap (cli 0.4.80):** a role-scoped or bare write with NO owner on the model and no
-  `where:` — `can('create', { role: 'authenticated' })` on an owner-less table, `can('delete',
-  { role: 'admin' })`, `can('manage', { role: 'editor' })` — compiles the grant and NO policy. It
-  reads as access and grants none. A vacuous `where: sql\`true\`` does NOT help: the compiler
-  discards a `true` predicate and still emits nothing. What compiles today: `owner:` / `via:`
-  for row-scoped writes; `can('manage', { role: 'admin' })` for the admin bypass; and, for
-  `authenticated` only, a real (non-vacuous) `where:` on a `create`/`update`/`delete`, which
-  compiles a predicate-only policy for `authenticated`. There is no in-model spelling for a
-  role-wide write by any other role — and do not try a `where:` on another role's write: the
-  write compiler never reads the declared role, so `can('update', { role: 'editor', where })`
-  grants editor and lands the predicate on the **`authenticated`** policy. Run that write on the
-  trusted admin connection until the write-policy matrix ships.
-- `check:` is the WITH CHECK half verbatim — it REPLACES the owner term, it does not narrow it —
-  so a `check:` on an owner model must carry the owner term itself.
+Every declared write compiles a policy — there is no shape that grants and then leaves the
+role dark. The rule, by who the write is for:
+
+- **`authenticated`** — named `role: 'authenticated'` or the role-less default:
+  - on a **row-scoped model** (some ability declares `owner:` or `via:`) it is ALWAYS
+    owner-checked: `<t>_insert_own` / `_update_own` / `_delete_own`. A bare `can('create')`,
+    `can('create', { role: 'authenticated' })`, or a `create` carrying only a `where:` all
+    compile the owner-checked insert on such a model — the role can never write a row it does
+    not own.
+  - on a model with **no row scope** it compiles `<t>_<verb>_authenticated`: `USING = where`
+    (or `true`), `WITH CHECK = check ?? where` (or `true`). A bare `can('create', { role:
+    'authenticated' })` on an owner-less table is a real `INSERT` policy with `WITH CHECK true`.
+- **any other role** — `admin`, `editor`, a custom role — gets its OWN policy, never folded
+  into `_own`. `can('update', { role: 'editor', where })` compiles `<t>_update_editor` carrying
+  the editor predicate; a `where:` on one role never lands on another's rows.
+- **`can('manage', { role })`** — for `authenticated`/role-less on a row-scoped model it is
+  manage-own (the four `_own` verbs); for any other role, or for `authenticated` with no row
+  scope, it is one `ALL` policy `<t>_<role>`, `true`/`true` (`<t>_admin` is just the first
+  instance of that rule).
+- A vacuous `where: sql\`true\`` is discarded (no `WHERE true` noise), but the policy still
+  exists — the predicate collapses to `true`, it does not delete the policy.
+- `check:` is the WITH CHECK half and it NARROWS: the compiled check is `rowScope AND check`,
+  symmetric with `USING = rowScope AND where`. The owner term is never removable — a `check:`
+  can tighten what a row may BECOME (a state guard the read did not carry) but can never let an
+  owner write a row into someone else's name.
 
 ## Handler Config for Schema