[Decision] Override-recall of a `returned` approval: an ADR-0044 side effect to retire, or a capability to keep? The gate, the prose and the viewer flag disagree three ways

[huangyiirene]

Filed by the triage seat (session session_01Aujz2zykf5LXt3T98gRsGe) splitting the maintainer-floor half out of #12716, so that card is not held hostage to it. #12716 is queued for its own fix (surface the override-recall button on pending) and ⛔ does not depend on this ruling.

Measured by the #12716 dev and independently re-verified by the domain:services PM on origin/main at 86df0c99e — full evidence chain in #12716 comment 5442740007. ⛔ Not re-measured by this seat; re-verify before acting.

The three-way disagreement

surface	what it says about override-recall on a returned request
the gate — approval-service.ts:2763 + the status-blind override short-circuit at :2774	admitted
the viewer flag — attachViewers:4848, can_override: row.status === 'pending' && isOverrideActor(...) (ANDed)	pending-only
the prose — :808 "may always act on a PENDING request … or recall it", plus :2767, :4833	pending-only

Two surfaces say pending-only; the gate is the odd one out, and isOverrideActor(context, requestOrg?) structurally cannot be status-aware — there is no status parameter.

⭐ The reach looks like a side effect, not a grant. ADR-0044 widened recall's state check to cover the submitter's revise window; the override short-circuit sitting above it was never re-scoped alongside. Recall is the only one of the four override levers that accepts a non-pending status at all — decideNode:2308 and loadPendingRow:796 make approve / reject / reassign pending-only at the endpoint.

Why it is the maintainer's and not triage's

Retiring the reach narrows a permission on a live endpoint and removes a capability that exists in shipped code and is pinned by nothing. Both the dev and the services PM reached that boundary and handed it up rather than taking it; this seat agrees and is ⛔ not ruling it.

Options

	shape	cost
A	Keep the reach; make prose and viewer flag agree with the gate	To actually surface it needs a new, recall-specific viewer signal — can_override cannot be relaxed, since it also feeds the three sibling predicates whose endpoints are pending-only. New declared surface, permanent obligation
B	Retire the reach — re-scope the :2774 short-circuit to pending so all three agree at one point	Narrows a live permission. ⚠️ If any operator workflow relies on override-recalling a returned request, B breaks it silently
C	Leave all three as they are	The disagreement persists, undocumented. It has already cost one wrong triage ruling this round

<!-- os-decision-facets -->

一句话问题:管理员能不能撤回一张「已退回给提交人修改」的审批单?代码说能,产品文档和界面判据都说不能 —— 三处对同一个问题给了两个答案,而且没人知道哪个是当初想要的。

• ① 项目长远合理性:B 让闸门、散文、视图旗标在一个点上一致,消除三方分歧;A 也能一致,但方向相反且要新增一个声明信号;C 把矛盾永久化 —— 它这一轮已经让一次分诊裁决翻车,下一个读代码的人还会再量一次。
• ② 实际业务拉动:⚠️ 未测,而且这是本卡最关键的空白 —— 不知道有没有运维流程真的在用「管理员撤回已退回单」。但有一条反向证据:returned 的记录锁已经释放(approval-revise.test.ts:293/:313 pin 了 returned → unlocked),而 Approval routed to an empty position permanently locks the record (no admin override, no recovery) #3424 的原始动机场景(审批路由到无人岗位、单子卡死)按定义是 pending。⇒ 「管理员要来解救」这个理由在 returned 上不成立。
• ③ 防 AI 犯错:C 最差 —— 三个面对同一问题给三个答案,任何按约定读代码的 agent 都会推断错(本轮已实证)。B 让代码与散文一致且可被一条 pin 钉住;A 新增一个 recall 专用信号,面更大、更容易再漂。
• ④ 创业阶段不扩散:B 是收窄,不新增面;A 新增一个永久维护的声明信号。

推荐:B,附硬前置条件 —— 落地前先从审计留痕读出「是否真有 override actor 在 returned 上撤回过」。读数为零才动手;非零则当场改判 A,⛔ 不许带着非零读数硬做。回退:A。

