/**
 * Can this user's writes actually LAND in this workspace?
 *
 * ★ Separate from `useAssistantApiAccess`, and deliberately not a replacement
 * for it. That hook asks `myRoles` at ORG scope, which is the right question for
 * "may this person use a mode that mints an OAuth app under their identity".
 * Execution, though, happens at WORKSPACE scope — so an org admin could enter
 * Take-action mode, have the model plan a change, confirm it, and only then hit
 * a permission error. The two questions have different answers and both are
 * legitimate; this hook asks the second one.
 *
 * ★ What it can look like: measured 2026-09-02 against prod, `checkPermissions`
 * answered cleanly (HTTP 200, no errors) with `allowed: false`,
 * `decisionPath: "default:deny"` and a null role — for an org OWNER. That was
 * ONE workspace whose roles had never been initialised (fixed 2026-09-07 by
 * `initializeWorkspaceRoles`), not the platform: workspaces are seeded with
 * their role templates, and for a member whose role grants the probed actions
 * this returns `granted`.
 *
 * ★ Which is exactly why this hook only WARNS. The `@rbac` check on each
 * mutation is the authority; a client-side read like this one can be wrong —
 * an uninitialised workspace, a stale role — and a GATE built on it would hide
 * Take-action from a person who is allowed to use it. A warning that turns out
 * to be unnecessary costs a sentence; a wrong gate costs the mode.
 *
 * Fails OPEN on error or while loading: a network blip must not accuse someone
 * of lacking a permission they may well have.
 */
/** `unknown` while in flight or unanswerable — never treated as a refusal. */
export type WorkspaceWriteAccess = "granted" | "denied" | "unknown";
export declare function useWorkspaceWriteAccess(actorId: string | null, workspaceId: string | null, probeResources: readonly string[]): WorkspaceWriteAccess;
//# sourceMappingURL=useWorkspaceWriteAccess.d.ts.map