[objectstack-fleet]

Requested by Elon · project thread

Fixes #32993

Clause-②: yes (widening)
Metadata-protocol: none

维护者速读

• 改了什么:审批单上「撤回」和「重新提交」两个按钮,现在也对 AI 助手开放(通过 MCP 列出、可执行),而且和审批人的四个决定动作一样,每次执行都必须先经用户确认。
• 为什么改:提交人的 AI 助手提交报销单后,用户要改明细,助手得先撤回审批,但 MCP 上没有撤回动作,只能让用户自己去控制台点一下。现在「撤回 → 改单 → 再提交」整条路助手都能走完。
• 风险与回滚:放宽(多开放两个已有动作给 AI)。谁能撤回 / 重提仍只由审批服务判定,和控制台按钮完全一样:提交人可以;待审中的单子管理员可代撤回;其他人一律被拒、单子不动。回滚即删两个 ai 块。
• 先看:packages/plugins/plugin-approvals/src/sys-approval-request.object.ts(approval_recall、approval_resubmit 的两个 ai 块和数组上方说明);packages/qa/dogfood/test/approval-decide-over-mcp.dogfood.test.ts(新增三条端到端钉子)。
• 两分钟验证:pnpm --filter @objectstack/dogfood exec vitest run --maxWorkers=2 test/approval-decide-over-mcp.dogfood.test.ts,应见 Tests 8 passed (8)。
• 需要你做的:无,席位落地。

What changes

The submitter-side branch of ruling A on #32442. PR #32886 exposed the approver's four decisions on sys_approval_request; the submitter's own levers on the same object stayed UI-only, so a submitter's agent that had to recall a request (to fix the record) handed the click back to the person.

