/**
 * COMPILE-TIME assertions that the four trust verbs reject the wrong kind of key.
 *
 * This is the half of the guarantee that a runtime check could not give you: a reader cannot
 * accidentally treat a caller-asserted value as proven, because the call does not compile. Each
 * `@ts-expect-error` fails the build (TS2578) if its line ever starts compiling.
 *
 * In COMPILED source deliberately — a `@ts-expect-error` inside a `.spec.ts` is inert here
 * (tsconfig.lib.json excludes specs; vitest strips types with esbuild), so the tripwire would be a
 * no-op. See `ContextKeyTrustCompileAssertions` for the key-construction half.
 */
export declare class RequestContextTrustCompileAssertions {
    private readonly trusted;
    private readonly untrusted;
    /** Reading an untrusted value as if it were proven is the bug this whole change exists to stop. */
    cannotReadUntrustedAsTrusted(): void;
    /** And the reverse, so a call site always states which kind of value it believes it has. */
    cannotReadTrustedAsUntrusted(): void;
    /** FORGERY: writing a trusted key through the untrusted verb must not compile. */
    cannotForgeTrustedViaUntrustedWrite(): void;
    /** Claiming proof for an untrusted key must not compile either — trust is not a caller's choice. */
    cannotClaimProofForUntrustedKey(): void;
    /** POSITIVE: the matching pairs must keep compiling, with the value type inferred from the key. */
    matchingVerbsCompile(): void;
    /** The value type still comes from the key: a trusted string key rejects a number. */
    valueTypeStillEnforced(): void;
}