/**
 * Helpers for shaping `aft doctor --issue` GitHub issue bodies within
 * GitHub's hard ~64KB issue-body limit.
 *
 * Two responsibilities live here:
 *
 *   1. Error-line extraction — pull the most-recent ERROR-shaped lines from
 *      a sanitized log so the issue body has a dedicated `## Recent errors`
 *      section that survives even when the main log tail needs aggressive
 *      truncation.
 *
 *   2. GitHub byte-budget capping — when a rendered report exceeds the
 *      budget, shrink the main log block (the noise-heavy section) from
 *      the top, preserving the diagnostics / configuration / error sections
 *      that matter most.
 *
 * Both helpers operate on already-sanitized markdown so they're harness-
 * agnostic — OpenCode and Pi share the same byte budget, the same
 * truncation marker text, and the same precision/false-positive tradeoff
 * on what counts as an "error" line.
 */
/**
 * GitHub issue body byte budget. GitHub enforces ~64KB (65536 bytes); we
 * leave 4KB of headroom for: GH's own URL encoding when opening the
 * "Submit new issue" tab via `gh issue create --web`, future minor
 * markdown growth from new sections, and a safety margin against any
 * single-line entry crossing the cap.
 */
export declare const MAX_GITHUB_BODY_BYTES = 60000;
export declare function filterLogToSession(logText: string, sessionId: string): string;
/**
 * Extract the most-recent error-shaped log lines from a sanitized log.
 * Returns them in chronological order (oldest match first → newest match
 * last) so the issue body reads naturally top-to-bottom.
 *
 * **Why this exists**: GitHub issue bodies have a hard ~64KB limit and a
 * busy session's tail can easily blow past that. If the body needs
 * truncation, the error section MUST survive because the whole point of
 * the issue is the error. This extractor pulls them into a separate
 * section that the body-cap is careful not to drop.
 */
export declare function extractRecentErrors(sanitized: string, limit?: number): string[];
/**
 * Apply a byte budget to a rendered issue body. If the body is already
 * within budget, returns it unchanged. Otherwise rewrites the main
 * fenced log block (whose heading must start with `## Logs (last`) to
 * drop oldest log lines until the body fits, leaving a clear
 * `[truncated for GitHub 64KB limit — older log lines dropped]` marker
 * at the top of the kept slice.
 *
 * This deliberately ONLY touches the main-log section — the description,
 * environment, diagnostics, and recent-errors sections are preserved
 * intact because they're the most useful parts of the report. The main
 * log is the noise-heavy one and the right thing to shrink first.
 *
 * AFT's main log section contains per-harness sub-sections (`#### opencode
 * log (path)\n```...```\n#### pi log (path)\n```...```\n`). The cap walks
 * the entire `## Logs (last ...` block as a single shrinkable region
 * because precise per-harness allocation is fiddly and the alternative —
 * dropping the whole log block on overflow — is strictly worse for
 * debugging.
 *
 * Returns the (possibly-shrunk) body. UTF-8 byte length is the budget,
 * matching how GitHub measures issue bodies (the issue API rejects
 * `body` payloads above the limit).
 */
export declare function capBodyToGithubLimit(body: string, maxBytes?: number): string;
//# sourceMappingURL=issue-body.d.ts.map