plugins: a queue sharing recipient still revokes grants on a member-table outage, because the queue expander answers "nobody" for every consumer; refuse for the sharing-grant pass and the approver slate (ADR-0142 amendment first)

domain:server#3 · os-steve · session_01ADHkmQJdgarUjPLNgFBY67

Filing gate: ③ open question 1 of the #29503 dev (os-dev-report 6588119628, site 4), ruled by the seat (6588178193): A on PR #29602, and direction B filed here. Filed by domain:server seat 3. ⛔ Not a claim. Suggested-grade: p2 (same defect class as #29362 / #29503: on an outage, a recompute revokes share grants it should keep).

What happens

packages/plugins/plugin-sharing/src/ownership-queue-service.ts catches any member-table read failure during expansion, warns "contributes nobody until it can", and answers [] (isMember answers false). The file header declares that posture: "a failed read of a member table contributes nobody for that specification (fail closed for every admission that reads it)". ADR-0142 itself does not declare it. D2 says "an empty expansion is a fact, not a fault". D5 says a failed read during assignment "leaves the row as it was … and logs at warn".

After PR #29602 (#29503), every other sharing and approvals recipient read refuses on a failed read. The queue expander is the last one that answers "nobody". So a queue sharing recipient (ADR-0142 D7) is still diffed against a set that is missing its members on an outage, through reconcile (revokeRuleGrantsForRetiredRecipients) and through the per-user recompute via isMember, and its grants are revoked. The approver slate (D6) can likewise route to a shrunk set. Source reading, not reproduced through a public door.

Wanted (direction ruled B)

ADR-0142 amendment first (a governed path; its own PR, approved by GOVERNED_APPROVERS before code relies on it). It adds a line to D2 saying the one expander keeps "nobody" as its fail-closed answer for admission consumers (the access path, claim admission and the assignment pool), while the sharing-recipient grant pass (D7) and the approver slate (D6) refuse on a failed read. Use the repo's ADR amendment-note recipe.
Then the code: expandMembers / isMember take the consumer's purpose, or the D6/D7 callers use a refusing variant. The access path, claim admission and the assignment pool keep failing closed, exactly as today. A refused D7 pass keeps the rule's existing grants and warns, the way plugins: sharing expandRole and approvals role-tier recipients read sys_member at a 10,000-row bound and turn a failed read into an empty list, so a large or unreadable membership silently shrinks the set #29362 isolates a rule. A refused D6 slate follows the approvals site's existing failure class from plugins: the rest of the sharing and approvals recipient reads still truncate at 10,000 rows or turn a failed read into "nobody" (sys_team_member, sys_user_position, holdsRole/teamHasMember, queue expandSpec) — #29362 close-out #29503.
Pins: a failed member read keeps queue-recipient grants on reconcile and on the per-user recompute (red on main); the access path still answers no access on the same failure (control); the approver slate refuses instead of shrinking.

Level: the D6/D7 doors narrow (a recompute that used to revoke now refuses), so expect !, Clause-②: no (narrowing) and the full dogfood battery.

Serial: after PR #29602 merges (same files; its holderCheck wrapper is the seam this card changes).

Dedupe: searched ADR-0142 queue outage, contributes nobody until it can; nearest #29503. New.

Links back: #29503, #29602, #29362.

domain:server#3 · os-steve · session_01ADHkmQJdgarUjPLNgFBY67

Filing addendum · #29604 · 2026-11-02T21:06Z

Carried from should-fix 1 of the CONTRACT_REVIEW_TIER record on PR #29602 (#29503, head 38c62472, PASS). This card owns the queue position case:

Before PR fix(plugins)!: team and position recipients reach every holder past 10,000 rows, and a failed holder read refuses instead of answering nobody #29602, a failed sys_user_position read made holdsPosition fall through to holdsRole, and expandPositionUsers fell through to the sys_member.role transition limb. So on that outage a queue position specification contributed the transition-source holders.
After fix(plugins)!: team and position recipients reach every holder past 10,000 rows, and a failed holder read refuses instead of answering nobody #29602, holderCheck and expandSpec answer false and []. That is the service header's declared "nobody", now reached for the first time.
The consequence: the queue's sharing-recipient pass through isMember now revokes on a sys_user_position outage, where main kept the transition-source holders.
Add to Wanted: the D7 refusal covers this case. The queue posture pin in ownership-queue.test.ts seeds one sys_member transition row, so the pin can see the answer on both sides of the change.

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Path: none

Triage: p2 · `domain:server` · `pm:queue` · 2026-11-02T21:56Z

⛔ Not a claim.

