@@ -0,0 +1,26 @@
+---
+'@object-ui/types': minor
+'@object-ui/react': minor
+'@object-ui/sdui-parser': minor
+'@object-ui/app-shell': patch
+---
+
+feat(types,react,sdui-parser,app-shell)!: the node-level `visibleOn` / `hiddenOn` / `disabledOn` spellings are retired; `visibleWhen` / `hidden` / `disabled` are the one predicate each
+
+Clause-②: no (narrowing)
+Metadata-protocol: narrowed
+
+<!-- adr-0087: not-required (no-migration-prescription) The three keys are `@object-ui/types` schema members on objectui's own node face, not an `@objectstack/spec` key, object definition, stored row or stored shape: the spec declares `visibleWhen` as the one conditional-visibility predicate at every layer (ADR-0089) and never declared a `*On` suffix on a page component, so the ADR-0087 registries in `packages/spec` have no entry to write and `objectstack migrate meta` has nothing to rewrite. Each old spelling is refused by name on both faces (the TypeScript compiler, the Zod mirror behind `objectui validate`), and the refusal names the surviving key; that is the same disposition the objectui retirements took when the package merged into this repository (maintainer ruling 28 = B on objectstack#25831). The guidance below is for the author of a page, not for a metadata upgrader. The other categories are closed on facts: the four packages publish (not unpublished); no ADR-0087 id is named or touched (not registered or already-registered); and what narrows is a declared schema key on a published metadata face, not a runtime-only interface, a type annotation or a runtime export (not runtime-interface-only, type-surface-only or runtime-export-retired). -->
+
+`@objectstack/spec` declares exactly one conditional-visibility predicate at every layer, `visibleWhen`, and objectui carried three spellings of its own beside it: `visibleOn` beside `visibleWhen`, `hiddenOn` beside `hidden`, `disabledOn` beside `disabled`. Each pair was evaluated by the same code with the same polarity, so the second spelling added a dialect and nothing else. The three are retired, with no alias window.
+
+- **`@object-ui/types`**: `BaseSchema.visibleOn`, `hiddenOn` and `disabledOn` are `never` on the TypeScript face and alias refusals on the Zod mirror. A document that writes one is refused at that key, and the message names the key that survives (`visibleWhen`, `hidden`, `disabled`), says the polarity is the same, and says the value is unchanged. `objectui validate` reads the same mirror, so it prints the same refusal. The `object-view` table slot's refusal of the same three keys now names the surviving node key too (write `visibleWhen` / `hidden` / `disabled` on the object-view node itself) instead of sending the author to a retired spelling. Boolean `visible` stays: the spec declares it on actions, navigation entries, tabs, alerts and settings, and the renderer keeps evaluating it.
+- **`@object-ui/react`**: `SchemaRenderer`'s visibility chain has three legs, `visibleWhen` and `visible` (shown when truthy) and `hidden` (hidden when truthy), and the enablement gate has one, `disabled`. A stale retired key that reaches the renderer unvalidated is not consulted and is held out of the component's props, so it neither gates the node nor lands in the DOM.
+- **`@object-ui/sdui-parser`**: the three keys are no longer base props. `validateTree` reports each as an `unknown-prop` diagnostic that names the surviving key, so a TSX tree is told the same thing a JSON document is. `checkRetiredVisibilityDialect` and `RETIRED_VISIBILITY_DIALECTS` are exported for that reading.
+- **`@object-ui/app-shell`**: the command palette reads a navigation entry's `visible` only; the `visibleOn` fallback it carried read a key `NavigationItem` never declared.
+
+**BREAKING** (an accept-set narrowing) for any page, view or component document that writes `visibleOn`, `hiddenOn` or `disabledOn` on a node. No shipped example, fixture or skill example in this repository wrote one; the ones in the documentation and the `objectui` skill are rewritten in this change.
+
+- **Before.** The three keys parsed, were evaluated beside their canonical twin, and the docs taught both spellings.
+- **Now.** Each is refused by name on `objectui validate`, on the Zod mirror, by the TypeScript compiler and by the SDUI parser, and the renderer does not read it.
+- **Fix.** Rename the key and keep the value: `visibleOn` becomes `visibleWhen`, `hiddenOn` becomes `hidden`, `disabledOn` becomes `disabled`. A form field's `fields[].visibleOn` is a different, view-level slot and is unchanged.
@@ -0,0 +1,12 @@
+---
+'@object-ui/plugin-grid': patch
+---
+
+fix(plugin-grid): a bulk action's confirm sentence formats its numbers and dates in the viewer's display locale
+
+Clause-②: no
+Metadata-protocol: none
+
+A bulk `confirmText` such as `Set the amount to {{ amount | currency:EUR }} on {{ count }} records?` formatted its numbers and dates in `en-US` for every viewer, while the same action's single-record confirm formats them in the viewer's language. `BulkActionDialog` now reads `useDisplayLocale()`, the locale every date, number and currency renderer and the console's action runners read, and `bulkConfirmText` takes it as an optional third argument, handed to `fillTemplateHoles`'s locale channel apart from the template roots. A German viewer reads `1.234.567,50 €`; with no locale handed, the sentence formats in `en-US` as before.
+
+What to do: nothing.
@@ -0,0 +1,18 @@
+---
+'@objectstack/spec': patch
+'@objectstack/plugin-approvals': patch
+'@objectstack/rest': patch
+'@objectstack/client': patch
+---
+
+feat(plugin-approvals,rest,client): a record-anchored approval lock read, `{ locked }` for every caller who can read the record
+
+Clause-②: yes (widening)
+Metadata-protocol: none
+
+A member who could read and edit a record but was not on its approval was offered an edit the server then refused with `409 RECORD_LOCKED`. The lock's only carrier was the request row's `lock_record`, and that row is rightly not served to a non-participant unless the object turns on `approvalsVisibleToReaders`. The lock now has a carrier of its own.
+
+- **`@objectstack/spec`.** `IApprovalService` gains the optional member `getRecordLock(object, recordId, context)`, which answers `{ locked: boolean }`, or `null` when the caller cannot read the record. No exported schema or type is added.
+- **`@objectstack/plugin-approvals`.** `ApprovalService.getRecordLock` reads the record as the caller. A record the caller cannot read answers `null`, the same answer as an id that does not exist. A caller with no read on the object is refused for every id, whether it exists or not. `locked` is `true` while a pending request's node has `lockRecord` other than `false`. The lock judgement is now one function, `nodeConfigLocksRecord` (not exported from the package), and the record-lock hook, the request row's `lock_record` and the new read all call it. Request content stays behind `approvalsVisibleToReaders`: the answer carries no request id, node, approvers or `pending` flag.
+- **`@objectstack/rest`.** New route `GET /api/v1/approvals/records/:object/:recordId/lock`. It answers `{ success: true, data: { locked } }`. A `null` answers `404 RECORD_NOT_FOUND` with one body, whether the record is unreadable or missing. A service without the member answers `501`. The route's closed query-parameter set is empty, so any query parameter is refused with a `400`. The route is ledgered as `sdk`.
+- **`@objectstack/client`.** `client.approvals.getRecordLock(object, recordId)` calls that route.
@@ -376,6 +376,27 @@ never deadlock against itself. The exemption is keyed on run identity rather tha
 elevation, so a `runAs:'user'` run stays row-level-security scoped while it
 writes — it does not become a system write.
 
