/**
 * The supplier's fixture status, and what our own `MatchStatus` makes of it.
 *
 * One table, because two callers must not be able to disagree about what "FT"
 * means: the scraper's fixture fetch (`api-football/matches.ts`, which
 * re-exports `mapApiFootballStatusToMatchStatus` from here) and
 * `api-gateway/scripts/backfill-match-statuses.ts`, which asks the supplier
 * about fixtures the scrape can no longer reach. The `deriveGlobalRanks`
 * arrangement.
 *
 * ## Why a past fixture could sit at `Fixture` forever
 *
 * The scraper posts only `kickoff > now` (`persistMatchesToDatabase`), so a
 * fixture's status was written once, at ingest, while it was still in the
 * future — and never again. Measured 2026-08-27: **123,950 of the 124,576 past
 * matches read `Fixture` and only 258 read `Played`.** Nothing was wrong with
 * the mapping; nothing ever asked it a second time.
 *
 * ## `isFinal`
 *
 * Whether a status is an END state. `Played`, `Canceled` and `Postponed` are
 * conclusions about a fixture that has happened or definitively has not;
 * `Fixture`, `KickoffUnknown` and `Playing` are not. This is what the results
 * paths refuse to overwrite with: writing `Fixture` onto a past row is the
 * stale state itself, so a supplier still answering `NS` for a match played
 * four months ago must not be allowed to reassert it.
 */
import { MatchStatus } from "@weekendgoals/weekendgoals-types/dist/matches";
/**
 * API-Football `fixture.status.short` → our status.
 *
 * Unmapped codes fall to `Fixture`, which is the honest answer for a code we
 * have not seen: it is the schema default and claims nothing happened. Note
 * that this makes an unknown code indistinguishable from "not started", which
 * is why `isFinalStatus` exists rather than callers testing for `Fixture`.
 */
export declare function mapSupplierStatus(status: string): MatchStatus;
/** An end state: this fixture has happened, or definitively has not. */
export declare function isFinalStatus(status: MatchStatus | string): boolean;
/**
 * Should a stored status be replaced by one the supplier now reports?
 *
 * Three refusals, and each of them is a way a naive "just write what the
 * supplier says" would make the data worse:
 *
 *  - **Never write a non-final status onto a past row.** `Fixture` on a past
 *    match is exactly the defect being repaired; a supplier answering `NS` for
 *    a fixture played months ago (which happens — the 2025 rows include ids the
 *    supplier has since reused or abandoned) would rewrite the repair back to
 *    the bug.
 *  - **Never move a row that is already final back to non-final.** A row we
 *    have as `Played` is not un-played by a later `NS`.
 *  - **No-ops are refused rather than counted as work**, so a re-run reports
 *    honestly that it changed nothing.
 *
 * `Playing → Played` is allowed and is the one non-final source state that
 * moves: a match in progress at scrape time finishes.
 */
export declare function shouldApplyStatus(stored: MatchStatus | string | undefined, incoming: MatchStatus, kickoffIsPast: boolean): boolean;
//# sourceMappingURL=match-status.d.ts.map