docs(automation): the flows guide states the decider's segment identity

The runAs row and the resume section of the hand-written flows guide now
say what the describe says: a 'user' run is the trigger user until a
human decision and the decider after it, a 'system' run's attribution
user is the decider after a decision, and a resumed run continues under
the identity stored on the run. The decider pin file's header names the
approvals test that holds the hand-off pins.

Claude-Session: https://claude.ai/code/session_01Nk17Z26X5DB59iQztDBADH
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

content/docs/automation/flows.mdx

@@ -73,7 +73,7 @@ const approvalFlow = {
 | `version` | `number` | optional | Version number (defaults to `1`) |
 | `status` | `enum` | optional | `'draft'`, `'active'`, `'obsolete'`, `'invalid'` (defaults to `'draft'`) |
 | `type` | `FlowType` | ✅ | Flow trigger type (see below) |
-| `runAs` | `enum` | optional | `'system'` (elevated, bypasses RLS) or `'user'` (the triggering user, RLS-respecting; the default). A `'user'` run that resolved **no** trigger user has nothing to scope to, so its data operations are refused — declare `'system'` for schedule / time-relative / API triggers and for record-change flows fired by a write that carried no user |
+| `runAs` | `enum` | optional | `'system'` (elevated, bypasses RLS; after an approval decision its attribution user is the decider) or `'user'` (the default, RLS-respecting: the trigger user until a human decision, the decider after it, with the decider's permissions). A `'user'` run that resolved **no** trigger user has nothing to scope to, so its data operations are refused — declare `'system'` for schedule / time-relative / API triggers and for record-change flows fired by a write that carried no user |
 | `variables` | `FlowVariable[]` | optional | Input/output variables |
 | `nodes` | `FlowNode[]` | ✅ | Flow nodes |
 | `edges` | `FlowEdge[]` | ✅ | Connections between nodes |
@@ -1088,8 +1088,8 @@ referent there. The shape is `ResumeFailureDetailsSchema` in
 The route asks two questions, in this order. Both must pass.
 
 **1. Who is resuming.** A resumed run continues under the identity stored on
-the run, so its data nodes run as the user who **started** it, whoever sent the
-values. The route therefore admits only:
+the run — the user who **started** it or, after an approval decision, the
+decider — whoever sent the values. The route therefore admits only:
 
 - the user who started the run (the run's `trigger.userId`) — no extra
   permission needed;

packages/services/service-automation/src/resume-decider-identity.integration.test.ts

@@ -41,7 +41,7 @@
  * declares `resumeAuthority: 'service'`, resumed with the
  * `RESUME_AUTHORITY_SERVICE` marker and `resumedBy` exactly as
  * `ApprovalService.decide` hands them over (that hand-off is pinned in
- * `plugin-approvals`' `decision-resume-decider.test.ts`).
+ * `plugin-approvals`' `restored-approval-continuation.test.ts`).
  */
 
 import { describe, it, expect, beforeAll, afterAll } from 'vitest';