@piercebarney/whs-eleventy 2026.9.3 → 2026.9.8

package/lib/compliance.js

@@ -664,16 +664,26 @@ const CHECKS = {
 
 // ---- standard-version drift -----------------------------------------
 
-// Every chapter slug the CHANGELOG records as changed after `pin`. `### core: a
-// · b · c` yields every slug on the line, not just the first; a
-// `### stacks/eleventy-netlify.md` heading yields the binding marker.
-function changelogSlugs(changelog, pin) {
-  const slugs = new Set();
-  let inRange = false;
+// Every CHANGELOG entry (`## <date> [breaking|non-breaking]`) dated after
+// `pin`, with the chapter slugs it touched. `### core: a · b · c` yields
+// every slug on the line, not just the first; a
+// `### stacks/eleventy-netlify.md` heading yields the binding marker. An
+// entry heading with no severity tag (a fixture, or a pre-2026-09-04
+// CHANGELOG snapshot) defaults to non-breaking — the real standard's own
+// CHANGELOG.md always carries the tag (bin/check's 6th check enforces it).
+function changelogEntries(changelog, pin) {
+  const entries = [];
+  let current = null;
   for (const line of (changelog || "").split("\n")) {
-    const dateM = line.match(/^##\s+([0-9]{4}-[0-9]{2}-[0-9]{2})/);
-    if (dateM) inRange = dateM[1] > pin;
-    if (!inRange) continue;
+    const dateM = line.match(
+      /^##\s+([0-9]{4}-[0-9]{2}-[0-9]{2}).*?(?:\[(breaking|non-breaking)\])?\s*$/,
+    );
+    if (dateM) {
+      current = dateM[1] > pin ? { severity: dateM[2] || "non-breaking", slugs: new Set() } : null;
+      if (current) entries.push(current);
+      continue;
+    }
+    if (!current) continue;
     const coreM = line.match(/^###\s+core:\s+(.+)/);
     if (coreM) {
       for (const part of coreM[1].split(/[·,]/)) {
@@ -687,15 +697,23 @@ function changelogSlugs(changelog, pin) {
           // not a literal slug named "all" — the registry has no such slug,
           // so emitting it as one would print a `MANUAL: re-check #all` row
           // that looks real but isn't.
-          slugs.add("(all core chapters)");
+          current.slugs.add("(all core chapters)");
           continue;
         }
         const slug = (cleaned.match(/^[a-z0-9-]+/) || [])[0];
-        if (slug) slugs.add(slug);
+        if (slug) current.slugs.add(slug);
       }
     }
-    if (/^###\s+stacks\/eleventy-netlify\.md/.test(line)) slugs.add("(eleventy binding)");
+    if (/^###\s+stacks\/eleventy-netlify\.md/.test(line)) current.slugs.add("(eleventy binding)");
   }
+  return entries.map((e) => ({ severity: e.severity, slugs: [...e.slugs] }));
+}
+
+// Every chapter slug the CHANGELOG records as changed after `pin`, flattened
+// (severity dropped) — kept for callers that only need the slug set.
+function changelogSlugs(changelog, pin) {
+  const slugs = new Set();
+  for (const e of changelogEntries(changelog, pin)) for (const s of e.slugs) slugs.add(s);
   return [...slugs];
 }
 
@@ -716,11 +734,22 @@ function versionDrift() {
   if (pin >= current) return { pin, current, rows: [] };
 
   const changelog = read("CHANGELOG.md", STANDARD) || "";
+  // Worst-case severity per slug: one breaking touch marks it breaking for
+  // good, even if a later (or earlier) entry touching the same slug since
+  // the pin was non-breaking.
+  const severityBySlug = new Map();
+  for (const entry of changelogEntries(changelog, pin)) {
+    for (const slug of entry.slugs) {
+      if (severityBySlug.get(slug) !== "breaking") severityBySlug.set(slug, entry.severity);
+    }
+  }
   return {
     pin,
     current,
-    rows: changelogSlugs(changelog, pin).map(
-      (s) => `MANUAL: re-check #${s} — changed since the pinned ${pin}`,
+    rows: [...severityBySlug.entries()].map(([slug, severity]) =>
+      severity === "breaking"
+        ? `BREAKING: re-check #${slug} — changed since the pinned ${pin}`
+        : `MANUAL: re-check #${slug} — changed since the pinned ${pin}`,
     ),
   };
 }
@@ -751,10 +780,11 @@ function runCompliance() {
 
 function summarize({ results, drift }) {
   const n = (s) => results.filter((r) => r.status === s).length;
+  const breakingDrift = drift.rows.filter((r) => r.startsWith("BREAKING:")).length;
   return {
     pass: n(PASS),
-    fail: n(FAIL),
-    manual: n(MANUAL) + drift.rows.length,
+    fail: n(FAIL) + breakingDrift,
+    manual: n(MANUAL) + (drift.rows.length - breakingDrift),
     na: n(NA),
   };
 }
@@ -793,7 +823,7 @@ function main() {
   writeCache({ ...payload, summary: s });
 
   if (strict && s.fail) {
-    console.error("compliance --strict: FAIL chapters present.");
+    console.error("compliance --strict: FAIL chapters or BREAKING standard-version drift present.");
     process.exit(1);
   }
 }
@@ -802,4 +832,4 @@ if (require.main === module) main();
 
 // CHECKS is exported for the "coverage" test — nothing else should read it as
 // data (call runCompliance() for results).
-module.exports = { runCompliance, summarize, changelogSlugs, CHECKS };
+module.exports = { runCompliance, summarize, changelogSlugs, changelogEntries, CHECKS };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@piercebarney/whs-eleventy",
-  "version": "2026.9.3",
+  "version": "2026.9.8",
   "description": "The web house style's Eleventy + Netlify tooling — the compliance sweep, the infra doctor, the link/CSP integrity check, and the a11y scan, shared by every project on the stack.",
   "bin": {
     "whs": "cli.js"
@@ -36,8 +36,8 @@
     "sirv": "^3.0.2"
   },
   "devDependencies": {
-    "@eslint/js": "^9.39.5",
-    "eslint": "^9.39.5",
+    "@eslint/js": "^10.0.1",
+    "eslint": "^10.9.1",
     "globals": "^17.11.0",
     "prettier": "^3.9.6"
   }

package/standard/CHANGELOG.md

@@ -6,9 +6,679 @@ at a glance. Stack-only changes list the file.
 
 Format: `## <date>` → `### core: <slug>` / `### <stack>` entries.
 
+**Severity.** Every `## <date>` heading also carries `[breaking]` or
+`[non-breaking]`. An entry is **breaking** if a project that was fully
+compliant *before* the change is no longer compliant *after* it — the change
+adds or tightens a requirement, removes a previously-sanctioned pattern, or
+corrects a documented mechanism that didn't actually work (so a project
+following the old doc has broken/non-compliant behavior it thought was fine).
+Everything else — wording fixes, doc corrections that don't change what's
+enforced, new *opt-in* chapters/capabilities, tooling-only changes — is
+**non-breaking**. `bin/check` fails if a heading is missing the tag.
+
+---
+
+## 2026-09-08 — content-ops: reservation becomes a real opt-in, not a hardcoded default [non-breaking]
+
+Found while building `/whs:build`'s Content stage agent, which needs to know
+whether a project's content is reserved before touching anything.
+`core.md#content-model`'s Ownership paragraph already documented the default
+correctly ("by default the party that builds the site may also edit its
+content") — but `templates/eleventy-netlify/` shipped `CONTENT.md` (declaring
+"reserved for: Cowork") unconditionally, with no way to opt out. Every
+project scaffolded from it started reserved regardless of whether that was
+true, contradicting the standard's own stated default.
+
+### core: content-model
+
+- New House-style field: `content-ops` (`in-repo` default | `reserved`).
+  Recorded as the sixth stack-selection question (`#adopting`). `CONTENT.md`
+  ships only when `reserved` is chosen; the voice guide ships either way —
+  clarified as not reservation-conditional (it was ambiguously grouped with
+  `CONTENT.md` before).
+
+### templates/eleventy-netlify
+
+- `bin/init` reads `content-ops` from the brief (default `in-repo`): deletes
+  `CONTENT.md` and `requests/` when not reserved, keeps them when it is.
+- `CLAUDE.md`'s Content section carries both branches of the reservation
+  paragraph behind a `<!-- content-ops:reserved -->` /
+  `<!-- content-ops:in-repo -->` marker pair — the same mechanism-marker
+  idiom `{ include: "…" }` already uses elsewhere — and `bin/init` resolves
+  to whichever branch applies, dropping the other.
+- Verified both branches end-to-end in a scratch copy: `content-ops: reserved`
+  keeps `CONTENT.md` + `requests/` and the reserved paragraph; the default
+  keeps neither and shows the in-repo paragraph instead.
+
+## 2026-09-04 — sveltekit-netlify's brand token layer, and a Pico gap that predates it [non-breaking]
+
+Third of the four functional gaps being closed ahead of the real project
+adopting this stack. Scoping this one surfaced a bigger, previously
+unnoticed gap: `AGENTS.md` and `stacks/sveltekit-netlify.md#styling` both
+already asserted "Pico classless" as this template's CSS default, but Pico
+was never actually installed, imported, or linked anywhere in the shipped
+code — the "unstyled" state `TEMPLATE.md` flagged wasn't Pico-with-no-brand-
+colors, it was no CSS framework at all. Fixing that was a real, if small,
+scope expansion beyond "just add brand.ts" — confirmed with the user before
+proceeding, on the grounds that the template's job is to satisfy
+`core.md#styling` on day one the same as every other chapter, and the fix
+doesn't foreclose Tailwind for the real project (still the documented
+per-project alternative at adoption time, unaffected by this).
+
+### templates/sveltekit-netlify
+
+- Added `@picocss/pico@2.1.1` (matching `templates/eleventy-netlify/`'s
+  pin) to `dependencies`.
+- New `src/lib/brand.ts`: the token source (colors, fonts, logo), the exact
+  field shape of `templates/eleventy-netlify/src/_data/brand.js`.
+- New `src/routes/pico.css/+server.ts`: serves Pico's classless jade build
+  self-hosted at `/pico.css`, re-exporting the npm package's CSS via Vite's
+  `?raw` import — no vendor-file copy step needed the way Eleventy's
+  passthrough-copy config requires.
+- New `src/routes/tokens.css/+server.ts`: generates the `--pico-*` remap
+  from `brand.ts`, mirroring `tokens.css.njk`'s logic. `app.html` links
+  `/pico.css` then `/tokens.css`.
+- **A real gotcha, found only by actually rendering a page:** load order
+  alone doesn't decide the cascade here. Pico 2.1.1's own light-mode block
+  is `:root:not([data-theme="dark"])`, which out-specifies a plain
+  `:root{}` override regardless of which stylesheet loads second — the
+  brand remap silently lost to Pico's stock teal-green palette until the
+  override's selector was changed to match Pico's specificity. Caught with
+  a real Playwright screenshot (installed for this session — the built
+  site had never been visually rendered before), not by reading the CSS.
+  `[data-theme="dark"]` and the `prefers-color-scheme: dark` media block
+  didn't have this problem — Pico's own selectors there are already the
+  same specificity as the override, so source order alone decides,
+  correctly. Verified both branches with real screenshots (light and
+  forced-dark) showing the brand magenta, not Pico's defaults.
+- Full `npm run check` gate passes.
+
+### stacks/sveltekit-netlify.md: styling, brand-source
+
+- `styling` now documents the shipped mechanism, including the specificity
+  gotcha above, so the next person touching this doesn't rediscover it the
+  hard way. `brand-source` now distinguishes the CSS consumer (built) from
+  the OG-card renderer and icon generator (still not built — `logo` sits in
+  `brand.ts` unused, waiting for either).
+
+### templates/sveltekit-netlify/TEMPLATE.md
+
+- The brand-layer "still owns" bullet replaced with a "replace the
+  placeholder palette" note, since the layer itself now exists.
+
+---
+
+## 2026-09-04 — sveltekit-netlify's canonical tag, wired [non-breaking]
+
+Second of the four functional gaps being closed ahead of the real project
+adopting this stack (see the permalink-shape entry, below, for the full
+context). `stacks/sveltekit-netlify.md#seo-urls` already named the exact
+mechanism — `SITE_URL` from `src/lib/site.ts`, never `$page.url.origin` — but
+no canonical tag actually shipped yet. This wires it.
+
+### templates/sveltekit-netlify
+
+- New `src/lib/components/Canonical.svelte`: reads `page.url.pathname` from
+  `$app/state` (the path only — never `.url.origin`, which is the
+  request/preview host, not necessarily production) and `SITE_URL` from
+  `src/lib/site.ts`, emitting `<link rel="canonical" href={SITE_URL +
+  pathname}>` from its own `<svelte:head>`.
+- Mounted once in the root `+layout.svelte` — Svelte merges `<svelte:head>`
+  blocks from anywhere in the component tree, so every route gets a
+  canonical tag without a per-page component instance.
+- Verified with a real build: every page's canonical trailing slash matches
+  its own permalink exactly — home (`https://example.com/`), a static route
+  (`.../about/`), the guides index, a guide detail page, and the audit page
+  all checked directly in the built HTML. Full `npm run check` gate passes.
+
+### stacks/sveltekit-netlify.md: seo-urls, seo-meta, noindex
+
+- `seo-urls`'s "not yet wired" note replaced with the actual mechanism and
+  verification. `seo-meta` now distinguishes the canonical tag (shared
+  component, shipped) from the still-deferred full OG/Twitter `<Seo>`
+  component (needs per-page `load` data, a bigger job — unchanged scope).
+  `noindex`'s Layer 3 note updated from "not yet wired" to a pointer at
+  `seo-urls`.
+
+---
+
+## 2026-09-04 — sveltekit-netlify: fixes from an independent code review [non-breaking]
+
+The four functional-gap fixes above were self-verified (real builds, real
+screenshots) but not independently reviewed before landing. An `/code-review
+high` pass across the full diff, run afterward, surfaced one real regression
+and several smaller gaps the self-verification didn't check for. All fixed
+and re-verified against real builds/tests, not just read over.
+
+### netlify.toml
+
+- **The regression.** The permalink-shape fix's `trailingSlash: 'always'`
+  moved the audit page's served/canonical URL to `/audit/`, but the
+  `X-Robots-Tag: noindex` header rule still targeted the bare `/audit` path.
+  Netlify's `for` header-path matching is exact-string outside an explicit
+  wildcard (confirmed against Netlify's own docs) — the rule silently
+  stopped matching the page it was written for. The in-HTML `<meta
+  robots>` tag still fired, so this wasn't a total exposure, but a
+  documented defense-in-depth layer quietly broke as an unaddressed side
+  effect of an unrelated change. Fixed with two explicit `[[headers]]`
+  rules (`/audit` and `/audit/`) rather than a wildcard.
+
+### templates/sveltekit-netlify
+
+- `.claude/hooks/og-guard.sh`: the rebuild's exit code was discarded (`||
+  true`, inherited verbatim from `templates/eleventy-netlify/`'s own hook,
+  which has the same bug) and the hook printed "rebuilt" unconditionally.
+  Fixed to print a different message on failure, naming the output files as
+  possibly stale rather than asserting they're current — verified by
+  actually breaking `brand.ts` and running the hook, not just reading the
+  diff.
+- `src/lib/components/Canonical.svelte`: now wraps `page.url.pathname` in
+  `withTrailingSlash()` like every other internal href in this pass,
+  instead of trusting it already normalized — covers an error/404 render or
+  a future route opting out of the layout's `trailingSlash`.
+  `withTrailingSlash()`'s parameter type loosened from `ResolvedPathname` to
+  plain `string` so it accepts a raw pathname too; its return type stays
+  `ResolvedPathname` so the two existing `<a href>` call sites still satisfy
+  `eslint-plugin-svelte`'s navigation rule (a `<link rel="canonical">` was
+  never a target of that rule regardless).
+- `src/lib/site.test.ts` (new): unit tests for `withTrailingSlash()` — pure,
+  trivially testable logic that shipped with none, despite vitest already
+  being wired into this template's gate and a direct precedent
+  (`content/validate.test.ts`) for testing exactly this kind of logic.
+- `src/lib/staticRoutes.ts` (new, moved out of `sitemap.xml/+server.ts`) and
+  `src/lib/tokensCss.ts` (new, moved out of `tokens.css/+server.ts`): both
+  were flagged as hand-synced/duplicated logic with no drift check.
+  Factoring them out of their `+server.ts` files was **required**, not just
+  tidiness — SvelteKit restricts `+server.ts` exports to a fixed list
+  (`GET`, `prerender`, etc.) and rejects any other named export at build
+  time, caught only by actually running `vite build` after first trying to
+  export them inline. `staticRoutes.test.ts` checks `STATIC_ROUTES` against
+  the real `+page.svelte` route tree; `tokensCss.test.ts` checks the
+  generated CSS's light-mode selector against the *installed*
+  `@picocss/pico` package's own CSS, so a future Pico version bump that
+  changes that selector fails a test instead of silently losing the cascade
+  again (the exact bug the permalink-shape entry above found and fixed by
+  hand). `tokens.css/+server.ts`'s dark-mode block, previously written out
+  twice (once for `[data-theme="dark"]`, once for `prefers-color-scheme`),
+  is now built once and reused by both.
+- `src/lib/brand.ts`: `color.muted` had zero consumers anywhere in this
+  template (unlike Eleventy's, where it feeds the OG card's subtitle — this
+  template's simpler single-line card has none) and, unlike `logo`, carried
+  no comment saying so. Commented as intentionally unused rather than left
+  to look like dead code.
+
+### templates/eleventy-netlify/src/tokens.css.njk
+
+- Added a comment cross-referencing `templates/sveltekit-netlify/src/lib/
+  tokensCss.ts` as the same mechanism for that stack, stating explicitly
+  that the two `--pico-*` remap blocks must be kept in sync by hand (not
+  factored into a shared module — the two templates don't share a runtime).
+  Verified `templates/verify.sh`'s eleventy-netlify branch still passes
+  (28 pass · 0 fail · 5 manual · 6 n/a) after this comment-only change.
+
+### stacks/sveltekit-netlify.md: seo-urls, brand-source, audit-page, generated-asset-freshness
+
+- Updated to describe the fixes above and their verification.
+  `brand-source` also had a stale paragraph from before the og-image entry
+  above — still said the OG-card renderer was "not yet built" after it had
+  been; corrected in the same pass since it was found while touching this
+  section anyway.
+
+Last of the four functional gaps closed ahead of the real project adopting
+this stack. `og-image`'s own note already named the front-runner mechanism
+(a prerendered `+server.ts` route, `satori` + `@resvg/resvg-js`) without
+committing to it; this takes it, and the same trick already proven for
+`tokens.css` (item 3) turns out to solve
+`core.md#generated-asset-freshness`'s tier 1 for free — a genuinely better
+answer than Eleventy's `eleventy.after` hook, not merely an adequate
+substitute for it, since there's no persisted file that can go stale between
+builds at all.
+
+### templates/sveltekit-netlify
+
+- Added `satori@0.33.4`, `@resvg/resvg-js@2.6.2`, `@fontsource/inter@5.3.0`
+  (same versions as `templates/eleventy-netlify/scripts/og.js`) to
+  `dependencies`.
+- New `src/routes/og/default.png/+server.ts`: renders the site-wide default
+  1200×630 OG card from `src/lib/brand.ts` (a primary-color bar + the site
+  name, Inter regardless of the live site's font — an OG card is a designed
+  asset). Deleted `static/og/default.png`, the hand-placed file this route
+  now replaces at the same path.
+- **Scope check, not scope creep:** no page emits an `og:image` meta tag
+  anywhere in this template yet (that's `seo-meta`'s separately-deferred
+  full OG/Twitter table). So this generates the one site-wide default only,
+  not per-page cards — building those now would be output nothing
+  references. Flagged explicitly in `TEMPLATE.md` and `stacks/
+  sveltekit-netlify.md#og-image` so it isn't mistaken for full OG support.
+- Verified beyond a successful build: `build/og/default.png` is a real
+  1200×630 8-bit PNG, ~10 KB (well under the ~1 MB ceiling), and was
+  actually viewed (Playwright's Chromium, installed last session, made this
+  possible) to confirm the brand color and text render correctly, not just
+  that `satori`/`resvg` didn't throw.
+- `core.md#generated-asset-freshness`, all three tiers: (1) the build step —
+  free, as above; (2) `.claude/hooks/og-guard.sh` + `.claude/settings.json`,
+  the same `PostToolUse` pattern as `templates/eleventy-netlify/`'s
+  `og-guard.sh`, watching `brand.ts` and both generator `+server.ts` files,
+  rebuilding, and pointing the operator at the two output files directly
+  (this stack's audit page has no OG-gallery tab yet) — tested directly with
+  matching and non-matching `tool_input.file_path` values, not just read
+  over; (3) a new "Generated visual assets" paragraph in `AGENTS.md` (this
+  stack's actual instructions file — see below).
+- Full `npm run check` gate passes.
+
+### stacks/sveltekit-netlify.md: og-image, generated-asset-freshness, where-sveltekit-fights-the-grain
+
+- `og-image` and `generated-asset-freshness` now describe what's built and
+  what verified it, including the explicit per-page-cards non-scope.
+  `where-sveltekit-fights-the-grain`#5 retitled from "still deferred" to
+  "resolved differently" — the `+server.ts` route isn't a lesser substitute
+  for `eleventy.after`, it has no staleness window at all, which Eleventy's
+  own mechanism can't claim.
+
+### templates/sveltekit-netlify/TEMPLATE.md
+
+- The "No OG-image generation" bullet replaced with what's actually built
+  and what's still missing (per-page cards, the meta tag). Noted `AGENTS.md`
+  uses this stack's real instructions filename, not `CLAUDE.md` — a
+  pre-existing naming difference from `templates/eleventy-netlify/`, not
+  something this change introduced or is fixing.
+
+---
+
+## 2026-09-04 — sveltekit-netlify's permalink shape, actually resolved [non-breaking]
+
+A real project is about to adopt `templates/sveltekit-netlify/` (closing the
+"deliberately deferred" item in `TODO.md`), which turns the binding's four
+self-documented gaps from theoretical to load-bearing. First of four: the
+permalink shape. `stacks/sveltekit-netlify.md#seo-urls` had already found and
+recorded that the naive fix — `trailingSlash: 'always'` alone — trades one
+gap for a subtler one, since `resolve()` and a hand-built `sitemap.xml` don't
+pick the setting up on their own. This closes it for real, verified against
+an actual build's output files, rendered `href`s, and `sitemap.xml` content,
+not just an exit code.
+
+### templates/sveltekit-netlify
+
+- `src/routes/+layout.ts`: added `export const trailingSlash = 'always';`.
+- `src/lib/site.ts`: added `withTrailingSlash()`, typed `(path:
+  ResolvedPathname) => ResolvedPathname` rather than `string` — plain
+  `string` would make `eslint-plugin-svelte`'s
+  `svelte/no-navigation-without-resolve` rule stop recognizing the wrapped
+  `resolve()` call as safe, since that rule accepts an expression either by
+  syntax (a literal `resolve()` call) or by matching `$app/types`'s
+  `ResolvedPathname` type structurally — a generic wrapper satisfies neither
+  unless typed this way.
+- `src/routes/guides/+page.svelte` and `guides/[slug]/+page.svelte`: every
+  `<a href>` built from `resolve('/guides/[slug]', { slug })` now wraps it in
+  `withTrailingSlash(...)`.
+- `src/routes/sitemap.xml/+server.ts`: the static route list and guide-slug
+  URLs are plain literals under our control (not `resolve()` output), so
+  they're simply written with the trailing slash already baked in, rather
+  than routed through the same helper.
+- Verified with a real `npm run build`: `build/about/index.html` (not
+  `about.html`); guide-list and guide-detail pages' rendered `href`s end in
+  `/`; `sitemap.xml`'s 8 entries (5 static + 3 guides) all end in `/`. Full
+  `npm run check` gate passes.
+
+### stacks/sveltekit-netlify.md: seo-urls
+
+- The permalink-shape note updated from "a real gap, not yet resolved" to
+  "resolved," describing the actual fix and the `ResolvedPathname`-typing
+  wrinkle the lint rule forced.
+
 ---
 
-## 2026-09-03 — the content-arm interface: a project and its coding arm
+## 2026-09-04 — the standalone-page shape divergence, accepted and documented [non-breaking]
+
+Triages `feedback/2026-09-03-pages-model-diverges-across-stacks.md`
+(deleted, per this file's own triage convention). The note found that
+"standalone pages are data" is implemented three different ways across the
+templates — `eleventy-netlify`'s `pages.json` (an array, structured `body`
+sections, `{ include }` markers, layout blocks), `sveltekit-netlify`'s (an
+object keyed by page name, a flat `body: string[]`), `phoenix`'s (no
+`pages.json` at all — markdown or a reviewed component) — and asked for a
+decision: converge on one shape, or document the difference. The note's own
+read was right: convergence "wants a second real adopting project on a
+non-eleventy stack to justify the work" (`TODO.md`'s already-recorded
+decision not to invest further in Phoenix/SvelteKit until one exists says
+the same thing), so this takes the documented-divergence option.
+
+### core: content-model
+
+- New Spec: the standalone-page entry shape is a per-stack choice, named by
+  each stack's own impl doc (and, where one ships, the project's own
+  `CONTENT.md` "entry shape" section — the one an editing session actually
+  needs, read fresh each session rather than assumed from another project).
+
+### stacks/sveltekit-netlify.md: content-model
+
+- A real, previously-undocumented gap fixed while here: this section named
+  the files (`{guides,pages}.json` + zod) but never their field shape,
+  unlike the Eleventy and Phoenix bindings, which both already document
+  theirs. Added, verified against the real `*.schema.ts` files: `guides.json`
+  mirrors `eleventy-netlify`'s field set structurally; `pages.json` is
+  genuinely simpler (an object keyed by page name, a flat `body: string[]`,
+  no markers or blocks) — not just smaller, a different shape, and now
+  stated as a deliberate one.
+
+### templates/sveltekit-netlify/CONTENT.md
+
+- Gains "The entry shape — `guides.json`" / "`pages.json`" sections mirroring
+  `templates/eleventy-netlify/CONTENT.md`'s existing pattern — previously
+  named the content set files with no field-level reference at all, so an
+  editorial agent had nothing to read for this stack's shape short of the
+  binding doc (which the editorial-project instruction doesn't point it at —
+  `CONTENT.md` is the one per-session read).
+
+## 2026-09-04 — Q1's SvelteKit criterion stops being circular [non-breaking]
+
+Flagged in a review of the stack-selection guidance (`TODO.md`, prompted by
+`PROJECT-OVERVIEW.md`'s planning conversation): Q1 told an adopter to pick
+`sveltekit-netlify` "when a project specifically needs Svelte components"
+without ever saying what would make that true, so it gave no real signal
+against the default. Meanwhile `stacks/sveltekit-netlify.md`'s own
+`where-sveltekit-fights-the-grain` #2 had already found, and buried, the
+actual answer: SvelteKit hydrates every page by default, so picking it ships
+the framework runtime site-wide, not only on the interactive page — a real
+cost `core.md#client-logic`'s pure-function-plus-wiring pattern avoids
+entirely for the common case (one calculator, one widget). Phoenix's
+criterion ("a database or server-side state is in scope") was already crisp
+by comparison — only the SvelteKit clause needed the fix. No project's
+existing stack choice is invalidated — this sharpens guidance for a *future*
+choice, it doesn't reopen a past one.
+
+### core: adopting
+
+- Q1's SvelteKit clause restated around the real trigger (several
+  interactive pieces genuinely sharing state, not one calculation) plus the
+  hydration-cost tradeoff, with a pointer to
+  `stacks/sveltekit-netlify.md#where-sveltekit-fights-the-grain` #2. Phoenix's
+  and the "other" bucket's wording untouched — re-read, no knock-on issue
+  found. All three stacks' own mirrored `adopting` sections re-read too
+  (none restate Q1's selection criteria — nothing to change there).
+
+### README.md
+
+- Q1's framework-question mirror gets the same tightened SvelteKit clause,
+  condensed to match this doc's shorter style.
+
+## 2026-09-04 — the standard-version drift row is severity-tagged [breaking]
+
+The other half of the severity-signal work (`TODO.md` #1 depended on this, not
+just the tag itself): the `#compliance` drift row now distinguishes
+`BREAKING` from `MANUAL` per slug, using each changed CHANGELOG entry's own
+tag, so `whs compliance --strict` actually gates on being behind on a
+breaking change rather than treating every changed slug — a typo fix and a
+broken-mechanism correction alike — as the same easy-to-miss `MANUAL` note.
+This is the concrete fix for the gap `TODO.md` #1's evidence section
+documented: `everydaymoneycalc` being 8 entries behind (several of them
+breaking, per the backfill above) produced no signal beyond a note buried in
+a `MANUAL` list.
+
+### core: compliance
+
+- `#compliance`'s drift-row Spec: a slug from a `breaking` CHANGELOG entry
+  now emits `BREAKING: re-check #<slug>` and folds into the fail count
+  (gates `--strict`); a `non-breaking` one still emits the softer
+  `MANUAL: re-check #<slug>`. A slug touched by more than one entry since the
+  pin takes the worst severity seen.
+
+### stacks/eleventy-netlify.md
+
+- `packages/whs-eleventy/lib/compliance.js`'s `versionDrift()` reads each
+  entry's `[breaking]`/`[non-breaking]` tag via a new `changelogEntries()`
+  (`changelogSlugs()` kept, now a flattened view over it, for backward
+  compatibility) and emits the tagged row; `summarize()` folds `BREAKING`
+  rows into the fail count, `main()`'s `--strict` message updated to match.
+  `src/audit.njk`'s drift list bolds `BREAKING` rows. Verified end to end:
+  rolled `templates/eleventy-netlify/`'s pin back to `2026-08-27` and
+  confirmed `whs compliance` printed exactly 8 `BREAKING` + 8 `MANUAL` rows
+  matching the backfilled tags (`28 pass · 8 fail · 13 manual · 6 n/a` — 0
+  real chapter `FAIL`s, all 8 from drift), the built `/audit/` page bolding
+  only the `BREAKING` `<li>`s, then restored the pin. `npm run
+  check`/`compliance` re-verified clean afterward. 5 new tests added to
+  `packages/whs-eleventy/test/compliance.test.js` (54 total, all green).
+
+### stacks/phoenix.md
+
+- The still-unshipped `#compliance` design doc's drift-row description
+  updated to match — the same `BREAKING`/`MANUAL` split, once built, per
+  `versionDrift()`, "the pattern to port."
+
+## 2026-09-04 — a severity signal on CHANGELOG entries [non-breaking]
+
+Flagged in a planning conversation (`PROJECT-OVERVIEW.md`): entries were dated
+but not marked as breaking vs. non-breaking, so a project couldn't tell from
+the log alone whether it was safe to ignore an update or urgently behind — and
+without that signal, an eventual upgrade path for already-adopted projects
+(tracked in `TODO.md`) would have nothing to prioritize on. Every `## <date>`
+heading, past and present, now carries `[breaking]` or `[non-breaking]`, per
+the rule stated in this file's own header note. Not a `core.md`/`stacks/*.md`
+content change — process/tooling only, no version bump (same precedent as the
+2026-08-30 "the standard is a git repo" entry).
+
+### tooling
+
+- `bin/check` gains a sixth check: every `## <date>` CHANGELOG heading must
+  carry a severity tag. `CLAUDE.md` and `README.md`'s Consistency checks
+  section updated to match (six checks; `templates/verify.sh` is now the
+  *seventh*, not sixth).
+
+### CHANGELOG.md
+
+- All 20 existing entries backfilled with a severity tag, judged against the
+  rule stated in the new header note (breaking = a previously-compliant
+  project is no longer compliant after the change).
+
+## 2026-09-04 — name the deploy hand-off in the content-ops protocol [breaking]
+
+The content-arm interface (2026-09-03, below) defined how an LLM agent (Cowork)
+edits reserved content, but left the last step implicit: the agent commits to
+`main` and cannot deploy, and the only cue to the operator was "if it's
+time-sensitive, say so in the commit message" — passive, no addressee. A real
+adopter workflow (Cowork owning content post-launch) surfaced the gap. The
+deploy boundary is unchanged — a person still runs the press — but the signal is
+now named: a `DEPLOY:` line closing the agent's reply, and `[deploy by <date>]`
+in the `content:` subject when there's a deadline.
+
+### core: content-model
+
+- The LLM-agent content-ops protocol gains a fifth element: the agent does not
+  deploy — it commits a finished change to the default branch and hands it to
+  the human deploy cadence (`#ci-cd`) with a session-closing report, deadline in
+  the commit subject. `#adopting`'s "Editorial operation" stable instruction
+  reworded to match ("never deploy — handed off, not shipped").
+
+### stacks/eleventy-netlify.md: content-model
+
+- New **Deploy hand-off** bullet: the `DEPLOY: awaiting …` / `DEPLOY: by <date>
+  …` closing line, the `[deploy by <date>]` commit-subject tag for the
+  operator's `git log <last-deploy>..main` batch review, and the two deploy
+  doorways (`deploy.yml` Run workflow / `npm run deploy`) — nothing in the
+  pre-flight or tooling changes.
+- The representative `#compliance` `content-model` row in the mechanical-checks
+  table now spells out the protocol-presence note (`CONTENT.md`,
+  `content-check`, `requests/`) the sweep already emits — the row had listed
+  only the data + schema + validator half.
+- `stacks/phoenix.md` and `stacks/sveltekit-netlify.md` content-model sections
+  and the three template `CONTENT.md`s (+
+  `templates/eleventy-netlify/CLAUDE.md`) mirror the hand-off wording.
+
+## 2026-09-04 — the SvelteKit binding renamed to sveltekit-netlify, honestly scoped [non-breaking]
+
+Caught in conversation, not tooling: `stacks/sveltekit.md` / `templates/sveltekit/`
+were named as if this were a general-purpose SvelteKit binding, when its actual
+origin and entire scope is narrower — it exists specifically to answer "Svelte,
+static, on Netlify," because plain Svelte has no durable static-site tooling of
+its own. The naming didn't say so, and that's an inconsistency the repo's own
+implicit rule already flags: a binding scoped to exactly one host with no
+alternative documented (`eleventy-netlify` is the model) gets the host in its
+name; a binding documenting multiple real hosts (`phoenix` — Render default,
+Gigalixir/Fly as the graduate path) correctly doesn't. `sveltekit` documented
+only Netlify, so by that same rule it should have carried the host in its name
+too — it didn't, and nothing explained why not.
+
+### stacks/sveltekit-netlify.md (renamed from stacks/sveltekit.md)
+
+- Retitled **SvelteKit + Netlify**. The intro now states the binding's real
+  origin up front — "why SvelteKit, if the actual need is just Svelte, static,
+  on Netlify" — rather than reading as a general SvelteKit offering that
+  happens to default to Netlify. A project that needs SvelteKit's actual
+  server capabilities (real SSR, live `+server.ts` endpoints, a database) is
+  explicitly called out as a different, larger binding this repo does not
+  have — not something this doc quietly under-scopes.
+- Section-header labels (`How (SvelteKit)`, `Adopting this standard
+  (SvelteKit)`, etc.) deliberately keep the framework-only wording, matching
+  `stacks/eleventy-netlify.md`'s own convention of naming the binding
+  file/directory with the host but labeling in-body sections by framework
+  alone.
+
+### templates/sveltekit-netlify (renamed from templates/sveltekit)
+
+- Directory, all internal doc cross-references (`AGENTS.md`, `README.md`,
+  `TEMPLATE.md`), and the CI job (`templates-sveltekit-netlify`) renamed to
+  match. `AGENTS.md`'s `framework:` data-block value now reads
+  `sveltekit-netlify`. Along the way, fixed a real, unrelated inaccuracy found
+  in the same file: `TEMPLATE.md` told an adopter to rename `whs_sveltekit` in
+  `package.json` — the actual placeholder there is `__PKG_NAME__`
+  (`whs_sveltekit` was a leftover copy-paste from the Phoenix template's
+  equivalent instruction, which is accurate for Phoenix's real OTP app name
+  but was never true here).
+
+### core: adopting
+
+- Q1's framework list: `SvelteKit` → `SvelteKit + Netlify`, with the same
+  origin-story framing as the doc's own intro — a project with no Svelte
+  requirement should still default to Eleventy + Netlify; a project that
+  needs SvelteKit's server features has no binding here yet (falls to
+  "other").
+
+### tooling
+
+- `index.json`'s `sveltekit` key → `sveltekit-netlify` (file, template path,
+  and summary all updated to state the narrower scope explicitly).
+  `README.md`'s doc-map table, framework-question wording, and
+  `templates/verify.sh` description updated to match.
+  `templates/concept-brief.md`'s `framework:` comment and the one open
+  `feedback/` report referencing the old name updated for accuracy while
+  still open.
+
+---
+
+## 2026-09-03 — a self-audit: gate/gitignore/doc gaps found by external review [non-breaking]
+
+A skeptical outside audit of the standard's own repo (docs, templates, CI,
+tooling) turned up a cluster of small-but-real defects — none a contract
+violation, all either a check that couldn't catch its own failure mode, a
+tooling side-effect leaking outside its own project, or a doc claim that had
+drifted from what the repo actually contains. Fixed together as one pass;
+see `git log` for the individual verification each one got (cold installs,
+mutation tests, real builds, fetched external docs).
+
+### core: adopting
+
+- **Stale template-count claim.** The stack-selection flow's "Starting
+  point" paragraph said "Only `eleventy-netlify` has a template today; the
+  others follow the checklist" — both `templates/phoenix/` and
+  `templates/sveltekit/` have existed (with real, passing gates) since
+  2026-09-02. Corrected to point at `index.json`'s `active`/`draft` status
+  instead of a hardcoded, now-wrong count. Re-read each `stacks/*.md`
+  mirrored `adopting` section — all three already stated their own template's
+  real status correctly; only this file's flow-level prose had drifted.
+
+### bin/check
+
+- **Check #5 (version strings agree) couldn't detect a missing pin** — it
+  compared only the *distinct values* found, so a file missing its
+  `standard-version:`/`**Version:**` line entirely just vanished from the
+  comparison instead of failing it (confirmed: deleting
+  `templates/sveltekit/AGENTS.md`'s pin left the check green). Now checks
+  pin *presence* per expected file first, and names the file if one is
+  missing.
+
+### templates/phoenix
+
+- **The `git_hooks` monorepo guard was incomplete.** `config/dev.exs`
+  guarded the `hooks:` config behind `File.dir?(".git")` so the template
+  wouldn't install hooks into the standard's own repo when compiled in
+  place — but `git_hooks`'s `auto_install` (default `true`) runs before that
+  config is ever consulted, and unconditionally writes a `git_hooks.db`
+  marker into whatever `.git/hooks` it finds via `git rev-parse
+  --show-toplevel`. Confirmed landing in the standard's own `.git/hooks/`
+  a second time, guard already in place. Fixed with an explicit
+  `auto_install: false` in the guard's `else` branch — verified with a full
+  `rm -rf _build deps && mix deps.get && mix compile`, the exact sequence
+  that reproduced the bug, no longer touching the main checkout.
+
+### repo-hygiene (root .gitignore)
+
+- Added `erl_crash.dump` — the root `.gitignore` covered only Node/JS build
+  output; a BEAM crash dump landing at the repo root (any `mix` command run
+  from there, not inside `templates/phoenix/`) was untracked and therefore
+  invisible to `bin/check`'s `git grep`-based sterility scan despite
+  containing a personal filesystem path. `templates/phoenix/.gitignore`
+  already covered its own case; this was the repo-root gap.
+
+### stacks/sveltekit.md, templates/*/netlify.toml
+
+- Corrected the stated root cause of `#noindex` layer 2 not applying: the
+  doc said per-context header scoping "needs th[e] build pipeline to run"
+  (implying it would work if Netlify's build system did run) — Netlify's
+  docs are explicit that `[[headers]]` is never context-aware on *any*
+  deploy path; the pre-built-artifact deploy model is a second, independent
+  reason the documented workaround doesn't apply here, not the cause of the
+  first problem. `stacks/eleventy-netlify.md` and both templates'
+  `netlify.toml` already stated this correctly; only this file's prose had
+  drifted. Also dropped an unverifiable direct quotation of Netlify's docs
+  (substance was correct, exact wording wasn't confirmed) from this file and
+  `templates/eleventy-netlify/netlify.toml`.
+- Corrected two "previously-undocumented" claims (the `vite.config.ts`
+  config-consolidation and `resolve()` from `$app/paths`) — both are real,
+  and both are documented on svelte.dev; what was actually true is that this
+  binding hadn't previously accounted for them.
+- Documented a real, previously-unstated gap: the template's flat
+  `about.html`-shaped build output doesn't meet `core.md#adopting`'s
+  directory-style-permalink item. Tried the one-line fix
+  (`trailingSlash = 'always'`) and verified in a real build that it's not
+  sufficient alone — `resolve()` from `$app/paths` doesn't append the
+  trailing slash to match, nor does the hand-built sitemap route list, so it
+  trades one gap for a file-layout/link/sitemap mismatch. Left unfixed,
+  documented precisely instead.
+
+### stacks/phoenix.md
+
+- Tightened Render free-Postgres wording: "deleted 30 days after creation"
+  → "expires 30 days after creation" (inaccessible immediately, permanently
+  deleted after a further 14-day grace period) — matches Render's own docs.
+
+### .github/workflows/standard.yml
+
+- Added a comment at the `templates` job's matrix declaration explaining
+  that the `[eleventy-netlify]` list is manually curated (not discovered
+  from `templates/*/` the way `templates/verify.sh` is) and when a new
+  template should be added to it — the file's top-of-file comment already
+  explained this design, but not at the point someone would actually edit.
+
+### templates/new-project.sh
+
+- The no-`bin/init`-yet branch's own comment said "fail loudly" but the
+  script exited 0 regardless — nothing after the `echo` produced a non-zero
+  status. Added the missing `exit 1`; verified against `sveltekit` (no
+  `bin/init` yet) going from exit 0 to exit 1, `eleventy-netlify`'s
+  (`bin/init`-having) path unaffected.
+
+### packages/whs-eleventy, templates/eleventy-netlify
+
+- Bumped `eslint`/`@eslint/js` off the EOL `9.39.5` pin (`npm warn
+  deprecated eslint@9.39.5: This version is no longer supported`) to
+  `10.9.1`/`10.0.1` in both — `templates/sveltekit/` was already on the
+  current major. Verified with a cold `rm -rf node_modules package-lock.json
+  && npm install` plus the full gate for each: `whs-eleventy`'s `npm run
+  check` (49 tests), `eleventy-netlify`'s `npm run check` (lint → validate →
+  test → build → links → a11y), both green, no deprecation warning on
+  install.
+
+## 2026-09-03 — the content-arm interface: a project and its coding arm [breaking]
 
 A project built to the house style is often only part of a larger operation —
 an editor-in-chief (a Claude Project, ideation + editorial context) that hands
@@ -133,7 +803,7 @@ for the common small-site case); a **`schedule` trigger** on the deploy workflow
   sveltekit flat `string[]`, phoenix none) — converge or document the split, at
   triage.
 
-## 2026-09-02 — a starter template for the SvelteKit binding, moved out of parked
+## 2026-09-02 — a starter template for the SvelteKit binding, moved out of parked [non-breaking]
 
 `stacks/sveltekit.md` was a parked stub — every mirrored section's "How
 (SvelteKit)" was `TODO`, not offered by the `#adopting` flow. A real need
@@ -255,7 +925,7 @@ and real `vite build` output, not written from the binding's prose alone.
 
 ---
 
-## 2026-09-02 — Render as the Phoenix binding's default free-launch host
+## 2026-09-02 — Render as the Phoenix binding's default free-launch host [non-breaking]
 
 Netlify can't run this stack at all — LiveView needs a persistent BEAM node
 (long-lived WebSocket connections, a warm Postgres pool), not a static
@@ -330,7 +1000,7 @@ isn't trustworthy here.
 
 ---
 
-## 2026-09-02 — a starter template for the Phoenix binding, and hardening the doc it's built from
+## 2026-09-02 — a starter template for the Phoenix binding, and hardening the doc it's built from [breaking]
 
 Built `templates/phoenix/` the same way `templates/eleventy-netlify/` was
 proven out: generic placeholder content, independent of any real business,
@@ -465,7 +1135,7 @@ fabricated or imprecise APIs the same way the earlier `Plug.CSP` finding did.
 
 ---
 
-## 2026-09-02 — closing the gap between the compliance grid and the Contracts it checks
+## 2026-09-02 — closing the gap between the compliance grid and the Contracts it checks [non-breaking]
 
 A pass through every chapter's actual enforcement, prompted by an outside
 evaluation that traced specific checks to specific failure modes they
@@ -624,7 +1294,7 @@ consistency defects the same pass turned up.
 
 ---
 
-## 2026-09-01 — the shared tooling package (#compliance mechanism, eleventy)
+## 2026-09-01 — the shared tooling package (#compliance mechanism, eleventy) [non-breaking]
 
 ### stacks/eleventy-netlify.md
 
@@ -662,7 +1332,7 @@ consistency defects the same pass turned up.
 
 ---
 
-## 2026-08-31 — the Cowork ↔ Claude Code loop: concept brief + content ops (#content-model)
+## 2026-08-31 — the Cowork ↔ Claude Code loop: concept brief + content ops (#content-model) [breaking]
 
 ### core: adopting
 
@@ -741,7 +1411,7 @@ consistency defects the same pass turned up.
 
 ---
 
-## 2026-08-30 — a copy-and-modify template for Eleventy + Netlify (#adopting)
+## 2026-08-30 — a copy-and-modify template for Eleventy + Netlify (#adopting) [non-breaking]
 
 ### templates/eleventy-netlify (new)
 
@@ -838,7 +1508,7 @@ consistency defects the same pass turned up.
 
 ---
 
-## 2026-08-30 — the standard is a git repo
+## 2026-08-30 — the standard is a git repo [non-breaking]
 
 ### repo
 
@@ -854,7 +1524,7 @@ consistency defects the same pass turned up.
 
 ---
 
-## 2026-08-29 — AI & agent capabilities, opt-in (#llm-integration, #agent-artifacts, #usage-metering)
+## 2026-08-29 — AI & agent capabilities, opt-in (#llm-integration, #agent-artifacts, #usage-metering) [non-breaking]
 
 ### core: llm-integration · agent-artifacts · usage-metering (new chapters)
 
@@ -935,7 +1605,7 @@ consistency defects the same pass turned up.
 
 ---
 
-## 2026-08-28 — codebase-vs-standard conformance (#compliance)
+## 2026-08-28 — codebase-vs-standard conformance (#compliance) [non-breaking]
 
 ### core: compliance (new chapter)
 
@@ -992,7 +1662,7 @@ consistency defects the same pass turned up.
 
 ---
 
-## 2026-08-28 — the `CLAUDE.md` House-style directive
+## 2026-08-28 — the `CLAUDE.md` House-style directive [breaking]
 
 ### core: adopting
 
@@ -1015,7 +1685,7 @@ consistency defects the same pass turned up.
 
 ---
 
-## 2026-08-28 — display advertising (AdSense)
+## 2026-08-28 — display advertising (AdSense) [non-breaking]
 
 ### core: ads (new chapter)
 
@@ -1066,7 +1736,7 @@ consistency defects the same pass turned up.
 
 ---
 
-## 2026-08-28 — hardening from the first full Eleventy migration
+## 2026-08-28 — hardening from the first full Eleventy migration [breaking]
 
 Fixes and gaps surfaced running the first full Eleventy migration end to end.
 
@@ -1117,7 +1787,7 @@ Fixes and gaps surfaced running the first full Eleventy migration end to end.
 
 ---
 
-## 2026-08-28 — solo is the default working mode
+## 2026-08-28 — solo is the default working mode [non-breaking]
 
 ### core: ci-cd
 
@@ -1150,7 +1820,7 @@ Fixes and gaps surfaced running the first full Eleventy migration end to end.
   across all three; migration `[one PR:]` markers → `[together:]`; the
   "busy PR flow" build-minutes framing dropped.
 
-## 2026-08-27 — netlify deploy `--no-build`
+## 2026-08-27 — netlify deploy `--no-build` [breaking]
 
 ### stacks/eleventy-netlify.md
 
@@ -1168,7 +1838,7 @@ Fixes and gaps surfaced running the first full Eleventy migration end to end.
 
 - `ci-cd` hint — same `--no-build` fix in the `adapter-static` + Netlify note.
 
-## 2026-08-27 — initial split
+## 2026-08-27 — initial split [non-breaking]
 
 The single 1518-line "Eleventy + Netlify static-site house style" document was
 split into a stack-agnostic CORE contract plus per-stack implementation

package/standard/core.md

@@ -1,11 +1,11 @@
 # Web project house style — CORE (stack-agnostic)
 
-**Version:** 2026-09-03 · **Status:** active
+**Version:** 2026-09-08 · **Status:** active
 
 This is the stack-agnostic contract every web project follows, regardless of
 framework, host, or CSS system. It says **what** must be true, with concrete
 specs. It never says **how** — that lives in one implementation doc per stack
-(`stacks/eleventy-netlify.md`, `stacks/phoenix.md`, `stacks/sveltekit.md`).
+(`stacks/eleventy-netlify.md`, `stacks/phoenix.md`, `stacks/sveltekit-netlify.md`).
 
 **How to use this:** at project start, run the stack-selection flow
 (`#adopting`). Then load **this file plus the one `stacks/*.md` file** matching
@@ -114,25 +114,43 @@ a build-time schema gate hard-fails the build on invalid content.
   the same data files is acceptable — a separate database for site content is
   not.
 - **Ownership.** By default the party that builds the site may also edit its
-  content. A project that runs a **separate content operation** — a non-developer,
-  or an LLM agent editing the data files directly — **reserves** that content:
-  one file at the repo root names the reserving party and the exact set it owns,
-  and is authoritative for every party. The builder treats the reserved set as
-  read-only and routes any change it needs there through the project's escalation
-  channel, never a direct edit. The reserved set is enumerated at whatever
-  granularity the project needs — all content, or named collections/paths.
+  content — recorded as `content-ops: in-repo` in `CLAUDE.md` (`#adopting`),
+  and no reservation file ships. A project that runs a **separate content
+  operation** — a non-developer, or an LLM agent editing the data files
+  directly — **reserves** that content: `content-ops: reserved` in `CLAUDE.md`,
+  and one file at the repo root (`CONTENT.md`) names the reserving party and
+  the exact set it owns, and is authoritative for every party. The builder
+  treats the reserved set as read-only and routes any change it needs there
+  through the project's escalation channel, never a direct edit. The reserved
+  set is enumerated at whatever granularity the project needs — all content,
+  or named collections/paths.
 - An **LLM agent** editing reserved content follows a documented per-project
   content-ops protocol: it changes only the reserved set; a pre-commit content
   check (the content-relevant slice of the gate) **errors** on any staged change
   outside that set; a `content:` commit convention; and an escalation channel for
-  anything structural, so a blocked request is recorded, not lost. See your
-  stack's impl doc.
+  anything structural, so a blocked request is recorded, not lost. The agent does
+  not deploy: it commits a finished change to the default branch and hands it to
+  the human deploy cadence (`#ci-cd`) — a session-closing report that names what
+  landed and whether it is time-sensitive, with any deadline also carried in the
+  commit subject. See your stack's impl doc.
 - **Drafts** are a data flag. A draft renders in local and preview builds
   (reviewable) but is excluded from the production build and the sitemap.
   Publishing is removing the flag.
 - The project records its target publishing rate for new content pages in
   `CLAUDE.md`. Bulk-publishing many pages at once depresses indexing; pace
   deliberately.
+- **The standalone-page entry shape is a per-stack choice, made explicitly.**
+  This chapter requires only that page content *is* data (above) — the
+  concrete fields, whether entries are an array or a simpler keyed object,
+  and how a mechanism-bound section is marked, is named by each stack's own
+  impl doc, and may legitimately differ between stacks. This is a documented
+  choice, not an inconsistency: forcing one shape onto every stack would cost
+  more (a rewrite of a working, unproven template) than it buys (one less
+  thing for a cross-stack content agent to learn) while only one stack has a
+  real adopting project. Where a project ships a `CONTENT.md` for agent
+  editing (above), that file's own "entry shape" section is the one an
+  editing session actually needs — read it fresh each session, don't assume
+  another project's stack taught you this one's shape.
 
 **Rationale.** Content that lives in templates can't be validated, can't be
 edited safely by non-developers, and drifts from its own stated facts (a
@@ -898,10 +916,17 @@ and it is **not** part of the gate.
   page's Compliance panel (`#audit-page`); and the **deploy pre-flight**
   (`#ci-cd`) **warns** on any chapter that went `PASS → FAIL` since the last
   deploy (a real regression of something previously compliant).
-- **Standard-version drift is a row.** The command compares the project's pinned
-  `standard-version:` (`#adopting`) to the standard's own version header; if the
-  pin is behind, each `CHANGELOG` slug changed since becomes a
-  `MANUAL: re-check #<slug>` line.
+- **Standard-version drift is a row, severity-tagged.** The command compares
+  the project's pinned `standard-version:` (`#adopting`) to the standard's own
+  version header; if the pin is behind, each `CHANGELOG` slug changed since
+  becomes a re-check line, carrying the severity of the entry it came from
+  (`CHANGELOG.md`'s own `[breaking]` / `[non-breaking]` tag on the `## <date>`
+  heading — see its header note for the rule): `BREAKING: re-check #<slug>`
+  folds into the fail count and gates `--strict`; `MANUAL: re-check #<slug>`
+  stays a judgment call, same as any other `MANUAL` chapter result. A slug
+  touched by more than one entry since the pin takes the worst (a single
+  breaking touch marks it `BREAKING`, even if a later entry on the same slug
+  was non-breaking).
 - The mechanical tier **reuses existing machinery** — the repo-config
   introspection already in the audit doctor and the built-output scan already in
   the link/reference check — not a parallel implementation.
@@ -1297,17 +1322,25 @@ records the result. "The gate passing" is the definition of compliant.
 **Specs.**
 
 **Stack-selection flow** — run at project start (or when onboarding an existing
-project), before non-trivial work. Ask five questions with defaults:
+project), before non-trivial work. Ask six questions with defaults:
 
 1. **Framework?** Eleventy + Netlify *(default)* · Elixir/Phoenix *(when a
    database or server-side state is in scope — `#beyond-this-standard`)* ·
-   SvelteKit *(only when a project specifically needs it — Svelte components
-   without SvelteKit has no durable static-site tooling, so SvelteKit +
-   `adapter-static`, used minimally as a build tool with no server, is the
-   fallback even for a "just static Svelte" need; a project with no Svelte
-   requirement should still default to Eleventy + Netlify)* · other *(→ no
-   binding exists; use this file as principles and do what is idiomatic for
-   the technology)*.
+   SvelteKit + Netlify *(only when the client-side need is genuinely
+   component-shaped — several interactive pieces sharing state, not a single
+   calculation `#client-logic`'s pure-function-plus-wiring pattern already
+   covers; SvelteKit hydrates every page by default, so picking it means the
+   framework runtime ships site-wide, not just where it's interactive — a
+   real cost, not a free upgrade
+   (`stacks/sveltekit-netlify.md#where-sveltekit-fights-the-grain` #2). Plain
+   Svelte has no durable static-site tooling of its own, so this binding is
+   SvelteKit + `adapter-static`, used minimally as a build tool with no
+   server — a "static Svelte, on Netlify" need specifically, not a
+   general-purpose SvelteKit offering; a project whose interactivity is one
+   widget should still default to Eleventy + Netlify)* · other *(→ no binding
+   exists; use this file as principles and do what is idiomatic for the
+   technology — this covers SvelteKit with real server features too, which
+   this standard does not have a binding for yet)*.
 2. **CSS system?** Pico classless *(default)* · Pico class-based · Tailwind ·
    Tailwind + component library · vanilla tokens. (Options are bound per stack
    in the impl doc's `styling` section.)
@@ -1323,6 +1356,13 @@ project), before non-trivial work. Ask five questions with defaults:
    `#agent-artifacts`); is pricing usage-based rather than flat? (→ add
    `+metering`, `#usage-metering`). This gate is by real need, not by framework —
    a plain CRUD app that calls no model is unaffected.
+6. **Who edits content after launch?** *Default: the builder* — record
+   `content-ops: in-repo`; no reservation file ships, no protocol to follow.
+   A **separate content operation** (a Claude Project / Cowork, a
+   non-developer editing the data files directly) → record
+   `content-ops: reserved`, `#content-model` Ownership — ships `CONTENT.md`
+   (the reserved set + escalation protocol) at the project root. The voice
+   guide ships either way, read by whichever party writes copy.
 
 Follow-ups when relevant: production domain; content type (`tool` vs `article` —
 `article` implies feeds); publishing rate for content sites.
@@ -1333,8 +1373,8 @@ the new-project path: the template is already compliant, so a new project begins
 at "fill in brand + content" instead of "assemble the machinery". The impl doc's
 numbered new-project checklist is then two things: the by-hand equivalent for a
 stack with no template, and the annotated inventory of what the template
-contains. Only `eleventy-netlify` has a template today; the others follow the
-checklist. The recommended input to the flow is a filled
+contains. A template exists for every stack today (`templates/<stack>/`); `index.json`
+records which are `active` vs `draft`. The recommended input to the flow is a filled
 `templates/concept-brief.md` (the idea, the answers above, a concept-level
 brand, the content model, layout notes) — `README.md` has the hand-off. If the
 brief cannot honestly fit an offered stack, that is a `feedback/` note (below)
@@ -1378,10 +1418,11 @@ governs it and follow that chapter — the slugs are the index (a `<script>` →
 - scope: static+forms          # or: +db, +auth, +ssr — see core.md#beyond-this-standard
 - ads: none                    # or: adsense — see core.md#ads
 - ai: none                     # or: llm-api  (+artifacts if model-driven file downloads, +metering if usage-priced) — see core.md#llm-integration
+- content-ops: in-repo         # or: reserved — a separate content operation owns content, see core.md#content-model
 - production-url: https://example.com
 - content-type: tool           # tool | article  (article => feeds)
 - publishing-rate: ~5 pages/week
-- standard-version: 2026-09-03  # recommended — enables standard-version drift tracking (#compliance)
+- standard-version: 2026-09-08  # recommended — enables standard-version drift tracking (#compliance)
 ```
 
 If the section is absent, the assistant's first action is to run the flow above
@@ -1389,14 +1430,17 @@ and propose it. Each impl doc's `adopting` section fills in the gate command and
 adds any stack-specific `CLAUDE.md` prose (e.g. the generated-assets note).
 
 **Editorial operation.** Where content is maintained after launch by an LLM
-agent rather than by in-repo development (`#content-model` — a *reserved*
-content set), two files ship at the project root: `CONTENT.md` (the reserved set
-plus the per-project content-ops protocol) and a voice guide (see the impl
-doc). The operation's editor-in-chief — the human's standing ideation/editorial
+agent rather than by in-repo development (`content-ops: reserved`,
+`#content-model` — a *reserved* content set), `CONTENT.md` ships at the
+project root — the reserved set plus the per-project content-ops protocol.
+The voice guide ships regardless of `content-ops` (see the impl doc) — it's
+read by whichever party writes copy, builder or editorial operation alike.
+The operation's editor-in-chief — the human's standing ideation/editorial
 context, typically a Claude Project — connects to the repo through a **thin,
 stable instruction**: check out the repo; read `CONTENT.md` and the voice guide
 at the start of each session; follow `CONTENT.md`; escalate through its channel;
-never deploy. The detail stays in the repo, re-read each session — not in the
+never deploy — a finished change is handed off for the human deploy cadence, not
+shipped. The detail stays in the repo, re-read each session — not in the
 instruction — and `CONTENT.md` carries a paste-once "setting up" section for
 exactly this. The build arm treats the reserved set as read-only and escalates
 into the same channel.