/**
 * Venue FAQ: one text field -> the Q/A rows the accordion renders.
 *
 * The venue's `faq` is a single free-text field an operator fills from a
 * textarea ("Common questions and answers for customers"). FaqAccordion renders
 * {question, answer} pairs. This is the bridge, and it is shared so the event
 * page and the series page read that one field the same way.
 *
 * The shape is INFERRED rather than demanded: the field is a plain textarea and
 * no operator is told a format, so the parser has to make sense of whatever is
 * in there.
 *
 * The rules, in the order they are tried:
 *
 *   1. Already structured — an array of {question, answer}, from any caller that
 *      holds pre-split pairs, passes through.
 *   2. Explicit Q:/A: markers, the convention people reach for unprompted.
 *   3. A line ending in "?" starts a question; the lines under it are its
 *      answer. This is what venue FAQs actually look like.
 *   4. None of the above — no question mark anywhere, no markers — is a single
 *      block of prose, and it stays one row rather than being chopped at
 *      arbitrary line breaks.
 *
 * A line's OPENING WORDS are deliberately not evidence, even though the ticket
 * PDF's formatter treats "what"/"how"/"can i" that way: on a PDF a mis-split is
 * a cosmetic line break, but here it collapses the rest of a sentence into a
 * closed accordion row and hides it. Ending punctuation and explicit markers are
 * evidence; sentence openings are a guess.
 */
export interface ParsedFAQItem {
    question: string;
    answer: string;
}
/**
 * Normalizes whatever the API answered for a venue's FAQ into accordion rows.
 * Accepts the structured array, the text column, or nothing; always returns an
 * array (empty when there is nothing to show), so callers can render
 * unconditionally.
 */
export declare function parseVenueFaq(raw: unknown): ParsedFAQItem[];