@@ -0,0 +1,16 @@
+---
+'@objectstack/runtime': patch
+---
+
+fix(runtime): a non-admin approver's decision from the request page reaches the approvals routes instead of answering 404 (#28657)
+
+Clause-②: yes (widening: on `POST /api/v1/actions/:object/:action` and MCP `run_action`, a same-origin `type: 'api'` action whose subject row the caller's own scope does not deliver, and whose request needs no field of that row, is forwarded and answers its target's answer where it answered `404 RECORD_NOT_FOUND`)
+Metadata-protocol: none
+
+The request page's decision actions (`approval_approve`, `approval_reject`, `approval_comment`, `approval_request_info`, and the submitter's `approval_remind` / `approval_recall`) are same-origin `type: 'api'` actions that forward to the approvals routes (`/api/v1/approvals/requests/{id}/approve` and the rest). The action door loaded the `sys_approval_request` row in the caller's data scope first, and a member has no data-door read on that object by design, so every decision a non-admin sent from the page answered `404 RECORD_NOT_FOUND` before the approvals route, which admits a pending approver itself, was ever asked.
+
+- **Now.** When the caller-scope load does not deliver the row, a same-origin api action is forwarded anyway, and the door answers what the target answers: a pending approver's Approve answers 200 and the request moves; a member who is not on the slate gets the approvals route's own refusal. The target authorizes the caller with the caller's own credentials (ADR-0066 D4), the same request the caller could send it directly, so nothing new is disclosed.
+- **⛔ No row data the caller could not read reaches the request.** On a denied load the request is built from the `recordId`, the params and the caller only. A declaration whose request needs a field of the row (a `{field}` path token other than `{id}`, or a `recordIdParam` read from a `recordIdField` other than `id`) keeps the `404 RECORD_NOT_FOUND`, and nothing is forwarded.
+- **Unchanged.** The declarative update, `type: 'flow'` and script/body actions still refuse a denied load with `404 RECORD_NOT_FOUND` before anything trusted is built. The member data grant on `sys_approval_request` is not widened.
+- **Both doors, one rule.** The REST `/actions` door and the MCP `run_action` bridge call one shared function at the same point (`refuseDeniedSubjectLoadBeforeDispatch`, with `apiForwardSubjectRecord` building the request's row).
+- **The target's sentence is relayed.** A target that answers `{ code, error: '<sentence>' }`, as the approvals decision routes do, now has that sentence relayed as the refusal's message (for example, which decision outputs are required to approve), where the door answered "its target answered HTTP 400".
@@ -1980,8 +1980,15 @@ export function apiActionRefusalMembers(answer: ApiActionForwardAnswer): Record<
  */
 export function apiActionForwardRefusal(action: any, answer: ApiActionForwardAnswer): Error {
     const body = answer.body;
+    // [#28657] Three places a target writes its sentence: the ADR-0112
+    // envelope's `error.message`, a bare `message` (better-auth), and a bare
+    // STRING `error` beside a top-level `code` — the approvals decision routes'
+    // `{ code, error }`, whose prescription (which decision outputs are
+    // required to approve, why this actor may not decide) was replaced by the
+    // fallback below before this read it.
     const message: string =
         (body && typeof body === 'object' && typeof body.error?.message === 'string' && body.error.message) ||
+        (body && typeof body === 'object' && typeof body.error === 'string' && body.error) ||
         (body && typeof body === 'object' && typeof body.message === 'string' && body.message) ||
         `Action '${action?.name ?? 'unknown'}' — its target answered HTTP ${answer.status}`;
     const code: string =
@@ -3356,6 +3363,102 @@ export function refuseDeniedSubjectLoad(
     throw recordNotFoundError(objectName, recordId ?? '');
 }
 
+/**
+ * Contract point 3 as the two action doors' dispatch reads it, for every
+ * branch: {@link refuseDeniedSubjectLoad}, except for a same-origin
+ * `type: 'api'` forward that needs nothing from the row.
+ *
+ * ## Why the api forward is different
+ *
+ * The 404 exists so that nothing TRUSTED is built for a caller who has not
+ * shown read access to the subject row: the RLS/FLS-bypassing `ctx.engine` /
+ * `ctx.api` of a script body, a persisted flow run, a declarative write. An
+ * api forward builds none of those. It hands its declared `target` the
+ * caller's OWN credentials, and the target authorizes the caller itself
+ * (ADR-0066 D4) — a request the caller could send to that target directly.
+ * Refusing it here put the generic data door's verdict in front of a door
+ * that answers the question itself, and wrongly: approval decisions are
+ * authorized by the approvals routes (a pending approver may decide), while a
+ * member has no data-door read on `sys_approval_request` by design. So a
+ * denied load no longer answers its own 404 ahead of the forward; the door
+ * forwards and relays what the target answers. A load that names nothing and
+ * a load that was filtered are the same answer to the target too, so this
+ * opens no existence oracle the target does not already answer.
+ *
+ * ## ⛔ No row data the caller could not read reaches the request
+ *
+ * On a denied load the request is built from the `recordId`, the params and
+ * the caller only ({@link apiForwardSubjectRecord}). A declaration whose
+ * request needs a field OF the row ({@link apiActionRequestReadsSubjectRow})
+ * cannot be built from those, so it keeps today's 404 `RECORD_NOT_FOUND`.
+ *
+ * Every other branch — the declarative update, the flow dispatch, the
+ * script/body dispatch — keeps the refusal unchanged. Both doors call this
+ * ONE function at the same point (the REST `/actions` door and the MCP
+ * `run_action` bridge), so the rule cannot hold at one and not the other.
+ */
+export function refuseDeniedSubjectLoadBeforeDispatch(
+    action: any,
+    objectName: string,
+    recordId: string | undefined,
+    subject: ActionSubjectRecordLoad,
+): void {
+    if (subject.recordLoadDenied && forwardsOnDeniedSubjectLoad(action)) return;
+    refuseDeniedSubjectLoad(objectName, recordId, subject);
+}
+
+/**
+ * Does a denied subject load still forward this action? Exactly a same-origin
+ * `type: 'api'` action (the doors refuse an off-origin one earlier) whose
+ * request can be built without the row. A declarative update is never one,
+ * whatever its `type` says: `operation` before `type`.
+ */
+export function forwardsOnDeniedSubjectLoad(action: any): boolean {
+    return !isDeclarativeUpdateAction(action)
+        && action?.type === 'api'
+        && isSameOriginApiTarget(action?.target)
+        && !apiActionRequestReadsSubjectRow(action);
+}
+
+/**
+ * Does this api action's request need a field OF the subject row — beyond the
+ * `id` the caller already named? Two places in the declaration read the row
+ * ({@link buildApiActionRequest}): a `{field}` path token in `target`, and a
+ * `recordIdParam` seeded from a `recordIdField`. `{id}` and a `recordIdField`
+ * of `id` (the default) are the routed `recordId` itself, so they do not.
+ *
+ * Read off the declaration, before any substitution: a token that only looks
+ * like a field (a `${name}` with no scope the substitution leaves in place)
+ * counts as one, which errs toward the 404, never toward a forward.
+ */
+export function apiActionRequestReadsSubjectRow(action: any): boolean {
+    const target: string = typeof action?.target === 'string' ? action.target : '';
+    for (const match of target.matchAll(/\{([a-z_][a-z0-9_]*)\}/gi)) {
+        if (match[1] !== 'id') return true;
+    }
+    const recordIdParam = typeof action?.recordIdParam === 'string' && action.recordIdParam ? action.recordIdParam : undefined;
+    if (recordIdParam) {
+        const field: string = typeof action?.recordIdField === 'string' && action.recordIdField ? action.recordIdField : 'id';
+        if (field !== 'id') return true;
+    }
+    return false;
+}
+
+/**
+ * The subject row an api forward's request is built from. A row the caller's
+ * own scope delivered, as it was; on a denied load, `{ id: recordId }` and
+ * nothing else — built from the id the caller named, ⛔ never from whatever
+ * the load left behind, so no field of a row the caller could not read can
+ * reach the request.
+ */
+export function apiForwardSubjectRecord(
+    recordId: string | undefined,
+    subject: ActionSubjectRecordLoad,
+): Record<string, unknown> {
+    if (!subject.recordLoadDenied) return subject.record;
+    return recordId ? { id: recordId } : {};
+}
+
 /**
  * [#15079] The prior/next value pair a successful declarative update hands back
  * when the action declares `undoable: true` — the anchor that key never had.
@@ -3867,7 +3970,11 @@ async function dispatchAdmittedBusinessAction(deps: ActionExecutionDeps,
     //    persisted automation run exists and no trusted body has been entered
     //    when the refusal lands. `ok: true` on a row the caller cannot read is
     //    the defect; refusing after the run was created would only describe it.
-    refuseDeniedSubjectLoad(objectName, recordId, subject);
+    //
+    // [#28657] Except ahead of an api forward that needs nothing from the row
+    // (`refuseDeniedSubjectLoadBeforeDispatch`): the target authorizes the
+    // caller itself. The REST `/actions` door calls the same function.
+    refuseDeniedSubjectLoadBeforeDispatch(action, objectName, recordId, subject);
 
     // ── api forward (#27506) ── a same-origin `type: 'api'` action is
     // forwarded in-process to its declared `target` with the caller's own
@@ -3889,7 +3996,7 @@ async function dispatchAdmittedBusinessAction(deps: ActionExecutionDeps,
                 code: standardErrorCodeForHttpStatus(503), status: 503,
             });
         }
-        const built = buildApiActionRequest(action, { recordId, record, params, ec });
+        const built = buildApiActionRequest(action, { recordId, record: apiForwardSubjectRecord(recordId, subject), params, ec });
         if ('message' in built) {
             throw Object.assign(new Error(built.message), { code: standardErrorCodeForHttpStatus(built.status), status: built.status });
         }
 
@@ -879,7 +879,13 @@ async function dispatchAdmittedRestAction(
         // audit line and the RLS/FLS-bypassing `ctx.engine` / `ctx.api` are
         // built below, and none of them may exist for a caller who has not
         // demonstrated read access to the subject row.
-        actionExec.refuseDeniedSubjectLoad(objectName, recordId, subject);
+        //
+        // [#28657] Except ahead of an api forward that needs nothing from the
+        // row: it builds none of that, and its target authorizes the caller
+        // itself (ADR-0066 D4), so a denied load forwards and the target's
+        // answer is this door's — see `refuseDeniedSubjectLoadBeforeDispatch`.
+        // The MCP `run_action` bridge calls the same function at the same point.
+        actionExec.refuseDeniedSubjectLoadBeforeDispatch(actionDef, objectName, recordId, subject);
 
         // ── api forward (#27506, ruling 6499781492) ── a same-origin
         // `type: 'api'` action is forwarded IN-PROCESS to its declared
@@ -903,7 +909,11 @@ async function dispatchAdmittedRestAction(
             if (!inject) {
                 return { handled: true, response: deps.error(actionExec.apiActionForwardUnavailableError(actionDef), 503) };
             }
-            const built = actionExec.buildApiActionRequest(actionDef, { recordId, record, params: reqParams, ec });
+            // [#28657] On a denied load the request is built from the
+            // `recordId` alone — ⛔ never from a row the caller could not read.
+            const built = actionExec.buildApiActionRequest(actionDef, {
+                recordId, record: actionExec.apiForwardSubjectRecord(recordId, subject), params: reqParams, ec,
+            });
             if ('message' in built) {
                 return { handled: true, response: deps.error(built.message, built.status) };
             }