@astram/guide 0.2.11 → 0.2.13

package/CAPABILITIES.md

@@ -324,7 +324,11 @@ imports: [
   joins the outer transaction.
 - `transaction(fn)` runs several pipe calls in one unit of work (rolls back on any failed write);
   `lockForUpdate(typeKey, id)` serialises a check-then-write.
-- `@Field({ immutable: true })` create-only fields; `trusted` fields are stamped server-side.
+- `@Field({ immutable: true })` create-only fields; `@Field({ nullable: true })` fields that
+  create, update and `createMany` may set to NULL (`json` included: SQL NULL, not `"null"`;
+  the audit row lists the cleared keys, never values; the column must be NULL-able in your
+  migration; refused on trusted, primary-key, `readScope` and `required` fields). Without
+  `nullable`, `null` is a validation error. `trusted` fields are stamped server-side.
   `readScope` declares the subtree wall; `create: 'unscoped'` opts a type out of the create wall.
 - **Physical wall** — the raw DB pool is sealed in the engine. The scaffold's
   `server/eslint.config.mjs` fails lint on driver imports, raw pools, `.query()` and the
@@ -380,6 +384,17 @@ imports: [
   action or `*`). Allow resolves `void`; deny, a missing row and another tenant's row all throw
   the same `AuthorizationDeniedError` (403); an undeclared action throws `RegistrationError`
   (500) before any query. It returns no row data, writes no audit row and is not a list filter.
+- **Type-level check before the first write**: `records.authorizeType(typeKey, action)` (also on
+  `BoundRecords` and the `transaction(fn)` handle) needs no record id and writes nothing. Use it
+  when a request may or may not write a type, so the grant decides, not the data: e.g. call
+  `authorizeType('my_issue', 'create')` before writing a batch that has 0–500 issue rows. It runs
+  the same type-level decision a `create` runs (and the same refusals): allow resolves `void`,
+  deny throws `AuthorizationDeniedError` (403), an undeclared action throws `RegistrationError`.
+  No query, no audit row; a deny you catch inside `transaction(fn)` does not make it
+  rollback-only (an uncaught one rolls it back, as any throw does). It proves the
+  type grant only: a `readScope` create can still be refused after insert (outside your
+  subtree), and for `read`/`update`/`delete`/custom actions use `authorize(typeKey, id, action)`
+  for the record-level answer.
 - **A handler that writes needs two grants**: `authorize()` for the custom action, then the
   write through the normal pipe (`records.update(...)`), which needs `update` and is audited.
   There is no write under the custom action's key. With `activate` alone the update is 403. To

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@astram/guide",
-  "version": "0.2.11",
+  "version": "0.2.13",
   "license": "MIT",
   "description": "Astram framework — the AI/dev GUIDE layer (ADR-0025). Ships the framework's hard rules + capabilities manifest as installed, upgrade-refreshed docs. A consumer app's CLAUDE.md references FRAMEWORK_RULES.md from this package; `npm update` replaces it wholesale so new rules arrive cleanly, while the app's own .astram/guide/ layer is never touched. This is the framework-owned FLOOR: an app rule may tighten it, never weaken it.",
   "type": "commonjs",