/**
 * Query-error classification policy for `/api/query`.
 *
 * Extracted from routes/query.ts (PR #2330 review): that file is a ~1.4k-line
 * mixed-purpose route, and the policy had grown into two cooperating exported
 * helpers with an implicit ordering dependency between them. One classifier
 * owns it now — typed errors are a terminal branch, legacy message matching
 * applies only to untyped ones — so there is a single place to add a rule and
 * no way to place it wrongly.
 */
import type { ServerResponse } from "node:http";
/**
 * Should `/api/query` answer 400 for this thrown error?
 *
 * `true` renders a 400; `false` rethrows as a server fault.
 *
 * A bare upstream status is NOT sufficient (PR #2330 review): one request also
 * runs engine-generated queries for access control, graph resolution and
 * metadata scans, and a store rejecting one of those with 400 is an
 * integration fault, not a malformed caller query. The query engine marks the
 * single store call that carried caller-supplied SPARQL; only that marker — or
 * a legacy message family with no typed carrier — yields a 400.
 *
 * This is the sole exported classifier. The legacy message matcher stays
 * private so the provenance-first rule cannot be bypassed.
 */
export declare function isClientQueryFailure(err: unknown): boolean;
/**
 * Answer a failed `/api/query` whose failure has an answer of its own, and say
 * whether it did. `false` leaves the error to the daemon's top-level mapping.
 *
 * - The caller's own SPARQL was rejected: 400, see {@link isClientQueryFailure}.
 * - An unscoped result was withheld: a retryable 503. Losing that check says
 *   nothing about the request and the same query succeeds once the write has
 *   settled, so it gets the shape of the route's other transient answers, not
 *   a 500. The sentence is the one the agent throws.
 */
export declare function respondToQueryFailure(res: ServerResponse, err: unknown): boolean;
//# sourceMappingURL=query-error.d.ts.map