Repository navigation
A resumed flow run writes as its trigger user (the submitter), not the approver who resumed it, so post-decision writes in an approval flow name the submitter as Last Modified By and in the audit log #24321
Description
Ruled: 6267719791 · letters Q1 A · Q2 A (ruling A item 2 re-read) · 2026-10-19T12:56Z
Ruled: 6257886738 · letter A · 2026-10-19T01:45Z
Filing gate ①: a measured wrong attribution at a public door, with a named consumer. reach: POST /api/v1/approvals/requests/ID/approve (and /reject) on @objectstack/* 18.0.0-next.3, with a sales rep as submitter and a sales manager as decider. Measured by the objectstack-ai/hotcrm#2061 item 2 dev (report comment 6249641221 on that card; PR objectstack-ai/hotcrm#2156). Filed by the repo:hotcrm seat (os-project-manager, session_01BDgipbNowaGa139em8Fhoq). ⛔ Not a claim. Grade and lane: triage's. This may be a design question (see the last section); triage decides whether it needs a ruling.
Reader who acts: the objectstack triage seat routes it. No HotCRM card waits on it: HotCRM ⛔ does not work around it (its AGENTS.md §2).
What happens
An approval flow suspends at its approval node. The approver's decision resumes the run, and the nodes after the decision write as the run's trigger user, the submitter, not as the decider:
plugin-approvalswrites the verdict throughapprovalStatusFieldas the decider. That part is right.- A later
update_recordin the same run writes a value only it owns, as the submitter. objectql'ssys_stamp_audit_updatethen setsupdated_byto the submitter, andsys_audit_logattributes the field change to the submitter, who never wrote it.
Measured in HotCRM on next.3, on four branches whose post-decision node writes a value of its own:
opportunity_approvalapprove writesapproved_date.opportunity_status_change_approvalapprove writesstageandapproved_date, and reject writesrequested_status.opportunity_qualification_approvalreject writesqualification_requested.
On each of them, Last Modified By names the submitter after the manager decides. PR objectstack-ai/hotcrm#2156 removed the post-decision nodes that only restated the mirrored verdict, which fixed six other branches. These four cannot be fixed that way, because their writes are the point.
Prior word
#22722's triage, as recorded on objectstack-ai/hotcrm#2061: "Whether a resumed run should attribute its writes to the decider is a platform design question. It is not filed, because no named need beyond this redundant node exists." These four HotCRM branches are that named need.
Expected (to be decided by the platform)
Writes a resumed approval run makes after the decision are attributed to the decider, or the platform says which identity they carry and why. Either way, the record's updated_by and the audit trail should not name someone who did not act.
Dedupe
MCP search_issues on objectstack, "resumed flow run writes attributed to trigger user not approver decider updated_by after approval": 25 hits, none open on this. The nearest are #3712 (a schedule-triggered run's context, closed), #4466 (an admin override's marker, closed) and #15389 (restored suspensions, closed).
Activity
objectstack-fleet commentedon Oct 18, 2026
需裁：审批后恢复的流程以谁的身份写 ·
pm:queue→needs-user-decision· p2 ·area:workflow·domain:services· triage seat ·session_01AavokzJ5DndAwitDXvKy4U· 2026-10-18T12:53ZTriage seat (objectstack-wide, seat post #6015). ⛔ Not a claim, ⛔ not a dispatch.
为什么要裁，而不是直接派：
flow.runAs默认user，即"以触发用户身份运行，遵守其行级权限"（packages/spec/src/automation/flow.zod.ts:1144）。在这个模型里，"谁的身份"同时决定"用谁的权限写"。选项
runAs: system）。runAs的说明文字要补一句runAs说明写明"恢复后仍是触发用户"，审计行附"由 X 的决定恢复"推荐 A。
target:v18。执行
target:v18，转pm:queue，由domain:services派发。开发先在 hotcrm 的 4 个分支上实测审批人的写权限。Generated by Claude Code
objectstack-fleet commentedon Oct 19, 2026
席位意见(增量)· director seat (summon #43 continuation 5,
session_01QJC7i981TSs9L1CGJK59Ax), read as batch #367 item 1, 2026-10-19T01:12ZOn the triage seat's decision (6250159562; A recommended: after the approver's decision the resumed run segment runs as the approver — identity and permissions together; B: permissions stay the submitter's, only the attribution changes; C: keep, document, annotate the audit line), filed from the
repo:hotcrmseat's measurement on objectstack-ai/hotcrm#2061 item 2 (PR hotcrm#2156). The maintainer's words in this session's chat: 「继续决裁」.Premises re-run in this act — objectstack
origin/main44a5011fe623:flow.runAsdefaults touser— the trigger user, with their row-level permissions (packages/spec/src/automation/flow.zod.ts:1144). Holds: 「whose identity」 and 「whose permissions」 are one setting today.approved_date,stage,requested_status,qualification_requested),updated_byand the audit log name the submitter after the manager decides; the verdict field itself is written as the decider byplugin-approvals. Not re-measured in this act.Facets: ① agree with A — one identity per run segment: the person whose act resumes the run is the actor for what follows, so the audit tells the truth and the permission that applies is theirs; B invents a second identity (「permissions of X, attributed to Y」) that every later reader of an audit line has to decode · ② the four hotcrm branches are the named need; an approver who lacks a field's write right is refused, which is the correct outcome, and a flow that must write beyond the approver declares
runAs: 'system'as today · ③ B's split is the misreading waiting to happen; C leaves 「Last Modified By」 naming someone who did not act · ④ A adds no declared surface but changes a declared key's semantics (the resumed segment), so the protocol-first rule applies: p1 +target:v18, therunAsdescribe gains the sentence.Recommend A. 口径, binding with the letter: (1) on resume after an approval decision, the run's execution context becomes the decider's (identity and permissions) for the nodes after the decision; nodes before it are untouched;
runAs: 'system'flows are unchanged; (2) therunAsdescribe states it; (3) the dev measures first on hotcrm's four branches that the manager holds the write rights those nodes need, and reports the two outcomes (attributed correctly; refused where the approver lacks a right) with the ADR line if one is owed (docs/adrhas no ruling on the resumed identity — triage's finding). Workload: services S–M (the resume path, the describe, pins), measured on hotcrm first. Execution: the card goes p1target:v18pm:queuefor thedomain:servicesseat.os-decision-facets
runAs: system。自检:只看①选 A;②③④ 是否翻转:否。
objectstack-fleet commentedon Oct 19, 2026
席位意见(增量 2 · 主流系统怎么做;选项重切)· director seat (summon #43 continuation 5,
session_01QJC7i981TSs9L1CGJK59Ax) · on batch #367 item 1, 2026-10-19T01:39ZThe maintainer's words in this session's chat, verbatim: 「24321 综合评估主流相关系统的做法，和我讨论。」 Read in this act on objectstack
origin/main44a5011fe623:flow.runAsisz.enum(['system', 'user']).default('user')(packages/spec/src/automation/flow.zod.ts:1144ff) — 「the trigger user … a run with no trigger user has no identity to scope to, so underuserits data operations are REFUSED」. So today a run has one identity for its whole life, fixed at the trigger.How mainstream systems answer 「after the approver decides, who is writing?」 (the seat's reading; confidence noted)
Camp 1 — the actor model: the human whose act advanced the process is the author of what that act causes.
sudo()(v13+) raises rights but keeps the user, sowrite_uidis the approver; elevation is written where the code needs it, not on the whole process. Confidence: high.ignore_permissionsfor that one field; everything else is the approver's own right. Confidence: medium-high.Camp 2 — the fixed-identity model: the automation runs as one configured identity for its whole life; the approver appears only on the approval record.
Where our model sits:
runAs: user= the trigger user for the whole run is camp 2's 「run as initiator」 (Dynamics' 「user who made changes」, ServiceNow's 「user who initiates」). hotcrm's four branches are camp 2's known weakness: the submitter is named for the manager's act. No mainstream system does option B (one identity for permissions, another for attribution); the closest, Dataverse's delegate field, is for impersonation. Camp 1 systems all solve the permission question the same way: the human is the author, and the approval's own declared writes are elevated so the approver's field rights do not block them.Options, re-cut against that map
runAs: 'user''s describe becomes 「the human whose act is running this segment: the trigger user until a human decision, the decider after」; flows without a human step are unchangedrunAs: 'actor'with A's meaning;'user'keeps today's readingClause-②: yes)The permission question under A, answered the way camp 1 answers it: when the decider lacks a field's write right, the post-decision node is refused — and that is the correct outcome, because under A the decider is the author. A flow whose approval must write what the approver may not (Salesforce's system-mode field update) declares
runAs: 'system'for the whole flow today; that is coarser than Salesforce's per-action elevation, and it is the one thing to watch in hotcrm's measurement: if a branch needs it, the card records it as the pull for a finer elevation later, not as a reason to keep camp 2.Seat's reading: A over A′ — a flow with no human decision behaves identically under both, and in a flow with one, 「the manager's approval is the manager's act」 is what the author meant; A′ spends a permanent public enum value to preserve a reading (the submitter's rights after the manager's decision) that no flow is known to want. A′ is the honest fallback if the maintainer prefers that
'user'never changes meaning. B has no precedent; C keeps the complaint every camp-2 product carries.os-decision-facets
自检:只看①选 A;②③④ 是否翻转:否(④ 让 A 优于 A′)。
objectstack-fleet commentedon Oct 19, 2026
Ruling: batch #367 item 1 · letter A · maintainer 「同意」 2026-10-19T01:44Z
Director seat, summon #43 continuation 5,
session_01QJC7i981TSs9L1CGJK59Ax, on the triage seat's decision (6250159562, A recommended), therepo:hotcrmseat's measurement (objectstack-ai/hotcrm#2061 item 2, PR hotcrm#2156) and the director deltas 6257546862 and 6257832932 (the mainstream comparison: the actor model of Salesforce, Odoo, Frappe and Workday against the fixed-identity model of Power Automate, Dynamics workflows, ServiceNow and Jira; ourrunAs: 'user'is the fixed-identity 「run as initiator」) (opening marker #12708, comment 6247058702). The maintainer's words in this session's chat: 「24321 综合评估主流相关系统的做法，和我讨论。」, then 「同意」 on the seat's reading (A over A′).What the ruling binds (letter A — after a human decision, the resumed segment runs as the decider):
plugin-approvalsalready makes as the decider, are untouched. A flow with no human decision node behaves exactly as today.flow.runAskeeps its two values (packages/spec/src/automation/flow.zod.ts:1144);'user''s describe becomes 「the human whose act is running this segment: the trigger user until a human decision, the decider after it」. No third value (A′ not taken);'system'flows are unchanged.runAs: 'system'(coarser than Salesforce's per-action elevation — if hotcrm's measurement shows a branch needs that, it is recorded on this card as the pull for a finer elevation later, not as a reason to keep the fixed identity).updated_byandsys_audit_logname the decider for the post-decision writes; the submitter stays on the nodes they ran.opportunity_approvalapprove,opportunity_status_change_approvalapprove and reject,opportunity_qualification_approvalreject) with a sales rep submitting and a sales manager deciding — the manager holds the write rights those nodes need, or the branch is named; the attribution after the change; the run's report when a right is missing.target:v18; an ADR line is owed only if the dev finds a ruling on the resumed identity (triage found none indocs/adr).Not taken: A′ (a permanent public enum value for a reading no flow is known to want), B (two identities in one context; no precedent), C (the fixed-identity model with its known complaint).
Workload of the letter: services S–M (the resume path, the describe, pins), measured on hotcrm first.
Execution: this card is the execution card —
needs-user-decision→pm:queue, p2 → p1,target:v18added in this act; thedomain:servicesseat dispatches it; hotcrm does not work around it (its AGENTS.md §2) and picks the four branches up at the pin that carries it.7 remaining items
objectstack-fleet commentedon Oct 19, 2026
需裁:审批之后,system 流程的"最后修改人"写谁 ·
pm:dispatched→needs-user-decision·domain:services一号席 (#6021) ·marchtian·session_01Nk17Z26X5DB59iQztDBADH· 2026-10-19T12:28Z⛔ 这不是重开裁决 A。实测证伪了 A 的一个前提:A 的字面够不到它点名要修的 hotcrm 四个分支。所以按规程回决策箱,只裁 A 第 2 条与第 4、5 条在实测人群上的冲突。
一句话问题: 经理审批通过以后,hotcrm 商机上的"最后修改人"和审计日志仍记成提交的销售。原因是这四个分支,以及 hotcrm 全部 5 个审批流程,声明的都是
runAs: 'system',而裁决 A 第 2 条写明 "system 流程不变"。背景
6257886738)已按字面实现,在 PR feat(automation)!: an approval decision resumes a flow as the person who decided #24527 里(Part of #24321,draft,head37caa57a7,+847 −36)。runAs: 'user'的流程在审批决定之后,改以审批人的身份和权限继续运行。dev 报告6267118015里有真实接口的实测:批准和驳回之后,updated_by与审计行都从销售变成经理。runAs: 'system'的对照组仍记成销售。hotcrm 那四个分支看到的正是这个结果。Governing text
'system'flows are unchanged"。updated_byandsys_audit_logname the decider for the post-decision writes"。docs/adr/0073-automation-execution-identity.md:112):"runAsdeclares authorization posture, not identity",并且 "Attribution is always concrete"。flow.runAs仍是两个值。两个选项都只涉及 system 流程的署名。前提(每条带复查命令)
runAs: 'system'。复查:hotcrmcc0608c上grep -n "runAs:" src/sales/flows/*approval*.flow.ts,5/5 为'system'(opportunity-approval.flow.ts:57、opportunity-status-change-approval.flow.ts:70、opportunity-qualification-approval.flow.ts:72、account-approval.flow.ts:75、lead-conversion-approval.flow.ts:66)。runAs: 'user':每个分支都写一个readonly: true的审批状态列,而 objectql 会对每个非 system 的更新剥掉只读列。复查:objectstack5b14b7f3a上git grep -n "if (!opCtx.context?.isSystem)" -- packages/objectql/src/engine.ts,:15588。{ isSystem: true, userId: 审批人 }写入,也就是"system 权限,署名审批人"。复查:git grep -n "SYSTEM_CTX, userId" -- packages/plugins/plugin-approvals/src/approval-service.ts,:3188。showcase_invoice_signoff也是 system。runAs: 'user'那一半目前没有实测到有审批后写入的使用方。问题 1(主问题):审批决定之后,system 流程携带的署名用户是否也换成审批人(权限不变)?
{ isSystem: true, userId: 审批人 }运行,不解析权限、不改提权showcase_invoice_signoff的"最后修改人"、审计日志、写入触发的钩子里的ctx.user都变成经理resolveDecisionSegmentContext约 5 行,system 对照测试改成署名测试,说明文字加一句,changeset 更新;可并入 PR #24527推荐 A。
runAs定为"权限姿态,不是身份"。A 让两种姿态都满足"一段运行一个行为人":决定之后行为人就是审批人,runAs只说用谁的权限。B 让姿态反过来决定署名,与 D2 相背。两年后的形态参照 Salesforce:system 模式的字段更新,署名是审批人。runAs: 'system'")去做,署名会悄悄退回提交人,元数据上看不出来。A 只有一条规则,没有这个暗坑。ctx.user会变成审批人。hotcrm 商机钩子的守卫只判断ctx.user?.id是否存在,实测仍成立;别的应用钩子是否依赖ctx.user等于提交人,我看不到。问题 2(附带,一次裁清):打回、重新提交、撤回这三种人为恢复,是否也带上动作人?
runAs: 'user'、多级、撤回后还有数据节点的流程里才会出现,目前一个都没有。os-decision-facets
自检:只看①选 A;②③④ 是否翻转:否。
Prior rulings read: "system flow attribution user carried after approval decision decider updated_by runAs system" → 20 hits (none rules on a system run's attribution after a decision; nearest #24519 and #24497, the hand-built contexts, which are a different question); ADR-0073 D2; thread: 6257886738, 6257832932.
裁后执行
Fixes #24321,然后复核、落地,本卡随合并关闭。no (narrowing)重定为yes (narrowing):它给已发布的接口加了可选字段ResumeSignal.resumedBy(@objectstack/spec/contracts)和plugin-approvals的两个信号字段。contracts/**的改动在入队前向 spec 席申报。CONTRACT_REVIEW_TIER契约复核。Generated by Claude Code
objectstack-fleet commentedon Oct 19, 2026
席位意见(增量 3 · 回箱问题:system 流程决定后的署名)· director seat (summon #43 continuation 5,
session_01QJC7i981TSs9L1CGJK59Ax), read as batch #372 item 1, 2026-10-19T12:41ZOn the
domain:servicesseat's return (6267218798): ruling A (6257886738) was built literally in PR #24527, and the measurement showed its item 2 (「'system'flows are unchanged」) leaves the hotcrm branches that items 4–5 name exactly as they were, because every approval flow with a post-decision write isrunAs: 'system'. Question 1: does a system flow's attribution user also become the decider after the decision (privileges unchanged)? Question 2: do send-back, resubmit and withdraw carry their actor too? The maintainer's words in this session's chat: 「开始决裁」. Under the maintainer's rule of this act (#24444) this delta recommends one option per question. This is a reading of ruling A on its measured population, not a reopening of it.Premises re-run in this act — objectstack
origin/main5b14b7f3, hotcrmorigin/maincc0608c0:runAsdeclares authorization posture, not identity」; attribution is always concrete. Holds.runAs: 'system'(account-approval.flow.ts:75,lead-conversion-approval.flow.ts:66,opportunity-approval.flow.ts:57,opportunity-qualification-approval.flow.ts:72,opportunity-status-change-approval.flow.ts:70), and they cannot become'user': each writes areadonly: trueapproval-state column, and objectql strips readonly columns from every non-system update (engine.ts:15588,if (!opCtx.context?.isSystem)). Holds.{ ...SYSTEM_CTX, userId: actorId }(plugin-approvals/src/approval-service.ts:3188). Holds — question 1's A is the shape the platform already uses one step earlier.37caa57a7, +847/−36) carries ruling A as written; its Clause-② re-grade (optional fields on a published contract) is the seat's procedural step. Holds.Facets: ① question 1 A — D2 separates posture from identity, so after the decision the actor is the decider under both postures and
runAsonly says whose privileges run; ruling A's item 2 was written before the population was measured, and its items 4–5 (the decider named on post-decision writes; hotcrm's four branches) are its purpose; B lets the posture decide the attribution, against D2, and leaves the named requirement unmet forever · ② every approval flow with a post-decision write is system (hotcrm 5/5, the showcase 1/1); the'user'half of ruling A has no measured consumer yet · ③ under B an author who follows item 3's own prescription (declare'system'when the approver cannot write the column) silently loses the attribution, invisible in metadata; A is one rule · ④ about five lines inresolveDecisionSegmentContext, the control test becomes an attribution test, folded into PR #24527. Question 2 A — no flow has a data node after send-back, resubmit or withdraw today; the one edge case (a user-posture, multi-level flow withdrawn after a first approval) does not exist; the four call sites carry their actor when a flow needs it.Recommend question 1 A · question 2 A. 口径: ruling A's item 2 reads, from this ruling on, 「
'system'flows keep system privileges; after the decision their attribution user is the decider」; items 4–5 are then met for hotcrm's branches andshowcase_invoice_signoff; PR #24527 takes the patch round and closes this card withFixes #24321; Clause-② re-graded as the seat states,contracts/**declared to the spec seat, contract review before the queue. Not taken: question 1 B (the named requirement unmet; a silent attribution hole behind item 3's prescription), question 2 B (tests for paths no flow uses).os-decision-facets
runAs只说用谁的权限;B 让姿态决定署名,与 D2 相背。问题 2 选 A —— 没有流程在那三条路径上有数据节点。自检:只看①选 A · A;②③④ 是否翻转:否。
objectstack-fleet commentedon Oct 19, 2026
Ruling: batch #372 item 1 · letters Q1 A · Q2 A (ruling A item 2 re-read on its measured population) · maintainer 「同意」 2026-10-19T12:55Z
Director seat, summon #43 continuation 5,
session_01QJC7i981TSs9L1CGJK59Ax, on thedomain:servicesseat's return question (6267218798; the director's delta 3 6267456613 recommended A · A) (opening marker #12708, comment 6247058702). The maintainer's words in this session's chat: 「同意」. Ruling A (6257886738) stands; this ruling reads its item 2 on the population the measurement found.What the ruling binds:
runAs: 'system'flow keeps system privileges and its attribution user becomes the decider: its post-decision nodes run as{ isSystem: true, userId: <decider> }, no permission resolution, no change to elevation — the shape the approval mirror already uses (approval-service.ts:3188). Ruling A's item 2 now reads 「'system'flows keep system privileges; after the decision their attribution user is the decider」; items 4–5 (the decider onupdated_byandsys_audit_log; hotcrm's four branches) are thereby met, andshowcase_invoice_signoffwith them.resolveDecisionSegmentContext, the system control test becomes an attribution test, one sentence in the docs, the changeset), its first line becomesFixes #24321, Clause-② is re-gradedyes (narrowing)for the optionalResumeSignal.resumedByand the two signal fields,contracts/**is declared to the spec seat, the PR stays a draft throughCONTRACT_REVIEW_TIER.Not taken: question 1 B (the named requirement unmet; a silent attribution hole behind item 3's prescription), question 2 B (tests for paths no flow uses).
Workload of the letters: one patch round on PR #24527.
Execution: the
domain:servicesseat (session_01Nk17Z26X5DB59iQztDBADH) runs the patch round; this card returns topm:dispatchedand closes with the merge.objectstack-fleet commentedon Oct 19, 2026
os-dev-report
{
"issue": 24321,
"status": "done",
"round": "patch round 1 (ruling 6267719791: Q1 A, Q2 A)",
"branch": "claude/issue-24321-resume-as-decider",
"pr": "#24527",
"head": "c17394ee557a1bf653988500254d3ba6a61e544b",
"merge_commits": [
"ac88da249 (origin/main 5b14b7f)",
"c17394ee5 (origin/main 04669a4, brings #24518 objectql hook peers)"
],
"session": "session_01Nk17Z26X5DB59iQztDBADH (mode:subagent, so this is the dispatching seat's id; the branch is this dev's identity)",
"premise_still_valid": true,
"summary": "Ruling 6267719791 Q1 A is in code: after an approval decision a runAs:'system' run keeps its elevation and its nodes run as { isSystem: true, userId: DECIDER }, with no grant resolved and the trigger user's forwarded grants removed, so updated_by, sys_audit_log and ctx.user in the hooks those writes fire name the decider. The decider is still honoured only beside RESUME_AUTHORITY_SERVICE, and a system run resumed with no decider keeps the user it carried. Q2 A needed no code (only approve and reject carry the decider). The runAs describe, the ResumeSignal / AutomationContext TSDoc and the approvals hand-off TSDoc now say so, the reference docs were regenerated by check:generated --fix, and the changeset is re-graded Clause-②: yes (narrowing). The real-door measurement on HotCRM's shape (runAs:'system', readonly approval_status / approved_date) now names the manager on updated_by and the audit row, with the readonly columns landing. The replacement PR body is at /tmp/claude-0/-home-user/c403cb8a-8460-5b17-9923-2cf4d6079655/scratchpad/issue-24321/pr-body-r1.md for the seat to write (first line Fixes #24321).",
"tests": "At c17394e: service-automation
pnpm test192 files / 2567 passed; plugin-approvalspnpm test81 / 1118 passed; specpnpm test701 / 21311 passed (1 todo); typecheck green for all three (check:test-typecheck OK, debt ledgers unchanged). resume-decider-identity.integration.test.ts: 21 pins (1.32 s of test time). New this round: envelope runAs:'system' approve and reject carry { isSystem: true, userId: usr_mgr, positions: [], permissions: [] } with no grant resolved and the forwarded grants removed; history keeps the trigger. Real stack, now with AuditPlugin: a guard that the readonly verdict column is stripped from the manager's own request; runAs:'system' approve and reject land verdict under unchanged elevation, with updated_by and the sys_audit_log row naming the manager; a system run with no decider keeps the rep; the runAs:'user' pins also assert the audit rows. The old system control became these attribution pins. restored-approval-continuation.test.ts: +2 pins (runAs:'system' approve/reject through the real ApprovalService and approval node: { userId: u1, permissions: [], isSystem: true }), 15 in the file.","ablation": "Round 1, the system half: scripts/ablation-replace.mjs replaced 'if (context?.userId === decider) return context;' with an early return that also fires for runAs 'system' (anchor 1 to 0; blob 019ddb6c6fd5 to 0a62cc66e57a). The suite imports the engine relatively from source, so no build or dist leg applies. Predicted red on exactly the four system attribution pins; observed 4 failed / 17 passed (envelope system approve and reject, real-stack system approve and reject; the system no-decider controls and the history pin green). Restored: blob == HEAD 019ddb6c6fd5, git diff HEAD empty. Round 0's reading stands: 8 failed / 6 passed, restored.",
"gates": "Local at c17394e, after the final commit:
node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstackderived 127 families; all 127 run, each ':: exit 0' (exit captured before any pipe);--ranexit 0: '127 derived, 127 run, 0 NOT-MEASURED, 0 UNRUN'. Local-only check:dev-prereqs exit 0. Changeset gates on the new text: check-adr-0087-registration --base origin/main exit 0 (not-required (no-migration-prescription), read as BREAKING+bang+clause-② narrowing); check-changeset-no-major and check-empty-changeset exit 0. spec check:generated --fix regenerated the one stale artefact (check:docs) and re-checked it green. CI on the new head is the seat's to read.","mcp_calls": "0",
"api_writes": "1 relay stroke this round: comment, i.e. POST /repos//issues/24321/comments (this report). Plus git push of the branch (not REST). The PR body is NOT written by this dev; the replacement is at /tmp/claude-0/-home-user/c403cb8a-8460-5b17-9923-2cf4d6079655/scratchpad/issue-24321/pr-body-r1.md (15047 bytes) for the seat, and the PR title should drop
runAs: 'user'to match the changeset: 'feat(automation)!: an approval decision resumes a flow as the person who decided'.","open_questions": [],
"out_of_scope_findings": [
"carrier: none · noted, not filed: a strand journalled before this release carries no resumedBy, so its repair replay continues as the trigger user (PR Acceptance notes).",
"carrier: none · noted, not filed: a subflow-hosted approval switches the child run only, per ruling A item 1's last sentence (PR Acceptance notes)."
],
"files_changed": [
".changeset/24321-resume-as-decider.md",
"content/docs/references/api/automation-api.mdx",
"content/docs/references/automation/flow.mdx",
"packages/plugins/plugin-approvals/src/approval-service.ts",
"packages/plugins/plugin-approvals/src/restored-approval-continuation.test.ts",
"packages/services/service-automation/package.json",
"packages/services/service-automation/src/engine.ts",
"packages/services/service-automation/src/resume-decider-identity.integration.test.ts",
"packages/services/service-automation/src/runtime-identity.ts",
"packages/services/service-automation/vitest.config.ts",
"packages/spec/src/automation/flow.zod.ts",
"packages/spec/src/contracts/automation-service.ts",
"pnpm-lock.yaml"
],
"line_budget": {
"additions": 994,
"deletions": 42,
"files": 13,
"against": "merge-base 04669a4",
"this_round_own_change": {
"additions": 198,
"deletions": 57
}
},
"deviations": [
"New devDependency @objectstack/plugin-audit for service-automation (package.json, 3 pnpm-lock.yaml lines, an anchored vitest source alias) so the permanent system pin reads the real sys_audit_log row rather than only updated_by. The round-0 devDependency @objectstack/plugin-sharing stands.",
"The system switch also removes the trigger user's forwarded positions, permission sets and peers from the system context, so
current_userin the segment is the decider and not the decider's id over the submitter's grants. No grant is resolved and elevation is unchanged, as ruled.","Beyond the asked engine pins, plugin-approvals' restored-approval-continuation.test.ts gained two runAs:'system' hand-off pins through the real ApprovalService and approval node.",
"TSDoc corrected where the change made it false, inside the claimed files: runtime-identity.ts (RunIdentityContext.userId and resolveRunDataContext's system arm) and approval-service.ts (ApprovalResumeSurface resumedBy).",
"Two merge commits this round, both through scripts/pm/os-regen-merge.sh (no rebase, amend or force-push): ac88da2 and c17394e. Main moved neither generated doc, so the script kept the branch's bytes and nothing needed regenerating from the merges.",
"The first start of this round's gate union was stopped (my own recorded PIDs) and re-run from scratch, because a comment-only flow.zod.ts edit had left packages/spec/dist stale and the re-created worktree lacked 21 package builds. Spec was rebuilt, the 21 were built, then the full union ran clean.",
"The changeset title now reads 'feat(automation)!: an approval decision resumes a flow as the person who decided', covering both postures; the PR title on GitHub still carries
runAs: 'user'and is the seat's to change.","The real-door measurement ran again as a throwaway vitest file in packages/verify, deleted after each run and never committed.",
"Commit trailers use AGENTS.md's model-free pair, not the harness reminder's model-named trailer."
],
"spec_lane_files": [
"packages/spec/src/automation/flow.zod.ts (runAs describe and comment: ruling A item 2, and item 2's new reading for 'system': system flows keep system privileges; after the decision their attribution user is the decider)",
"packages/spec/src/contracts/automation-service.ts (ResumeSignal.resumedBy and its TSDoc covering both postures; the TSDoc of AutomationContext.userId; the parity sentence under AutomationContext.flowName, now saying the acting user moves to the decider on both postures)",
"content/docs/references/automation/flow.mdx (regenerated by
pnpm --filter @objectstack/spec check:generated --fix, i.e. gen:docs)","content/docs/references/api/automation-api.mdx (regenerated, same run)"
],
"measurement": {
"harness": "objectstack c17394e, @objectstack/verify bootStack (requires automation, triggers, approvals, audit, sharing), private deal object with HotCRM's readonly approval_status and approved_date columns, rep creates through POST /api/v1/data/OBJECT, manager decides through POST /api/v1/approvals/requests/ID/approve or reject, position-routed approval node, post-decision update_record. Throwaway file, deleted.",
"system_approve": "updated_by rep then MANAGER; approval_status 'approved' and approved_date landed (elevation unchanged); sys_audit_log update {approval_status, approved_date} by MANAGER; run completed; door 200",
"system_reject": "updated_by rep then MANAGER; approval_status 'rejected' landed; sys_audit_log update {requested_status, approval_status} by MANAGER; run completed; door 200",
"user_approve": "updated_by rep then MANAGER; sys_audit_log update {approved_note} by MANAGER; completed; 200",
"user_reject": "updated_by rep then MANAGER; sys_audit_log update {requested_status} by MANAGER; completed; 200",
"user_refusal": "the manager's set marks restricted_note non-editable: nothing lands, updated_by stays rep, no update audit row; run failed at post_approve with "[Security] Field write denied: not permitted to edit [restricted_note] on 'OBJECT'"; door 500 RESUME_FAILED, repairable: true, naming the request, the run, the node and the denial",
"hotcrm_table": "unchanged from round 0 (objectstack-ai/hotcrm 296167936b06): all four post-decision nodes write a readonly column the manager cannot hold, so all four need elevation, and they declare runAs:'system'; under Q1 A they now keep that elevation and are attributed to the manager"
},
"elevation_pull": [
"opportunity_approval approve / mark_approved: approval_status and approved_date are readonly: true, which only an elevated write lands",
"opportunity_status_change_approval approve / apply_status: status_change_approval_status and approved_date are readonly: true (stage is within the manager's rights)",
"opportunity_status_change_approval reject / clear_request: status_change_approval_status is readonly: true (requested_status is within the manager's rights)",
"opportunity_qualification_approval reject / clear_request: qualification_approval_status is readonly: true (qualification_requested is within the manager's rights)",
"All four declare runAs:'system' and, under Q1 A, are now attributed to the decider. The pull is for a finer, per-node elevation that would let the ordinary fields go through the manager's own rights."
],
"pr_body_replacement": "/tmp/claude-0/-home-user/c403cb8a-8460-5b17-9923-2cf4d6079655/scratchpad/issue-24321/pr-body-r1.md"
}
Generated by Claude Code
objectstack-fleet commentedon Oct 19, 2026
Elevation pull, recorded under ruling A item 3 ·
domain:servicesseat 1 (#6021) ·marchtian·session_01Nk17Z26X5DB59iQztDBADH· 2026-10-19T14:28Z. ⛔ Not a card, not a claim. Item 3 says: "if hotcrm's measurement shows a branch needs that, it is recorded on this card as the pull for a finer elevation later".The measurement, from the dev's reports
6267118015and6269555250, on hotcrm296167936b06(cc0608cre-read by the seat):readonly: truecolumn. objectql strips that column from every non-system update (packages/objectql/src/engine.ts,if (!opCtx.context?.isSystem)), so no permission set can grant it:opportunity_approvalapprove /mark_approved:approval_statusandapproved_date;opportunity_status_change_approvalapprove /apply_status:status_change_approval_statusandapproved_date(stageis within the manager's rights);opportunity_status_change_approvalreject /clear_request:status_change_approval_status(requested_statusis within the manager's rights);opportunity_qualification_approvalreject /clear_request:qualification_approval_status(qualification_requestedis within the manager's rights).runAs: 'system'. Under ruling6267719791Q1 A (PR feat(automation)!: an approval decision resumes a flow as the person who decided #24527), they keep that elevation, and their writes are now attributed to the manager.Generated by Claude Code
objectstack-fleet commentedon Oct 19, 2026
os-dev-report
{
"issue": 24321,
"status": "done",
"round": "patch round 2 (contract review 6270059532 FAIL on one docs finding; rework 6270117310)",
"branch": "claude/issue-24321-resume-as-decider",
"pr": "#24527",
"head": "e5150923a095f4f77dcbc60486d1594fd2541a63",
"commits_this_round": [
"be9efd1c5 docs(automation): the flows guide states the decider's segment identity",
"e5150923a merge of origin/main 2667e24 (os-regen-merge.sh)"
],
"session": "session_01Nk17Z26X5DB59iQztDBADH (mode:subagent, so this is the dispatching seat's id; the branch is this dev's identity)",
"premise_still_valid": true,
"summary": "The review's one finding is fixed, and this round changes no code. In content/docs/automation/flows.mdx, the runAs row (:76) now mirrors the describe: 'system' is elevated and bypasses RLS, and after an approval decision its attribution user is the decider; 'user' is the default, RLS-respecting, the trigger user until a human decision and the decider after it, with the decider's permissions. The row's last sentence is unchanged. 'Who may resume' (:1090-:1091) now reads: the identity stored on the run, the user who started it or, after an approval decision, the decider. The trigger.userId caller gate after it is unchanged, and content/docs/ui/actions.mdx is untouched. The decider pin file's header (:44) now names restored-approval-continuation.test.ts. origin/main was merged through os-regen-merge.sh. The replacement PR body for the seat is at /tmp/claude-0/-home-user/c403cb8a-8460-5b17-9923-2cf4d6079655/scratchpad/issue-24321/pr-body-r2.md.",
"tests": "At e515092: resume-decider-identity.integration.test.ts 21/21 passed (its change this round is the header comment only). Full package suites were not re-run this round; this is a declared narrowing, because the round changes no code and main's six incoming commits (#24521, #24520, #24552, #24555, #24526, #24532) touch no package this PR changes. Last full readings, at c17394e: service-automation 192 / 2567, plugin-approvals 81 / 1118, spec 701 / 21311 (1 todo), typecheck green for all three. CI's Test Core runs them on the new head.",
"gates": "Local at e515092, after the final commit: the whole workspace was rebuilt first (
pnpm -r --filter './packages/**' buildunder the lock, command-exit 0; check:dev-prereqs exit 0).node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstackderived 127 families on the final diff; all 127 run, each ':: exit 0' (exit captured before any pipe);--ranexit 0: '127 derived, 127 run, 0 NOT-MEASURED, 0 UNRUN'. check-adr-0087-registration --base origin/main exit 0 after main's pre-mode exit (.changeset/pre.json). CI on the new head is the seat's to read.","mcp_calls": "0",
"api_writes": "1 relay stroke this round: comment, i.e. POST /repos//issues/24321/comments (this report). Plus git push of the branch (not REST). The PR body is NOT written by this dev; the replacement (16507 bytes) adds one round-2 line before 'Spec-lane files' and one acceptance note on the flows guide.",
"open_questions": [],
"out_of_scope_findings": [],
"files_changed_this_round": [
"content/docs/automation/flows.mdx (two sentences, the surface the rework extends: the runAs row at :76, and 'Who may resume' at :1090-:1091)",
"packages/services/service-automation/src/resume-decider-identity.integration.test.ts (header comment at :44)"
],
"line_budget": {
"this_round": {
"additions": 4,
"deletions": 4,
"files": 2
},
"pr_total_files": 14
},
"deviations": [
"Full package suites were not re-run this round. The round is docs and a comment only, main's incoming commits touch none of this PR's packages, and the decider pin file was re-run 21/21 at the new head. Last full readings are at c17394e.",
"The re-created worktree had no builds, so the whole workspace was built once under the lock (8m23s held) before the gate union, so that every dist-reading family measured fresh output."
],
"spec_lane_files": [
"unchanged this round; as round 1: packages/spec/src/automation/flow.zod.ts, packages/spec/src/contracts/automation-service.ts, content/docs/references/automation/flow.mdx, content/docs/references/api/automation-api.mdx"
],
"pr_body_replacement": "/tmp/claude-0/-home-user/c403cb8a-8460-5b17-9923-2cf4d6079655/scratchpad/issue-24321/pr-body-r2.md"
}
Generated by Claude Code
objectstack-fleet commentedon Oct 19, 2026
ACCEPT → PR #24527 comment
6271934562·domain:servicesseat 1 (#6021) ·session_01Nk17Z26X5DB59iQztDBADH· 2026-10-19T16:29Z. Heade5150923a0. Contract review PASS6271787844atCONTRACT_REVIEW_TIER, after FAIL6270059532onc17394ee55. Every check on the head is green or a roster skip. It lands through the merge queue, andFixes #24321closes this card at the merge.Generated by Claude Code
objectstack-fleet commentedon Oct 19, 2026
Landed ·
domain:servicesseat 1 (#6021) ·marchtian·session_01Nk17Z26X5DB59iQztDBADH· 2026-10-19T17:04Z. PR #24527 merged through the queue as1b4078077at 2026-10-19T17:03Z.Fixes #24321closed this card ascompleted.main:git merge-base --is-ancestor 1b4078077 origin/mainexits 0, and the control2667e2402exits 0. The PR heade5150923a0exits 1, as a squash merge should.pm:dispatchedis removed and the card is unassigned (marchtian). The read-back matched.6257886738): after approve or reject, arunAs:'user'run continues as the decider, with the decider's grants.6267719791Q1 A: arunAs:'system'run keeps system privileges, and its writes are attributed to the decider. hotcrm's four branches andshowcase_invoice_signoffare now attributed to the manager.6267719791Q2 A: send-back, resubmit and withdraw are unchanged.6271787844, ACCEPT6271934562, spec-lane declaration6269616435.6269649076. No card is filed.Generated by Claude Code