+**Reading the lock.** Anyone who can read the record can ask whether it is
+locked, including a member who is not on the approval and so is served no
+request row:
+
+```bash
+curl -b cookies.txt \
+  "https://your-app.example.com/api/v1/approvals/records/expense/rec_123/lock"
+# → { "success": true, "data": { "locked": true } }
+```
+
+The answer is `locked` and nothing else: no request, approvers or history,
+which stay behind the object's `approvalsVisibleToReaders` switch. `locked` is
+`true` while a pending request's node has `lockRecord` other than `false`. That
+is the same check the server applies when it refuses an edit with `409
+RECORD_LOCKED`, so a page that reads it never offers an edit the server will
+refuse. The record is read as the caller: a record they cannot read answers
+`404 RECORD_NOT_FOUND`, the same body a record id that does not exist gets. The
+SDK call is `client.approvals.getRecordLock(object, recordId)`, and the service
+member is `IApprovalService.getRecordLock`. An approvals service without that
+member answers `501`.
+
 Only `approvers` is required on the node; everything else has a default
 (`behavior: 'first_response'`, `lockRecord: true`, `maxRevisions: 3`).
 
 
@@ -704,6 +704,15 @@ describe('Approvals namespace (ADR-0019)', () => {
         expect(url).toContain('/api/v1/approvals/requests/req-1');
     });
 
