merge origin/main (os-regen artifacts taken from main; regeneration follows)

Author: claude

.changeset/18545-formula-can-permission-predicate.md

@@ -0,0 +1,32 @@
+---
+'@objectstack/formula': minor
+---
+
+Add `current_user.can(object, verb)` — the permission predicate — to the CEL engine, together with the data it is answered from.
+
+`Clause-②: yes` — a new callable name widens the authorable surface. Purely additive: nothing is removed, renamed or narrowed, and every expression that evaluated before evaluates the same way.
+
+**What you can write now**
+
+```cel
+current_user.can('crm_lead', 'edit')
+```
+
+`can` is registered **receiver-only**, so it is called ON the acting subject (`current_user`, or its `user` / `ctx.user` / `os.user` aliases — the same object). A bare `can(object, verb)` is deliberately not registered and keeps faulting: a permission question with no subject has no meaning.
+
+The verb vocabulary is the closed table `OBJECT_PERMISSION_VERBS` in `@objectstack/spec/security` — `read`, `create`, `edit`/`update`/`write`, `delete`/`remove`, `export`, `transfer`, `import`. A verb outside it is refused loudly rather than answered `false`. The answer folds the super-user bits exactly as the enforcement door does, so a predicate and the server's 403 cannot disagree.
+
+**What a call site must pass**
+
+`EvalContext` gains `permissions` — a pure data map, object name → `EffectiveObjectPermission`, which is the `objects` map of the published `/auth/me/permissions` response, unchanged. Build it through the new `toEvalPermissions(response.objects)`, which refuses a payload that is not that shape.
+
+```ts
+import { toEvalPermissions } from '@objectstack/formula';
+
+const permissions = toEvalPermissions(mePermissions.objects);
+ExpressionEngine.evaluate(predicate, { user, record, permissions });
+```
+
+**With no permission data in the context, `can` THROWS** (`ok: false`, `kind: 'runtime'`) and names the missing input. It never answers `true` (which would reveal what the subject may not see) and never answers a silent `false` (which would hide a gated element from everyone, indistinguishable from a real denial). An *empty* map is a real answer and evaluates to `false`, as does an object the map does not mention.
+
+**Also new, all additive**: `EvalPermissions` and `PermissionBinding` types, `registerPermissionPredicate()`, and an optional fourth argument on `registerStdLib()` carrying the binding. Existing three-argument calls are unaffected.

.changeset/18545-spec-object-permission-verbs.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/spec': minor
+---
+
+Publish the object-permission VERB vocabulary and the effective-entry reader from `@objectstack/spec/security`.
+
+`Clause-②: yes` — new exported names on a published surface. Purely additive: no export is removed, renamed or narrowed, and no schema changes shape.
+
+**New exports**
+
+- `OBJECT_PERMISSION_VERBS` — the closed verb → `allow*` bit table. Derived from the bare verbs of the object-permission key aliases (`read`, `create`, `edit`/`update`/`write`, `delete`/`remove`, `export`, `transfer`) plus one row that is not derivable and is recorded as a deliberate choice: `import` → `allowCreate`, because importing rows is creating rows. `restore` / `purge` are absent, as they are on the alias table since their bits were retired.
+- `OBJECT_PERMISSION_VERB_NAMES` — the same vocabulary, sorted, for a refusal message to name in full.
+- `resolveObjectPermissionVerb(verb)` — the only supported read of the table. Use it rather than indexing the record: a direct index answers `toString` with a function, which a truthiness check reads as a grant.
+- `objectPermissionGrants(permission, target)` — whether one `EffectiveObjectPermission` entry grants a bit, folded the way the enforcement path folds it: `viewAllRecords` or `modifyAllRecords` grants read; `modifyAllRecords` grants edit, delete and transfer but never create; `export` is `grant ∧ read`. An absent entry and an all-`false` entry both answer `false`.
+- `ObjectPermissionVerbTarget` — the `allow*` bit type a verb can resolve to.
+
+**Why they are published**: `@objectstack/formula`'s new `current_user.can(object, verb)` predicate reads a `/auth/me/permissions` map, and a client rendering the same capability reads the same map. One table and one fold, published once, so the predicate an author writes and the 403 the server returns cannot answer differently.

.changeset/18603-anchor-binding-declared-capabilities.md