置信缺口(本分析看不见什么):看不见生产部署里 override-recall-on-returned 的实际调用量。本席只能读代码,读不到运行数据 —— 而这恰恰是 A 与 B 之间唯一的真判据,也是 B 唯一的静默破坏风险所在。

裁后我会怎么执行(你不用管):裁 B ⇒ 翻 pm:queue 派 domain:services 席,派发令强制先跑审计读数、零才动手、非零停手回报;裁 A ⇒ 新增 recall 专用视图信号属扩大公开面,走条款②契约复审档位;裁 C ⇒ 关 not planned,但必须把三方分歧写进 approval-service.ts 的散文,免得第三次被人重新量出来。

Refs

• approvals: the approval_recall action hides the #3424 admin-override recall — the service admits it, the visible predicate never shows it #12716 — the queued half (surface the button on pending); its option A is correct-by-construction because can_override is already pending-scoped
• Approval routed to an empty position permanently locks the record (no admin override, no recovery) #3424 — the admin override this all descends from · ADR-0044 — the revise-window widening that produced the side effect
• approvals: ten service endpoints return request: fresh! — a non-null assertion that is false whenever the read-back is org-filtered out, shipping { "request": null } with HTTP 200 #12769 — the unrelated defect the same probe run surfaced

⚠️ Dedup run by this seat over the override / recall / revise-window family before filing: no existing card covers this scope question.

[os-litant]

⛔ Not dispatching yet — the ruling's precondition names an instrument that does not exist. ⭐ But one that works does, and here it is.

domain:services seat, session session_0194kbQJxUvv2yvsGRtuXpP5, 2026-08-28. Card left pm:queue, unclaimed. Reporting before acting, per the ruling's own "before ANY code change".

The ruling requires: "read the audit trail for override-recalls actually executed on returned requests. Reading zero ⇒ proceed with B."

Measured on origin/main at aef1b7e64 — that reading cannot be taken as phrased, for two independent reasons.

1. Recall does not record the override marker

via_override is written at exactly two sites in approval-service.ts — :2443 and :3251. ⛔ Neither is recall. What recall writes (:2832) is:

await this.engine.insert('sys_approval_action', {
  id: uid('aact'), request_id: requestId, organization_id: org,
  step_name: nodeId, step_index: 0, action: 'recall',
  actor_id: actorId, comment: input.comment ?? null, created_at: now,
}, { context: SYSTEM_CTX });

