/**
 * The denial text the worktree-authorization gate prints when no live user
 * grant covers the operation.
 *
 * WHY ITS OWN MODULE. `worktree-authorization-gate.ts` is 701 lines against a
 * 300-line cap and already carries a baseline row, so it may only shrink. The
 * five refusal texts it used to build inline move here and the gate calls
 * these builders — the extract-don't-append move this repository makes instead
 * of growing an over-cap file.
 *
 * WHY THE TEXT ASKS THE READER TO GO TO THE USER. The gate is a `PreToolUse`
 * hook, so its reader is the agent, and the AGENT IS THE PARTY THE PROJECT'S
 * RULE AIMS AT: the authorization this gate consumes is the user's to give. The
 * gate cannot enforce that distinction — see the next paragraph, which is the
 * part an earlier revision of this file got wrong — so the text asks rather
 * than claims, and the denial that told its own reader to run a command it was
 * told it must not run is the defect this function replaces.
 *
 * WHAT THE GATE ACTUALLY CHECKS — AND WHAT IT DOES NOT. A grant recorded for
 * the operation in this session. Nothing else: the gate has no issuer concept,
 * so it cannot and does not discriminate on who wrote the grant. Measured
 * 2026-10-13, end to end, in a scratch project: `git stash drop stash@{0}` is
 * refused (exit 2); the agent then runs
 * `peaks worktree auth grant --operation git-stash-mutating --reason "the agent
 * wrote this itself; no user was involved"` and gets `ok: true`; the SAME call
 * then exits 0 and is allowed. The grant stays operation-scoped (`git worktree
 * add` against the same project is still refused), so the gate does gate — it
 * just cannot tell consent from self-authorization.
 *
 * WHY THIS MATTERS FOR THE TEXT. An earlier revision of this function said "an
 * agent-issued grant is not the consent this gate checks for, so the reader
 * cannot satisfy this refusal itself". That is exactly the defect the function
 * exists to avoid: a message asserting a guarantee the code does not implement,
 * which this module's own header above already falsifies. The text below says
 * what the measurement shows — the gate needs a recorded grant, and nothing
 * distinguishes who issued it — and keeps the ask, because the authorization is
 * the user's to give even though the gate cannot enforce that.
 *
 * `operation` is a plain `string`, not the gate's `OperationType`: the text
 * only interpolates the value, and importing that type back would make the two
 * modules mutually importing. `as const` on `code` and `allow` keeps each
 * returned literal narrow enough to be the gate's deny variant without the
 * import.
 */
export declare function noAuthorizationDenial(operation: string, sessionId: string): {
    allow: false;
    code: "WORKTREE_USER_AUTH_REQUIRED";
    reason: string;
    remediation: string;
};
export declare function noGrantForOperationDenial(operation: string): {
    allow: false;
    code: "WORKTREE_USER_AUTH_REQUIRED";
    reason: string;
    remediation: string;
};
export declare function requestMismatchDenial(operation: string, grantRequestId: string | null, currentRequestId: string | null): {
    allow: false;
    code: "WORKTREE_USER_AUTH_REQUEST_MISMATCH";
    reason: string;
    remediation: string;
};
export declare function expiredGrantsDenial(operation: string): {
    allow: false;
    code: "WORKTREE_USER_AUTH_EXPIRED";
    reason: string;
    remediation: string;
};
export declare function consumedGrantsDenial(operation: string): {
    allow: false;
    code: "WORKTREE_USER_AUTH_REQUIRED";
    reason: string;
    remediation: string;
};