@assembly-js/app-foundation 0.8.1 → 0.8.2

package/CHANGELOG.md

@@ -19,6 +19,9 @@ 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.
 

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.
 
 ---
 

package/package.json

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