/*
 * The front application sheet (0.75.0, the brief of 31 Oct 2026, "rooster.systems on Rooster Zero" step 2; CONTRACT
 * §1 "An application page"): the kit's recipes an application page uses on the storefront (the portal's screens
 * under My Account, built with the library's builders inside the theme's app shell), compiled against the theme's
 * tokens (front-tokens.css maps every `--ra-*` onto `--wp--preset--*` and `--wp--custom--rooster--*` on the
 * application root, `.rooster-admin-app`). `npm run build` writes ../front-app.css and its minified twin, which
 * front-app.php's rooster_admin_front() registers for the screen that asks and nothing else loads: at most 20 KB
 * gzipped (BuildTest), the common path of every application page.
 *
 * What is here: the families of kit.css an application page uses, in the kit's order, then the field patterns, the
 * states and the pieces of more.css, then the chrome's shared sections (the card, the field rows, the checks, the form
 * pieces, the dialog, the field rows on a narrow screen), then a card per row (table-cards). What is not: the chrome
 * (the brand bar, the menu bar, the Home, the palette, the settings screens), the searchable select, the toasts, the
 * side panel, the picker, the adoption layer, the guidance level; the page board and a page's windows are their own
 * opt-in sheets on the storefront (front-board.css, front-windows.css), loaded only by a screen that asks, so this
 * sheet stays the common path (the owner's rule: a feature for a handful of screens is its own component).
 */

@import "tailwindcss/theme.css" layer(theme);
@import "tailwindcss/utilities.css" layer(utilities) source(none);
@import "./front-tokens.css";
@import "./theme.css";
@import "./utilities.css";

/* The kit's families an application page uses (kit.css's order). */
@import "./kit/buttons.css";
@import "./kit/badges.css";
@import "./kit/notices.css";
@import "./kit/tabs.css";
@import "./kit/controls.css";
@import "./kit/dialogs.css";
@import "./kit/empty.css";
@import "./kit/pager.css";
@import "./kit/table.css";
@import "./kit/table-wide.css";
@import "./kit/table-more.css";
@import "./kit/progress.css";
@import "./kit/stars.css";
@import "./kit/stats.css";
@import "./kit/charts.css";
@import "./kit/fold.css";
@import "./kit/editable.css";
@import "./fields.css";
@import "./states.css";
@import "./more.css";

/* The chrome's sections an application page shares (chrome.css's order). */
@import "./chrome/cards.css";
@import "./chrome/field-rows.css";
@import "./chrome/checks.css";
@import "./chrome/form.css";
@import "./chrome/dialogs.css";
@import "./chrome/narrow-fields.css";

/* A card per row (the admin loads it as its own sheet by the first table that asks; here it is part of the one). */
@import "./kit/table-cards.css";

/* ── The application root (Ui::app()): the screen's box inside the theme's app shell. A size container, so the kit's
   container queries (a card's field rows, two charts side by side) answer to the application's width; the body's
   font and colour are the theme's, the tokens above do the rest. ── */
.rooster-admin-app {
	@apply block min-w-0 text-foreground;
	container-type: inline-size;
}

/* The kit's own `.rooster-admin` scopes (a control's recipe, a filter bar) hold on the root too: it carries both. */
.rooster-admin-app > * + * {
	@apply mt-(--ra-gap-card);
}

/* FE-F4 (0.75.1, the owner's ruling on the reply's question 3): under 783 px the kit's field controls and the choice
   controls' text take the theme's field size, 1 rem, as the theme's own fields do (iOS Safari zooms the page on a
   field under 16 px); the small-text mapping of front-tokens.css stays, so nothing else grows. */
@media (width < 783px) {
	.rooster-admin-app
		:is(
			.rooster-admin-input,
			.rooster-admin-textarea,
			.rooster-admin-combo__control,
			select:not([multiple], [size]),
			.rooster-admin-check,
			.rooster-admin-switch
		) {
		font-size: 1rem; /* the native select named as the kit's recipe names it, so this weighs the same and comes later */
	}
}