+    it('[#26314] reads a record\'s approval lock off the envelope, path segments encoded', async () => {
+        const { client, fetchMock } = createMockClient({ success: true, data: { locked: true } });
+        const result = await client.approvals.getRecordLock('order', 'rec/1');
+        expect(result).toEqual({ locked: true });
+        const [url, opts] = fetchMock.mock.calls[0];
+        expect(String(url)).toBe('http://localhost:3000/api/v1/approvals/records/order/rec%2F1/lock');
+        expect(opts?.method ?? 'GET').toBe('GET');
+    });
+
     it('should record an approve decision', async () => {
         const { client, fetchMock } = createMockClient({
             request: { id: 'req-1', status: 'approved' }, finalized: true, decision: 'approve', resumed: true
 
@@ -6260,6 +6260,21 @@ export class ObjectStackClient {
       return this.unwrapResponse<ApprovalRequestRow>(res);
     },
 
+    /**
+     * Whether a record is held by a locking approval — `{ locked }` and
+     * nothing else, answered to every caller who can read the record, whether
+     * or not they take part in the approval (`IApprovalService.getRecordLock`).
+     * A record the caller cannot read answers 404, exactly as a record id that
+     * does not exist; a deployment without the read answers 501.
+     */
+    getRecordLock: async (object: string, recordId: string): Promise<{ locked: boolean }> => {
+      const route = this.getRoute('approvals');
+      const res = await this.fetch(
+        `${this.baseUrl}${route}/records/${encodeURIComponent(object)}/${encodeURIComponent(recordId)}/lock`,
+      );
+      return this.unwrapResponse<{ locked: boolean }>(res);
+    },
+
     /**
      * Record an approve decision on a request. Finalises the request when the
      * node's behaviour is satisfied and resumes the owning flow run.
 
@@ -120,6 +120,7 @@ import {
   type FieldVisibilitySource,
 } from './payload-redaction.js';
 import { APPROVAL_REQUEST_CHILD_OBJECTS, type RequestVisibilitySource } from './request-read-gate.js';
+import { nodeConfigLocksRecord, recordHeldByLockingApproval } from './lifecycle-hooks.js';
 // The ADR-0043 pages — the ONE copy of their text, rendered by the plugin's
 // self-hosted mount and by `handleActionPage` alike.
 import { renderConfirmPage, renderResultPage } from './action-link-pages.js';
@@ -1280,13 +1281,13 @@ function rowFromRequest(row: any): ApprovalRequestRow {
     // ADR-0044 revision round (rides the config snapshot; absent ⇒ round 1).
     round: typeof cfg?.__round === 'number' ? cfg.__round : undefined,
     // objectui#2902: the node's record-lock policy. The lock is enforced
-    // server-side in `lifecycle-hooks.ts` off THIS SAME snapshot with the
-    // same `!== false` default, so the flag a client renders and the rule the
-    // server applies can never drift. Without it a console can only see
-    // "a pending request exists" and has to assume the record is locked —
-    // which mislabels every `lockRecord: false` node as locked and hides an
-    // edit the server would have accepted.
-    lock_record: cfg?.lockRecord !== false,
+    // server-side in `lifecycle-hooks.ts` off THIS SAME snapshot by the SAME
+    // judgement (`nodeConfigLocksRecord`, #26314), so the flag a client renders
+    // and the rule the server applies can never drift. Without it a console can
+    // only see "a pending request exists" and has to assume the record is
+    // locked — which mislabels every `lockRecord: false` node as locked and
+    // hides an edit the server would have accepted.
+    lock_record: nodeConfigLocksRecord(cfg),
     // #3447 P2: the node's author-declared decision outputs, surfaced so a
     // decision UI can render input fields for them and POST `outputs` on
     // approve/reject. Per-request (each node declares its own), which is why
@@ -8641,6 +8642,46 @@ export class ApprovalService implements IApprovalService {
     return this.loadRequest(requestId, context, true);
   }
 
+  /**
+   * [#26314] `IApprovalService.getRecordLock` — is this record held by a
+   * locking approval, for EVERY caller who can read the record (#25934 ruling
+   * A). A non-participant is told the record is locked before they edit it,
+   * instead of being offered an edit the lock hook then refuses.
+   *
+   * ## Who is answered — the #8652 anchor, read as the caller
+   *
+   * `engine.find(object, { where: { id }, context })` with the CALLER's
+   * context, exactly as {@link addRecordReaderVisibleIds} reads it: object CRUD
+   * read, then RLS. A row the caller may not see comes back empty and answers
+   * `null` — the very answer a record id that does not exist gets, because it
+   * is the same branch. ⛔ No path tells the two apart. A refusal of the read
+   * itself (no read on the object) is thrown, and is the same refusal for any
+   * id, existing or not. ⚠️ Probing with {@link SYSTEM_CTX} here would admit
+   * every authenticated user in the tenant.
+   *
+   * ## What is answered — the lock, and nothing about the request
+   *
+   * `{ locked }` only: no request id, node, participants or `pending`. Request
+   * content stays behind `approvalsVisibleToReaders` (#8652 ruling 5299823744,
+   * untouched). The judgement is the record-lock hook's own
+   * ({@link recordHeldByLockingApproval}), never a second copy of it.
+   */
+  async getRecordLock(
+    object: string,
+    recordId: string,
+    context: ExecutionContext,
+  ): Promise<{ locked: boolean } | null> {
+    const objectName = String(object ?? '').trim();
+    const id = String(recordId ?? '').trim();
+    if (!objectName || !id) return null;
+    // The anchor. As the CALLER — see the doc block.
+    const readable = await this.engine.find(objectName, {
+      where: { id }, fields: ['id'], limit: 1, context,
+    });
+    if (!Array.isArray(readable) || readable.length === 0) return null;
+    return { locked: await recordHeldByLockingApproval(this.engine, objectName, id) };
+  }
+
   private async loadRequest(
     requestId: string,
     context: ExecutionContext,
 
@@ -315,7 +315,7 @@ function asIdList(id: unknown): Array<string | number> | null {
 
 /** The pending request gating a record, plus its snapshotted node config. */
 async function pendingRequestFor(
-  engine: MinimalEngine,
+  engine: Pick<MinimalEngine, 'find'>,
   objectName: string,
   recordId: string,
 ): Promise<any | null> {
@@ -333,7 +333,7 @@ async function pendingRequestFor(
 
 /** Pending requests gating any of the records a write names by id. */
 async function pendingRequestsForRecords(
-  engine: MinimalEngine,
+  engine: Pick<MinimalEngine, 'find'>,
   objectName: string,
   recordIds: ReadonlyArray<string | number>,
 ): Promise<any[]> {
@@ -388,6 +388,57 @@ async function pendingRequestsForObject(
   }
 }
 
+/**
+ * THE lock judgement: does a pending request whose node snapshotted `config`
+ * lock its target record against edits?
+ *
+ * `lockRecord` defaults to `true` (`ApprovalNodeConfigSchema`), so a node locks
+ * unless it explicitly opted out. This is the one place that reading lives
+ * (#26314): the record-lock hook below enforces it, the request row mirrors it
+ * as `lock_record` (`rowFromRequest` in `approval-service.ts`), and the
+ * record-anchored read ({@link recordHeldByLockingApproval}) answers it — so
+ * what a client is told and what the server refuses can never drift. ⛔ Never
+ * re-spell `lockRecord !== false` at a call site.
+ */
+export function nodeConfigLocksRecord(config: unknown): boolean {
+  return (config as { lockRecord?: unknown } | null | undefined)?.lockRecord !== false;
+}
+
+/**
+ * The approvals plugin's own bookkeeping objects are never locked: the hook
+ * skips them with this cheap prefix test (it is a `beforeUpdate` guard, and
+ * the delete linkage below excludes them at registration instead).
+ */
+function isApprovalBookkeepingObject(objectName: string): boolean {
+  return String(objectName).startsWith('sys_approval');
+}
+
+/**
+ * [#26314] Is `recordId` of `objectName` held by a LOCKING pending approval —
+ * would an ordinary edit of it be refused `RECORD_LOCKED`?
+ *
+ * Asked exactly as the record-lock hook asks it of a by-id write: the same
+ * pending-request lookup ({@link pendingRequestsForRecords}, read as SYSTEM, so
+ * the bookkeeping is never narrowed by a caller's visibility) and the same
+ * judgement ({@link nodeConfigLocksRecord}). What it leaves out is what belongs
+ * to a WRITE, not to the record: the opening run's own writes (#3456) and a
+ * write touching only the status mirror are exempt there because of who writes
+ * and what, and neither is a property of the record.
+ *
+ * ⚠️ It answers for the record, not for a caller, and reads nothing as one.
+ * Whether the asker may learn the answer — may read the record at all — is the
+ * caller's question to settle first (`ApprovalService.getRecordLock`).
+ */
+export async function recordHeldByLockingApproval(
+  engine: Pick<MinimalEngine, 'find'>,
+  objectName: string,
+  recordId: string,
+): Promise<boolean> {
+  if (isApprovalBookkeepingObject(objectName)) return false;
+  const gating = await pendingRequestsForRecords(engine, objectName, [recordId]);
+  return gating.some((pending) => nodeConfigLocksRecord(parseJson<unknown>(pending?.node_config_json, {})));
+}
+
 /**
  * Narrow `candidates` (pending requests) to the ones whose record the caller's
  * predicate actually matches — asked of the engine as an intersection, so the
@@ -487,7 +538,7 @@ export function bindApprovalLockHook(
   engine.registerHook('beforeUpdate', async (ctx: any) => {
     const object = (ctx?.object ?? ctx?.objectName) as string | undefined;
     // No object name (shouldn't happen) or our own bookkeeping objects → skip.
-    if (!object || String(object).startsWith('sys_approval')) return;
+    if (!object || isApprovalBookkeepingObject(object)) return;
 
     const data = (ctx?.input?.data ?? {}) as Record<string, unknown>;
     const changedFields = Object.keys(data).filter((k) => k !== 'id' && k !== 'updated_at');
@@ -538,7 +589,7 @@ export function bindApprovalLockHook(
       if (writerRun && pending?.flow_run_id && String(writerRun) === String(pending.flow_run_id)) continue;
 
       const config = parseJson<any>(pending?.node_config_json, {});
-      if (config?.lockRecord === false) continue;
+      if (!nodeConfigLocksRecord(config)) continue;
 
       // Allow when every changed field is the approval status mirror.
       const mirror = config?.approvalStatusField;