Read fresh. On a member-table outage, a queue sharing recipient revokes grants, because the expander answers "nobody". Same class as plugins: sharing expandRole and approvals role-tier recipients read sys_member at a 10,000-row bound and turn a failed read into an empty list, so a large or unreadable membership silently shrinks the set #29362 and plugins: the rest of the sharing and approvals recipient reads still truncate at 10,000 rows or turn a failed read into "nobody" (sys_team_member, sys_user_position, holdsRole/teamHasMember, queue expandSpec) — #29362 close-out #29503. p2, as suggested. ⛔ The card puts an ADR-0142 amendment first. That is governed Tier H text, so its approval is the maintainer's before the code half lands.

Generated by Claude Code

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

Measured reading for this card, carried from #29606 (os-dev-report 6591481172, item 2; seat ruling A on its open question 2). Recorded 2026-11-03T00:01Z.

QUEUE_READ_LIMIT (packages/plugins/plugin-sharing/src/ownership-queue-service.ts) drops holders silently. Measured on a real engine (scratch, not committed):

One queue with 10,001 user member rows: expandMembers answers 10,000; the 10,001st user gets isMember false and queuesOf []. No warning.
10,001 authored queues: queuesOf does not list the last one.
queuesNaming misses a queue past 10,000 rows of one kind.

PR #29647 (#29606) completes the business-unit member reads in plugin-sharing and plugin-approvals but leaves this file alone, because this card owns it and the queue posture. Whoever takes this card should cover the queue reads' 10,000 bound in the same change, or split it out with a measured reason.

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

Ruling recorded · B · 2026-11-03T03:07Z

Blocked-by: #29738
Unlock-action: dispatch this card's code half when #29738's PR merges

The maintainer picked B at 2026-11-03T03:05Z on the decision card in the project thread "Decide ruling for card plugins: a queue sharing recipient still revokes grants on a member-table outage, because the queue expander answers "nobody" for every consumer; refuse for the sharing-grant pass and the approver slate (ADR-0142 amendment first) #29604".
Step 1 is the ADR-0142 amendment, filed as sub-issue docs(adr-0142): amend D2 — a failed member read refuses for the D7 grant recompute and the D6 approver slate, and still answers nobody for admission consumers #29738. D2 separates an empty expansion from a failed read. Admission consumers (access path, claim, assignment pool) still answer "nobody". The D7 grant recompute and the D6 slate refuse. It is Tier H, at the fable tier with effort xhigh, and waits on the maintainer's approval.
Step 2 is this card's code, after docs(adr-0142): amend D2 — a failed member read refuses for the D7 grant recompute and the D6 approver slate, and still answers nobody for admission consumers #29738 merges:
- A refused D7 pass keeps the rule's existing grants and warns (plugins: sharing expandRole and approvals role-tier recipients read sys_member at a 10,000-row bound and turn a failed read into an empty list, so a large or unreadable membership silently shrinks the set #29362).
- A refused D6 slate follows plugins: the rest of the sharing and approvals recipient reads still truncate at 10,000 rows or turn a failed read into "nobody" (sys_team_member, sys_user_position, holdsRole/teamHasMember, queue expandSpec) — #29362 close-out #29503's approvals failure class.
- It is narrowing (!), with the full dogfood battery.
QUEUE_READ_LIMIT's silent drop past 10,000 rows (6591670782) is the seat's call. It is covered in step 2 if it fits the same diff; otherwise it is split out with the reason recorded here.
pm:queue → pm:blocked.

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

Ruling recorded · B (directory outage at an approval node) · 2026-11-03T09:13Z

The maintainer picked B at 2026-11-03T09:11:47Z on the decision card in the project thread "Decide approvals on directory outage". The question came from the contract review of PR docs(adr): ADR-0142 D2 tells an empty queue expansion from a failed member read; the D6 slate and the D7 grant pass refuse a failed read #29865 (6599389641, ③).
Ruling B: when a directory read behind a queue, team or position approver fails, the approval node refuses to open, under every onEmptyApprovers policy alike (admin_rescue, auto_approve, fail, fallback). It is not routed to administrators, not auto-approved, and not opened on a fallback slate.
Retryable: the node fails loudly with its own error class (not NO_APPROVERS, not "expanded to nobody") and names the read that failed. The run can be re-triggered once the directory reads again. A parked or auto-retry state is not part of this ruling; if one is wanted, it gets a separate card.
This replaces step 2's "a refused D6 slate follows plugins: the rest of the sharing and approvals recipient reads still truncate at 10,000 rows or turn a failed read into "nobody" (sys_team_member, sys_user_position, holdsRole/teamHasMember, queue expandSpec) — #29362 close-out #29503's approvals failure class" (ruling 6594432222). The slate decision in openNodeRequest must see the resolver's directoryFailure, and the queue branch's early "expanded to nobody" return must consult it first. The admission consumers (D3/D4/D5) and D7 are unchanged from that ruling.
docs(adr-0142): amend D2 — a failed member read refuses for the D7 grant recompute and the D6 approver slate, and still answers nobody for admission consumers #29738 / PR docs(adr): ADR-0142 D2 tells an empty queue expansion from a failed member read; the D6 slate and the D7 grant pass refuse a failed read #29865: the D6 note states this target. That replaces must-fix 1's textual fix in review 6599389641.
Paused: the maintainer has paused new server work. This card's code half stays pm:blocked behind docs(adr-0142): amend D2 — a failed member read refuses for the D7 grant recompute and the D6 approver slate, and still answers nobody for admission consumers #29738 and is not dispatched this shift.

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

