/**
 * Short field hints for the user-script inputs on both publish tools
 * (`webSettings.jsUserScripts` on the builder, `customInjection` on
 * old-devtools).
 *
 * These used to inline the whole `skill/injection-api.md` guide (~22 KB) into
 * the tool's input schema. That guide is needed by a small minority of
 * providers, but an input-schema description is sent to the model on EVERY
 * request — it was roughly half the old-devtools tool surface on its own. The
 * prose now lives in `skill/user-script.md`, `skill/interception.md` and
 * `skill/hash-validation.md`, served on demand as `how_it_works` topics; what
 * stays here is the pointer plus the one warning that must be seen BEFORE the
 * field is filled in, since acting on it wrongly is worse than not acting.
 *
 * Shared by both publish tools so the two can't drift apart.
 */
/** Auth behavior shared by intercepted and script-requested claims. */
export declare const COOKIE_ATTACHMENT_HINT: string;
/** What the script is and where the real guidance lives. */
export declare const USER_SCRIPT_HINT: string;
/** Prefixes the `allowedJsRequests` / `allowedInjectedRequestData` field. The
 *  trap it describes is silent and total — a mis-declared entry makes
 *  `verifyProof({ providerId })` reject EVERY real proof — so the warning
 *  itself stays in the schema even though its explanation moved to a topic. */
export declare const ALLOWED_REQUESTS_HINT: string;