fix(studio): sole workspace owner cannot reveal pending proposals owned by another principal

[mroops0111]

Summary

In a single-member workspace, the owner has no way to see a pending proposal whose owner is a different principal. The proposals list personal-filters to owner === caller unless showAll is passed, showAll is gated to effectiveRole === 'owner' on the server, but Studio only renders the "Show All" toggle when the workspace has more than one member. So a sole owner is permanently locked to their own drafts, with no UI to reveal the rest.

Where

• packages/server/src/routes/proposals.ts:186 sets viewerId = (showAll && viewer?.effectiveRole === 'owner') ? undefined : getUserId(context), so without showAll the list is filtered to the caller's own proposals.
• packages/studio/src/pages/Proposals.tsx:207-208 renders the ShowAllToggle only when effectiveRole === 'owner' && status === 'pending' && multiMember, where multiMember = (members?.items.length ?? 0) > 1. A single-member workspace never shows the toggle, so showAll can never be sent.

Repro

1. Open a single-member workspace as its owner.
2. Have a pending proposal whose owner is not the current user (e.g. authored by another principal).
3. Proposals to Pending shows "No Pending Proposals", and there is no toggle to reveal it.

Observed concretely while reviewing: a pending proposal with owner: "local-user" was invisible to a session logged in as a different user id, with no affordance to show it.

Why it matters

The common path is fine (you run a skill, the proposal is owned by you, you see it). The gap bites when a pending proposal's owner is not the sole member, for example:

• a proposal authored under a synthetic or service principal,
• a proposal inherited from a member who has since left,
• any future flow that submits drafts under an id other than the interactive caller.

In those cases the sole owner cannot review or apply the proposal at all through Studio.

Suggested direction

Show the owner the "Show All" toggle regardless of member count (drop the multiMember condition), or default an owner's pending view to all-drafts. The server-side owner gate already protects the bypass, so relaxing the client condition is safe. The multiMember guard assumes "sole member implies sole submitter", which does not hold once ownership can diverge from the interactive caller.

🤖 Generated with Claude Code

[mroops0111]

Resolved on fix/reactor-system-owner (#86, plus a follow-up making service accounts registry-data-driven via User.kind / ownerKind).

The operative case — a sole workspace owner could not review a pending proposal authored by the autonomous reactor — is fixed. The reactor now acts as a reactor service account, its proposals carry ownerKind: 'service' snapshotted at submit time, and an owner's Pending view surfaces service-owned pending (owner-only).

Deliberate scope note (diverges from the original "drop the multiMember Show All toggle" suggestion): another human's pending drafts stay private to that human by design. Only service-owned (autonomous) pending is surfaced to the owner. The framework branches on the declared ownerKind capability, not on a principal identity. Revealing a departed human member's drafts, if ever needed, is a separate concern.