/**
 * The LSP stdio Content-Length frame decoder, as JS SOURCE — embedded verbatim into `BRIDGE_SOURCE` (which runs
 * inside the E2B sandbox, can't import TS) AND unit-tested here (test/lsp-frames.test.ts evals this same string).
 * So the in-sandbox parser is actually exercised (council #5: the untestable raw-string parser was the risk).
 *
 * Guards: a frame claiming a non-finite / negative / over-cap length is skipped instead of looping or waiting
 * forever (council #1 defense); the accumulator is dropped if it exceeds the cap with no complete frame (council
 * #2 — a server that never sends `\r\n\r\n`, or a huge Content-Length, can't grow the buffer without bound).
 * The runaway cap carries a `HEADER_SLACK` (core 1.196 #6 twin): a VALID frame whose PAYLOAD passes the
 * `len <= maxBytes` check but whose `Content-Length: <n>\r\n\r\n` header pushes header+payload just over `maxBytes`
 * must NOT be wiped mid-arrival (that silently dropped an in-window legal reply) — so cap at `maxBytes + 128`.
 */
export declare const FRAME_DECODER_JS: string;
//# sourceMappingURL=lsp-frames.d.ts.map