Merge remote-tracking branch 'origin/main' into claude/issue-7665-by-id-write-visibility-gate

Author: claude

.changeset/api-key-revoke-product-route.md

@@ -0,0 +1,54 @@
+---
+"@objectstack/platform-objects": patch
+"@objectstack/plugin-auth": patch
+---
+
+fix(platform-objects,plugin-auth): let the API-key revoke/restore actions actually run (#7727)
+
+`sys_api_key` contradicted itself. It declared two row actions —
+`revoke_api_key` / `restore_api_key` — as `PATCH /api/v1/data/sys_api_key/{id}`
+with `bodyExtra: { revoked: true|false }`, while the same object set
+`enable.apiMethods = ['get', 'list']`. The declared PATCH was refused at the
+ADR-0049 method gate with `405 OBJECT_API_METHOD_NOT_ALLOWED` before any
+authorization ran, so **no product route revoked an API key**: the Setup →
+API Keys → Revoke button produced an error toast, the row still read
+`revoked = false`, and the key kept authenticating. A leaked key could only be
+retired by writing the row out of band.
+
+Enforcement of the flag was never the problem — the verifier filters
+`revoked: false` and re-checks the row, so a flipped bit takes effect on the
+very next `x-api-key` call. The missing piece was purely the write path, and it
+had **two** gates, not one:
+
+- **The method gate.** `enable.apiMethods` now carries `update`. `create` and
+  `delete` stay off: minting is `POST /api/v1/keys` (the only path that ever
+  returns the raw secret) and keys are retired by revoking, not deleting.
+- **The affordance reconciler.** ADR-0103's `reconcileManagedApiMethods` strips
+  any write verb a `managedBy` object's resolved affordances do not grant —
+  warning, not failing. So `apiMethods` alone would still have served 405 while
+  the source read correctly. `userActions: { edit: true }` declares the
+  affordance, exactly as `sys_user` does under ADR-0092 D4.
+
+**Opening the method does not open the columns.** `sys_api_key` stays
+`managedBy: 'better-auth'`, so ADR-0092 D2's identity write guard still
+fail-closed rejects user-context writes, and its per-object update whitelist
+remains the only opening. `revoked` is registered there and nothing else is:
+`key` stays unwritable (a rotated hash would mint a credential nobody holds),
+`user_id` stays unwritable (re-owning a key is privilege transfer), and
+`expires_at` stays on the mint path. A PATCH carrying only non-whitelisted
+columns is refused `403 PERMISSION_DENIED` rather than degrading into a
+timestamp touch, and a mixed patch applies `revoked` while stripping the rest.
+The guard itself is unchanged — no general weakening, and every other identity
+table keeps its default-deny.
+
+Per ADR-0092 D4's form-rendering constraint, the columns outside the whitelist
+(`name`, `prefix`, `user_id`, `scopes`, `expires_at`) are now `readonly`, so the
+edit form this affordance turns on cannot offer a write the server refuses —
+the declared-≠-enforced shape that caused the original defect.
+
+Nothing pinned any of this before: the existing tests exercise key *resolution*
+against a pre-revoked row and never call the route the actions declare, which is
+how a declared action and a method gate cancelled out unnoticed. The new
+`api-key-revoke-lifecycle` dogfood suite drives the real PATCH, asserts `200`,
+and then asserts the consequence — the key stops authenticating — because a 200
+that leaves the key working is the defect wearing a success code.

.changeset/i18n-locale-label-declared-enforced.md

@@ -0,0 +1,42 @@
+---
+"@objectstack/spec": patch
+---
+
+docs(spec,i18n): `GET /i18n/locales` stops declaring `label` a display name
+
+`GetLocalesResponseSchema` described each locale descriptor's `label` as
+"Display name of the locale", and no producer has ever written one. The sole
+producer is `toLocaleDescriptors` (`system/i18n-resolver.ts`) — deliberately
+shared by the runtime dispatcher's `/i18n` domain and `service-i18n`'s
+autonomous route, so there is no second implementation to diverge — and it sets
+`label` to the code. `GET /api/v1/i18n/locales` answers `{ code: 'th', label:
+'th' }`, never `{ code: 'th', label: 'ไทย' }`. Declared not enforced (ADR-0049),
+one field wide, and the describe is what carries the claim into the generated
+JSON Schema, the OpenAPI surface and the SDK type — so a client that trusts it
+renders locale codes at users and only finds out by looking. objectui#4039 hit
+exactly that and routed around the field: the console's language menu reads
+`code` alone off this body and names locales from its own built-in table plus
+`Intl.DisplayNames`.
+
+Patch, and describe-only. The measurement behind that: **no consumer anywhere
+reads `label`**. In this repo every read of the body takes `code` or
+`isDefault` (`http-dispatcher.test.ts`, `domain-handler-registry.test.ts`,
+`i18n-success-envelope.conformance.test.ts`); the one wire fixture that spells
+`label` sets it to the code and asserts only the array length. In objectui the
+one real consumer, `apps/console/src/loadLocales.ts`, reads `entry?.code` and
+documents in its header that the descriptor's label is not a display name. With
+nothing consuming the field, the honest declaration is the whole fix: the
+runtime behaviour is unchanged, and only the field's documented meaning moves.
+
+So the declaration now states the convention it ships — `label` equals `code`;
+naming a locale for a UI is the client's job, where `Intl.DisplayNames` already
+lives and where the choice of *which* language to name it in belongs. The two
+alternatives are deliberately not taken here: serving real display names is a
+capability addition with no measured pull (CLDR data on the server for
+something every client can compute), and retiring the field is a heavier
+response-contract action. Both stay open on #7634.
+
+`toLocaleDescriptors`' output and the declaration are now pinned against each
+other in `i18n-resolver.test.ts`, on both sides — a producer that starts
+inventing display names and a describe that starts promising them each turn it
+red separately.

.changeset/summary-recompute-system-context.md

@@ -0,0 +1,51 @@
+---
+"@objectstack/objectql": patch
+---
+
+fix(engine): a granted child write no longer 500s because the parent's roll-up recompute ran as the caller
+
+Creating a child record returned **HTTP 500 after the row had already been
+written** whenever the child fed a roll-up `summary` on a parent the caller may
+not edit — the ordinary parent/child shape for tasks, line items, comments and
+time entries. A client that retried (or a user who clicked Save again) created a
+duplicate row
+([#7673](https://github.com/objectstack-ai/objectstack/issues/7673),
+[#7719](https://github.com/objectstack-ai/objectstack/issues/7719)).
+
+`recomputeSummaries` issued the parent roll-up write under the **caller's**
+execution context, so an engine-derived write was authorized as if the caller had
+asked for it. On the showcase app a plain member holding `showcase_task: create +
+read` hit it on every `POST` and `PATCH`: the recompute of
+`showcase_project.task_count` raised `PERMISSION_DENIED`, the engine recorded it
+as a recompute failure, and the call site rethrew it as `SummaryRecomputeError`
+(`ERR_SUMMARY_RECOMPUTE`) — which REST maps to a 500. The access matrix and
+`/security/explain` both said `create: true`, so a declared-and-granted operation
+failed on a permission check about a record the caller never asked to touch.
+
+**The recompute now runs system-elevated**, on all three call sites (insert,
+update, delete). A roll-up is engine-derived state, not a caller write: the
+permission decision that matters — may this caller write the **child** — has
+already been made by the time the recompute runs. The elevation is a
+`sudo()`-shaped derivative of the caller's context, so an open transaction
+handle, `tenantId` and `timezone` still ride along; it is the same posture the
+roll-up's two other writers already held (the insert-time seed and the
+`summary-nulls` backfill), so all three writers of a summary column now agree
+about who owns it.
+
+Two quieter defects go with it, both of which only showed where the caller
+*could* write the parent and the recompute therefore "succeeded":
+
+- the aggregate was computed over the caller's **row-level-visible subset**, so
+  the parent's column was silently rewritten to one reader's view of the child
+  collection;
+- an author-declared `readonly: true` roll-up column was dropped by the
+  write-path read-only strip (which runs on `!context.isSystem`), so the summary
+  never landed at all.
+
+This does not widen what a caller may read or write. The parent's row is still
+governed by the caller's grants (a direct update of the parent is refused exactly
+as before), the summary column stays subject to the parent's field-level security
+on read, and the only value this path can move is the one the author declared as
+a function of the child collection. `ERR_SUMMARY_RECOMPUTE` is unchanged and
+still surfaces genuinely failed recomputes (a driver or network failure that
+outlives its retries), which is what the seed loader and import runner branch on.

.changeset/uninstall-env-wide-metadata-orphans.md

@@ -0,0 +1,42 @@
+---
+"@objectstack/metadata-protocol": patch
+---
+
+fix(metadata-protocol): uninstall no longer orphans a package's env-wide `sys_metadata` rows (#7705)
+
+`protocol.deletePackage` selected the rows to remove with a strict
+`organization_id` equality:
+
+```ts
+const where = { package_id: request.packageId };
+if (request.organizationId) where.organization_id = request.organizationId;
+```
+
+Against rows stored **env-wide** (`organization_id IS NULL`) that predicate
+matches nothing, so an uninstall issued by a session with an active
+organization removed only whichever rows happened to be org-scoped and left
+every env-wide row behind — while reporting a nonzero `deletedCount` and
+`success: true` over the survivors. The package's metadata stayed in
+`sys_metadata` after its uninstall "succeeded", and a reinstall then collided
+with the rows that were never removed.
+
+Env-wide is where a package's metadata normally lands, which is why this was
+the common case rather than a corner: the REST `PUT /meta/:type/:name` save
+path does not thread the session's active organization, and AI-authored
+metadata is written env-wide too. Measured on a real engine over SQLite, an
+org-scoped uninstall of a package holding three env-wide rows and one
+org-scoped row deleted **1 of 4** and reported success.
+
+An org-scoped uninstall now matches its own organization **or** env-wide, the
+same `$or [{organization_id: oid}, {organization_id: null}]` shape this package
+already uses for the #3115 "orphaned draft" fix, and the same shape the SQL
+driver's own implicit tenant wall uses (`field = :tenant OR field IS NULL`,
+#2734).
+
+Scoping is unchanged in both directions that must not widen: another
+organization's rows for the same package are still out of scope for an
+org-scoped uninstall, and another package's rows are never touched. An
+uninstall issued with **no** organization is also unchanged — it stays
+package-wide, because the direct-mount REST door passes no organization at all
+and narrowing that branch to env-wide-only would orphan every org-scoped row
+instead.