@homepages/template-kit 0.2.0 → 0.4.0

package/dist/ssr.js

@@ -0,0 +1,46 @@
+import { FixtureModuleShape, buildFixtureSet, buildInvariantFixtures } from "./schema/fixture-schema.js";
+import { hasClientDirective } from "./eslint/is-client-file.js";
+import { isClientComponentFile, islandKey } from "./islands/detect.js";
+import { findSectionIslands } from "./islands/discover.js";
+import { wrapClientModuleSource } from "./islands/wrap.js";
+import { islandTransformEsbuildPlugin } from "./islands/esbuild-plugin.js";
+import { createElement } from "react";
+import { basename, join } from "node:path";
+import { pathToFileURL } from "node:url";
+import { renderToStaticMarkup } from "react-dom/server";
+
+//#region src/ssr/index.ts
+const nativeSectionLoader = (dir, file) => import(pathToFileURL(join(dir, file)).href);
+/**
+* Load a bundle's Renderer plus its resolved snapshot and invariant fixture
+* sets from the bundle directory `dir`. `load` resolves each of the four
+* contract files; it defaults to native dynamic import.
+*/
+async function loadSectionBundle(dir, load = nativeSectionLoader) {
+	const rendererMod = await load(dir, "Renderer.tsx");
+	const fixturesMod = await load(dir, "fixtures.ts");
+	const schemaMod = await load(dir, "schema.ts");
+	const parsed = FixtureModuleShape.parse(fixturesMod.default);
+	const selfAnchor = schemaMod.schema.meta?.anchor ?? basename(dir);
+	return {
+		Renderer: rendererMod.default,
+		snapshotFixtures: buildFixtureSet({
+			schema: schemaMod.schema,
+			module: parsed,
+			selfAnchor
+		}),
+		invariantFixtures: buildInvariantFixtures({
+			schema: schemaMod.schema,
+			module: parsed,
+			selfAnchor
+		}),
+		schemaSlots: schemaMod.schema.slots
+	};
+}
+/** Render a resolved fixture's props to static markup — the byte-for-byte page render. */
+function renderSectionHtml(renderer, props) {
+	return renderToStaticMarkup(createElement(renderer, props));
+}
+
+//#endregion
+export { findSectionIslands, hasClientDirective, isClientComponentFile, islandKey, islandTransformEsbuildPlugin, loadSectionBundle, nativeSectionLoader, renderSectionHtml, wrapClientModuleSource };

package/dist/styles.css

@@ -1,15 +1,26 @@
 /*
- * @homepages/template-kit — theme tokens + kit source registration.
+ * @homepages/template-kit — the global Tailwind preamble.
  *
- * Import this AFTER `@import "tailwindcss";` in your own CSS entry:
+ * Import this AFTER `@import "tailwindcss";` in your own CSS entry, and import your
+ * template's compiled theme after it:
  *
  *   @import "tailwindcss";
  *   @import "@homepages/template-kit/styles.css";
+ *   @import "./theme.css";        // compileThemeToCss(yourTheme) output
  *
  * This file must NOT import Tailwind itself. Exactly one `@import "tailwindcss"` may
  * exist per build graph — your entry owns it. Two double-emit Tailwind's preflight
  * reset (box-sizing declared twice, ~4 KB of duplicate base layer).
  *
+ * WHAT IS HERE: only what is true of EVERY template — the breakpoint ladder, the
+ * spacing base unit, and the motion defaults.
+ *
+ * WHAT IS NOT: your design tokens. Colors, fonts, type, radii and shadows are yours.
+ * Declare them in `theme.ts` under names you choose, and `compileThemeToCss` generates
+ * the `@theme inline` alias layer that turns each one into a utility. Nothing about
+ * your visual system is shared, and there is no global file for you to edit to make a
+ * token of yours usable.
+ *
  * The @source below resolves relative to THIS FILE'S SHIPPED LOCATION (dist/styles.css),
  * registering the kit's compiled JS for class scanning — that is how the utility classes
  * baked into the kit's primitives reach your compiled CSS. It also overrides Tailwind's
@@ -23,107 +34,39 @@
  * utilities and 19 stray @property registrations, ~2.5 KB. If a primitive ever moves out
  * of primitives/, widen this — an unstyled <Image> in every template is the failure mode,
  * and scripts/verify-consumer.mjs is what catches it.
- *
- * The @theme block aliases Tailwind's utility namespace onto the `--tr-*` custom
- * properties your template's theme.ts supplies (`text-ink` → `var(--tr-color-ink)`).
- * The aliases are the cross-template contract; the values behind them are yours.
  */
 @source "./primitives/**/*.js";
 
