@@ -0,0 +1,14 @@
+---
+'@objectstack/spec': patch
+---
+
+Two published `describe` sentences that the `.objectui-sha` bump to objectui `87af769e9a3e` makes false are corrected against the new pin (#17429).
+
+`Clause-②: no`
+
+Both are claims about what the SHIPPED console renderer does, so the pin is what dates them — and both were re-read by executing the pinned tree, not by refreshing a sha.
+
+- `Dataset` measure `format`: the clause said "a datetime value ignores it". objectui#8352 lands inside the `53ded82bf7a4...87af769e9a3e` range and makes the datetime arm of `formatMeasureDate` honour the same two words the date arm does — `relative` through `formatRelativeDate`, `short` through `formatDateTime(v, { locale, style: 'compact' })`. A date PATTERN is still ignored on both arms, which is the half of the sentence that survives.
+- `FormField.span`: the clause said only the widest container-query tier's class is emitted, so a `'full'` field took one cell of two at the 720px modal width (objectstack#17328). objectui#9244 / objectui#9253 (objectui `bd09957380`) are also inside the range: `spanLadderFor` now emits one clamped col-span class per multi-column tier, so `'full'` is the whole row at every multi-column tier. The `'auto'` half — textarea, markdown, html, richtext and repeater — re-measured unchanged at the new pin.
+
+No key, default, enum member or export moves: the same authored metadata is accepted and refused as before, and `content/docs/references/ui/{dataset,view}.mdx` are regenerated from these two sentences.
@@ -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,14 @@
+---
+"@objectstack/sdui-parser": minor
+---
+
+The save gate now stamps `inert-quick-add` and `member-type-mismatch`, the two diagnostics that existed only in objectui's copy of this parser — so a page no longer saves clean here and renders with a different verdict there (#17645).
+
+The two copies of this parser owe each other one thing: byte agreement on the accepted grammar and on diagnostic codes. This copy runs the **save gate** and objectui's runs the **renderer**, so a code on one side only is a dialect — the author gets one reading when they save and another when the page draws, which is surface-dependent and therefore reaches them as intermittent. Measured at the ported revision: objectui stamped 26 codes, this copy stamped 24, and the missing two were exactly these.
+
+- **`inert-quick-add`** (warning) — `quickAdd` on `<object-kanban>` reaches no control. The Quick Add button is gated on **both** `quickAdd` and an `onQuickAdd` handler, and `onQuickAdd` takes a function, which no page on this tier can write (this tier parses, it never executes) and which the board substitutes none of its own for. It **replaces** the `unknown-prop` this copy used to emit for the key, which was false against the contract: `ComponentPropsMap['object-kanban']` publishes `quickAdd`, so an author who checked the spec found the warning contradicted and kept a key that will never do anything. Asked ahead of the declaration lookup on purpose — the claim is about the render path, so declaring the key must not silently disarm it. A falsy value and an unevaluated braced expression are deliberately untouched.
+- **`member-type-mismatch`** (warning; `error` when an `enum` arm is present) — the coarse type check one level down, over the member kind an input declares. This brings the `ManifestInput.of` key and its three readers with it: the validator, the serializer's canonicalization, and the codegen's element type. `of: 'string'` on an array input now types the members `string[]` in the generated `.d.ts` instead of `unknown[]`, and a member no declared arm accepts draws **one** diagnostic naming every offending position rather than one per member.
+
+**Nothing published changes shape for an input that declares no `of`.** The key is absent-means-undeclared: the validator checks no member, the codegen emits the unnarrowed element type, and `manifestFromConfigs` publishes no `of` at all, so an entry written before the key existed serializes byte-identically. Measured on the tracked `sdui.manifest.json`: 0 of 339 inputs declare `of`, and the artefact regenerates to the same sha256 across this change.
+
+⚠️ **Both new codes are diagnostics, not a new red gate.** Each is a warning, so `compile().ok` — the save gate's pass/fail — is unchanged, and a page that saves today still saves. Escalating an inert authored key to `error` is a separate question and belongs at the save gate, not here.
@@ -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.