import { U as UseCase } from './types-aLlrbaFC.js'; /** * Every word a `parityType` may be: the parity types, every kind the declaration door * publishes (`custom.field_kinds()` — entity_reference, signature, long_text …, which a * lane-8 template needs for S4 and e-sign), their behaviors, the synonyms. */ declare const RESOLVABLE_FIELD_TYPE_WORDS: readonly string[]; /** * The minimum a seeded business needs before a screen looks like it is working * rather than like a fixture. Below this, a screenshot shows an empty state. * * It was 8 until a real dataset argued with it: a whole-house renovation has SIX * ROOMS, and demanding eight would have meant inventing two rooms that do not * exist — which is the exact failure this whole library is against. Six rooms on * a board is a working project, not an empty screen. So the floor is what a * screen genuinely needs, and the suite keeps the stronger check where it * belongs: at least 20 rows across the whole use case. */ declare const MIN_ROWS_IN_PRIMARY_TABLE = 5; /** A refusal: what is wrong, where, and what to do. */ interface UseCaseProblem { /** Dotted path into the use case: "tables[1].fields[3].choices". */ at: string; /** The sentence. Always says what to do, never only what is wrong. */ says: string; } interface UseCaseVerdict { ok: boolean; problems: UseCaseProblem[]; } /** * Check one use case. Returns every problem rather than the first, because a * crew fixing a dataset wants the whole list in one pass. */ declare function validateUseCase(useCase: UseCase): UseCaseVerdict; /** * Validate, and throw with every problem listed. This is what a seeder calls * before it writes anything to a live organization — a half-valid dataset is * worse than none, because it produces a screen that looks like it worked. */ declare function assertUseCase(useCase: UseCase): void; export { MIN_ROWS_IN_PRIMARY_TABLE as M, RESOLVABLE_FIELD_TYPE_WORDS as R, assertUseCase as b, validateUseCase as v }; export type { UseCaseProblem as U, UseCaseVerdict as a };