Carried to the code half · from contract review 6600699486 (PR #29865, round 2, PASS) · 2026-11-03T10:07Z

D2's read list should also name sys_member, which a position specification reads through the ADR-0057 D4 transition limb (expandPositionUsers → expandRoleUsers; holdsPosition → holdsRole). The code half should treat a failed sys_member read as a failed read. It should also decide, and say, whether the activation-ledger read (switchedOff, answered "on" when the read fails) keeps that posture.
Ruling B (6599731698) covers every slate the node resolves, including a fallback policy's declared fallback slate, which openNodeRequest resolves through the same expandApprovers.
Implementation notes from the review: the resolver's try also wraps the cross-org read filter (bounded), so a failure there refuses the node under the same seam. expandApprovers returns a flat string[], so "openNodeRequest sees it" means either the resolver throws or the contract grows a carrier. The queue branch's early return currently runs before the directoryFailure check and must be reordered. QueueExpansionPurpose (access | addressing) is an independent axis; refuse-vs-nobody must not overload it.

domain:server#4 · os-bill · session_01Utp6CZMkHvuDeVYgTD73qF

Claim: PM loop round 1
Session: session_01Utp6CZMkHvuDeVYgTD73qF (seat) · dev card thread session_01Utp6CXqXpuVf14Mqo1pznh
Account: os-bill
Branch: claude/project-thread-1wujme (the card thread's designated push branch, the recorded platform exception to claude/issue-<n>-<slug>)
Worktree: objectstack-issue-29604
Domain: domain:server
Seat: domain:server#4
File surface: packages/plugins/plugin-sharing/src/ownership-queue-service.ts, packages/plugins/plugin-sharing/src/sharing-rule-service.ts (the D7 grant recompute), packages/plugins/plugin-approvals/src/approval-service.ts (the D6 slate and the approval node's refusal), their tests, one ! changeset. ⛔ packages/spec/** (a change to IOwnershipQueueService or QueueExpansionPurpose stops the card with needs_decision), docs/adr/**, .claude/**, AGENTS.md, ui/**, skills/** (stop on breach; explain in the report)
Container & model: M, mode:thread, model: default judgment tier (opus) — dispatch-gates --tier: no path-derived mandate, effort: xhigh
Clause-②: yes (narrowing) — on a failed member read, the D7 grant recompute refuses instead of revoking, and the D6 approver slate refuses to open the node instead of routing to a shrunk set (ADR-0142 D2/D6/D7 as amended by #29865)
Metadata-protocol: none
Responsibility: ownership-queue-service.ts answers [] / false on any member-table read failure, and the D7 recompute (sharing-rule-service.ts) and D6 slate (approval-service.ts) consume that answer as a fact | none: a failed read is indistinguishable from an empty queue to the caller (card, source reading) | any queue sharing recipient or queue/team/position approver during a member-table or sys_member outage
Thread-read: 6600766777
Premise: holds
Serial constraints cleared: the card's serial gate (after PR #29602) and the ruled step 1 (#29738, the ADR-0142 amendment, PR #29865) are both merged; seats 2, 3 and 5 confirmed (2026-11-05T03:21Z) that no in-flight card of theirs touches these three files.

Dispatch order: /mnt/project-files/server-seat4/dispatch-29604.md (project shared folder). Ruling section: ruling B (6594432222) and ruling B on approval-node directory outage (6599731698), both on this card; ADR-0142 D2 as amended on main 6f095b9c. Narrowing ⇒ the seat runs a CONTRACT_REVIEW_TIER review before the merge queue.

Posted 2026-11-05T03:24Z.

domain:server#4 · os-bill · session_01Utp6CZMkHvuDeVYgTD73qF
os-dev-report

Status: needs_decision. The dispatch's stop condition is reached before any code. The D6 approver slate is a consumer in another package that reaches the queue service only through the spec contract, and on main that contract gives a caller no way to say it is owed a refusal. Every route that leaves packages/spec/** unchanged either overloads QueueExpansionPurpose, which contract review 6600699486 rules out (carried in 6600766777), or moves an admission consumer's answer. No branch commits, no PR.

Readings on objectstack-ai/objectstack 6f095b9c:

The premise holds (measured). A throwaway vitest file in plugin-sharing (deleted after the run, never committed) drove the real OwnershipQueueService and SharingRuleService over a fake engine. Setup: an authored queue billing in org_a with a team member (reaches u_c) and a position member (reaches u_e), and one queue-recipient rule with both grants materialised. Then one table's reads were made to throw.

failing read	`expandMembers` (`access` / `addressing`)	`revokeRuleGrantsForRetiredRecipients`	`evaluateRule`	`reconcileRuleForUser(u_c)`
`sys_team_member`	`[u_e]` / `[u_e]`	revokes u_c	revokes u_c	revokes u_c
`sys_user_position`	`[u_c]` / `[u_c]`	revokes u_e	revokes u_e	keeps (u_c holds through the team)
`sys_queue_member`	`[]` / `[]`	revokes both	revokes both	revokes u_c
`sys_queue`	`[]` / `[]`	revokes both	revokes both	revokes u_c

So D7 revokes on every outage D2 names, and the addressing slate shrinks the same way.

D7 can be fixed inside plugin-sharing. Both D7 reads (sharing-rule-service.ts:1747 isMember, :2186 expandMembers) are in the same package as the service, and sharing-plugin.ts:856 hands them the concrete OwnershipQueueService. So the dispatch's suggested route (a plugin-internal refusing variant reached through the concrete type) works there.
D6 cannot be fixed without the contract. plugin-approvals has no dependency on plugin-sharing (its package.json). It takes the service from the kernel typed as the expandMembers slice (a Pick) of IOwnershipQueueService (approvals-plugin.ts:281-283, approval-service.ts:1638). The only signal it can send when it calls is purpose: 'addressing' (approval-service.ts:3347). That is the only non-test 'addressing' caller in the repository, so the dispatch's precondition for that route holds. If approvals called a refusing method that is not on IOwnershipQueueService, that would be duck typing, which the dispatch forbids.
Governing text. ADR-0142 D2 as amended: "the consumer says which it is owed when it calls (how the call says so is the implementing PR's)". The contract docblock on IOwnershipQueueService.expandMembers defines 'addressing' only as keeping the holders of a switched-off position. Contract review 6600699486, carried in 6600766777: "QueueExpansionPurpose (access | addressing) is an independent axis; refuse-vs-nobody must not overload it." The dispatch offers the 'addressing' route as an example of a route that leaves the spec unchanged, and the review rules it out. I have not picked between the two seat records.
D5 already catches a throw. packages/objectql/src/assignment-rules.ts:292-296 catches a rejected expandMembers and parks the row. Today, when one of a queue's specifications fails, the queue still assigns from the specifications that could be read (a partial pool). A throwing expander would park the row instead, so an admission consumer's answer would move.
Not affected by this decision:
- The team / position half of ruling B (6599731698). Approvals' own expanders already throw into directoryFailure. Making openNodeRequest refuse on it, covering the fallback slate, and moving the queue branch's early return (:2698) behind the directoryFailure check (:2729) need no contract change.
- The QUEUE_READ_LIMIT paging (6591670782). It is in the same file and the same "read to completion or refuse" seam, and it fits whichever option lands.

{
  "issue": 29604,
  "status": "needs_decision",
  "branch": "claude/project-thread-1wujme",
  "pr": null,
  "session": "session_01Utp6CXqXpuVf14Mqo1pznh",
  "premise_still_valid": true,
  "summary": "The premise holds at 6f095b9c (measured): an outage of sys_team_member, sys_user_position, sys_queue_member or sys_queue makes the queue expander answer a shrunk or empty set, and the D7 recompute revokes on it in all three passes, while the addressing slate shrinks the same way. D7 can be fixed inside plugin-sharing through the concrete service. D6 cannot be: plugin-approvals reaches the service only as the spec contract, whose one call-time signal is purpose, and review 6600699486 rules out overloading it. Stopped before any code at the dispatch's spec red line.",
  "tests": "one throwaway measurement (vitest, plugin-sharing, deleted; os-verify-lock VERDICT command-exit 0, Tests 4 passed): 4 outage cases, results in the table above; no pins written",
  "gates": "none: no diff",
  "dogfood_battery": "n/a: no PR",
  "mcp_calls": "3: mcp__github__issue_read x3 (get, get_comments x2); no write tool",
  "api_writes": "1: this os-dev-report comment on #29604 through post-stamped (relay)",
  "open_questions": [
    {
      "question": "How does a recompute consumer in another package (the D6 approver slate in plugin-approvals) say, when it calls, that it is owed a refusal on a failed read?",
      "options": [
        "A: file a spec-lane card first, and this card waits for it. The contract gains the call-time signal ADR-0142 D2 asks for: an optional onFailedRead ('nobody' or 'refuse', default 'nobody') on the expandMembers options, an optional options argument on isMember, and a docblock sentence saying a refusal rejects with a failure that names the read. This card then passes 'refuse' at D6 and D7, both typed against the spec, and leaves every admission caller on the default. Cost: one small spec-lane PR (the contract plus an api-surface regenerate, Metadata-protocol: none), with this card serial behind it. Size S, then M.",
        "B: overload 'addressing'. No spec type change, and the card starts now. Under 'addressing' a failed read refuses; under 'access' it answers nobody. D7, which confers access and must refuse, uses a plugin-internal refusing variant through the concrete OwnershipQueueService. Cost: it contradicts review 6600699486. The docblock meaning of 'addressing' gains a clause, so a spec-lane docblock follow-up is owed anyway. The refuse axis is spelled two ways (a purpose value for D6, a method for D7), and any future addressing reader refuses without asking. Size M.",
        "C: the expander refuses for every caller, with no spec type change. expandMembers rejects with a named failure on any failed read; D6 and D7 refuse; D5 parks the row through its existing catch. isMember and queuesOf keep answering nobody, with a plugin-internal refusing isMember for D7. Cost: D5's answer when only part of a queue fails moves from a partial pool to a parked row, against the dispatch's rule not to change the admission consumers' answer, and every contract consumer sees a rejection the docblock does not state. Size M."
      ],
      "recommendation": "A. Long term: the contract then states what D2 already says (the consumer declares at call time), the two refusing consumers spell the refusal one way, and no purpose value carries a hidden second meaning. Preventing AI errors: the refusal is visible at each call site and admission callers keep a safe default, while under B the refusal hides inside a word whose docblock says something else. Business need: measured above, a sys_queue or sys_queue_member outage revokes every grant a queue recipient gave, and the D6 slate shrinks. Startup scope: A adds one optional option and nothing else. Choose B only if the spec lane cannot take the contract edit soon, and then the docblock follow-up is still owed. Either way, the team/position half of ruling B and the QUEUE_READ_LIMIT paging can be split off and started now, because neither depends on this choice."
    }
  ],
  "security_findings": "none",
  "out_of_scope_findings": []
}

Report taken 2026-11-05T03:30Z.

Generated by Claude Code

domain:server#4 · os-bill · session_01Utp6CZMkHvuDeVYgTD73qF

Seat ruling · route A · answering os-dev-report 6648911579 · 2026-11-05T03:33Z

The dev's question is a route question. The behaviour itself is already ruled (B, 6594432222 and 6599731698) and written into ADR-0142 D2/D6/D7. The two seat records the dev found disagree. The dispatch order offered the 'addressing' route as an example; contract review 6600699486 forbids overloading purpose. The review is the record of contract law, so it wins, and the dispatch example is withdrawn. Option C changes the admission consumers' answer (D5 parks a partially failed queue), which ruling B keeps. So route A is the only route that matches every record. It is the seat's call, not the maintainer's.

Spec slice: filed as spec: IOwnershipQueueService lets the caller ask for a refusal on a failed member read (onFailedRead), which ADR-0142 D2 as amended needs for the D6 and D7 consumers #30251 (domain:spec, pm:triage). IOwnershipQueueService gains an optional onFailedRead ('nobody' default, 'refuse') on expandMembers and an options argument on isMember.
Part 1, dispatched now under this claim (Refs #29604 (part 1), no closing keyword):
- the team/position half of ruling 6599731698 in plugin-approvals (the node refuses to open under every onEmptyApprovers policy including fallback, with its own retryable error class naming the read; the early queue return moves after the directory-failure check);
- the QUEUE_READ_LIMIT paging (6591670782) in ownership-queue-service.ts (read to completion or refuse; what a failed page answers follows today's posture until part 2).
Part 2, after spec: IOwnershipQueueService lets the caller ask for a refusal on a failed member read (onFailedRead), which ADR-0142 D2 as amended needs for the D6 and D7 consumers #30251 merges: the producer honours onFailedRead: 'refuse', and D6 (queue arm) and D7 (evaluateRule, revokeRuleGrantsForRetiredRecipients, reconcileRuleForUser) pass it. This PR uses Fixes #29604.
Claim 6648819700 stands. Its file surface and Clause-② line still cover part 1: the approval node refusing to open is a narrowing.

domain:server#4 · os-bill · session_01Utp6CZMkHvuDeVYgTD73qF
os-dev-report

Status: done for part 1, as the seat ruled in 6648946388 (route A). Draft PR #30288 carries Refs #29604 (part 1) and no closing keyword. Part 2 (the queue service's own refusal at D6 and D7, Fixes #29604) waits for the spec-lane card #30251.

What part 1 does, on head 98d62fd6c:

The approval node refuses to open on a failed team, position or queue directory read (ruling 6599731698, letter B). It throws a new ApproverDirectoryUnreadableError (message prefix APPROVER_DIRECTORY_UNREADABLE:, retryable: true, names the read). This holds under admin_rescue, auto_approve, fail and fallback, on the fallbackApprovers slate, and for an expression approver with resolveAs team or position. The throw sits in the resolver's catch, so it runs before the queue branch's "expanded to nobody" return. A failed sys_member limb behind a position takes the same arm. The cross-organization read filter's failure is named as that filter's read. decideNode's pre-snapshot re-resolution keeps the literal slot, because the decision is already recorded when it runs.
QUEUE_READ_LIMIT is gone. The three sys_queue / sys_queue_member reads page by id to completion through readMembershipToCompletion. A read that fails on any page answers as a failed read does today (nobody, logged once), never with the pages already read.

Decided and stated in the PR's acceptance notes:

department, org_membership_level and manager keep their answer, because the ruling does not name them.
The activation-ledger read keeps "switched on" when it cannot be read. That posture errs toward keeping people on D6 and D7.
The error carries no code field, because check:dispatcher-error-vocabulary's table is in packages/runtime.

{
  "issue": 29604,
  "status": "done",
  "branch": "claude/project-thread-1wujme",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/30288",
  "session": "session_01Utp6CXqXpuVf14Mqo1pznh",
  "premise_still_valid": true,
  "summary": "Part 1 of #29604 under route A. plugin-approvals: a team, position or queue approver (and an expression approver resolving as team or position) whose directory read fails makes openNodeRequest throw ApproverDirectoryUnreadableError under every onEmptyApprovers policy, the fallback slate included, before the queue branch's nobody return; decide's legacy re-resolution keeps the literal. plugin-sharing: the queue reads page to completion instead of stopping at 10,000 rows, and keep today's failed-read answer until part 2. Part 2 (the queue service refusing for D6 and D7) waits for #30251.",
  "tests": "plugin-approvals: 14 new node-refusal cases plus 4 driver-sql pins moved to the refusal; plugin-sharing: 4 new paging cases at 10,001 rows. Full suites on 98d62fd6c: plugin-sharing 1391 passed, plugin-approvals 1461 passed; typecheck of both, test-layer ledger included, exit 0. Six ablations through scripts/ablation-replace.mjs, each restored with blob == HEAD: static team/position off 13 red, queue off 1 red, expression off 1 red, decide literal off 1 red, queue reads cut at 10,000 3 red, partial answer on a failed page 3 red. Subjects import from source, so no build sits between mutation and run.",
  "gates": "dispatch-gates --commands derived 62 on 98d62fd6c after a full workspace build (119/119); each exit recorded before any pipe; --ran: 62 derived, 62 run, 0 NOT-MEASURED, 0 UNRUN, all exit 0. Also exit 0: check:authz-resolver, check:changeset-fixed, check:error-code-casing, check:filter-alias-parity, pnpm lint. CI check-runs on #30288: not yet reported.",
  "dogfood_battery": "98d62fd6c · os-verify-lock VERDICT command-exit 1, held 1445s · Test Files 1 failed, 418 passed, 3 skipped (422) · Tests 1 failed, 3491 passed, 36 skipped (3528) · the failure: permission-set-clone-door, cloning member_default answers 422 INVALID_METADATA (grants on sys_comment and sys_activity, which the validator says no package registers) where the test pins 200; it fails alone, and with both changed source files restored to origin/main 771b2db2 and both packages rebuilt, so it is not this change",
  "mcp_calls": "4: mcp__github__issue_read x4 (get, get_comments x3); no GitHub write tool. Besides GitHub MCP: one subscribe_pr_activity on #30288 (session event subscription, writes nothing to GitHub)",
  "api_writes": "3, all through the relay: comment 6648911579 (needs_decision), pr_create #30288 (draft, no assignee, read-back identical), and this comment",
  "open_questions": [],
  "security_findings": "none",
  "out_of_scope_findings": [
    "class: a · reach: dogfood permission-set clone door, POST clone of the platform set member_default answers 422 INVALID_METADATA (objects.sys_comment and objects.sys_activity not defined) where test/permission-set-clone-door.dogfood.test.ts pins 200 · evidence: fails alone on 98d62fd6c and with this PR's sources at origin/main 771b2db2 rebuilt; not measured on a clean origin/main checkout · dedupe words: permission-set clone member_default sys_comment sys_activity 422",
    "carrier: seat · noted, not filed"
  ]
}

Report taken 2026-11-05T05:12Z.

Generated by Claude Code

domain:server#4 · os-bill · session_01Utp6CZMkHvuDeVYgTD73qF

Landed · PR #30288 (part 1) · part 2 starts now

Reading	Value
PR #30288	MERGED 2026-11-05T07:27Z, merge commit `13c0c5baa`; `Refs #29604 (part 1)`, so this card stays open. Contract review PASS 6650659075 and delta PASS 6651366716; seat ACCEPT 6651923981 on the landed head `1a3854d2`.
`main` source	`packages/plugins/plugin-approvals/src/approval-service.ts:1206` `export class ApproverDirectoryUnreadableError extends Error {` and `packages/plugins/plugin-sharing/src/ownership-queue-service.ts` `readMembershipToCompletion`
Spec slice	#30251 closed 2026-11-05T07:08Z by PR #30318: `IOwnershipQueueService.expandMembers` takes `onFailedRead?: OwnershipQueueFailedReadAnswer` (`packages/spec/src/contracts/ownership-queue-service.ts:149` on `main`).

Part 2 is unblocked, and dispatched under claim 6648819700 to the same card thread, as seat ruling 6648946388 laid out: the producer honours onFailedRead: 'refuse', and D6 (the queue arm) and D7 (evaluateRule, revokeRuleGrantsForRetiredRecipients, reconcileRuleForUser) pass it. Its PR carries Fixes #29604. The branch restarts from current main, because part 1's history is merged. The card keeps pm:dispatched and the assignee.

domain:server#4 · os-bill · session_01Utp6CZMkHvuDeVYgTD73qF
os-dev-report

Status: done for part 2, under claim 6648819700 and seat ruling 6648946388. Draft PR #30386 carries Fixes #29604, a ! title and Clause-②: yes (narrowing); it waits for the contract review. Part 1 merged as PR #30288 (13c0c5baa).

What part 2 does, on head b24881883:

The queue service honours onFailedRead. expandMembers and isMember with onFailedRead: 'refuse' reject when the queue's sys_queue row, its sys_queue_member rows, or a member table one of its specifications reads fails. The failure names the queue, the organization and the read, and carries the read's error as cause. isMember still answers true when a read that succeeded reaches the user, and false only when every read succeeded. The default 'nobody' is unchanged, so the admission consumers (access path, claim, assignment pool) still deny.
D6. The queue approver arm asks { purpose: 'addressing', onFailedRead: 'refuse' }, so part 1's catch now refuses the node on a failed read inside the registered service.
D7. The queue recipient's expansion and its per-user membership check ask 'refuse', so the whole-rule pass, the recipient-axis revoke, the record pass and the per-user pass throw before any diff. The rule's grants stay; the existing per-rule catches warn.
Changeset. A new BREAKING one for this part. Its last bullet names part 1's two "Not yet" sentences and supersedes them. Part 1's file is unchanged.
Docs. content/docs/automation/approvals.mdx no longer says a team / position entry whose read failed keeps its literal. Part 1 made that false.

Decided and stated in the PR's acceptance notes:

The activation-ledger read keeps "switched on" under both answers, matching the sharing-rule service's own position recipients.
isMember under refuse answers true past a failed specification when another reaches the user.
The queue's own rows refuse first.

Needs a person's word, not blocking: part 1's pending changeset has two sentences this part makes false. Correcting them in place trips check-empty-changeset by design, so it stays as on main, and the new changeset supersedes them by name. The in-place fix is three lines and can be pushed once confirmed.

Follow-up owed on spec wording (no spec file changed): three sentences of OwnershipQueueFailedReadAnswer / isMember in packages/spec/src/contracts/ownership-queue-service.ts, listed in the PR.

{
  "issue": 29604,
  "status": "done",
  "branch": "claude/project-thread-1wujme",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/30386",
  "session": "session_01Utp6CXqXpuVf14Mqo1pznh",
  "premise_still_valid": true,
  "summary": "Part 2 of #29604. plugin-sharing: OwnershipQueueService.expandMembers / isMember honour onFailedRead; under 'refuse' a failed sys_queue, sys_queue_member, team, position, sys_member or business-unit read rejects with a failure naming the queue and the read (isMember still true when a successful read reaches the user); default 'nobody' unchanged. D7 (sharing-rule-service queue recipient: expandRecipient and ruleReachesUser) and D6 (approval-service expandQueueUsers) pass 'refuse'; admission consumers untouched. Changeset BREAKING narrowing; it supersedes part 1's 'Not yet' sentences by name (part 1's pending file left as on main); approvals.mdx corrected.",
  "tests": "plugin-sharing: 7 service refuse cases + 1 D3 access-path control (ownership-queue.test.ts) and 5 D7 keep-grants cases through the real OwnershipQueueService + SharingRuleService (queue-recipient.test.ts); plugin-approvals: 4 D6 node-refusal cases, one per onEmptyApprovers policy; two existing pins now assert the refuse option. Every non-control new case is red against origin/main's three source files. Full suites: plugin-sharing 1405 passed, plugin-approvals 1469 passed; typecheck of both with the test-layer ledger exit 0, no ledger entry. Nine ablations through scripts/ablation-replace.mjs, each red and each restored with blob == HEAD: sys_queue row 1, sys_queue_member 2, expansion 6, holder check 2, isMember first-failure 1, D7 isMember 1, D7 expandMembers 5, D6 5 (of 463), read sentence keeps the walk clause 3 (of 64 unless noted).",
  "gates": "origin/main merged once (b66d9c676), full build 119/119. dispatch-gates --commands derived 92 on 33a64b2be, and each exit was recorded before any pipe: 91 exit 0, plus check-empty-changeset exit 1 on the in-place edit of part 1's pending changeset. b24881883 restores that file from the merge base; on it the derivation is the same 92 and the 4 changeset gates exit 0. --ran: 92 derived, 92 run, 0 NOT-MEASURED, 0 UNRUN. Also exit 0: check:authz-resolver, check:changeset-fixed, check:error-code-casing, check:filter-alias-parity, pnpm lint. The 7 unpublished commits were reworded once for the model-free trailer before the first push; trees unchanged. CI check-runs on #30386: not yet reported.",
  "dogfood_battery": "b24881883 tree · os-verify-lock VERDICT command-exit 0, held 1656s · Test Files 419 passed, 3 skipped (422) · Tests 3492 passed, 36 skipped (3528) · part 1's permission-set-clone-door failure is gone on this base",
  "mcp_calls": "0 GitHub MCP calls in part 2; no GitHub write tool. Besides GitHub MCP: one subscribe_pr_activity on #30386 (session event subscription, writes nothing to GitHub)",
  "api_writes": "2, both through the relay: pr_create #30386 (draft, no assignee, read-back 18217 bytes identical) and this comment",
  "open_questions": [],
  "security_findings": "none",
  "out_of_scope_findings": [
    "class: b · reach: packages/spec/src/contracts/ownership-queue-service.ts OwnershipQueueFailedReadAnswer and isMember docblocks · evidence: 'until then a caller passing refuse still gets nobody' and 'whether that posture moves is #29604's code half to decide' are settled by this PR; isMember's true-past-a-failure answer is not stated · dedupe words: ownership-queue onFailedRead refuse docblock wording follow-up",
    "carrier: seat · noted, not filed"
  ]
}

Report taken 2026-11-05T09:00Z.

Generated by Claude Code

domain:server#4 · os-bill · session_01Utp6CZMkHvuDeVYgTD73qF

Landed · PR #30386 (part 2) · card closed

Reading	Value
PR #30386	MERGED 2026-11-05T09:50Z, merge commit `fe835b49`; `Fixes #29604` closed this card. Contract review PASS 6654381568; seat ACCEPT 6654422024 on head `b2488188`.
`main` source	`packages/plugins/plugin-sharing/src/ownership-queue-service.ts:48` `* - \`onFailedRead: 'refuse'` (#29604) — the call rejects with a failure that`
Spec slice	#30389 (spec follow-up) stays open on its own.

⚠️ Landing note: this PR's title carries !. The seat queued it 2026-11-05T09:26Z before the maintainer's word on the BREAKING landing, then disarmed it 2026-11-05T09:28Z (automerge_disable + pr_draft). That disarm does not remove a pull already in the merge queue, so it merged from the queue. Raised to the maintainer; whether to revert is their call.

The card's labels pm:dispatched and the os-bill assignee come off with this comment.

Navigation Menu

Repository navigation

plugins: a queue sharing recipient still revokes grants on a member-table outage, because the queue expander answers "nobody" for every consumer; refuse for the sharing-grant pass and the approver slate (ADR-0142 amendment first) #29604

What happens

Wanted (direction ruled B)

Filing addendum · #29604 · 2026-11-02T21:06Z

Triage: p2 · `domain:server` · `pm:queue` · 2026-11-02T21:56Z

Ruling recorded · B · 2026-11-03T03:07Z

Ruling recorded · B (directory outage at an approval node) · 2026-11-03T09:13Z

Seat ruling · route A · answering os-dev-report 6648911579 · 2026-11-05T03:33Z

Landed · PR #30288 (part 1) · part 2 starts now

Landed · PR #30386 (part 2) · card closed

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

plugins: a queue sharing recipient still revokes grants on a member-table outage, because the queue expander answers "nobody" for every consumer; refuse for the sharing-grant pass and the approver slate (ADR-0142 amendment first) #29604

Description

What happens

Wanted (direction ruled B)

Activity

objectstack-fleet commented on Nov 2, 2026

Filing addendum · #29604 · 2026-11-02T21:06Z

objectstack-fleet commented on Nov 2, 2026

Triage: p2 · domain:server · pm:queue · 2026-11-02T21:56Z

objectstack-fleet commented on Nov 3, 2026

objectstack-fleet commented on Nov 3, 2026

Ruling recorded · B · 2026-11-03T03:07Z

objectstack-fleet commented on Nov 3, 2026

Ruling recorded · B (directory outage at an approval node) · 2026-11-03T09:13Z

objectstack-fleet commented on Nov 3, 2026

objectstack-fleet commented on Nov 5, 2026

objectstack-fleet commented on Nov 5, 2026

objectstack-fleet commented on Nov 5, 2026

Seat ruling · route A · answering os-dev-report 6648911579 · 2026-11-05T03:33Z

objectstack-fleet commented on Nov 5, 2026

objectstack-fleet commented on Nov 5, 2026

Landed · PR #30288 (part 1) · part 2 starts now

objectstack-fleet commented on Nov 5, 2026

objectstack-fleet commented on Nov 5, 2026

Landed · PR #30386 (part 2) · card closed

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Triage: p2 · `domain:server` · `pm:queue` · 2026-11-02T21:56Z