Merge branch 'main' into claude/issue-7679-i18n-supported-locales

Author: os-help

.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/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/sys-api-key-no-batch-route.md

@@ -0,0 +1,34 @@
+---
+"@objectstack/spec": patch
+"@objectstack/platform-objects": patch
+---
+
+fix(spec,platform-objects): put `sys_api_key`'s missing batch route on the record (#7802)
+
+`@objectstack/spec`'s `apiMethods` conformance scan was failing on `main` — and,
+because the scan lives in `spec` while the object it judges lives in
+`platform-objects`, failing for every PR that touched `spec` and no others.
+#7769 had added `update` to `sys_api_key`'s `enable.apiMethods` so the Setup
+UI's Revoke button had a working route, which tripped the rule "a whitelist that
+grants single-record writes must also grant `bulk`".
+
+Resolved as the rule's second documented outcome — a registered exemption, not a
+widened object. `sys_api_key` now carries the monorepo's only
+`SINGLE_RECORD_WRITE_ONLY` entry, with the evidence behind it:
+
+- **No batch surface exists to deny.** The console renders no checkbox column on
+  any of the object's list views: multi-select is auto-enabled only when a bulk
+  action exists, the sole implicit one is bulk-delete, and this object grants no
+  delete affordance (`managedBy: 'better-auth'` denies by default, `userActions`
+  opens `edit` alone, `delete` is not in `apiMethods`).
+- **A future multi-select revoke would not need `bulk` either.** `revoke_api_key`
+  / `restore_api_key` are `list_item` actions; promoting one into a view's
+  `bulkActions` resolves it to a `custom` def that the grid executor fans out
+  through the action runner as N single-record PATCHes — never `/batch`.
+
+So `POST /api/v1/data/sys_api_key/batch` and the `*Many` routes keep answering
+405 for API keys, deliberately: the object's authorable surface is the single
+`revoked` boolean that ADR-0092 D2's identity write guard admits, and nothing
+asks to write it in bulk. #7769's `update` grant is untouched — the Revoke
+button keeps working. Adding `bulk` later requires retiring the exemption in the
+same commit; the conformance suite's stale-entry check refuses to let both stand.

.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.