+/* `@theme inline` so a spacing/breakpoint value is substituted straight into the
+ * utilities Tailwind generates (`.gap-2 { gap: .5rem }`), rather than emitted as a
+ * `:root` custom property the utilities then read through `var()`. These are fixed
+ * global constants, not per-page-overridable tokens, so inlining is both correct and
+ * what keeps the compiled output stable. Nothing here may reference a token a theme.ts
+ * defines. */
 @theme inline {
-  /* ---------- Colors (alias to the --tr-color-* values a theme.ts supplies) ---------- */
-  --color-ink:           var(--tr-color-ink);
-  --color-ink-soft:      var(--tr-color-ink-soft);
-  --color-ink-mute:      var(--tr-color-ink-mute);
-  --color-background:    var(--tr-color-background);
-  --color-surface:       var(--tr-color-surface);
-  --color-surface-alt:   var(--tr-color-surface-alt);
-  --color-border:        var(--tr-color-border);
-  --color-border-strong: var(--tr-color-border-strong);
-  --color-accent:        var(--tr-color-accent);
-  --color-accent-strong: var(--tr-color-accent-strong);
-  --color-accent-contrast: var(--tr-color-accent-contrast);
-  --color-primary:         var(--tr-color-primary);
-  --color-primary-fg:      var(--tr-color-primary-fg);
-  --color-primary-darker:  var(--tr-color-primary-darker);
-  --color-overlay:        var(--tr-color-overlay);
-  --color-overlay-strong: var(--tr-color-overlay-strong);
-  --color-overlay-light:  var(--tr-color-overlay-light);
-  --color-footer-bg:      var(--tr-color-footer-bg);
-  --color-footer-fg:      var(--tr-color-footer-fg);
-  --color-footer-fg-mute: var(--tr-color-footer-fg-mute);
-  --color-footer-divider: var(--tr-color-footer-divider);
-
-  /* Decorative brand swatches — the open `palette` escape hatch in TokenTheme.
-   * A theme that omits one leaves its utility resolving to an unset custom
-   * property; only reach for these when a semantic role genuinely doesn't fit. */
-  --color-yellow-deep:  var(--tr-color-yellow-deep);
-  --color-yellow-200:   var(--tr-color-yellow-200);
-  --color-yellow-100:   var(--tr-color-yellow-100);
-  --color-brown:        var(--tr-color-brown);
-  --color-green:        var(--tr-color-green);
-  --color-blue:         var(--tr-color-blue);
-  --color-rule:         var(--tr-color-rule);
-  --color-gray-light:   var(--tr-color-gray-light);
-  --color-team-gold:   var(--tr-color-team-gold);
-  --color-mute:         var(--tr-color-mute);
-  --color-scrim:        var(--tr-color-scrim);
-  --color-footer-line:  var(--tr-color-footer-line);
-  --color-footer-mute:  var(--tr-color-footer-mute);
-  --color-divider-40:   var(--tr-color-divider-40);
-  --color-contact-deep: var(--tr-color-contact-deep);
-  --color-header-deep:  var(--tr-color-header-deep);
-
-  /* ---------- Fonts ---------- */
-  --font-sans:    var(--tr-font-sans);
-  --font-display: var(--tr-font-sans);
-  --font-serif:   var(--tr-font-serif);
-  --font-num:     var(--tr-font-num);
-  --font-label:   var(--tr-font-label);
-
-  /* ---------- Type scale (mobile baseline; layer up with md:/lg:) ---------- */
-  --text-xs:      var(--tr-text-xs);
-  --text-sm:      var(--tr-text-sm);
-  --text-base:    var(--tr-text-base);
-  --text-lg:      var(--tr-text-lg);
-  --text-xl:      var(--tr-text-xl);
-  --text-2xl:     var(--tr-text-2xl);
-  --text-3xl:     var(--tr-text-3xl);
-  --text-4xl:     var(--tr-text-4xl);
-  --text-5xl:     var(--tr-text-5xl);
-  --text-display: var(--tr-text-display);
-
-  /* ---------- Spacing (Tailwind's own scale — no custom aliases) ---------- */
+  /* ---------- Spacing ---------- */
   --spacing: 0.25rem;  /* v4 base unit; Tailwind multiplies (e.g. p-4 = 1rem) */
 
-  /* ---------- Radii ---------- */
-  --radius-sm:   var(--tr-radius-sm);
-  --radius-md:   var(--tr-radius-md);
-  --radius-lg:   var(--tr-radius-lg);
-  --radius-full: var(--tr-radius-full);
-
-  /* ---------- Shadows ---------- */
-  --shadow-sm: var(--tr-shadow-sm);
-  --shadow-md: var(--tr-shadow-md);
-  --shadow-lg: var(--tr-shadow-lg);
-
-  /* ---------- Motion ---------- */
+  /* ---------- Motion ----------
+   * The --tr-* values these read are defined in base.css, which every page loads. */
   --default-transition-duration: var(--tr-duration-fast);
   --default-transition-timing-function: var(--tr-ease);
 
   /* ---------- Canonical breakpoint ladder ----------
-   * Eight canonical widths — the same set the preview grid and the screenshot
-   * harness verify a section against (VERIFICATION_WIDTHS is the matching TS
-   * constant). 350 is the mobile-first BASE (no prefix); the other seven are
-   * named breakpoints:
+   * Eight canonical widths — the same set the preview grid and the screenshot harness
+   * verify a section against. `VERIFICATION_WIDTHS` (design-system/breakpoints.ts) is
+   * the matching TS constant; CSS cannot import it, so `src/css/styles.test.ts` fails
+   * the build if the two ever drift.
+   *
+   * 350 is the mobile-first BASE (no prefix); the other seven are named breakpoints:
    *
    *   bp390 (390) · bp425 (425) · bp512 (512) · md (768) · lg (1024)
    *   · bp1440 (1440) · bp1920 (1920)
    *
    * `md` and `lg` keep Tailwind's own names and values. The off-ladder defaults
-   * (sm/xl/2xl) are reset to `initial` so a section cannot come to depend on a
-   * width nobody screenshots. A swap-heavy section may still reach for a raw
-   * `@media` micro-breakpoint at an off-ladder width (e.g. 640 / 769).
+   * (sm/xl/2xl) are reset to `initial` so a section cannot come to depend on a width
+   * nobody screenshots. A swap-heavy section may still reach for a raw `@media`
+   * micro-breakpoint at an off-ladder width (e.g. 640 / 769).
    */
   --breakpoint-sm:    initial;
   --breakpoint-bp390:  390px;

package/docs/INDEX.md

@@ -2,7 +2,7 @@
 purpose: Router for the docs corpus that ships inside the @homepages/template-kit npm package.
 status: living
 related: []
-updated: 2026-07-14
+updated: 2026-07-16
 ---
 # template-kit docs — router
 
@@ -13,10 +13,19 @@ detail.
 
 | Doc | What it covers | Read when you're touching... |
 |---|---|---|
+| `quickstart.md` | The cold-start tutorial: create a workspace, preview the starter's `hero` section, read its four files, make one edit, and check it — owns the author-loop anchor every recipe links to | your first section, end to end |
+| `overview.md` | The one-page mental model: workspace → templates → sections, the four reserved files, and the server-vs-client mapping | orienting yourself before your first section |
 | `llms.txt` | Machine-readable index of this corpus for an agent working inside an installed kit | orienting an agent in a consuming workspace |
 | `schema-system.md` | The section authoring contract: `schema.ts` / `fill-spec.ts` / `fixtures.ts` / `Renderer.tsx`, `SectionProps` inference, the closed source/transform vocabulary, and the golden property fixtures | authoring or changing any section |
+| `vocabulary.md` | The closed authoring vocabulary — the 9 slot types, the `direct()` source fields, and the `derived()` transforms, with selection semantics | choosing which slot type / source / transform to use |
 | `primitives.md` | The five contract primitives (`Section`, `Slot`, `SlotItem`, `SlotGroup`, `Image`) and the marker attributes they emit | writing a section's markup |
-| `theme-and-css.md` | The two CSS entries, the one-Tailwind-import rule, `TokenTheme`, the breakpoint ladder, and the opt-in `content-visibility` recipe for long, image-heavy pages | a template's theme, its CSS entry, or a long page with a live map or full-screen overlay |
+| `assets.md` | Static assets (svg/images/fonts): where they live (template level or a section folder, if referenced), referencing them from a section's CSS with `url()`/`@font-face` or importing them into a component, and the asset-vs-content-image distinction | shipping a logo, texture, icon, or brand font with a template |
+| `theme-and-css.md` | The two CSS entries, the one-Tailwind-import rule, `TokenTheme` (your own token names → your own Tailwind utilities), the `template-kit theme` command that generates `theme.css` from `theme.ts`, the breakpoint ladder, and the opt-in `content-visibility` recipe for long, image-heavy pages | a template's theme, its CSS entry, or a long page with a live map or full-screen overlay |
 | `islands.md` | Interactivity: `"use client"` components, the serializable-props rule, editor options, the loader | anything interactive in a section |
-| `eslint.md` | The `@homepages/template-kit/eslint` preset: zero-config setup and its glob scope | wiring up lint in a template workspace |
+| `eslint.md` | The `@homepages/template-kit/eslint` preset: the two-line config, the ESLint + parser install it expects, and its glob scope | wiring up lint in a template workspace |
+| `check.md` | The `template-kit check` CLI command: the toolchain it resolves from your workspace, its stages, `--all`/`--json`, output shape, and exit code | running `check` locally or wiring it into CI |
+| `dev.md` | The `template-kit dev` CLI command: the local preview server, its home launcher and two tool cards (full template viewer, canvas mirror), the canvas mirror's selection overlay and per-slot edit panel, live reload, the content-override protocol, and the render/inspect/screenshot endpoints | previewing sections as you author them |
+| `new.md` | The `template-kit new` / `new-section` CLI commands: scaffolding a new template with a working starter section, or adding a bare section to an existing template | adding a template or a section to a workspace |
+| `pack.md` | The `template-kit pack` CLI command: builds a template's submission zip — template source, the workspace lockfile, and a stamped `pack-manifest.json`; refuses on a failing `check`, a missing lockfile, or a local-protocol dependency | packaging a template for submission |
 | `rules/` | One page per rule-id (`template-kit/*`), across both venues — the id printed by a lint or `check` failure resolves here. `rules/INDEX.md` routes them; `rules/server-vs-client.md` is the concept the server-rendering rules assume | any lint or `check` failure |
+| `recipes/` | Task recipes: how do I add a slot, bind a fact, add an island, package a template… Each is a minimal delta from the starter's `hero` section, ending in the author loop. `recipes/INDEX.md` routes them by task | doing something specific and not sure which file to touch |

package/docs/assets.md

@@ -0,0 +1,128 @@
+---
+purpose: Authoring static assets (svg, images, fonts) at the template level or in a section folder, and how they differ from content images.
+status: living
+related: [INDEX.md, primitives.md, theme-and-css.md, rules/size-assets.md, rules/bundle-binary-asset.md, rules/no-raw-element.md]
+updated: 2026-07-16
+---
+# Static assets
+
+A **static asset** is a file that is part of the template itself — a logo, a
+background texture, an icon, a brand webfont. It is authored once, is the
+**same for every deliverable** rendered from the template, and is referenced
+either from your CSS or from a component.
+
+## Where an asset lives
+
+An asset lives in one of two places:
+
+- **Template level** — e.g. `templates/<template>/assets/` — shared across every
+  section in the template. Reference it from a section's CSS with a `../../assets/…`
+  path (below).
+- **Section folder** — e.g. `sections/<section>/assets/` — local to that one
+  section. A section-folder asset must be *referenced*: imported in `Renderer.tsx`
+  or `url()`-referenced from one of the section's CSS files. An unreferenced binary
+  in a section folder is flagged by [`bundle-binary-asset`](rules/bundle-binary-asset.md) —
+  it has no build meaning and can never be served.
+
+Keep a logo, texture, or font that several sections share in the template-level
+folder; keep one that only a single section uses alongside that section.
+
+## Supported files
+
+```
+.svg .png .jpg .jpeg .gif .webp .avif .ico    images
+.woff .woff2 .ttf .otf .eot                   fonts
+.mp4 .webm .mov .mp3 .wav                      audio / video
+.pdf .zip                                      documents
+```
+
+## Referencing an asset — from CSS with `url()`
+
+Reference a template-level asset from a section's `styles.css` with `url()` —
+a `@font-face` `src` or a `background-image` resolves to the asset's built URL,
+identical in the `template-kit dev` preview, in the editor, and on the published
+page. Hand-CSS opens with a `css-reason:` comment (see
+[`css-reason`](rules/css-reason.md)):
+
+```css
+/* css-reason: brand webfont + crest watermark, both template assets */
+@font-face {
+  font-family: "Brand Serif";
+  src: url("../../assets/fonts/brand.woff2") format("woff2");
+  font-display: swap;
+}
+
+.hero-crest {
+  background-image: url("../../assets/crest.svg");
+}
+```
+
+The `../../assets/…` path climbs out of the section folder to the template-level
+`assets/` directory. A font you declare here is available to the whole section.
+If the family you want is one the template's theme already loads, reference that
+instead — see [Theme and CSS](theme-and-css.md); a font the page already has
+costs nothing to reuse.
+
+A **section-folder** asset is referenced the same way, with a section-relative
+path instead — no climbing out of the folder:
+
+```css
+/* css-reason: hero watermark, local to this section */
+.hero-crest {
+  background-image: url("./assets/crest.svg");
+}
+```
+
+## Referencing an asset — from a component with `import`
+
+An asset you render as an element — a logo, a crest — can be imported in the component and
+handed to the `Image` primitive, whose `src` accepts a URL string:
+
+```tsx
+import { Image } from "@homepages/template-kit";
+import crest from "./assets/crest.svg";
+
+export default function Renderer() {
+  return <Image src={crest} alt="" />;
+}
+```
+
+The import resolves to the asset's built `/section-assets/…` URL — the same URL in the
+`dev` preview, the editor, and the published page. The kit ships an ambient TypeScript
+declaration that types every supported asset import as that URL string, so the import
+typechecks with no per-workspace setup. Use `alt=""` for a purely decorative
+asset. (Never a raw `<img>` — `Image` carries the responsive/fallback contract; a raw
+`<img>` is rejected by [`no-raw-element`](rules/no-raw-element.md).)
+
+## Which to use
+
+- CSS decoration (backgrounds, `@font-face`, masks) → `url()`.
+- An asset rendered as an element → `import` + `<Image>`.
+- A tiny glyph or icon → inline `<svg>` markup — no file at all.
+
+## Assets vs. content images
+
+These are two different things; keep them apart.
+
+- A **static asset** is authored template decoration — a logo, a texture, a brand
+  font. It ships inside the template, is the same on every deliverable, and you
+  reference it from your CSS with `url()` or by importing it into a component (above).
+- A **content image** is the property's own content — listing photos, floor
+  plans, a headshot. It differs on every deliverable and flows through the
+  section's slots via the [`Image`](primitives.md) descriptor, never as a file in
+  your template. Declare an image slot in your schema and render it with the
+  `Image` primitive; the platform supplies the actual photo per deliverable.
+
+Rule of thumb: if the picture is the same for every home the template ever
+renders, it's an asset — place it at the template level or in the section folder
+and reference it from CSS or a component `import`. If it changes with the
+property, it's content — give it a slot. Never hard-code a listing photo as an
+asset.
+
+## Keep them lean
+
+Every asset a section pulls in counts toward its asset budget — see
+[`size-assets`](rules/size-assets.md). Fonts and images are already compressed, so
+the budget is raw bytes: subset a webfont to the weights and characters you use,
+export images at the size they render, and drop anything a section doesn't
+actually reference.

package/docs/check.md

@@ -0,0 +1,124 @@
+---
+purpose: The `template-kit check` command — what it runs, its flags, its output shape, and its exit code.
+status: living
+related: [INDEX.md, rules/INDEX.md, eslint.md, theme-and-css.md, dev.md]
+updated: 2026-07-15
+---
+# template-kit check
+
+`template-kit check` is the one command that answers "will the platform accept this
+template?" — the same gate you run locally and the one the registry re-runs when you
+submit. Every failure prints a stable `template-kit/<id>`, a `file:line` where one
+applies, and a one-line fix hint. The id resolves to its own page under
+[`rules/`](rules/INDEX.md).
+
+## Usage
+
+```bash
+template-kit check                # infer the template from cwd, or the workspace's one template
+template-kit check <template>     # check one named template by its key
+template-kit check --all          # check every template in the workspace
+template-kit check --json         # machine-readable report (combine with any of the above)
+```
+
+Run it from the workspace root, or from inside a template's own folder — a bare `check`
+infers which template you mean. A workspace with more than one template must either name
+one or pass `--all`.
+
+### What it needs installed
+
+```bash
+npm i -D typescript eslint @typescript-eslint/parser esbuild
+```
+
+`check` runs **your** toolchain, not a copy of its own: it resolves TypeScript, ESLint
+and esbuild from your workspace, so the compiler that judges your types is the one you
+pinned, and a linter and a bundler never end up in the production install of a package
+whose job is to render sections. A missing one is reported by name, with the install
+line to fix it.
+
+## What it runs
+
+Two granularities, because a workspace has one `package.json` and one lockfile, but can
+hold many templates.
+
+**Six authoring stages**, run in order, once per selected template. None of them abort
+the run — a template with several unrelated problems reports all of them in one pass, not
+one class of fix at a time:
+
+1. **typecheck** — the workspace's own TypeScript compiles the template's files, judged
+   against the workspace's own `tsconfig.json`.
+2. **lint** — the workspace's own ESLint, running the kit's shipped preset over the
+   template's files. See [the ESLint preset](eslint.md) for the rules this stage shares
+   with your editor.
+3. **validate** — the schema, fill-spec, fixtures, and manifest contracts: every
+   cross-reference between a section's contract files, and a template's `manifest.json`
+   against the sections it composes.
+4. **tree** — the rules a one-file-at-a-time linter cannot express: a missing contract
+   file, a slot declared in `schema.ts` with no marker anywhere in the section's JSX, a
+   hand-written CSS file's own rules.
+5. **render** — a determinism probe (every fixture is rendered twice; the two outputs
+   must be byte-identical) and a scan of the rendered HTML for objective defects — a
+   stray `[object Object]`, a bare `null`/`undefined`/`NaN` leaf, a `src`-less `<img>` —
+   plus, for the `typical` fixture, that the editor's sidebar order matches the page's
+   real render order.
+6. **size** — every section's renderer bundle, compiled stylesheet, and largest island
+   (browser) bundle, gzipped, against a fixed byte budget; and its static assets
+   (svg/images/fonts), budgeted by raw bytes since they are already compressed.
+
+**The dependency gates** run once per invocation, never once per template — they are
+properties of the workspace's one lockfile and installed tree, not of any one template:
+a lockfile present and satisfying `package.json`, exactly one copy of React installed,
+no `npm audit` finding at high or critical severity, and every shipped dependency's
+license on an allowlist.
+
+A run that selects zero templates to check is itself a failure —
+[`no-templates`](rules/no-templates.md) — never a silent pass.
+
+## Output
+
+Human-readable output prints one line per template (`✓ <key>`, or `✗ <key> — N
+problem(s)` followed by each finding), then any workspace-level findings from the
+dependency gates, then `check passed` if everything passed.
+
+`--json` prints one report object instead, keyed per template so a single-template
+consumer (the registry, ingesting one submission) and an all-templates consumer (your
+own CI) parse the same shape:
+
+```ts
+{
+  ok: boolean,
+  kitVersion: string,
+  templates: {
+    [templateKey: string]: { ok: boolean, diagnostics: Diagnostic[] },
+  },
+  // Dependency-gate findings — evaluated once, not per template.
+  workspace: { ok: boolean, diagnostics: Diagnostic[] },
+}
+```
+
+Each `Diagnostic` carries a `ruleId` (`template-kit/<id>`), the `template` it belongs to,
+an optional `section` and `file`/`line`, a `message`, and a `fix`.
+
+## Exit code
+
+`0` iff every selected template and the workspace pass. `1` otherwise — including when
+the run itself can't proceed at all (an unknown template name, no `templates/` folder
+in the workspace).
+
+## Thresholds are not configurable
+
+Every byte budget, severity floor, and license allowlist `check` enforces is a platform
+acceptance criterion, not a per-workspace preference — there is no config file or flag
+that raises them. If a template has a legitimate reason to need an exception, ask the
+platform team; a workaround that quietly disables a gate will simply fail again at
+submission.
+
+## See also
+
+- [Rules](rules/INDEX.md) — every id `check` (and the lint preset) can print, one page
+  each, Rule / Reason / Fix.
+- [ESLint preset](eslint.md) — the one-file-at-a-time half of the same rule set, run
+  directly by your editor, not only through `check`.
+- [Dev](dev.md) — the other workspace command: preview sections in a browser as you
+  author, before running `check` as the acceptance gate.