import { type CapabilityPin } from './types.js';
/** The tool grant itself, `tool:<name>`. */
export declare function toolScopeGrant(toolName: string): string;
/** The implementation-pin prefix, `tool:<name>:impl:`. */
export declare function implementationPinPrefix(toolName: string): string;
/** The declared-metadata-pin prefix, `tool:<name>:meta:`. */
export declare function metadataPinPrefix(toolName: string): string;
/** Read the pin a grant's scope carries for one tool.
 *
 *  Returns `null` when the grant does not name the tool at all, which is a DIFFERENT
 *  ANSWER from a grant that names it and pins nothing. The second comes back as a
 *  `CapabilityPin` with both digest arrays empty. `evaluateCapabilityBinding` gives the two
 *  different reason codes, `TOOL_NOT_IN_GRANT_SCOPE` and `NO_CAPABILITY_PIN_IN_GRANT`, and
 *  collapsing them loses the distinction CAND-07 v2's unpinned limb is about.
 *
 *  Pins are returned in the order the grants appear, de-duplicated, and are NOT validated
 *  as digests: an unparseable pin value is a pin that will not match, which is a verdict,
 *  not an error. */
export declare function parseCapabilityPinFromScopeGrants(grants: readonly string[], toolName: string): CapabilityPin | null;
/** Write a pin as scope grants, the inverse of `parseCapabilityPinFromScopeGrants`.
 *
 *  Returns the tool grant followed by one grant per pinned digest, sorted by UTF-8 bytes so
 *  a caller appending them to an existing grant array can keep the array canonical, which
 *  draft-03 section 3.2 requires of scope arrays. Refuses a pin whose `encoding` is not
 *  `scope_grant_v0`, because writing a `bound_record_v0` pin into a scope would be a
 *  silently different artifact. */
export declare function capabilityPinScopeGrants(pin: CapabilityPin): readonly string[];
/** Whether a pin pins nothing. CAND-07 v2's unpinned limb turns on exactly this. */
export declare function capabilityPinIsEmpty(pin: CapabilityPin): boolean;
//# sourceMappingURL=pins.d.ts.map