Merge remote-tracking branch 'origin/main' into claude/issue-8019-change-email-old-address-notice

Author: claude

.changeset/action-destructive-declared-semantics.md

@@ -0,0 +1,27 @@
+---
+"@objectstack/runtime": patch
+---
+
+fix(runtime): `actionLooksDestructive` classifies on declared semantics only (#7828)
+
+`actionLooksDestructive` (the classifier behind the MCP `list_actions` tool's
+`requiresConfirmation` field) treated the mere presence of `confirmText` — UI
+dialog copy — as an AI-facing destructiveness signal. #7278/#7309 are actively
+migrating authors away from pairing `confirmText` with `params`-bearing actions
+(the confirm question now rides `description` instead), so the heuristic's
+input was being withdrawn by design: measured on #7309's branch, 6 of its 14
+migrated identity actions flipped from destructive to not-destructive the
+moment their `confirmText` was dropped, because none of them declares
+`mode: 'delete'` or `variant: 'danger'` to fall back on.
+
+Maintainer ruling (issue #7828, Option A): drop the `confirmText` leg.
+`mode === 'delete' || variant === 'danger'` remain the signal — closed,
+declared enumerations an author sets on purpose, not UI copy a heuristic
+was never meant to read as a safety property.
+
+This path is gated dead for every action shipped today (all 14 identity
+actions are `sys_*`, `type: 'api'`, and none declares `ai.exposed: true`, so
+none reaches the MCP `listActions` bridge that calls this classifier) — so
+the change has no observable effect on any request a caller can make right
+now. It closes the gap before a future `ai.exposed`, non-`sys_*` action
+carrying only `confirmText` would have had its classification silently flip.

.changeset/bu-subtree-docstring-attribution.md

@@ -0,0 +1,22 @@
+---
+"@objectstack/spec": patch
+"@objectstack/platform-objects": patch
+---
+
+docs: fix `business_unit` sharing-rule docstrings that still attributed the BU subtree expansion to the narrow recipient (#8098)
+
+#7807 (PR #8097, `9b519815`) narrowed the `business_unit` sharing-rule
+recipient to expand exactly one unit's members, moving the subtree walk onto
+`unit_and_subordinates`. Two docstrings never got the memo:
+`IBusinessUnitGraphService` in `packages/spec/src/contracts/sharing-service.ts`
+and the `sys_business_unit` object definition in
+`packages/platform-objects/src/identity/sys-business-unit.object.ts`. Both
+still said `recipient_type='business_unit'` sharing rules were driven by the
+subtree walk. Both now name `unit_and_subordinates` as the subtree consumer,
+with `business_unit` as the narrow (single-unit) one.
+
+These are comment-only corrections — the `IBusinessUnitGraphService`
+docstring surfaces in `@objectstack/spec`'s built `dist/**/*.d.ts` hover, and
+the `sys_business_unit` docstring surfaces in
+`@objectstack/platform-objects`'s built `dist/**/*.d.ts` hover; no runtime or
+authoring behaviour changes.

.changeset/lint-visibility-prose-names-the-surface.md

@@ -0,0 +1,9 @@
+---
+'@objectstack/lint': patch
+---
+
+`visibility-root-mislayered` and `visibility-bare-identifier` now explain the metadata-editing layer by naming the **surface** — a schema-bound metadata-editing form, the row under edit — instead of a `*.form.ts` filename.
+
+Since the layer derivation landed (#7815), a form view declaring `data: { provider: 'schema', schemaId }` is judged at the metadata layer at the runtime publish gate. That door's audience is a Studio / REST `/meta` / MCP author who has no `*.form.ts` to open, so the prose justified a correct prescription by pointing at a file the reader cannot reach. The mirror (runtime) arm named `*.view.ts` / `*.page.ts` the same way and is fixed with it.
+
+Prose only: no rule id, severity, prescribed root or firing condition changes, and the actionable half of every message and hint is unchanged. The `*.form.ts` mentions addressed to a **file-aware caller** of `validateVisibilityPredicates` (the `opts.layer` contract) are deliberately kept — there the filename is accurate and is the point.

.changeset/oidc-authorize-env-gate-bearer.md

@@ -0,0 +1,42 @@
+---
+"@objectstack/plugin-auth": patch
+---
+
+fix(plugin-auth): the D5.1 `/oauth2/authorize` env-access gate now runs for a signed bearer credential (#8102)
+
+ADR-0069 D5.1's cloud-as-IdP gate (`oidcAuthorizeGate`) is what enforces
+org-membership / app-assignment before the OP issues an authorization code. It
+resolved its subject with an **inline copy** of the shared `resolveActor` —
+line for line the same logic, in a second place — and the two diverged the
+moment one of them was fixed.
+
+`#8049` taught `resolveActor` that a bearer credential must have its signature
+stripped before lookup: `bearer()` hands clients the signed form in the
+`set-auth-token` response header (the documented API-lane credential) and
+accepts it back, while `session.token` stores the **unsigned** value. The copy
+guarding `/oauth2/authorize` kept looking the signed credential up verbatim and
+so resolved nothing.
+
+**Why that is a security defect and not a lookup miss.** The unresolved case at
+this endpoint is deliberately **fail-open** — an anonymous caller must fall
+through so the OP can redirect them to log in. So an *authenticated* caller
+holding the signed bearer was read as unauthenticated, and the env-access check
+was not denied but **never evaluated at all**: the request proceeded, and
+against a `skip_consent` client it was issued an authorization code that the
+gate, had it run, would have refused. A declared control enforced for one
+credential spelling and silently absent for the other.
+
+Impact is bounded: `oidcAuthorizeGate` is set only on the cloud control plane
+(unset in open editions / self-host, where there is no gate at all), and the
+OP's authorize endpoint is normally browser/cookie-driven — the cookie branch
+always normalized and was never affected.
+
+**Fix.** The inline copy is deleted; the branch calls the shared
+`resolveActor`, so there is one resolution site instead of two. The fail-open
+default for genuinely unauthenticated callers is unchanged and deliberately
+preserved.
+
+Pinned by a new dogfood gate that arms a **denying** gate and drives
+`/oauth2/authorize` over the cookie lane and both accepted bearer spellings,
+asserting on each that the gate was actually invoked with the caller as its
+subject and that the request was refused rather than issued a code.

.changeset/platform-global-sharing-rule-delete-gate.md

@@ -0,0 +1,26 @@
+---
+'@objectstack/plugin-sharing': patch
+---
+
+Refuse deletion of a platform-global sharing rule to org-scoped callers (#7795)
+
+`SharingRuleService.deleteRule` now requires **platform** authority to delete a
+sharing rule whose `organization_id` is `null` — a row seeded from declared
+metadata that belongs to no organization. A caller holding only the org-scoped
+`manage_sharing` capability is refused with `PERMISSION_DENIED`, which the REST
+layer answers as **403**; the `manage_platform_settings` capability, the
+built-in `platform_admin` position, and system contexts are all still permitted.
+
+Why: such a rule's criteria query runs unscoped, so deleting it purged **every**
+tenant's `sys_record_share` grants under it — a cross-tenant destructive act
+authorized by a capability declared `scope: 'org'`. Two measured facts made it
+worse: the boot seeder re-creates the rule on the next restart under a *new* id,
+so the delete was a revocation wearing removal's clothes rather than a removal;
+and the safe lever was unavailable while the destructive one was not — an org
+admin's `active: false` creates a second, org-stamped row and leaves the shared
+rule running, so deletion was the only lever an org admin had over it.
+
+Deliberately **403, not 404**: the row is intentionally visible — listing,
+reading and evaluating platform-global rules stay open to org admins, exactly as
+shipped — so answering "no such rule" would contradict a read the same caller
+can perform one call earlier. Nothing on the read/evaluate surface changes.

.changeset/put-automation-error-class-parity.md

@@ -0,0 +1,11 @@
+---
+'@objectstack/runtime': patch
+---
+
+`PUT /api/v1/automation/:name` answers 400 `VALIDATION_FAILED`, not 500, for a malformed flow definition — matching `POST /api/v1/automation` (#8123)
+
+#8055 reclassified `POST /`'s `registerFlow` refusal from 500 `INTERNAL_ERROR` to 400 `VALIDATION_FAILED`. `PUT /:name` makes the identical `registerFlow` call in the same file and was left uncaught, so the two doors disagreed about the class of an identical refusal: publishing a flow through update got a different answer than publishing through create, for the same broken definition.
+
+`PUT /:name` now routes its `registerFlow` call through the same `flowDefinitionRefusal` helper `POST /` uses, so both doors answer the same `code`, `status`, and `details.fields[]` shape for the same malformed body — including the #4277 self-correcting undeclared-config-key message, which survives verbatim.
+
+**Which bodies are refused is unchanged** on both routes — a definition that registered before still registers, and every one that was refused is still refused, with the engine's own message intact.

.changeset/security-explain-envelope-convergence.md

@@ -0,0 +1,33 @@
+---
+"@objectstack/rest": patch
+---
+
+fix(rest): one error envelope across the `/security/explain` pair (#8073)
+
+`registerSecurityExplainEndpoints` — `GET/POST /api/v1/security/explain` and
+`GET /api/v1/security/my-delegable-scope` — answered two retired dialects across
+its eight refusal arms: the 401 / 501 / 400 / 403 arms were flat
+`{ code, message }`, and the two 500s were `{ code, error: 'a bare string' }`. So
+`body.error.code`, the one position ADR-0112 D5 declares, read `undefined` on all
+six — while the immediately adjacent registrar (`/security/suggested-bindings`,
+converged in #7981) already answered the declared shape. A client calling
+`explain` and then `suggested-bindings` met two envelopes inside one `security`
+family.
+
+Every arm now emits `{ success: false, error: { code, message } }` through the
+shared `sendError` from `@objectstack/types` — the same builder every conformant
+route module writes through — so the family agrees by construction rather than by
+eight literals happening to match. The 400 arm's Zod-issue dump moves from a
+top-level `detail` sibling to `error.details`, the slot `ApiErrorSchema` declares
+for structured context.
+
+No status code moves, and no code VALUE changes: `UNAUTHORIZED`,
+`NOT_IMPLEMENTED`, `VALIDATION_FAILED`, `PERMISSION_DENIED`, `EXPLAIN_FAILED` and
+`DELEGABLE_SCOPE_FAILED` are all already registered, so nothing in
+`packages/spec` moves. `ObjectStackClient` reads both envelopes' declared spots
+(`errorBody?.code ?? errorBody?.error?.code`, and a bare-string limb for the
+message), so `client.security.explain()` and
+`client.security.describeDelegableScope()` keep throwing identical `err.code` and
+`err.message` — re-measured against these call paths rather than inherited from
+#7981. `err.details` does change on refusals, from "the whole response body" to
+the structured slot or the new body.

.github/workflows/lint.yml

@@ -333,6 +333,22 @@ jobs:
       - name: Normalized metadata-type guard
         run: pnpm check:meta-type-normalized
 
+      # Filter-slot wire-alias parity guard (#8002). The ONE filter slot is
+      # spelled four ways, declared in TWO packages: `where`/`filter` come from
+      # the spec table, while the wire-only `filters`/`$filter` are declared in
+      # `metadata-protocol` (no schema declares them) and named LITERALLY in
+      # `packages/rest`, which gates the slot's arity at the querystring ingress
+      # (#7390). A runtime import cannot join them — the normalizer's table is a
+      # module-private const, and metadata-protocol is only a devDependency of
+      # rest — so a fifth wire-only spelling would fold correctly and be
+      # silently ungated, putting repetition on it back on the misdiagnosis
+      # #7390 removed. The REST side alone is pinned by that card's §5 test;
+      # this covers the half it cannot reach. AST-based, and an unreadable
+      # declaration is RED rather than an empty corpus reported as a pass
+      # (#4690). Runs its own --self-test first.
+      - name: Filter-slot wire-alias parity guard
+        run: pnpm check:filter-alias-parity
+
       # Init-service declaration guard (#4471, ADR-0116). The kernel's ordering
       # contract (dependencies / optionalDependencies / requiresServices /
       # providesServices) was complete but VOLUNTARY: a plugin that resolves
@@ -1081,6 +1097,42 @@ jobs:
       - name: Check the decision frame is in sync across its four copies
         run: pnpm check:skill-frame-sync
 
+      # The SECOND skill-frame gate — and deliberately only HALF of it (#8110).
+      #
+      # `pnpm check:skill-frame-freshness` is `--self-test && the scan`, and only the
+      # SCAN half is CI-hostile: it asks "is THIS WORKING TREE's frame current with
+      # origin/main?", which on a fresh merge ref is a tautological green, and on any
+      # PR that legitimately edits the frame would be a false red — "differs from main"
+      # is that PR's whole purpose. That script's own header ("WHERE IT RUNS") argues
+      # it, and the scan stays out of CI for exactly that reason. It is NOT wired here.
+      #
+      # The `--self-test` half is a different animal. It DERIVES a coherent two-axis
+      # specimen from this tree's own frame documents, commits it and the real
+      # documents into throwaway git repos whose `origin` points at a path that does
+      # not exist, and asserts 12 verdicts against the gate's own code. No network, no
+      # origin/main, no history: measured green in a `--depth 1` clone carrying no
+      # remote-tracking ref at all, in ~1.3s. So the half that CANNOT run in CI was
+      # keeping the half that CAN out of it, and the price was measured on #8024 —
+      # the fixture had stranded TWICE, neither time noticed, while the gate sat in
+      # the gate list reading as coverage and protecting nothing.
+      #
+      # This step cannot redden a PR that edits the frame on purpose: the specimen is
+      # re-derived from whatever the frame currently is, so a reword, a reflow or a
+      # principles-only rewrite carries the fixture with it (verified adversarially
+      # before wiring this — rewording axis prose across all three frame files keeps
+      # both gates green). What DOES redden it is a STRUCTURAL change — an axis added,
+      # removed, or its declaring sentence reworded past the shared anchors — and that
+      # reddens `check:skill-frame-sync` directly above with the same diagnosis, which
+      # the self-test's own failure message names as the thing to fix first. No PR can
+      # reach this step red with the step above green.
+      #
+      # Invoked as `node`, NOT `pnpm check:skill-frame-freshness`, precisely because
+      # that npm script would drag the scan half in with it — the same shape as the
+      # `dev` chain calling check-dev-prereqs.mjs directly rather than through its
+      # pnpm script (see that script's header).
+      - name: Self-test the skill-frame freshness gate (self-test half only, never the scan)
+        run: node scripts/check-skill-frame-freshness.mjs --self-test
+
       # The third gate over SKILL.md, covering the one line the other two cannot see
       # (#5331). check:skill-docs / check:skill-refs compare generated artifacts and
       # check:skill-examples typechecks `os:check` blocks; none of them reads the

examples/app-showcase/e2e/bulk-capability-gate.spec.ts

@@ -27,7 +27,7 @@ import { test, expect } from '@playwright/test';
  */
 
 // Ambient `process` for the env read below — the showcase tsconfig doesn't pull
-// in `@types/node`, and the package-global shim in test/node-shim.d.ts declares
+// in `@types/node`, and the package-global shim in types/node-shim.d.ts declares
 // only `cwd()`. Same idiom (and same reason) as the declarations in
 // objectstack.config.ts and src/system/self-url.ts: keeps `pnpm typecheck` green
 // without widening the type surface. Playwright provides the real `process`.

examples/app-showcase/e2e/detail-shapes.spec.ts

@@ -27,7 +27,7 @@ import { test, expect } from '@playwright/test';
  */
 
 // Ambient `process` for the env reads below — the showcase tsconfig doesn't pull
-// in `@types/node`, and the package-global shim in test/node-shim.d.ts declares
+// in `@types/node`, and the package-global shim in types/node-shim.d.ts declares
 // only `cwd()`. Same idiom (and same reason) as the declarations in
 // objectstack.config.ts and src/system/self-url.ts: keeps `pnpm typecheck` green
 // without widening the type surface. Playwright provides the real `process`.