• sys-approval-request.object.ts: approval_recall and approval_resubmit declare ai: { exposed: true, description, requiresConfirmation: true }, the shape feat(plugin-approvals): an approver's agent decides a pending approval request over MCP #32886 gave the decisions. Both are already same-origin type: 'api' actions targeting POST /api/v1/approvals/requests/{id}/recall and /resubmit, so run_action forwards them as the caller and ApprovalService stays the only gate: recall admits the submitter (and, on a pending request, the Approval routed to an empty position permanently locks the record (no admin override, no recovery) #3424 override holder) and refuses anyone else with approval_recall_not_submitter; resubmit admits the submitter alone and applies only to a returned request. No check is added in the MCP door or the action door.
• The tool descriptions are their own text (the recall dialog question stays in the top-level description, approvals: sys_approval_request.approval_reject / approval_recall declare both confirmText and params, so one decision opens two sequential dialogs #7278). Recall's tells the agent a recalled request is closed, so sending the record for approval again goes through the app's own submit action; resubmit's tells it resubmit applies only to a request sent back for revision.
• content/docs/ai/connect-mcp.mdx: the default exposure policy gains the submitter's bullet; "the submitter's own levers (remind, recall, resubmit) are not exposed" narrows to remind, request-info and comments.
• Changeset: @objectstack/plugin-approvals patch, Clause-②: yes (widening), Metadata-protocol: none (no spec key changes; two existing actions gain an existing key).

Tests

packages/plugins/plugin-approvals/src/sys-approval-request.object.test.ts (18 tests):

• The exposed set is exactly the four decisions plus recall and resubmit.
• Recall and resubmit ask for confirmation, name the submitter, carry a ≥40-char description, and target their own same-origin route.
• The recall dialog question is never armed as the AI tool description (the old "recall has no ai.description" line is replaced by the same not-the-question check approval_reject has).

packages/qa/dogfood/test/approval-decide-over-mcp.dogfood.test.ts (5 → 8, live MCP transport, real security/flows/approvals). The fixture flow gains an ADR-0044 revise window (revise → approval_revise → resubmit back edge); the existing decide pins are unchanged.

• list_actions for both the approver and the submitter lists the four decisions plus recall and resubmit, each aiExposed and requiresConfirmation.
• The submitter's recall is refused ACTION_CONFIRMATION_REQUIRED without confirm: true (request still pending, nothing recorded), then, confirmed, moves the request to recalled, recorded once as recall by the submitter.
• The approver (not the submitter) is refused recall: FORBIDDEN, carrying the approval_recall_not_submitter sentence verbatim from BUILTIN_OPERATION_MESSAGES.en; the request stays pending.
• On a request sent back over MCP, the submitter edits the record, then: unconfirmed resubmit is refused, the approver's resubmit is refused FORBIDDEN, the request stays returned with no round 2; the submitter's confirmed resubmit opens round 2 (one new pending request), recorded as revise by the approver and resubmit by the submitter.

Ablation: each ai block dropped alone (dogfood aliases plugin-approvals to source, so no rebuild is involved)

On committed head f5587158, through scripts/ablation-replace.mjs --delete, each restored with blob == HEAD and git diff HEAD empty.

• A. approval_recall's ai block deleted (anchor x1 → x0): Tests 3 failed | 5 passed (8) — the listing pin and both recall pins red.
• B. approval_resubmit's ai block deleted (anchor x1 → x0): Tests 2 failed | 6 passed (8) — the listing pin and the resubmit pin red.

Acceptance notes

• Out of scope, report only: the approver's read door ([Decision] Should an approver be able to see and decide their pending approvals over MCP? #32442 read half, blocked on spec spec: a per-object, read-only AI exposure declaration so an agent can read a declared system object through the MCP record tools (#32442 read half) #32865) is untouched. The MCP object tools still refuse sys_* objects, so an agent finds a request id through the app (as the dogfood file does through the system).
• The card's end-to-end story ("recall my claim, fix the lines, resubmit") is: recall over MCP (this PR), edit the record, then the app's own submit action, because a recalled request is closed and resubmit applies only to a request an approver sent back. The recall tool description says so, so an agent does not reach for resubmit after a recall.
• The Approval routed to an empty position permanently locks the record (no admin override, no recovery) #3424 override holder's agent can now recall a pending request it did not submit, exactly as the console's Recall button already lets that administrator do; this is the existing service admission, not a new reach.
• Remind stays unexposed (not named by the card).

Verification

Head f5587158 (origin/main 12b14462 merged before the PR opened; main had not moved). Every exit captured before any pipe.

Package tests and typecheck

• pnpm --filter @objectstack/plugin-approvals test: Test Files 118 passed (118), Tests 1624 passed (1624).
• pnpm --filter @objectstack/plugin-approvals typecheck (tsc --noEmit + scripts + check:test-typecheck): exit 0.
• pnpm --filter @objectstack/dogfood typecheck: exit 0.
• sys-approval-request.object.test.ts: Tests 18 passed (18); approval-decide-over-mcp.dogfood.test.ts: Tests 8 passed (8).
• Prerequisite: pnpm --filter '@objectstack/dogfood^...' build under the verify lock, exit 0.

Derived gates (dispatch-gates.mjs --commands, 96) and lint

• 92 of 96 exit 0 on the first pass.
• check-plugin-teardown-shape.mjs --self-test: exit 3 on the shallow clone (pinned fixture commit unreachable); after fetching 621a4876, exit 0 (48 cases).
• check:skill-examples, check:dts-closure, check:dual-build-cjs-loads: PREREQUISITE NOT MET (exit 3 / 1) — they read every package's dist/, and this tree had built only the dogfood closure. NOT MEASURED at PR open; a whole-tree turbo run build is running, and the re-run verdicts and the --ran reconciliation go into the os-dev report on MCP: a submitter's agent cannot recall or resubmit its own approval request — approval_recall / approval_resubmit are not ai.exposed, while the approver's four decide actions now are (ruling A on #32442) #32993. None of them reads a file this diff touches beyond the built output.
• pnpm lint (eslint . --no-inline-config): exit 0.

🤖 Generated with Claude Code

https://claude.ai/code/session_016WV4cwwUDMxb29FgtH4D53

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 6 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 4462b4d92b9fff58d43e6fa8e700fd0ea6d4f62d → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 74551ba69249a6bd06dc90dbb195512bd23e39eb — the merge of head f5587158283eaf01d6ce8b9a3c81e3bc45a65999 into base 4462b4d92b9fff58d43e6fa8e700fd0ea6d4f62d, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 74551ba69249a6bd06dc90dbb195512bd23e39eb && git checkout 74551ba69249a6bd06dc90dbb195512bd23e39eb
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4462b4d92b9fff58d43e6fa8e700fd0ea6d4f62d f5587158283eaf01d6ce8b9a3c81e3bc45a65999 && git checkout -B drift-repro 4462b4d92b9fff58d43e6fa8e700fd0ea6d4f62d && git merge --no-ff f5587158283eaf01d6ce8b9a3c81e3bc45a65999

node scripts/docs-audit/affected-docs.mjs --json 4462b4d92b9fff58d43e6fa8e700fd0ea6d4f62d

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[objectstack-fleet]

domain:server#8 · os-elon-musk · session_016WV4cwqTK71kjQzHae8T5J

ACCEPT · PR #33076 · head f5587158283eaf01d6ce8b9a3c81e3bc45a65999 · 2026-11-13T08:59Z · Fixes #32993

席位核对

1. Shape: draft PR to main, Fixes #32993. Files (5): packages/plugins/plugin-approvals/src/sys-approval-request.object.ts (two ai blocks and the note above the actions array) and its test, packages/qa/dogfood/test/approval-decide-over-mcp.dogfood.test.ts (extended), content/docs/ai/connect-mcp.mdx, one changeset. All are inside the claim (6847131641, re-posted 6847193267). No governed path. Tier S, review at TIER_DEFAULT: metadata declarations on existing actions, with no schema, export or accept-set change. Precedent: feat(plugin-approvals): an approver's agent decides a pending approval request over MCP #32886, the decide half, landed by its seat on the same footing.
2. Premise measured: approval_recall and approval_resubmit declared no ai block, so a submitter's agent could neither list nor run them over MCP. Each now declares ai: { exposed: true, description, requiresConfirmation: true } and still forwards to its approvals route as the caller.
3. Gate read against the code: ApprovalService.recall admits the submitter, plus the override actor on pending only, and refuses anyone else with FORBIDDEN and the approval_recall_not_submitter sentence. ApprovalService.resubmit admits the submitter alone, on returned only. The tool descriptions, the changeset and the connect-mcp.mdx bullet say exactly that. The MCP door adds no check.
4. Gates: check-runs on this head: 38 success, 15 skipped, 0 failed, 0 pending. Dev report 6848324250: dogfood 8/8, with ablation red (3 and 2); plugin-approvals 1624/1624; dispatch-gates --ran 96 run, 0 NOT MEASURED after a whole-tree build. The PR body's Verification still lists three dist-reading gates as NOT MEASURED, as of PR open. The report supersedes that line.
5. [Epic] MCP: what an agent can read and write on the HTTP MCP door, and answers that agree with the gate #32897 condition (triage 08:01Z): this PR is new surface only, two actions newly exposed to AI. It moves no 18.4.0 answer and touches no release-critical path, so it may land before the version commit.

• Landing: Clause-②: yes (widening), Metadata-protocol: none, patch. main not merged since the PR opened. K = 2 (4462b4d92b, this head's Test Core affected-set base, to origin/main), under 15. p1 under the maintainer's rule (「后续只派 p0 p1 和阻塞 p0 p1 的卡」).