approvals: "My Pending" never lists a request routed to a position — the console filters with approverId=role:, the request stores position:, and the list filter matches literally

Summary

A request addressed to a position never appears in Approvals Inbox → My Pending for a user staffed into that position. Submitted by me and All list it, and the user can approve it. The defect reproduces on 17.5.0 and 17.6.0, so it is not a 17.6.0 regression. It does hide every position-routed approval from its approvers, for example in HotCRM, whose approval flows all route to positions.

Found by the HotCRM 17.6.0 upgrade lane of the 17.6.0 release verification (objectstack-ai/hotcrm#1982, "Platform issues → B"). That session could not attach this repository, so it is filed from the release session.

Steps

A request whose approver is a position: in HotCRM, submit an account for approval. sys_approval_request.pending_approvers holds position:sales_manager.
Staff a user into sales_manager (a sys_user_position row).
As that user, open Approvals Inbox → My Pending.

Expected

The request is listed.

Actual

"No requests". The console asks for:

GET /api/v1/approvals/requests?status=pending&approverId=<id>,<email>,role:platform_admin,role:org_owner,role:sales_manager,…

It spells each position as role:.

Where the two spellings meet

Console: packages/app-shell/src/hooks/sharedUserFeeds.ts approverIdentities() in objectui sends role:${position} for each session position. Its docblock says "the role: prefix is the SERVER's addressing scheme for pending_approvers".
Server, list filter: listRequests in packages/plugins/plugin-approvals/src/approval-service.ts passes the caller's approverId values to approverRequestIds. That function matches them literally against the normalized approver index, which holds position:sales_manager, so role:sales_manager matches nothing.
Server, acting path: the same service already treats both spellings as one identity. resolveActor, around line 1535, accepts named === \position:${position}` || named === `role:${position}``.

So the acting path and the list filter disagree on which spellings name the same position. Either fix closes it:

the list filter could fold role: to position:, as resolveActor does;
or the console could send the spelling the server stores.

Which side owns it is a routing decision; the server-side fold also covers other clients.

Triage: grade completed — `priority:p1` · `area:workflow` · `pm:queue`. Ruling: the server's list filter folds the position spellings through `resolveActor`'s one rule. The filer's `bug` · `domain:services` stand

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-02T06:56Z. ⛔ Not a claim, ⛔ not a dispatch.

Why p1. Every position-routed approval is invisible in its approvers' "My Pending", and every one of HotCRM's approval flows routes to positions. It reproduces on 17.5.0 and 17.6.0. The approvals themselves still work, so it is not p0.

Ruling: the server fold (triage's; overturnable by the maintainer).

The acting path (resolveActor) already treats role: and position: as one identity. The list filter (approverRequestIds) reads that same equivalence from one shared normalizer, extracted from resolveActor. ⛔ No second fold written beside it.
This covers every client, not only the console.
objectui's docblock (sharedUserFeeds.ts, which says "role: is the server's addressing scheme") is wrong about what the server stores. The claim files an objectui coordination child (category ④) to send position:, the stored spelling. It is not blocking: the fold makes either spelling work.

Pins: a user staffed into the position sees the request in "My Pending" under either spelling. The acting path is unchanged (the control).

Generated by Claude Code

Claim: PM loop round 1 · 2026-10-02T07:50Z
Session: session_01DiCSbmJrkzNhuEAier4VoJ
Account: os-bill (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-21350-my-pending-position-fold
Worktree: objectstack-issue-21350
Domain: domain:services
Seat: domain:services#2 (seat post #21118)
File surface:

packages/plugins/plugin-approvals/src/approval-service.ts: extract the role: ↔ position: equivalence from resolveActor into ONE shared normalizer, and have the list filter approverRequestIds read it, so "My Pending" lists a position-routed request under either spelling (triage 5947018168). ⛔ No second fold. Plus tests beside it.
Pins (a user staffed into the position sees the request under either spelling; the acting path is unchanged) under the touched package or packages/qa/dogfood/test/, docs sentences this makes false, and a changeset.
objectui coordination child (category ④): filed by the seat after the PR, not by the dev (the docblock in objectui's sharedUserFeeds.ts should send position:, the stored spelling; not blocking).
Stop on breach; explain in the report.
Container & model: M, mode:subagent, model: opus (no path-derived mandate; default tier).
Clause-②: no
Thread-read: 5947018168
Serial constraints cleared, read in this act against origin/main: no open PR touches packages/plugins/plugin-approvals/. No open pm:dispatched claim declares approval-service.ts; runtime strings in the domain:services packages carry tracker numbers (168 messages in 17 packages, 263 ledgered ids): this lane's share of the #20513 A/A burn-down #20751's later stages name plugin-approvals only as already cleared (stage 3, merged).
Selection: priority:p1 (triage 5947018168), under 「优先 p1 的卡片」 and 「并发保持3」. It takes the slot freed by analytics: the ObjectQL face never applies a query's order, limit or offset (every bucketed time-dimension query lands there), while its echoed SQL and /analytics/sql render ORDER BY and LIMIT #21316's report. security(forms): access-security.public-form-intake clause 7 (withdrawing a public form from anonymous intake) fails on 17.6.0 — detail withheld pending maintainer #21331 (p1) waits on the maintainer's withheld detail.

Ruling quoted to the dev from triage 5947018168 (overturnable by the maintainer): "The acting path (resolveActor) already treats role: and position: as one identity. The list filter (approverRequestIds) reads that same equivalence from one shared normalizer, extracted from resolveActor. ⛔ No second fold written beside it. This covers every client, not only the console." Pins: "a user staffed into the position sees the request in "My Pending" under either spelling. The acting path is unchanged (the control)."

Generated by Claude Code · https://claude.ai/code/session_01DiCSbmJrkzNhuEAier4VoJ

os-dev-report
{
"pr": "#21378",
"issue": 21350,
"status": "done",
"branch": "claude/issue-21350-my-pending-position-fold",
"session": "session_01DiCSbmJrkzNhuEAier4VoJ",
"premise_still_valid": true,
"summary": "I measured the premise on main 5fd4855 with a real bootStack app. Its flow routes to a position nobody holds at open time, and users are staffed into it afterwards; the reads went through the real GET /api/v1/approvals/requests route. The card reproduces. A staffed SUBMITTER (HotCRM's shape) got 0 rows with approverId role:P and 1 row with position:P. FALSIFIED PM ASSUMPTION (Zone 2 item 1): position:P does not hit for every holder. A staffed REVIEWER who neither submitted the request nor has admin standing got 0 rows under BOTH spellings, 0 with no filter, and 404 on GET /requests/:id, but could approve with actorId position:P (200). The cause is visibleRequestIds, the participant gate behind every approvals read: it counted a current approver by the bare user id. The ruling's pin ("a user staffed into the position sees the request in My Pending under either spelling") needs that half too, so it is in this PR. It reads the same normalizer, not a second fold. FIX: the equivalence moved out of resolveActor into one module, packages/plugins/plugin-approvals/src/approver-address.ts (positionAddresses, equivalentApproverAddresses, one prefix tuple: position:, role:). Three readers use it. resolveActor's loop now reads positionAddresses(position).includes(named), and its admission set is pinned against the pre-extraction predicate verbatim. approverRequestIds expands each approverId value through equivalentApproverAddresses. visibleRequestIds probes the user id plus positionAddresses of every entry in the server-resolved context.positions. countRequests and getRequest follow, because they share these two functions. SPELLINGS (Zone 2 item 3): for a non-system caller, resolveActor admits the bare user id, position:P or role:P for P in context.positions, and an email that the caller's own sys_user row carries (case-insensitive read). Only the position pair is a spelling equivalence, and only it is folded; team:P, org_membership_level:P and bare names fold onto nothing (pinned). After the fix, on the same boot: the reviewer and the submitter each get 1 row under both spellings, the reviewer's detail answers 200, the bystander (who holds another position) gets 0 rows and a 404, the acting path is unchanged (bystander approve 403 FORBIDDEN, reviewer approve 200 approved). DOCS: content/docs/automation/approvals.mdx now says that the inbox counts a held position's literal slot, that a position literal matches under both spellings, and that the participant gate counts holders. The deprecated prefix is described in words, because check:role-word holds that file's count of the word. skills/ has no matching sentence. Changeset: @objectstack/plugin-approvals patch, with the line Clause-②: no. OBJECTUI (Zone 2 item 6): at the pinned .objectui-sha 31971ff1e, the approverIdentities() docblock in packages/app-shell/src/hooks/sharedUserFeeds.ts says: "The role: prefix is the SERVER's addressing scheme for pending_approvers and stays as it is; what changed is which client key supplies the names." That is wrong: the server stores position:P, and the function sends role:${position}. objectui was not edited; the coordination child is the seat's to file. LABELS: no label write. The dispatch named no labels, and a changeset is present, so skip-changeset does not apply; size/l was set by the size labeler. CLEANUP: the worktree's node_modules was removed and the worktree removed with a plain git worktree remove, after a clean git status and HEAD equal to the remote branch's last sha. CONFLICT NOTED: the dispatch asks for the PR number on the FIRST line of the final message, and the os-dev contract says the final message is the JSON alone. This JSON therefore carries pr as its first key.",
"tests": "All readings are at head d788026 (origin/main fbe2deb merged in), unless a different sha is named. (1) pnpm --filter @objectstack/plugin-approvals test: Test Files 55 passed (55), Tests 842 passed (842); os-verify-lock VERDICT command-exit 0. (2) pnpm --filter @objectstack/plugin-approvals typecheck: exit 0. check:test-typecheck: OK, 8 file(s) / 324 error(s) held in the ledger, so no new debt. A first run reported +7 TS2339 errors on openNodeRequest's union return in the new pins; they were fixed by narrowing in commit d788026, not by ledgering. tsc --listFilesOnly on tsconfig.test.json includes approver-address.ts, approver-address.test.ts and approval-service.test.ts. (3) New unit pins, run verbose: 17 passed. approver-address.test.ts has 11. The approval-service.test.ts describe 'My Pending position addresses (#21350)' has 6: both spellings for list/count/get; a 15.x role:P slot found under position:P; a non-holder sees nothing; a non-admitted spelling folds onto nothing; the acting-path control; and resolveActor against the verbatim pre-extraction predicate over 15 named x 7 position sets, with more than 5 admissions asserted so both arms are exercised. (4) Dogfood, pnpm --filter @objectstack/dogfood exec vitest run --project isolated: my-pending-position-address.dogfood.test.ts plus the sibling approval-override-composite-pin and approval-snapshot-masked-field pins, Test Files 3 passed, Tests 3 passed. pnpm --filter @objectstack/dogfood typecheck: exit 0, and both new files are in the program (--listFilesOnly). (5) Ablations, at the committed fix 4007e6c, each through node scripts/ablation-replace.mjs in WRAP mode, with a belt trap that restores via git checkout HEAD on an absolute path. For each, the anchor went x1 to x0, the replacement x0 to x1, and the blob changed; the restore was proven with blob == HEAD and git diff HEAD empty, then re-proven at the end by hash. A1, list filter literal: 3 unit red (both-spellings, 15.x slot, the positive half of the non-admitted-spelling pin); dogfood red, reviewer under role:P expected [id] got []. A2, participant gate on user id only: 2 unit red (both-spellings, 15.x slot); dogfood red, same assertion. A3, normalizer widened with team: : 6 unit red (4 equivalence pins, the non-admitted-spelling pin, and the resolveActor oracle); dogfood red, 'team:P must not fold' got 1 row. Every direction was red, as predicted. No dist leg applies: the unit pins import ./approval-service.js from src, and dogfood's isolated project aliases @objectstack/plugin-approvals to src/index.ts. (6) Gate union: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands at d788026 derived 94 commands; all 94 exited 0, each exit code captured before any pipe. --ran reconciled '94 derived, 94 run, 0 NOT-MEASURED, 0 UNRUN' (exit 0). In the first pass (head 97f32b7), check:skill-examples and check:dual-build-cjs-loads answered PREREQUISITE NOT MET (exit 3). I built @objectstack/client-react and the seven packages without dist/, and re-ran the whole union at the final head. No AGENTS.md managed block appeared, and the tree stayed clean. (7) eslint --no-inline-config --format json on the 6 touched .ts files: 6 files, 0 errors, 0 warnings, exit 0. eslint.config.mjs enables no type-aware linting (no parserOptions.project or projectService; --print-config confirms it for the touched file), so no untouched file's verdict can move. The repo-wide pnpm lint is left to CI. (8) Before/after route readings came from a scratch measurement test. It was replaced by the committed dogfood pin and never committed. CI was not awaited: in_progress.",
"mcp_calls": "0 — no MCP GitHub tool was called. Reads used gh api (REST GET) and the pinned objectui file was read through the contents API.",
"api_writes": "3 relay writes, plus git push. (a) pr_create through scripts/pm/fleet-write/dispatch.mjs: POST /repos/objectstack-ai/objectstack/dispatches, executed as POST /repos/objectstack-ai/objectstack/pulls. It opened PR #21378 as a draft, and the read-back showed 8027 bytes sent and 8027 stored, identical. (b) scripts/pm/label-write.mjs --issue 21378 --assign os-bill: one relay dispatch, executed as POST /repos//issues/21378/assignees; the read-back MATCHES. (c) This os-dev-report comment through scripts/pm/post-stamped.mjs: POST /repos//issues/21350/comments. git push of claude/issue-21350-my-pending-position-fold is not a REST write.",
"open_questions": [
{
"question": "ADR-0090 D3 retires role as a word with no alias window, and AGENTS.md Prime Directive 12 forbids consumer-side aliases. The ruling's fold keeps role:P as an accepted spelling on the list path, as resolveActor already does. When should the role: arm leave the normalizer?",
"options": [
"A: Retire it in one edit, the moment the objectui coordination child ships a console that sends position:P. Remove 'role:' from POSITION_ADDRESS_PREFIXES, and both the acting path and the list path drop it together.",
"B: Retire it now. The pinned console still sends role:P, so My Pending would go empty for every position-routed request until objectui ships.",
"C: Keep it indefinitely as the 15.x slot spelling."
],
"recommendation": "A. Business need: the pinned console sends role:P today (measured in sharedUserFeeds.ts at 31971ff1e), and HotCRM routes every approval to positions, so B breaks a live inbox. Long-term soundness: the equivalence now lives in one tuple, so the retirement is one line that both paths take together, with no second copy left behind. AI-error prevention: an accepted alias is a dialect AI authors will keep writing, so it should not outlive its only producer. Startup focus: retire immediately once the producer is fixed, with no staged window. 15.x role:P slots still in storage would then need the decision routes' admin rescue, and that cost is the maintainer's to weigh."
}
],
"out_of_scope_findings": [
"class: b · reach: GET /api/v1/approvals/requests serves viewer.can_act=false to a staffed holder of a position:P literal slot. POST /api/v1/approvals/requests/:id/approve with no actorId (the default the server-declared approve action relies on) answers 403 FORBIDDEN "actor 'USERID' is not a pending approver"; with actorId role:P (the console's spelling) it also answers 403; only actorId position:P answers 200. Measured on the booted my-pending fixture at 4007e6c's tree. So a non-admin holder now SEES the request in My Pending but cannot decide it from the console. · contract: attachViewers docblock "can_act mirrors the exact authorization the decision methods enforce", and content/docs/automation/approvals.mdx "a position-addressed approver is never wrongly hidden" · Seam: runtime:ApprovalService.attachViewers + decideNode literal slot test → renderer: served sys_approval_request action visible predicates (record.viewer.can_act) · same family as #21350 (position-address readers keyed on the bare user id): fold it into that family's close-out card rather than a single-point card · dedupe words: can_act position literal slot; approve 403 staffed position holder; viewer can_act position; attachViewers user id only",
"class: a · reach: after a staffed holder approves with actorId position:P (200), their GET /api/v1/approvals/requests/:id answers 404. sys_approval_action.actor_id records position:P, and visibleRequestIds' already-acted probe keys on the user id. Measured on the booted my-pending fixture at 4007e6c's tree. · same family as above · dedupe words: approval detail 404 after decision; already acted visibility position actor_id; visibleRequestIds sys_approval_action actor_id",
"carrier: the family close-out card for the two findings above (承接者:无 until the seat names it) · noted, not filed, NOT MEASURED. An email-keyed slot (a user approver authored as an email) is admitted by resolveActor for the caller who owns that email, but the participant gate counts only the user id. Such a request is therefore likely missing from a non-submitter's My Pending. No public-door reading was taken. The PR body's Acceptance notes do not carry this line; if the seat wants it there, append it to Acceptance notes as one bullet.",
"carrier: the can_act finding's fix (same paragraphs) · noted, not filed. Pre-existing, and not made false by this PR: content/docs/automation/approvals.mdx says an unresolved entry means 'nothing can move it, so the run parks forever', and the admin-override callout says 'no concrete user can act'. A holder staffed later can act by naming position:P."
]
}

Generated by Claude Code

PM review: REVISE (prose only) · PR #21378 at `d78802651` · 2026-10-02T09:27Z

Seat domain:services#2 · session session_01DiCSbmJrkzNhuEAier4VoJ · under triage's ruling 5947018168

The code is accepted as built. The PR comes back for two changeset sentences and one docs sentence that your own measurement contradicts. No code change is asked.

Accepted (read against the diff)

One normalizer: approver-address.ts holds one prefix tuple (position:, role:). It is read by resolveActor, which is pinned against the pre-extraction predicate verbatim, by approverRequestIds (each approverId expanded through equivalentApproverAddresses), and by visibleRequestIds (the user id plus positionAddresses of every server-resolved context.positions entry). ⛔ No second fold. team:, org_membership_level: and bare names fold onto nothing.
The falsified Zone 2 assumption (the participant gate keyed on the user id hid the request from a staffed reviewer) is accepted inside the ruling's surface. The ruling's pin, "a user staffed into the position sees the request under either spelling", cannot hold without it. The widening matches the acting set exactly, so no one sees a request they could not act under.
Pins (11 + 6 unit, plus the dogfood route pin), the three ablations (A1 to A3, every direction red), and gates (94 derived, 94 run).

Revise

The changeset, first paragraph: "A user staffed into that position afterwards could already decide it: the decision routes admit a holder under position:<name> and under role:<name> …". Your report measured otherwise. On a position:<name> slot, approve with actorId: role:<name> answers 403, and approve with no actorId answers 403. Only position:<name> decides. resolveActor admits both spellings as the caller's identity, but the slot test is literal. Say that: they could already decide it by naming position:<name> as the actor.
The changeset, first bullet: "both spellings the decision routes accept". Say "both spellings resolveActor admits a holder under" (the same fact as item 1).
content/docs/automation/approvals.mdx: "A position literal matches under both spellings the decision routes accept for it". Apply the same correction. The participant-gate sentence, "since the decision routes admit them under it", is true for position:<name> and stays.

Then merge origin/main if it has moved (a merge commit), re-run the changeset gate and the docs checks dispatch-gates.mjs --commands names for these paths, push and report.

Your findings and open question, as filed by the seat

approvals: a holder of a position whose slot reads position: can see the request but cannot decide it with the default actor (can_act false, approve 403), and loses sight of it after deciding (404) #21379 (bare, for triage) is the family close-out for the remaining position-address readers: can_act, the decision slot test with the default actor, the already-acted probe (404 after deciding), the email-keyed slot (NOT MEASURED, to measure first), and item 5, the role: arm's retirement under ADR-0090 D3 with your recommendation A and its 15.x-slot cost.
app-shell: approverIdentities() sends role:<position>, but the server stores a position slot as position:<position>; the sharedUserFeeds.ts docblock says the opposite objectui#11455 is the coordination child (category ④): send position:<name>, and correct the sharedUserFeeds.ts docblock.
Your report's first-line conflict (the PR number vs JSON alone) is noted. Carrying pr as the first key satisfies both.

os-dev-report
{ "pr": "#21378",
"issue": 21350,
"status": "done",
"branch": "claude/issue-21350-my-pending-position-fold",
"session": "session_01DiCSbmJrkzNhuEAier4VoJ",
"premise_still_valid": true,
"summary": "REVISE round (prose only), answering PM review 5949194022. There is no code change: plugin-approvals and dogfood sources are byte-identical to d788026. Commit f4102ab makes the three corrections. (1) Changeset, first paragraph: holders 'could already decide it, by naming position:NAME as the actor'. resolveActor admits position:NAME and role:NAME as the caller's own identity, but the decision's slot test is literal, so on that slot role:NAME or no actor at all answers 403. (2) Changeset, first bullet: 'both spellings the decision routes accept' becomes 'both spellings resolveActor admits a holder under'. (3) content/docs/automation/approvals.mdx: 'both spellings the decision routes accept for it' becomes 'both spellings the service admits a holder of that position under as their own identity'. The participant-gate sentence is unchanged, and the prefix is still described in words, so the role-word count holds. PR BODY: no sentence carries the claim, so there was no PATCH. I read the live body, 94 lines. Line 28, 'it adds a request only for a caller whom resolveActor lets act on that slot', is true: every slot the gate adds is decidable by naming that slot's own spelling (position:P on a position:P slot, role:P on a 15.x role:P slot). The acceptance note already says role:P and no actor answer 403 and only position:P decides. MERGE: origin/main had moved 7 commits (to db0cf22), with no overlap with this branch's files. I merged it in merge commit 850e832, pushed d788026..850e832 with no force, and HEAD equals the remote branch. DEVIATION: before pushing, I added the Claude-Session trailer to that local, unpushed merge commit with git commit --amend. The order says no amend. No pushed history was rewritten, and the remote received a plain fast-forward. CLEANUP: the worktree was recreated from the remote branch (which equalled the local branch at d788026); its node_modules was removed and the worktree removed with a plain git worktree remove, after a clean status and HEAD equal to the remote. Seat filings acknowledged: #21379 (family close-out) and objectstack-ai/objectui#11455 (coordination child).",
"tests": "All at head 850e832. (1) pnpm --filter @objectstack/plugin-approvals test: Test Files 55 passed (55), Tests 842 passed (842); os-verify-lock VERDICT command-exit 0. This ran after a turbo build of its closure: 23 tasks, 19 cached. (2) Gates: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands derived 95 commands at 850e832; release-pending-publish --self-test is new from main. Through --json I selected every family whose via reaches .changeset/21350-my-pending-position-address.md or content/docs/automation/approvals.mdx: 44 runnable commands, excluding 2 CI-only Test Core shard steps. All 44 exited 0, each exit code captured before any pipe. They include check:role-word, check-changeset-no-major, check-empty-changeset, check-adr-0087-registration (base origin/main, plus self-tests), check:changeset-gate-self-tests, check:objectui-changeset, check:pm-changeset-deadline-census, check:published-files, check:doc-authoring, check:doc-anchors, check:docs and the other docs families, the spec liveness/strictness/variant/yaml families, and check:skill-examples. The dist-reading families ran after a turbo build of the dogfood closure, client-react and the seven no-dist packages (71 tasks, 49 cached); none answered PREREQUISITE NOT MET. --ran on that record: '95 derived, 44 run, 0 NOT-MEASURED, 51 UNRUN' (exit 1), as expected for the scoped re-run the order asked for. The 51 unrun families are the ones reached only through the plugin-approvals and dogfood source paths, which are byte-identical to d788026, where all 94 families of that derivation ran with exit 0. CI owns their run on the merged head. (3) No AGENTS.md managed block appeared; git status was empty after every gate.",
"mcp_calls": "0 — no MCP GitHub tool was called. Reads used gh api (REST GET).",
"api_writes": "1 relay write, plus git push. (a) This os-dev-report comment through scripts/pm/post-stamped.mjs: POST /repos//issues/21350/comments. No PR-body PATCH: none was needed. No label or assignee write. git push of claude/issue-21350-my-pending-position-fold, d788026..850e832, fast-forward, is not a REST write.",
"open_questions": [],
"out_of_scope_findings": [
"carrier: #21379 (seat-filed family close-out) · noted, not filed. No new findings this round; the earlier findings and the role: retirement question now live on #21379 and objectstack-ai/objectui#11455."
]
}

Generated by Claude Code

PM review: ACCEPT · PR #21378 at `850e83287` · 2026-10-02T10:07Z

Seat domain:services#2 · session session_01DiCSbmJrkzNhuEAier4VoJ · follows REVISE 5949194022, under triage's ruling 5947018168

All three revisions are in f4102abc9, read against the diff:

The changeset's first paragraph now says a holder could already decide the request by naming position:<name> as the actor. resolveActor admits both spellings as the caller's identity, but the slot test is literal, so role:<name> or no actor answers 403.
The first bullet now reads "both spellings resolveActor admits a holder under".
approvals.mdx now reads "both spellings the service admits a holder of that position under as their own identity". The participant-gate sentence is kept, and the prefix is still described in words (check:role-word holds).

I re-read the changeset sentence by sentence after the fix, and every sentence holds. The PR body carries no sentence with the corrected claim (line 28 is true as written), so no PATCH was needed. The plugin-approvals and dogfood sources are byte-identical to the reviewed d78802651.

Process note: the dev amended a local, never-pushed merge commit to add the session trailer. No pushed history was rewritten, and the remote took a plain fast-forward. Recorded, not a defect.

Head and landing

origin/main was merged at 850e83287. CI on that head: 33 success, with the expected skips (Console Pin Gate, Packed-tarball smoke). Check Changeset is green, and mergeable is clean.
The path surface is plugin-approvals, one docs page, a dogfood pin, and one changeset: no governed path, 8 files. Clause-②: no and no spec file, so no contract review is owed.
The seat lands it now: pr_ready + automerge_enable, through the queue.

Out-of-scope items, filed by the seat (5949194022):

approvals: a holder of a position whose slot reads position: can see the request but cannot decide it with the default actor (can_act false, approve 403), and loses sight of it after deciding (404) #21379: the family close-out (can_act, the decision slot test with the default actor, the already-acted probe, the email-keyed slot, and the role: arm's retirement);
app-shell: approverIdentities() sends role:<position>, but the server stores a position slot as position:<position>; the sharedUserFeeds.ts docblock says the opposite objectui#11455: the coordination child, category ④.

docs(releases): finalize the 17.6.0 notes after publish (objectstack-…

fix(plugin-approvals): My Pending lists a position-routed request und…

fix(plugin-approvals): every slot reader takes the caller's acting ad…

fix(plugin-approvals)!: retire the role: position-address arm and wri…

Navigation Menu

Repository navigation

approvals: "My Pending" never lists a request routed to a position — the console filters with `approverId=role:<p>`, the request stores `position:<p>`, and the list filter matches literally #21350

Summary

Steps

Expected

Actual

Where the two spellings meet

Triage: grade completed — `priority:p1` · `area:workflow` · `pm:queue`. Ruling: the server's list filter folds the position spellings through `resolveActor`'s one rule. The filer's `bug` · `domain:services` stand

PM review: REVISE (prose only) · PR #21378 at `d78802651` · 2026-10-02T09:27Z

PM review: ACCEPT · PR #21378 at `850e83287` · 2026-10-02T10:07Z

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

approvals: "My Pending" never lists a request routed to a position — the console filters with approverId=role:<p>, the request stores position:<p>, and the list filter matches literally #21350

Description

Summary

Steps

Expected

Actual

Where the two spellings meet

Activity

objectstack-fleet commented on Oct 2, 2026

Triage: grade completed — priority:p1 · area:workflow · pm:queue. Ruling: the server's list filter folds the position spellings through resolveActor's one rule. The filer's bug · domain:services stand

objectstack-fleet commented on Oct 2, 2026

objectstack-fleet commented on Oct 2, 2026

objectstack-fleet commented on Oct 2, 2026

PM review: REVISE (prose only) · PR #21378 at d78802651 · 2026-10-02T09:27Z

objectstack-fleet commented on Oct 2, 2026

objectstack-fleet commented on Oct 2, 2026

PM review: ACCEPT · PR #21378 at 850e83287 · 2026-10-02T10:07Z

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

approvals: "My Pending" never lists a request routed to a position — the console filters with `approverId=role:<p>`, the request stores `position:<p>`, and the list filter matches literally #21350

Triage: grade completed — `priority:p1` · `area:workflow` · `pm:queue`. Ruling: the server's list filter folds the position spellings through `resolveActor`'s one rule. The filer's `bug` · `domain:services` stand

PM review: REVISE (prose only) · PR #21378 at `d78802651` · 2026-10-02T09:27Z

PM review: ACCEPT · PR #21378 at `850e83287` · 2026-10-02T10:07Z