@@ -0,0 +1,47 @@
+---
+'@objectstack/spec': patch
+---
+
+`AnchorBindingContext`'s boot half names the stack's capability DECLARATIONS, not the `sys_capability` rows the seeder has not written yet
+
+The docblock named two sources for `declaredCapabilities`: at boot 「the
+`sys_capability` rows carrying `managed_by: 'package'` provenance」, at authoring
+time the stack's own `capabilities` array. The boot half carried an ordering
+precondition the sentence never stated, and a caller following it literally
+lands on the defect the input exists to remove.
+
+`runBootstrap` (`@objectstack/plugin-security`) awaits `bindBaselineToEveryone`
+— the ADR-0090 D5 anchor binding, the boot call site that consults
+`describeHighPrivilegeBits` — BEFORE it calls `bootstrapDeclaredCapabilities`,
+the seeder that WRITES those `managed_by: 'package'` rows. The order is fixed by
+two other constraints stated at that call site: the binding must follow the
+seeding of the `everyone` anchor it binds to, and precede the audience-binding
+suggestion reconciliation. So on a first boot the table is EMPTY at exactly the
+moment the docblock said to read it, and this docblock's own 「omission refuses」
+property turns that emptiness into a silent refusal of every declared token —
+the app's own `isDefault` set unbindable at the `everyone` anchor, which is the
+defect #17811 introduced the input to remove.
+
+The boot half now names the DECLARATIONS, read through the seeder's own two-step
+— the ObjectQL registry first, the metadata service as the fallback — which is
+what `readDeclaredCapabilityContext` (`@objectstack/plugin-security`, #18535)
+already implements, so the contract text and its one runtime consumer now
+corroborate each other instead of contradicting. The `sys_capability` rows stay
+a valid source, qualified: only once the seeder has written them, which is where
+an admin-surface or post-boot caller reads them.
+
+⛔ No behaviour changes. The diff is comment text: `git diff` against the branch
+point over `src/security/high-privilege.ts` changes **0** non-comment lines (the
+same predicate reads 33 on that file's own #17811 commit, which is the control
+proving it fires). No predicate, no type, no export, no accept set moves.
+
+**This is shipped, which is why it carries a changeset rather than
+`skip-changeset`.** `src/security/high-privilege.ts` is NOT shipped as source —
+`@objectstack/spec`'s published `files[]` takes `src/**/*.zod.ts`, and this file
+is not one (`npm pack --dry-run` lists 2021 files and excludes it, with the
+sibling `src/security/permission.zod.ts` present as the lit control). Its
+published reach is the emitted declarations, and they move: the new clause is
+present in `dist/security/index.d.ts` and `dist/security/index.d.mts`, both in
+that same shipped list, with the superseded spelling absent from every built
+declaration file and the docblock's unchanged neighbouring sentence present in
+the same two as the lit control.

.changeset/18607-client-readme-install-example-manifest.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/client": patch
+---
+
+docs(client): the published README's `packages.install` example is a manifest `ManifestSchema` actually accepts (#18607)
+
+The example shipped in the `@objectstack/client` npm tarball was refused on three
+counts when parsed against the contract its own call site declares
+(`PackageInstallRequestSchema`, whose `manifest` key is `ManifestSchema`):
+`invalid_type` at `[manifest, id]`, `invalid_value` at `[manifest, type]` — both
+required and absent — and `unrecognized_keys` at `[manifest]` for a `label` key
+that `ManifestSchema`'s `strictObject` close refuses by name.
+
+```diff
+ await client.packages.install({
+-  name: 'vendor_plugin',
+-  label: 'Vendor Plugin',
++  id: 'com.vendor.plugin',
++  type: 'plugin',
++  name: 'Vendor Plugin',
+   version: '1.0.0',
+ });
+```
+
+`label` is not a root manifest key and never was: the root shape declares `name`
+for the human-readable string (measured — `ManifestSchema` declares 25 root keys
+and `label` is not among them), so the example's `label` value moves to `name`
+and the machine identifier becomes the reverse-domain `id` the key documents.
+`type: 'plugin'` is the enum member the example's own subject names — a
+general-purpose functionality extension, not the consumer-installable `app`
+bundle. Required root keys, read off the schema rather than the prose: `id`,
+`name`, `type`, `version`.
+
+Nothing parses that contract at the install door today, so the example "worked"
+by being posted unvalidated — which is what made it a timed charge rather than a
+live outage: closing the door turns a silently-wrong published example into a
+loudly-broken one for every reader who copied it.
+
+Pinned in `packages/client/src/readme-package-install-example.test.ts`, which
+parses every `packages.install` manifest literal in this README against that
+schema and fails if the corpus is ever empty.
+
+Clause-②: no
+
+No schema, export, type or runtime behaviour changes. It ships because the README
+is listed in this package's `files[]` and is the first thing a new integrator
+copies.

.changeset/18614-conversion-registry-retryconfig-liveness-claim.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/spec": patch
+---
+
+`src/conversions/registry.ts` — the `connector-rate-limit-config-removed` entry no longer asserts that `retryConfig` and the connector timeouts "are live" (#18614). The assertion was measured false; the ledger seeded by #18582 had already recorded the correction on the other side.
+
+The comment conflated two different statements. That the rate-limit retirement left those keys *in place* is true and is kept — it is what the fixture's single notice demonstrates. That they are *live* was never measured by that entry and is false: the read-probe for `retryConfig`, `connectionTimeoutMs` and `requestTimeoutMs` finds no consumer anywhere outside `packages/spec` (the sibling key `providerConfig`, on the same schema, fires on the identical probe), no retry loop reads a strategy or a backoff, every timeout occurrence outside the spec is a write of the literal `30000` so a def satisfies the post-parse `Connector` type, and `ConnectorProviderContext` carries none of the three — so a provider factory cannot read them either. `liveness/connector.json` classifies all ten rows `dead` and is now cited as the authority.
+
+Nothing is retired here and no schema moved: ADR-0049 owes these keys a decision, which the corrected comment states rather than pre-empts. The text ships — `tsup` preserves comments, so these bytes reach `dist/index.js`, `dist/index.mjs` and the `shared`/`browser` bundles inside the published tarball, which is why this is a `patch` and not `skip-changeset`.
+
+Clause-②: no

.changeset/18677-validate-per-package-authoring-pass.md

@@ -0,0 +1,22 @@
+---
+'@objectstack/cli': minor
+---
+
+`os validate` runs the per-package author-time rule pass `os build` already ran — the false-clean residue #17069 left one layer down.
+
+`os build` runs the artifact's authoring rules **twice**: once over the union-folded stack, then a second `runAuthoringRules('build', …)` pass over each `artifactPackages(…)` entry with `packageBodyAsStack(…)` as resolution context, de-duplicated against the union run. `os validate` ran the union pass and stopped — it imported neither seam. By `compile.ts`' own description the survivors of that second pass are "exactly the set the union could not see", so that whole set was findings `os build` reported and `os validate` **structurally could not**. The direction is false-clean, and on the worse door: the fast pre-flight is what an author runs *before* shipping, so its clean bill of health is the strongest false assurance the three commands can give.
+
+Measured on `origin/main` 09e16a574 over `examples/app-multi-package`, both commands exiting 0:
+
+```
+os build    --json  warnings: 4      <- 3 union + 1 per-package survivor
+os validate --json  warnings: 3      <- the survivor is the defect
+```
+
+After: both report 4, the same set, in the same order.
+
+**The loop is now one seam, not two copies.** `runPerPackageAuthoringRules` lives beside `artifactPackages` / `packageBodyAsStack` in `utils/artifact-packages.ts`, whose header already forbids a second copy of that shape by name. What would have drifted between two hand-written loops is not the package reading but the **verdict** — the de-duplication key, the severity split, the `where` prefix. `os build`'s observable output is unchanged (text face byte-identical modulo timings; `--json` payload identical).
+
+**Severity mapping is `os build`'s, unchanged.** A per-package `error` refuses (exit 1); an advisory joins `warnings`. So `os validate` is narrowed only to the bar the command that *ships* already holds: every input it can now refuse is one `os build` already refuses, which means **nothing that builds today stops validating**. No newly-refused input could be exhibited on any fixture — across the repo's own two-package example and three constructed variants the observable change is advisory-only, because `packageBodyAsStack` hands each package the artifact's whole `packages[]` as resolution context and the reference-integrity suite resolves object names through it. Graded `minor` rather than `patch` for the new observable step line, the new advisories and the newly reachable non-zero exit; ⛔ **not** declared breaking, because the narrowing could not be exhibited and is bounded by an existing gate.
+
+Unchanged and out of scope: the ADR-0130 D4 union fold (#17069, fixed — `authoringRuleUnionStack` is in both commands), `--json` rendering (#11727), and disagreements *within* the per-package pass's verdicts (#18204). `os lint` still runs the union pass alone; its `artifactPackages` / `packageBodyAsStack` imports serve its own intra-package duplicate-name advisory, not the shared table.

.changeset/18685-cloud-adr-citation-spelling.md

@@ -0,0 +1,27 @@
+---
+'@objectstack/spec': patch
+---
+
+`ToolExecutionContext.userMessageText` now cites the cloud decision as `cloud ADR-0025`, not as a bare number that resolves to this repo's plugin-packaging ADR
+
+The docblock read `(cloud, post-ADR-0025)`. The parenthetical says the layer is
+cloud, but the id was spelled bare — and a bare id resolves against *this*
+registry, where `ADR-0025` is
+[Plugin Package Distribution](../docs/adr/0025-plugin-package-distribution.md):
+a real record about `.osplugin` artifacts, code-plugin trust tiers and
+marketplace install. Nothing in it decides who owns the agent route.
+
+That is worse than citing a number nobody has. A dangling id stops a reader; an
+id that resolves lets them believe they read the right page and walk away with
+the wrong decision. AGENTS.md Prime Directive 13 is explicit — an ADR "lives in
+the repository whose code it governs", and a cloud decision is cited as
+`cloud ADR-NNNN`, "never as a bare number".
+
+The line now reads `(cloud, post-cloud ADR-0025)`, which is verbatim what the
+sibling member `confirmedBlueprintIdentity` two declarations below already says.
+The two were deliberately inconsistent while this was open; they are consistent
+again.
+
+Docblock prose only — no type, no export and no runtime behaviour changes. The
+published `.d.ts` carries the comment, which is why this ships as a patch rather
+than silently.

.changeset/18739-batch-cap-embedder-only.md

@@ -0,0 +1,15 @@
+---
+'@objectstack/spec': patch
+---
+
+`BatchUpdateRequestSchema`'s cap comment no longer calls the batch-size cap "DEPLOYMENT policy". It is embedder-only, and this correction narrows the claim onto what is actually reachable.
+
+`packages/spec/src/api/batch.zod.ts` ships in this package's tarball (`files[]` carries `src/**/*.zod.ts`), so the sentence a reader finds beside `records` is published text. It told them the cap — `RestServerConfig.batch.maxBatchSize`, 1..1000, default 200 — was deployment policy, i.e. something an operator deploying this platform could move. No shipped boot path makes that true.
+
+**What the comment says now.** The cap keeps its span and its default as schema facts; the reachability sentence says who can write it. A `RestServerConfig` is the ARGUMENT a host passes when it constructs the server, and there is exactly one door: `createRestApiPlugin({ api })`. Neither shipped boot path opens it with a `batch` config — `os serve` forwards exactly two keys out of the stack config's `api:` block (`api.enableProjectScoping`, `api.projectResolution`) and the dev plugin calls `createRestApiPlugin()` with no config at all. A CLI-started deployment therefore always gets the default of 200, and no flag, config file or CLI option moves it; only the embedding host reaches anywhere in the 1..1000 span.
+
+**Nothing executable moves.** No schema key is added, removed or renamed, no accept set widens or narrows, no export changes, and no runtime behaviour is touched. `records` still carries shape only, the cap is still enforced at the route, and `.min(1)` is still absent. The diff is comment text inside one `lazySchema` factory.
+
+**Why this shipped as its own correction.** The same false claim had four other carriers, all already corrected under the same 2026-09-07 ruling: this package's `RestServerConfigSchema` docblocks and WHO CAN WRITE THIS CONFIG header, `enforceBatchSize` in `@objectstack/rest`, and the `data-api` and `http-protocol` reference pages. This was the fifth, and it carried the exact phrase struck from `enforceBatchSize` one package over. The wording is copied from those landings rather than invented, so the five now read the same way — as does the per-key REACHABILITY row in `liveness/batch_endpoints.json`, which also ships here.
+
+Clause-②: no — comment text only. No authorable key moves, no export is added or removed, and no accept set changes in either direction.

.changeset/spooky-poems-repeat.md

@@ -0,0 +1,22 @@
+---
+'@objectstack/spec': patch
+---
+
+Say it out loud when a `.refine()` never reaches the published JSON Schema.
+
+`z.toJSONSchema()` has no arm for a `custom` check, so every rule written as a
+`.refine()` / `.superRefine()` is enforced by the runtime and absent from the
+`json-schema/` tree that ships inside this package — a published file that is
+WIDER than the Zod type it was generated from, in the direction where an
+author's (or an AI's) validator says yes and the platform then says no. Measured
+on zod 4.4.3: 688 refinement sites across 240 published schemas, none of which
+projected anything.
+
+Nothing about what the schemas accept changes. Each affected file now carries an
+`x-dropped-refinements` annotation naming the paths whose rules it does not
+state — `x-` keywords are ignored by every validator, so the accepted document
+set is byte-for-byte what it was — and the generator reports the population on
+every run and refuses to grow it silently
+(`packages/spec/dropped-refinements.baseline.json`).
+
+Clause-②: no