`, `<meta name="description">`, OG tags - Only render published records ```astro --- import db from '../../data/db.ts'; import { <table> } from '../../data/schema/tables/<table>'; import { eq } from 'drizzle-orm'; export function getStaticPaths() { const items = db.select().from(<table>).where(eq(<table>.status, 'published')).all(); return items.map(item => ({ params: { slug: item.slug }, props: { item }, })); } const { item } = Astro.props; --- <html> <head> <title>{item.metaTitle || item.title}

` instead. - **Ambient prose** — `section-flow` and `prose-flow` include prose automatically via `@apply prose`. Raw HTML elements get typographic styling from prose at low specificity (`:where()`) — component classes always win. Don't add `prose` separately. The only local `prose` usage is for nested content zones that need their own vertical rhythm. - **Landmark components live on their own** — Hero, Footer, Nav go directly inside `section-flow`. They render their own semantic element with `data-component` and flow attributes (`data-seamless`, `data-full-width`). Don't wrap landmarks in `

`. - **Content components go inside `

`** — the consumer controls `title`, `seamless`, `narrow`, `fullWidth`, `withWrap`. Use `

` when a section needs edge-to-edge background but children should stay constrained to container width. - **Backgrounded sections use `seamless`** — `

` for sections with background colors/images. Adjacent seamless sections get 0 gap so backgrounds butt up. - Background alternation for visual rhythm — use semantic surface tokens for section variety. These automatically adapt in dark mode - Visual flow — the eye moves naturally through the page - Responsive behavior via container queries - SEO: ``, `<meta name="description">`, OG tags - **`color-scheme` meta tag** — already handled by `Layout.astro` for design system pages. For site pages, include `<meta name="color-scheme" content="light dark">` if the site supports dark mode, or `<meta name="color-scheme" content="light">` if light-only - **Images in dark mode** — photographs on dark backgrounds can feel jarring. Use `dark:brightness-80 dark:contrast-125` on `<img>` elements to dim slightly. Avoid images with baked-in white backgrounds — they become glowing rectangles in dark mode. Prefer transparent or neutral backgrounds for logos and illustrations ## Layout purity rules (design system layouts only) When building a layout in `src/pages/design-system/layouts/`, enforce these additional rules: - **Single-file rule** — a layout page is one `.astro` file. No extracted sub-components, no helper modules. If the layout feels too complex for one file, the components are too coarse — refine them in `/angora-component`. - **Zero-class layout rule** — layouts are pure component composition. No Tailwind utility classes on raw HTML elements. If you need to add a class to a `<div>`, a component is missing. **Allowed:** just `section-flow` on `<main>`. **Not allowed:** spacing wrappers (`<div class="mt-8">`), grid layouts (`<div class="grid grid-cols-2">`), visual treatments (`<div class="bg-card rounded-lg">`), styled headings, width constraints, Button wrapper divs, `class` overrides on components, raw markup. - **No client-side code** — design system layouts are static. No inline `<script>` tags for interactivity. If a section needs interactivity, it should use a Preact island via the component itself. - **Layout purity check** — after building, verify: single file? No client code? Zero-class compliance? Landmark components outside `<Section>`? Content components inside `<Section>`? No arbitrary values? No double-wrapping? Background rhythm makes sense? ## Review Present the completed page to the user and suggest they review in browser (`pnpm dev`). Then run `/angora-design-system-audit` automatically — this is verification, not a change. Present findings and proposed fixes. Wait for approval before applying fixes. (Accessibility is covered at the component and layout level by `pnpm test:a11y` — no need to re-test assembled pages.)