@assembly-js/app-foundation 0.8.0 → 0.8.2

package/CHANGELOG.md

@@ -19,6 +19,12 @@ A patch release never changes what an app's build requires; a minor release may
 not by hand; see `changes/README.md`. CI fails a PR that changes a check script without a
 `bump: minor` change file.
 
+## 0.8.2
+- [guidance] The build agent states its reading of an ambiguous rule about money or stored records before building it, asks before writing that reading into live records, and enforces a rule the user has stated instead of warning about it.
+
+## 0.8.1
+- [guidance] The build agent keeps the session check on every API route, even when the user asks for a temporary unauthenticated test route.
+
 ## 0.8.0
 - [new] `useUrlState('id')` from `@assembly-js/app-foundation/client` keeps a record selection in the URL search string, so a record panel is deep-linkable without its own route.
 - [new] `bun run build` runs `check:record-urls`, which fails when a record panel is opened from React state alone, with neither the helper nor a dynamic route. It only runs on apps that carry the inner-location skill.

package/CLAUDE.md

@@ -12,7 +12,12 @@ In user-facing chat, never mention ASSEMBLY_ENV, COPILOT_ENV, or any other inter
 
 When you describe a feature or a change, describe what the user and their clients will **experience** — who can open the app, what each audience sees or can do. The mechanics that produce it are plumbing too: keep manifest keys (`surfaces`, `app.json`), file names, SDK method names, and identity fields like `clientId`/`internalUserId` out of chat unless the user asks how it works. "Clients will see only their own record" is something they can act on; "add a client surface to the manifest and branch on `identity.clientId`" is not.
 
-When a request implies a scope or permission change, apply it and report the product effect — don't stop to ask the user to approve the mechanics. "When a client views this, show them their own info" already means "make this client-facing," so make the change and say what happened ("clients now see just their own record; your team still sees everyone"). Ask first only on a genuine product choice the user can weigh — who should see the app, what each audience sees — phrased in those terms, never as a manifest or surface decision.
+When a request implies a scope or permission change, apply it and report the product effect — don't stop to ask the user to approve the mechanics. "When a client views this, show them their own info" already means "make this client-facing," so make the change and say what happened ("clients now see just their own record; your team still sees everyone"). Ask first only on a genuine product choice the user can weigh — who should see the app, what each audience sees, what a rule about money or stored records means (below) — phrased in those terms, never as a manifest or surface decision.
+
+**Rules about money or stored records.** "Refund 3 of the remaining meetings", "one late fee per vendor, never two": everyday words that decide what a client is charged or what a record says. If your closing summary would carry a caveat about one ("you didn't say which 3", "a vendor flagged in both rounds is still charged twice"), that gap belongs before the build, not after it.
+
+- When the words admit more than one reading, say the one you are building in one line before you build; a rule built as app logic can be changed next turn. A write to live records — rows in the app's database, client or company records, custom fields, invoices, refunds — cannot be taken back, so when the reading decides such a write, ask first and hold the write until the user confirms.
+- When the user has stated the rule, the app enforces it. A warning staff can click past, or a note beside two fields, is not an implementation of "never"; make the invalid state impossible instead.
 
 ---
 
@@ -1076,6 +1081,8 @@ export async function PATCH(
 
 **Auth is entirely cookie-borne: no `?token=`, no `x-assembly-token` header, no token proxy, no `TokenLink`/`useWithToken`, no client-side token at all.** The middleware put the bearer in the cookie; `getAssembly()` / `getAssemblyForRequest()` read it. That's the whole story.
 
+**Never add a route that skips the session check, and never loosen one.** Every handler under `app/api` that a viewer calls uses `requireAuth(…)` or `getAssemblyForRequest(…)`; a cron or webhook route has no viewer and verifies its own secret instead (below). The rule covers a route gated on `NODE_ENV`, a `DEBUG` or `SKIP_AUTH` flag, a secret path or `localhost`, and a route you mean to delete later: every preview deployment is reachable by anyone with its URL, so a dev-only route is a public one. It holds when the user asks for it ("just for now", "so I can test it"). You cannot sign in as staff or as a client from the sandbox, and a test route cannot make that possible either; say that you can't verify the page end to end from here, keep the guard, and test the handler's logic by calling its function with a plain argument. Never build a session, token or cookie yourself to get past a check.
+
 ### Offline bearer — background work with no user (cron, webhooks)
 
 **Anything on a schedule — a reminder, a digest, a recurring send — must first read the `assembly-scheduled-work` skill.** The route below only ever runs if `vercel.json` declares a cron for it and the route verifies `CRON_SECRET`; the offline bearer is the auth half, the skill is the scheduling half.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@assembly-js/app-foundation",
-  "version": "0.8.0",
+  "version": "0.8.2",
   "description": "Versioned foundation helpers and build context for Assembly generated apps",
   "type": "module",
   "files": [