* fix(mcp): a refused call names its cause on both transports (BUG-3864)
A 403 from one of the shared gates now carries details.reason (role,
token_scope, no_access, workspace_not_authorized), with code and message
unchanged. MCP builds one permission_denied envelope from it on both
transports, with a hint that says what to do next. It used to lead with
"Insufficient role" for every 403, so a bot with a read-only API token was
told to ask for a role. An unverified Cloud email is reported as the
server's own email_not_verified code.
Stdio gets the same envelope from a structured marker the CLI root writes
for a 403 coded forbidden, permission_denied or email_not_verified. Before
it, the token-scope and unverified-email refusals said server_error there.
ToolSurfaceVersion 0.99 -> 0.100 (behavior).
Claude-Session: https://claude.ai/code/session_01MPeShv3DBfM9C94PTvMnqi
* fix(server): the inline workspace-role gates name their reason too (BUG-3864)
The bulk endpoint, the owner-only member doors and the owner-only app
install and upgrade doors say role, or no_access for a guest.
Claude-Session: https://claude.ai/code/session_01MPeShv3DBfM9C94PTvMnqi
* fix(mcp): the permission hint is the same on both transports (BUG-3864)
The remote hint appended the route, which stdio has no way to know, so one
refusal reached the two transports with different hints. The tests compared
prefixes only and missed it; both now assert the transports agree exactly.
Claude-Session: https://claude.ai/code/session_01MPeShv3DBfM9C94PTvMnqi
* fix(server): no role hint for a caller with no role to change (BUG-3864)
requireMinRole and the grants list said role for a guest, who holds grants
rather than a role, and for a caller with no workspace role at all. Both
now go through roleGateReason, which answers no_access for either.
Claude-Session: https://claude.ai/code/session_01MPeShv3DBfM9C94PTvMnqi
xarmian
ed89604ad8