@@ -0,0 +1,94 @@
+---
+"@objectstack/spec": minor
+"@objectstack/cli": minor
+"create-objectstack": minor
+---
+
+feat(spec)!: `manifest.id` enforces the reverse-domain rule its registry face already had (#17534)
+
+<!-- adr-0087: registered manifest-id-reverse-domain-required -->
+
+**BREAKING** in the accept-set sense, landing in the launch window as `minor`
+(the repo's convention: `major` is refused by `check-changeset-no-major`, and
+breaking-ness is carried by this banner plus the ADR-0087 disposition):
+`ManifestSchema.id` was `z.string()` and accepted any string. It now enforces
+reverse-domain notation — the same rule `PackageSchema.manifestId` has always
+carried, now declared once and referenced from both sites so the two cannot
+drift again.
+
+Two declarations named one identity and disagreed. The registry enforced the
+shape; the key an author actually writes did not. So a package scaffolded,
+validated, built and booted with an id the publish path would refuse, and the
+author met the rule for the first time at the most expensive possible moment.
+
+FROM → TO, for metadata that used to parse and now fails:
+
+```ts
+// FROM — accepted by defineStack, refused at publish
+defineStack({ manifest: { id: 'my_app',            /* … */ } });
+defineStack({ manifest: { id: 'com.acme.my_app',   /* … */ } });
+
+// TO — dot-separated lowercase segments; hyphens inside a segment, never underscores
+defineStack({ manifest: { id: 'com.example.my-app', /* … */ } });
+defineStack({ manifest: { id: 'com.acme.my-app',    /* … */ } });
+```
+
+The refusal carries the repair rather than restating the rule: it names the key,
+echoes the value, shows both documented examples, and — having first checked the
+candidate against the pattern itself — suggests `com.example.blank` for a bare
+word and `com.dogfood.flow-fixture` for a value whose only fault is an
+underscore. A suggestion it cannot verify it does not make.
+
+⚠️ **Changing an id is a republish, not an edit.** An id is an identity: the
+registry addresses a package by `manifest_id`, an installed row is keyed on it
+and a dependent declares it. Before renaming, confirm nothing still addresses
+the old value. That is why this ships as an ADR-0087 **semantic** entry
+(`manifest-id-reverse-domain-required`) with a structured TODO and no automatic
+rewrite — `objectstack migrate meta` will not rename an id for you.
+
+`manifest.namespace` is unchanged and still admits underscores, so the two are
+derived from a project name under different rules and neither is the other. Both
+scaffolders were producing ids the new rule refuses and both now derive a
+conforming one: the bundled `create-objectstack` template ships
+`com.example.blank` and interpolates `com.example.<project-name>` in kebab form,
+and `os init` derives its id from the project name instead of interpolating the
+snake_case namespace (`os init my-app` produced `com.example.my_app`).
+
+## ⚠️ One consent path reverses direction: fail-OPEN → fail-CLOSED
+
+Narrowing `manifest.id` also narrows the **accept set of the artifact load
+path**, and on one route that is a **fail-OPEN → fail-CLOSED reversal on a
+consent/permission path**. Stating it explicitly because a reversal in that
+direction is owed a named direction and a named population, however small the
+population turns out to be.
+
+**What changed.** `AssembledPackageBodySchema` extends `ManifestSchema`, so the
+artifact package entry schema now carries this rule too. An assembled package
+whose `manifest.id` is `''` used to parse: `artifactPackageId` is
+`manifest.id || manifest.name`, so such a package was carried under its `name`,
+while an install-time `grantedPermissions` record keyed by `''` matched no
+carried package and was registered nowhere. The package loaded **with no
+consent record at all** — reported as unbound, warned about, and otherwise
+allowed to run. That is the fail-OPEN half. Such an entry is now refused
+outright (`INVALID_ARTIFACT_PACKAGE_ENTRY`, 422) and the artifact does not
+materialize at all — fail-CLOSED.
+
+**Who is affected: artifacts carrying `manifest.id: ''`, and they were already
+half-broken in both directions.**
+
+- They could never be **published**: the registry face
+  (`PackageSchema.manifestId`) has carried this exact pattern all along — the
+  same regex literal, now the shared `MANIFEST_ID_PATTERN` — so the publish path
+  has always refused them.
+- Their granted-permissions **consent already did not apply**: a record keyed by
+  `''` bound to nothing, silently, on every load.
+
+⇒ For that population this converts a silent, already-ineffective consent
+binding into an explicit refusal that names `manifest.id`. Nobody who could
+publish an artifact loses the ability to load it; what they lose is a shape that
+only ever half-worked.
+
+⛔ This is the **artifact package door** refusing a malformed id, **not** the
+permission enforcer acquiring teeth. The install-time granted permission set is
+still registered and not enforced (#17147) — nothing on the tree queries that
+registry, and the repo-wide pin asserting so is unchanged and still green.
@@ -0,0 +1,71 @@
+---
+'@objectstack/plugin-security': patch
+'@objectstack/spec': minor
+---
+
+fix(plugin-security): the `sys_permission_set` duplicate-name refusal carries `UNIQUE_VIOLATION`, and the packaged-set lock answers first (#19307)
+
+Clause-②: yes
+
+Two halves of one defect on the data door's insert leg for `sys_permission_set`
+(`permission-set-projection.ts`), both measured live on `examples/app-showcase`
+with a seeded admin over a cookie session.
+
+**1. The refusal carried no machine-readable code.** It threw a bare `Error`
+with `.status = 409` and no `.code`, and the flat `{ error, code }` responder
+invents nothing for a producer that declared nothing, so the client got prose:
+
+```
+POST /api/v1/data/sys_permission_set {"name":"dev_local_set"}
+→ 409 {"error":"[Security] permission set 'dev_local_set' already exists","object":"sys_permission_set"}
+```
+
+ADR-0112's 2026-08-17 amendment closed `error.code` at the flat door too, so a
+409 with no code is that contract unhonoured — and a UI that has to branch on
+the refusal was pushed back to string-matching. The same request now answers
+`409 … "code":"UNIQUE_VIOLATION"`, message byte-identical.
+
+⚠️ `UNIQUE_VIOLATION` is REUSED, not minted. `sys_permission_set` declares
+`{ fields: ['name'], unique: 'organization' }`, so this very collision already
+answers `409 UNIQUE_VIOLATION` when the index catches it instead of this
+pre-check; a second spelling would make one condition answer two envelopes
+depending only on which layer got there first. The ledger gains a provenance
+row for `@objectstack/plugin-security` — the union, its casing and every other
+package's rows are unchanged, and no schema shape moves.
+
+**2. It ran BEFORE the packaged-set lock, so the most likely path answered the
+less useful of two true refusals.** A package-declared set has a projected row,
+so its name is duplicate AND locked at once. An admin who opened the Clone
+dialog on a packaged set and typed the base set's own name — the single most
+likely thing to type — got `already exists`, which names no remedy, and never
+reached `NOT_OVERRIDABLE`, which names the clone path. The lock now runs first:
+
+```
+POST /api/v1/data/sys_permission_set {"name":"showcase_manager"}
+→ 403 {"error":"[Security] Permission set 'showcase_manager' is declared by package
+   'com.example.showcase' and is locked … Choose a different name for your set, or clone
+   'showcase_manager' …","code":"NOT_OVERRIDABLE","object":"sys_permission_set"}
+```
+
+**What did NOT move**, measured on the same runtime: an ordinary
+(non-package-declared) duplicate **whose provenance the lock can resolve** still
+answers the duplicate refusal and not `NOT_OVERRIDABLE` — that qualifier is
+load-bearing, and the corner below is the case it excludes; an unauthenticated
+write on the same resource still answers `401 UNAUTHENTICATED`; and an `update`
+targeting a packaged set answers `403 NOT_OVERRIDABLE` exactly as before.
+
+⚠️ **One corner moved with the order**: an ordinary duplicate attempted while no
+artifact source can answer now takes the lock's fail-closed `unknown` refusal —
+`403` `NOT_OVERRIDABLE` (`PackagedPermissionSetProvenanceUnknownError`, "retry
+once the metadata layer is readable") — instead of the 409. Both are refusals and
+neither writes; it is pinned so the behaviour is declared rather than incidental.
+
+⚠️ **And the order has a cost, stated rather than discovered**: the lock's probe
+(`protocol.getMetaItemLayered`) used to be evaluated only AFTER the duplicate
+check passed, so a duplicate insert never paid for it. It is now evaluated
+unconditionally, ahead of that check. Two consequences, both deliberate: every
+**duplicate** insert on `sys_permission_set` costs one extra metadata round trip
+(the accepted path's cost is unchanged — it always paid this probe), and the
+duplicate path is now COUPLED to metadata-layer reachability, where before it
+answered from the record alone. That coupling is the mechanism behind the corner
+above, and it is the price of putting the refusal that names the remedy first.
@@ -0,0 +1,15 @@
+---
+"@objectstack/objectql": minor
+"@objectstack/spec": minor
+---
+
+`Clause-②: yes (widening)`
+
+A `percent` field's declared `scale` is the number of decimal places of the **percentage-point** value as displayed and entered; the **stored** allowance now derives from it. For a fraction-stored percent the record validator's `max_scale` branch accepts `scale + 2` decimal places in the stored fraction (#19320).
+
+Maintainer ruling batch #161 item 3 letter B (2026-09-18) settles what one word means: `scale: 2` on a percent field is two displayed decimals, so the edit widget offers `12.34` and writes the fraction `0.1234`. The branch compared those four places against the raw declaration and refused the write — an author could declare two displayed decimals and then not write two displayed decimals.
+
+- **Which fields move**: only a **fraction-stored** percent, i.e. one whose `percentScaleOf` is `fraction` — no declared `max`, or a `max` at or below 1. A **whole-percent** field (`max` above 1) stores the displayed number itself and keeps the declared `scale` exactly, as do `number`, `currency`, `slider` and `rating`. The split is read from the spec's `percentScaleOf`, not re-decided at this seam.
+- **Direction, measured in both**: over a 1,950-cell corpus of declaration x written value, **36 cells move from refused to accepted and 0 move the other way**. Nothing that writes today stops writing; no stored value is re-read or re-judged; no migration is implied.
+- **`FieldSchema.scale`'s describe states both meanings**, which is the half of the ruling that makes the derivation legible to an author: what the number counts (displayed percentage points) and what it permits in storage (`fraction` ⇒ `scale + 2`, `whole` ⇒ `scale`). The generated field reference page carries the same sentence, and `percentScaleOf`'s docblock points at it rather than restating it.
+- **The refusal envelope names the allowance that was applied.** On a fraction-stored `scale: 2` field, `0.12345` is still refused and reports `constraint: { scale: 4, actual: 5 }` — previously it would have read `{ scale: 2, actual: 5 }` on a field that accepts four places, a true refusal described by a false constraint. A consumer asserting the raw declaration back out of a percent field's `max_scale` envelope reads the derived number instead.
@@ -0,0 +1,42 @@
+---
+'@objectstack/metadata-protocol': patch
+---
+
+`POST /api/v1/data/{object}/batch` with `operation: "delete"` stops reporting a deletion it
+did not perform.
+
+This is the third and last of the by-id delete doors to read the engine's answer — the
+single-record `DELETE` and `deleteMany` already do. Each row of the batch answered
+`success: true` for every engine result that was not the driver contract's `false`. The
+`false` arm — "no row matched" — has reported honestly since #4435 and #5088; the other
+ending had not: a row that MATCHED and was deliberately NOT removed was counted in
+`succeeded` and reported as deleted, byte-identical to a real deletion.
+
+`sys_permission_set` is the shipped shape of it. Deleting a package-declared set is an
+ADR-0005 RESET: the overlay tombstones and the record re-projects to the declared body
+instead of vanishing. That behaviour is unchanged and deliberate — what was wrong is the
+answer, and on a security-configuration write it told an operator a permission set was gone
+while it was still being enforced.
+
+`IDataEngine.delete` declares `Promise<boolean | number>` — the driver boolean for a by-id
+write, a count of rows removed otherwise — so a numeric zero is the one value that positively
+means the record is still there. The per-row `success` now reads that count instead of being
+a literal.
+
+On the wire, for one row of a `delete` batch:
+
+- removed — `success: true`, counted in `succeeded` (unchanged);
+- matched but not removed — `success: false`, counted in `failed`, and no `errors[]` entry:
+  a surviving record is an outcome, not a fault, and this envelope's two per-row codes
+  (`ROLLED_BACK`, `NOT_ATTEMPTED`) both describe a row that never ran;
+- unknown id — `success: false` with `errors[0].code: RECORD_NOT_FOUND` (unchanged);
+- an off-contract `undefined` from a third-party driver keeps its #4435 reading.
+
+Because `succeeded` and `failed` partition `results`, a surviving row also makes the
+request-level `success` false, and an `atomic` batch containing one now rolls back rather
+than committing under a response that called every row deleted. A non-atomic batch is not
+stopped by it: nothing was thrown, so the `continueOnError` stop does not apply and the
+remaining records are still attempted. `returnRecords: false` keeps `success`, so the honest
+value survives that projection too.
+
+Clause-②: no
@@ -49,7 +49,11 @@
       "Bash(curl -sS -X PATCH https://api.github.com/repos/objectstack-ai/objectstack/pulls/* *)",
       "Bash(curl -sS -X PATCH https://api.github.com/repos/objectstack-ai/objectui/pulls/* *)",
       "Bash(curl -sS -X POST https://api.github.com/repos/objectstack-ai/objectstack/pulls/*/ccr/ready_for_review *)",
-      "Bash(curl -sS -X PUT https://api.github.com/repos/objectstack-ai/objectstack/pulls/*/ccr/auto_merge *)"
+      "Bash(curl -sS -X PUT https://api.github.com/repos/objectstack-ai/objectstack/pulls/*/ccr/auto_merge *)",
+      "Bash(node --use-env-proxy scripts/pm/post-stamped.mjs *)",
+      "Bash(node --use-env-proxy scripts/pm/label-write.mjs *)",
+      "Bash(curl -sS -X PATCH https://api.github.com/repos/objectstack-ai/objectstack/issues/* *)",
+      "Bash(curl -sS -X PATCH https://api.github.com/repos/objectstack-ai/objectui/issues/* *)"
     ],
     "deny": [
       "mcp__github__issue_write",
 
@@ -931,16 +931,26 @@ restores durability, or the explicit opt-out that makes the degradation delibera
 (`suspendedRunStore: 'memory'`, `OS_SKIP_SCHEMA_SYNC`). Say it **once**, at the first
 degradation, not once per failed write.
 
-**Do not over-apply it.** Escalating a functional degradation to `error` trains
-everyone to skim `error`. An `if (!service)` composition branch is usually functional
-and belongs at `warn`; a `catch` around a write, a DDL call, or a store initialization
-is where this rule bites. **And a failure handed to the CALLER is not a degradation at
-all** — the third legal answer: a `catch` that answers `errorFromThrown(e, 400)`, or a
-batch whose contract IS a per-item outcome report, does not look normal from the
-outside — the requester was told. Do **not** bolt a `logger.error` onto such a site;
-declare **how it delivers** instead — `FAILURE_PROPAGATION_CALLEES` (repo-wide names)
-or the function-scoped `FAILURE_PROPAGATION_SITES` in the checker, which then proves
-structurally that *every* path out of the `catch` delivers.
+**Do not over-apply it.** Escalating a functional degradation to `error` trains everyone
+to skim `error`. An `if (!service)` composition branch is usually functional and belongs
+at `warn`; a `catch` around a write, a DDL call, or a store initialization is where this
+rule bites. **And a failure handed to the CALLER is not a degradation at all** — the
+third legal answer: a `catch` that answers `errorFromThrown(e, 400)`, or a batch whose
+contract IS a per-item outcome report, does not look normal from the outside — the
+requester was told. Do **not** bolt a `logger.error` onto such a site; declare **how it
+delivers** instead — and which declaration exists depends on how the failure leaves the
+`catch`. Delivered by CALLING something: name that callee, repo-wide in
+`FAILURE_PROPAGATION_CALLEES` or function-scoped in `FAILURE_PROPAGATION_SITES`, and the
+checker then proves structurally that *every* path out of the `catch` reaches it.
+Delivered by **RETURNING** an outcome object — `return { ok: false, error }`, a `failed`
+receipt — there is **no callee to declare**: the delivery IS the constructed value, and
+both maps key on a name. ⛔ Never add such a seam to `DURABILITY_CRITICAL_CALLEES` or to
+either `FAILURE_PROPAGATION_*` map, ⛔ never baseline it, ⛔ never bolt on a
+`logger.error` to green the checker: the shape is outside its reach by construction. Pin
+it in **its own file's test** asserting the returned failure outcome (the
+`failed`-receipt case is the reference shape), and read its population from
+`scripts/measure-return-propagating-durability-seams.mjs`. ⭐ The invariant does not
+move: silent data loss must be loud, so what this checker cannot see, that test holds.
 
 **It has teeth**: `pnpm check:durability-log-level`
 (`scripts/check-durability-degradation-log-level.mjs`; its header is the authority)
 
@@ -47,7 +47,7 @@ import { defineStack } from '@objectstack/spec';
 
 export default defineStack({
   manifest: {
-    id: 'acme-crm',
+    id: 'com.acme.crm',
     name: 'Acme CRM',
     version: '1.0.0',
     type: 'app',
 
@@ -105,16 +105,16 @@ List installed packages.
 Install a package from its manifest (SDK: `client.packages.install`). Re-installing an
 already-installed `id` returns **409 Conflict** unless `overwrite: true`.
 
-**Body**: `{ manifest: { id: "plugin-auth", name: "Plugin Auth", version: "1.0.0", ... }, settings?: { ... }, enableOnInstall?: true, overwrite?: false }`  
-**Response**: `{ package: { id: "plugin-auth", version: "1.0.0", ... }, message?: "..." }`
+**Body**: `{ manifest: { id: "com.objectstack.plugin-auth", name: "Plugin Auth", version: "1.0.0", ... }, settings?: { ... }, enableOnInstall?: true, overwrite?: false }`  
+**Response**: `{ package: { id: "com.objectstack.plugin-auth", version: "1.0.0", ... }, message?: "..." }`
 
 ### `POST /packages/publish`
 
 Publish a package (manifest + metadata) to the package marketplace registry. This is
 publisher tooling, not part of the app SDK surface.
 
-**Body**: `{ manifest: { id: "plugin-auth", name: "Plugin Auth", version: "1.0.0", ... }, metadata: { objects: [...], views: [...], ... } }`  
-**Response**: `{ success: true, message: "...", package: { id: "plugin-auth", version: "1.0.0" } }`
+**Body**: `{ manifest: { id: "com.objectstack.plugin-auth", name: "Plugin Auth", version: "1.0.0", ... }, metadata: { objects: [...], views: [...], ... } }`  
+**Response**: `{ success: true, message: "...", package: { id: "com.objectstack.plugin-auth", version: "1.0.0" } }`
 
 ### `GET /packages/:id`
 
 
@@ -109,7 +109,7 @@ import * as objects from './src/objects/index.js';
 
 export default defineStack({
   manifest: {
-    id: 'my-app',
+    id: 'com.example.my-app',
     namespace: 'my_app',
     version: '0.1.0',
     type: 'app',
 
@@ -1179,7 +1179,7 @@ import { defineStack } from '@objectstack/spec';
 
 export default defineStack({
   manifest: {
-    id: 'acme-crm',
+    id: 'com.acme.crm',
     name: 'Acme CRM',
     version: '1.0.0',
     type: 'app',