No via_override. ⇒ The audit trail cannot distinguish an override-recall from a submitter-recall by the marker, which is the distinction the reading is entirely about. ⭐ This is not an oversight — via_override is a decision column (#4466: the override is recorded on the DECISION, not inferred later), and recall is precisely the lever that releases a record without recording a decision. The marker's absence is the design working as intended.

2. Even where it is recorded, absence is ambiguous — the code says so

approval-service.ts:585, verbatim:

null (a row written before the column existed) stays undefined: "not recorded" is not the same claim as "not an override".

⚠️ That matters directly to the ruling's shape: the branch "reading zero ⇒ proceed with B" would fire on an unrecorded absence exactly as it fires on a true zero. ⛔ Proceeding on that would be treating NOT MEASURED as a pass — on a card whose whole purpose is to avoid removing a reach someone is using.

⭐ The substitute — sound, and derivable from data the platform already records

The distinction is recoverable without via_override, from two facts recall does write:

• override vs submitter — sys_approval_action.actor_id is recorded on the recall row, and sys_approval_request.submitter_id is on the request. A recall whose actor_id ≠ submitter_id is an override-recall: the service admits exactly two callers, so a non-submitter recall is necessarily the override branch.
• "was returned at the time" — the request's current status is recalled after the fact, so it cannot be read directly. But the action log reconstructs it: a send_back action preceding the recall action with no intervening resubmit means the request was in the revise window when it was recalled.

⇒ The reading the ruling wants is: sys_approval_action rows with action='recall' and actor_id != <the request's submitter_id>, whose most recent prior action was send_back. No reliance on via_override, no ambiguity from an unpopulated column.

⚠️ What is still not this repo's to do

That query runs against a deployment's data, not against this repository — there is no in-repo audit trail to read, and I will not approximate one with a fixture and call it a reading. ⇒ The precondition splits cleanly:

	who
Build + pin the query (and prove it separates the two actor classes on a seeded rig)	dispatchable here
Run it against real deployments and report the count	⛔ operator / deployment layer — a human action, like #11632's IdP token reissue

What I need from you

⛔ I am not choosing between these — the precondition is yours and I am not reinterpreting a ruling to make it executable:

• (i) Accept the substitute instrument above as satisfying the precondition, and say who takes the reading — then this card dispatches in two steps (build+pin here; reading by an operator).
• (ii) Rule that the reading is unobtainable in practice and pick a branch on the evidence available — noting ⭐ approvals: the approval_recall action hides the #3424 admin-override recall — the service admits it, the visible predicate never shows it #12716's landed measurement is relevant: can_override is pending-scoped at attachViewers:4848, so no ObjectStack UI has ever offered override-recall on returned. Reaching it required a direct API call. That is not zero, but it is a strong prior about how much reach is actually in use.
• (iii) Something else.

⛔ Fallback A is untouched by this either way: if the reading comes back non-zero it still applies, and still re-enters at CONTRACT_REVIEW_TIER as you ruled.

---

Generated by Claude Code

[os-steve]

Not dispatched in R6 — and the reason is narrower than the fence it inherited

domain:services PM seat, session session_016ZC5rNQj3WEet5HAmmAkMs, 2026-08-30 ~14:45Z. ⛔ Not claiming; recording why this card stayed in pm:queue while a lower-priority card was dispatched ahead of it, so the next seat does not re-derive it.

This card is p1 + security and outranks everything else dispatchable in this lane under the seat's total order. It was passed over deliberately.

The inherited fence was too strong — measured, not assumed

The predecessor's seat post recorded that this card's hard precondition "names an instrument that does not exist", and fenced it as ⛔ do-not-dispatch. A scoping fence is an assertion about the code, so it was re-measured on origin/main rather than inherited:

✅ packages/plugins/plugin-approvals/src/approval-override-audit.test.ts   exists
✅ sys_approval_action                                                     exists (decision actions are recorded)
✅ approval-service.ts:4911    can_override: row.status === 'pending'      the view flag IS already pending-only

⇒ The schema and the instrument both exist. The three-way disagreement the card describes is real and the ruled repair still has a target.

What is actually missing: operational reach, not an instrument

The ruling's hard precondition is 「落地前先从审计留痕读出历史上是否有任何 override actor 在 returned 单上执行过撤回」 — a read of historical production data. A dev in a fresh worktree has an empty database; a PM seat has no deployment access. Neither can produce that reading.

⚠️ And the ruling's fork is binary — 零 ⇒ 执行 B;非零 ⇒ 当场改判 A — while the actual available reading is a third value: unmeasurable. An empty dev database returns zero rows, which is indistinguishable at the query from a true zero. ⛔ Dispatching as-is invites a dev to read "no rows in my test fixture" as the ruling's zero and narrow a security capability on it — which is precisely what 「⛔ 不许带着非零读数硬收」 exists to prevent, arriving through the one door that clause does not cover.

What would unblock it (⛔ neither is this seat's to do)

1. A maintainer/operator runs the reading against a real deployment and records the count here — then the fork resolves as written and this dispatches immediately at CONTRACT_REVIEW_TIER.
2. Or the maintainer rules how to treat "unmeasurable" — most plausibly "no deployment has this data ⇒ treat as zero, execute B", but ⛔ this seat does not make that call: it converts an unverified premise into a security narrowing, which is the maintainer floor in its plainest form.

Nothing else about the 08-29 ruling is touched by this comment. Option B, the three-face convergence, the pin narrowing, and the untouched ADR-0044 submitter revise window all stand exactly as ruled.

⇒ Left pm:queue, unassigned, ⛔ not moved to pm:blocked — the blocker is a question to the maintainer, not another card, and this lane does not manufacture a state label for it.

---

Generated by Claude Code