@piercebarney/whs-eleventy 2026.9.2 → 2026.9.3

package/lib/_project.js

@@ -22,6 +22,20 @@ function tryProjectRequire(rel, fallback = null) {
   }
 }
 
+// The content-arm -> build-arm escalation drawer (core.md#content-model): one
+// `YYYY-MM-DD-<slug>.md` per blocked structural request, triaged and deleted by
+// the build arm. Returns the open notes' filenames (README.md excluded), sorted.
+function openRequests(root = ROOT) {
+  try {
+    return fs
+      .readdirSync(path.join(root, "requests"))
+      .filter((f) => f.endsWith(".md") && f.toLowerCase() !== "readme.md")
+      .sort();
+  } catch {
+    return [];
+  }
+}
+
 // Locate the standard's text (core.md, CHANGELOG.md) for the drift check:
 //   1. WHS_STANDARD env var (the authoring repo points this at itself)
 //   2. the copy bundled into this package at publish time (standard/)
@@ -39,4 +53,4 @@ function resolveStandard() {
   return null;
 }
 
-module.exports = { ROOT, projectRequire, tryProjectRequire, resolveStandard };
+module.exports = { ROOT, projectRequire, tryProjectRequire, openRequests, resolveStandard };

package/lib/compliance.js

@@ -152,7 +152,9 @@ const CHECKS = {
     }
     const protocol =
       has("CONTENT.md") && /"content-check"/.test(read("package.json") || "")
-        ? "agent content-ops protocol present"
+        ? has("requests")
+          ? "agent content-ops protocol present (CONTENT.md, content-check, requests/)"
+          : "CONTENT.md + content-check present, but no requests/ escalation drawer"
         : "no CONTENT.md / content-check — add it if content is agent-edited";
     return {
       status: MANUAL,
@@ -412,14 +414,22 @@ const CHECKS = {
   },
 
   privacy: () => {
-    const p = read("src/privacy.njk") || "";
-    if (!has("src/privacy.njk")) return { status: FAIL, note: "no privacy page" };
-    if (!/for\s+t\s+in\s+thirdparties/.test(p))
+    // The privacy page may be a standalone src/privacy.njk or a pages.json
+    // entry rendered by a src/pages/ shell — check the built output, with a
+    // source fallback for when _site isn't built yet.
+    const built = has("_site/privacy/index.html");
+    const source =
+      has("src/privacy.njk") ||
+      /["']slug["']\s*:\s*["']privacy["']/.test(read("src/content/pages.json") || "");
+    if (!built && !source) return { status: FAIL, note: "no privacy page" };
+    // The third-party disclosure must be generated from _data/thirdparties.js,
+    // never hand-maintained — the loop lives in the privacy shell or an include.
+    if (grepSrc(/for\s+t\s+in\s+thirdparties/).length === 0)
       return {
         status: FAIL,
         note: "privacy third-party list not rendered from _data/thirdparties.js",
       };
-    return { status: PASS, note: "third-party list rendered from the manifest" };
+    return { status: PASS, note: "privacy page present; third-party list from the manifest" };
   },
 
   ads: () => {

package/lib/content-check.js

@@ -4,42 +4,94 @@
 //
 //   whs content-check
 //
-// Also warns — does not block — when the working tree has changes outside the
-// content set, so a stray code edit doesn't ride along in a `content:` commit.
+// A **staged** file outside the reserved content set is an error — a `content:`
+// commit can't carry a code/structure change. An unstaged stray only warns (it
+// won't be in the commit unless staged). Also reports the open requests/ notes
+// (the content-arm → build-arm escalation channel, core.md#content-model).
 
 const { execSync } = require("node:child_process");
+const { openRequests } = require("./_project.js");
 
-// Files an agent following CONTENT.md is expected to touch.
-const CONTENT_SET = [/^src\/content\//, /^src\/_data\/nav\.js$/, /^src\/_data\/glossary\.js$/];
+// Files an agent following CONTENT.md may touch — the reserved content set plus
+// its own escalation drawer. Everything else (the *.schema.json editor aids,
+// schema.js, the page shells, the includes, config) is a build-arm change.
+const RESERVED_SET = [
+  /^src\/content\/(?!.*\.schema\.json$)[^/]+\.json$/,
+  /^src\/_data\/nav\.js$/,
+  /^src\/_data\/glossary\.js$/,
+  /^requests\//,
+];
 
-function changedFiles() {
+// One `git status --porcelain` line → { path, staged }. `staged` is true when
+// the index column (X) holds a real status letter — i.e. the change is part of
+// the next commit. Untracked ("??") and worktree-only (" M") are not staged.
+function parsePorcelain(out) {
+  return out
+    .split("\n")
+    .filter(Boolean)
+    .map((l) => {
+      const x = l[0];
+      const rest = l.slice(3);
+      const path = rest.includes(" -> ") ? rest.split(" -> ")[1] : rest;
+      return { path: path.trim(), staged: x !== " " && x !== "?" };
+    });
+}
+
+function changedEntries() {
   try {
-    const out = execSync("git status --porcelain", { encoding: "utf8" });
-    return out
-      .split("\n")
-      .map((l) => l.slice(3).trim())
-      .filter(Boolean)
-      .map((f) => (f.includes(" -> ") ? f.split(" -> ")[1] : f));
+    return parsePorcelain(execSync("git status --porcelain", { encoding: "utf8" }));
   } catch {
     return [];
   }
 }
 
-const stray = changedFiles().filter((f) => !CONTENT_SET.some((re) => re.test(f)));
-if (stray.length) {
-  console.warn("\n⚠  changes outside the content set — these are code changes, not content:");
-  for (const f of stray) console.warn(`     ${f}`);
-  console.warn("   Commit them separately (a Claude Code task), or confirm they're intentional.\n");
+function strayFiles(paths) {
+  return paths.filter((f) => !RESERVED_SET.some((re) => re.test(f)));
 }
 
-const steps = ["lint", "validate", "build", "links"];
-for (const s of steps) {
-  process.stdout.write(`content-check: npm run ${s}\n`);
-  try {
-    execSync(`npm run ${s}`, { stdio: "inherit" });
-  } catch {
-    console.error(`\ncontent-check: '${s}' failed — fix it before committing.`);
+function splitStray(entries) {
+  return {
+    staged: strayFiles(entries.filter((e) => e.staged).map((e) => e.path)),
+    unstaged: strayFiles(entries.filter((e) => !e.staged).map((e) => e.path)),
+  };
+}
+
+function main() {
+  const { staged: stagedStray, unstaged: unstagedStray } = splitStray(changedEntries());
+
+  if (stagedStray.length) {
+    console.error("\n✗ staged changes outside the reserved content set (CONTENT.md):");
+    for (const f of stagedStray) console.error(`     ${f}`);
+    console.error(
+      "\n  A `content:` commit can't carry a code or structure change. Unstage them\n" +
+        "  (git restore --staged <file>), or file a requests/ note for the build arm.\n",
+    );
     process.exit(1);
   }
+  if (unstagedStray.length) {
+    console.warn("\n⚠  uncommitted changes outside the reserved set (not staged):");
+    for (const f of unstagedStray) console.warn(`     ${f}`);
+    console.warn("   They won't ride a `content:` commit unless you stage them.\n");
+  }
+
+  const reqs = openRequests();
+  if (reqs.length) {
+    console.log(`\nℹ  ${reqs.length} open request(s) in requests/ awaiting the build arm.\n`);
+  }
+
+  const steps = ["lint", "validate", "build", "links"];
+  for (const s of steps) {
+    process.stdout.write(`content-check: npm run ${s}\n`);
+    try {
+      execSync(`npm run ${s}`, { stdio: "inherit" });
+    } catch {
+      console.error(`\ncontent-check: '${s}' failed — fix it before committing.`);
+      process.exit(1);
+    }
+  }
+  console.log("\ncontent-check: ok — lint · validate · build · links");
 }
-console.log("\ncontent-check: ok — lint · validate · build · links");
+
+module.exports = { strayFiles, parsePorcelain, splitStray, RESERVED_SET };
+
+if (require.main === module) main();

package/lib/doctor.js

@@ -21,7 +21,7 @@
 const fs = require("node:fs");
 const path = require("node:path");
 const { execSync } = require("node:child_process");
-const { ROOT, projectRequire } = require("./_project.js");
+const { ROOT, projectRequire, openRequests } = require("./_project.js");
 const { asRegexMap } = require("./header-expect.js");
 
 const CACHE = path.join(ROOT, ".cache", "doctor.json");
@@ -376,6 +376,26 @@ function main() {
   }
 
   if (preflight) {
+    // Open content-arm → build-arm requests gate the deploy: a conditional
+    // hard stop (core.md#content-model). Zero → ship; one or more → refuse
+    // unless --ack-requests says the operator has reviewed them.
+    const reqs = openRequests();
+    if (reqs.length && !args.includes("--ack-requests")) {
+      console.error(
+        `\ndoctor: ${reqs.length} open request(s) in requests/ — the content arm is ` +
+          `waiting on\nthe build arm. Clear them, or re-run the deploy with ` +
+          `--ack-requests to ship anyway:`,
+      );
+      reqs.forEach((r) => console.error(`  - requests/${r}`));
+      console.error("\nRefusing to continue.");
+      process.exit(1);
+    }
+    console.log(
+      reqs.length
+        ? `\nOpen requests: ${reqs.length} — acknowledged (--ack-requests).`
+        : "\nOpen requests: 0.",
+    );
+
     const cr = complianceRegressions();
     if (!cr.checked) {
       console.log(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@piercebarney/whs-eleventy",
-  "version": "2026.9.2",
+  "version": "2026.9.3",
   "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"

package/standard/CHANGELOG.md

@@ -8,6 +8,463 @@ Format: `## <date>` → `### core: <slug>` / `### <stack>` entries.
 
 ---
 
+## 2026-09-03 — the content-arm interface: a project and its coding arm
+
+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
+work to a **coding arm** (Claude Code for structure, Cowork for content) in the
+repo. This release makes that hand-off a defined interface rather than a set of
+conventions the operator holds in their head. The model: editor-in-chief →
+typesetter → press. The typesetter turns editorial intent into validated data
+plus a `content:` commit on `main`; only a person runs the press (deploy —
+`#ci-cd`, unchanged).
+
+Grew out of a design conversation, filed and worked through in
+`feedback/2026-09-02-content-arm-interface.md` (now consumed into this entry).
+Six changes shipped together as one release; each is summarised below.
+
+**Rejected along the way**, recorded so they aren't re-litigated: standalone-page
+prose as **Markdown files** (lost to JSON — reuses the existing validator and
+render path, zero new parsing; Markdown ergonomics are what `add-ons/pages/` is
+for); an **always-on "I reviewed the requests" checkbox** on deploy (lost to a
+conditional hard-stop — friction only when the drawer is non-empty, so the
+checkbox never trains into a reflex); **Cowork as the default content owner**
+(lost to "Claude Code owns everything unless a project reserves a slice" — right
+for the common small-site case); a **`schedule` trigger** on the deploy workflow
+(lost — a timed deploy removes the person the open-requests gate assumes).
+
+### core: content-model
+
+- **Content-surface split.** Every user-visible string is data — standalone
+  pages (About, a policy page, a marketing page) included, not just collection
+  entries. The only prose that may stay in a template is copy bound to a
+  mechanism that same template implements (a generated disclosure list's
+  heading, a consent notice that must track real behaviour); the impl doc names
+  those cases. Test: could a non-developer rewrite this sentence without risking
+  a guarantee?
+- **Ownership states.** By default the party that builds the site may also edit
+  its content. A project running a *separate* content operation **reserves** it:
+  one authoritative file at the repo root names the reserving party and the
+  exact set it owns (any granularity — all content, or named paths). The builder
+  treats the reserved set as read-only and routes changes it needs there through
+  an escalation channel, never a direct edit.
+- The agent content-ops protocol now specifies: a pre-commit content check that
+  **errors** on a *staged* file outside the reserved set (an unstaged stray only
+  warns — so an `npm update` pull can't hard-fail a live project on incidental
+  worktree churn), and an escalation channel so a blocked structural request is
+  recorded, not lost.
+
+### core: adopting
+
+- **Editorial operation** spec: where an LLM agent maintains content after
+  launch, the project ships `CONTENT.md` (reserved set + protocol) and a voice
+  guide; the editor-in-chief connects to the repo through a *thin, stable*
+  instruction (read those two files each session, follow `CONTENT.md`, escalate,
+  never deploy) with the detail kept in the repo, re-read each session.
+  `CONTENT.md` carries a paste-once "setting up" section.
+- A concept brief that cannot honestly fit an offered stack is a `feedback/`
+  note *before* the build — resolved as a new binding or the nearest stack with
+  the compromise recorded. `concept-brief.md`'s `framework:` gains a `needs
+  discussion` option.
+
+### stacks/eleventy-netlify.md
+
+- `#content-model`: two content files — `content/guides.json` (a collection,
+  rendered via a `<dir>/<dir>.11tydata.js` directory-data file) and
+  `content/pages.json` (the standalone pages; `src/pages/` holds a one-line
+  shell each, prose is the JSON `body`). Mechanism-bound sections are
+  `{ include }` markers in `body`, dispatched by `src/_includes/prose.njk` and
+  validated against a known set. `add-ons/pages/` extends `body` with typed
+  layout blocks. The `src/` tree snippet and adopting narrative corrected to
+  match (no more `src/index.njk`).
+- New **escalation channel**: a `requests/` directory (one
+  `YYYY-MM-DD-<slug>.md` per blocked structural ask; the build arm makes the
+  change and deletes the note). `whs content-check` counts open requests;
+  `bin/deploy`'s pre-flight refuses to ship while any are open unless
+  `--ack-requests`.
+- `#ci-cd`: one sanctioned five-step release reached two ways — the
+  **`deploy.yml` `workflow_dispatch` button** (recommended: off your machine,
+  logged) or `bin/deploy` locally (the offline path). `workflow_dispatch` only,
+  no `schedule`. Secrets as repo secrets. The workflow's open-requests gate
+  writes the count to the run summary and fails pending `acknowledge_requests`.
+
+### templates/eleventy-netlify
+
+- `src/{index,about,privacy}.njk` → `src/pages/{home,about,privacy}.njk` thin
+  shells + `src/content/pages.json` + `pages.schema.json`; `schema.js` gains a
+  per-domain validator dispatch. `src/_includes/{prose,guide-list,thirdparty-disclosure}.njk`.
+- New root files: `CONTENT.md` (rewritten — reserved-set framing, the "setting
+  up the editorial project" section, the `requests/` escalation flow),
+  `VOICE.md` (seeded from the brief's *Feel* line, read by both arms),
+  `requests/README.md`.
+- `bin/deploy` accepts `--ack-requests`; `.github/workflows/deploy.yml` reworked
+  (see `#ci-cd`); `bin/init` / `TEMPLATE.md` / `README.md` updated for the new
+  layout and the editorial-project hand-off.
+- New add-on **`add-ons/pages/`** — typed marketing blocks (`hero` /
+  `feature-list` / `cta`) the content arm composes into a landing page with no
+  template change; the build arm owns the block types.
+- `add-ons/glossary/` + `add-ons/calculator/` corrected for the `pages.json`
+  split (the removed `policy` tag → `collections.page`; no `src/index.njk`).
+
+### tooling
+
+`@piercebarney/whs-eleventy` 2026.9.2 → 2026.9.3:
+
+- `content-check`: errors on a **staged** file outside the reserved set (unstaged
+  → warn); prints the open-`requests/` count. `RESERVED_SET` is `content/*.json`
+  (not the `*.schema.json` aids or `schema.js`) + `_data/{nav,glossary}.js` +
+  `requests/`. **Projects pulling this via `npm update` get the stricter
+  behaviour** — a `content:` commit can no longer carry a staged code change.
+- `doctor --deploy-preflight`: a conditional hard stop on open `requests/` —
+  refuses unless `--ack-requests`.
+- `_project.js` `openRequests()`; `compliance` `content-model` note also reports
+  whether `requests/` is present.
+- The `privacy` compliance check no longer hard-codes `src/privacy.njk` — it
+  checks the built `/privacy/` output and the third-party loop wherever it lives.
+- New fixture tests: the `privacy` check, `openRequests()`, the `content-check`
+  reserved-set + porcelain-parse + staged/unstaged split.
+
+### stacks/phoenix.md · sveltekit.md
+
+- `phoenix.md#content-model`: the "a reviewed component carrying editorial prose
+  is acceptable" escape removed — it contradicted the sharpened core Spec.
+- Filed `feedback/2026-09-03-pages-model-diverges-across-stacks.md`: the
+  standalone-pages model is now three shapes (eleventy rich `body` list,
+  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
+
+`stacks/sveltekit.md` was a parked stub — every mirrored section's "How
+(SvelteKit)" was `TODO`, not offered by the `#adopting` flow. A real need
+(plain Svelte, static output, deployed to Netlify) forced the decisions:
+there is no durable, officially-maintained framework for "pure Svelte, no
+SvelteKit, multi-page static site" (the community tools that do this are
+small single-maintainer projects), so the resolution is SvelteKit +
+`adapter-static`, used minimally as a build tool with no server ever
+touched. Built `templates/sveltekit/` the same way `templates/phoenix/` was
+built: every mechanism claim verified against a real `sv create` scaffold
+and real `vite build` output, not written from the binding's prose alone.
+
+### core: adopting
+
+- Q1's framework list gains SvelteKit as a real (draft) option — "only when
+  a project specifically needs it; a project with no Svelte requirement
+  should still default to Eleventy + Netlify" — replacing the previous
+  "treat as other" parked-stub instruction.
+
+### stacks/sveltekit.md
+
+- **Every `TODO` "How (SvelteKit)" section resolved or explicitly marked as
+  a real, flagged gap** — not left as a hint. The `PARKED STUB` banner and
+  `open-questions-for-later` section are both removed; every open question
+  they held is now answered inline in the relevant section, with the
+  reasoning kept (see `where-sveltekit-fights-the-grain`'s per-item
+  resolutions).
+- **A real, previously-undocumented SvelteKit architecture change found and
+  corrected:** a separate `svelte.config.js` is no longer generated or
+  required — `sv create`'s current scaffold (`@sveltejs/kit@2.63`) passes
+  the full `KitConfig` (adapter, `csp`, everything) directly into the
+  `sveltekit()` Vite plugin call in `vite.config.ts`. The old
+  `sveltekit-config` section (titled "svelte.config.js & vite.config.js")
+  assumed two files; corrected to one.
+- **Content pipeline resolved: plain JSON + zod**, not
+  `@content-collections/core` or `mdsvex` — checked
+  `templates/eleventy-netlify/src/content/schema.js` directly first: its
+  proven pattern is a hand-rolled, zero-dependency validator, so this is a
+  deliberate deviation kept at the shape level (JSON + a build-time
+  validator that hard-fails printing every error), not a copy of the exact
+  mechanism. Verified the "print every error" contract by deliberately
+  breaking content three ways at once and confirming all five resulting
+  errors surfaced together — an earlier draft of the validator only ran its
+  structural (duplicate-slug / dangling-reference) checks inside the
+  schema-success branch, silently dropping them whenever a field-level error
+  also fired; fixed to run unconditionally.
+- **CSS default resolved: Pico classless**, not Tailwind — matching
+  `eleventy-netlify`'s default; Svelte's component-scoped `<style>` blocks
+  compile to a real extracted stylesheet (verified in build output, not
+  inlined), so they coexist cleanly with a strict `style-src 'self'` and no
+  Tailwind/PostCSS step is needed.
+- **Netlify Forms compatibility with `adapter-static` verified end to end**,
+  not assumed from a blog post: a `data-netlify="true"` form with
+  `netlify-honeypot` and a hidden `form-name` input, inspected in the actual
+  prerendered `contact.html` output and confirmed to survive Svelte's
+  compilation intact. This is load-bearing, not incidental — Netlify's
+  deploy-time bot only ever parses the built static HTML.
+- **`csp: { mode: 'hash' }` verified against real build output**: a real
+  computed `sha256-` hash appears in the built `<meta
+  http-equiv="content-security-policy">` tag. Also found and documented:
+  `frame-ancestors` is silently absent from that tag regardless of being
+  listed in the config — the CSP spec doesn't allow that directive in a
+  `<meta>` tag at all — so `netlify.toml`'s global header block is the only
+  place it (and every other baseline header) actually takes effect.
+- **The Netlify per-context-headers landmine inherited and fixed
+  identically** to `stacks/eleventy-netlify.md#noindex`'s already-fixed
+  version, same root cause (a pre-built-artifact deploy bypasses Netlify's
+  build-context detection): `noindex`'s layer 2 (the header backstop)
+  doesn't apply to this stack's deploy model, stated plainly. Distinguished
+  from `security-headers`, which is **not** broken the same way — a global,
+  non-context header block doesn't need context detection at all, and is
+  confirmed working in production on `eleventy-netlify`'s own live
+  `netlify.toml`.
+- **A real, previously-undocumented SvelteKit 2.26+ feature found and
+  documented as a genuine advantage**: `resolve()` from `$app/paths` gives
+  compile-time internal-link validation (a typo'd route is a real
+  TypeScript error), enforced automatically by
+  `eslint-plugin-svelte`'s `no-navigation-without-resolve` rule (already
+  active from `sv create`'s own `eslint` add-on) — closer to Phoenix's `~p`
+  sigil than this binding's own prior "SvelteKit does not check `href`
+  strings at build time" assumption, which was wrong.
+- OG-image generation, a brand-token layer, and a theme toggle are
+  documented as deliberately deferred/not-yet-built, matching
+  `templates/phoenix/`'s `og.gen`/`icons.gen` treatment — TODO banners, not
+  silently assumed done.
+
+### templates/sveltekit (new)
+
+- New starter template: a real `sv create` scaffold (`--template minimal
+  --types ts --add prettier eslint vitest sveltekit-adapter=adapter:static`)
+  with plain-JSON+zod content (`guides`/`pages`, mirroring
+  `eleventy-netlify`'s collection shape at the structural level), the
+  verified Netlify-Forms contact page, prerendered `sitemap.xml`/
+  `robots.txt` routes, an env-gated `noindex` layer, a `netlify.toml` global
+  header block, and `bin/deploy` (Netlify CLI artifact upload, `--no-build`,
+  no bypass on prod — mirrors `eleventy-netlify`'s `bin/deploy` exactly, not
+  independently rediscovered). `npm run check` runs only real, off-the-shelf
+  steps (lint, content validation, `svelte-check`, vitest, build) —
+  `a11y`/link-check tooling stays `TODO`, matching `templates/phoenix/`'s
+  precedent; no tooling-package counterpart to `@piercebarney/whs-eleventy`
+  exists for this stack yet. No `bin/init` yet. Verified via a full
+  cold-cache `npm ci && npm run check` run, twice (mid-build and again from
+  the template's final repo location after the move).
+- `index.json`'s `sveltekit.status`: `parked` → `draft`;
+  `sveltekit.template` → `templates/sveltekit/`.
+- `README.md`'s doc-map table and framework-question wording updated for
+  both the stack-file row and the new template row.
+- `templates/verify.sh` and `standard.yml` gain an `npm run check`-only
+  branch for SvelteKit-shaped templates (keyed on `vite.config.ts`, checked
+  ahead of the generic `package.json` branch) — no `compliance --strict`
+  call, same deferred-tooling reasoning as Phoenix's branch.
+- `templates/new-project.sh`'s rsync excludes gain `build`/`.svelte-kit`.
+
+### tooling
+
+- Not touched this phase — no `@piercebarney/whs-sveltekit` package exists;
+  `a11y`/link-check stay design-only TODOs, explicitly deferred, same as
+  Phoenix's.
+
+---
+
+## 2026-09-02 — Render as the Phoenix binding's default free-launch host
+
+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
+artifact or a stateless function. `stacks/phoenix.md` previously named only
+Gigalixir/Fly, neither of which offers a genuinely free, no-credit-card,
+no-domain-to-attach launch anymore (Fly deprecated its free tier; Gigalixir
+requires a card at signup even though the free tier itself isn't charged).
+Verified against Render's own docs (`render.com/docs/free`,
+`/docs/blueprint-spec`, `/docs/deploy-phoenix`, `/docs/cli`) and its reference
+app (`github.com/render-examples/phoenix_hello`) rather than asserted from
+memory — pricing/free-tier terms move fast enough that a remembered claim
+isn't trustworthy here.
+
+### stacks/phoenix.md
+
+- **Render is now the documented default host** (`stack-baseline`, `ci-cd`,
+  `secrets`) — free with no credit card at signup, a live `onrender.com`
+  subdomain the moment the first deploy finishes, no domain to attach. The
+  real tradeoff, stated plainly: Render's free Postgres is **deleted 30 days
+  after creation**, and the free plan allows only **one** free database per
+  workspace — it doesn't comfortably fund the doc's existing `dev`/`staging`/
+  `prod` three-environment shape. Gigalixir/Fly stay documented as the
+  graduate-to-production path once that matters.
+- `ci-cd`'s `git_hooks` auto-install description corrected in the same pass:
+  there is no `auto_install: true` config key (none exists in the library's
+  schema) — merely having `git_hooks` as a `:dev` dependency is what triggers
+  the install. Documented the gotcha this project hit directly: that install
+  walks up to whatever repo `git rev-parse --show-toplevel` finds, so running
+  `mix deps.get`/`mix compile` from a checkout that isn't its own git repo
+  yet installs hooks into the *enclosing* repo instead — the fix is a
+  `File.dir?(".git")` guard around the config.
+- A new **"Not verifiable without a live Render account"** note in `ci-cd`
+  (same category as the existing Gigalixir-buildpack caveat): whether
+  `preDeployCommand` failure genuinely blocks promotion under every failure
+  mode, `RENDER_EXTERNAL_HOSTNAME`'s exact format, `force_ssl`/HSTS behind
+  Render's proxy, cold-start-vs-health-check timing, and Cachex/Hammer's
+  per-node behavior past one instance — flagged, not asserted.
+- `bin/check`'s sterility allowlist gains `render.com` / `onrender.com`.
+
+### templates/phoenix
+
+- **`render.yaml`** (new) — a Blueprint declaring the web service + Postgres
+  in-repo: `autoDeployTrigger: off` (a push to `main` never deploys on its
+  own — `bin/deploy` is the deliberate trigger), `buildCommand: ./build.sh`,
+  `startCommand` pointing at the release's `bin/server`, `preDeployCommand`
+  running the release's `Release.migrate` eval before the new instance is
+  promoted, `healthCheckPath` wired to the existing `HealthController`,
+  `envVars` using `generateValue`/`fromDatabase`/`sync: false` so no secret
+  value is ever written to the yaml.
+- **`build.sh`** (new) — verified verbatim against
+  `github.com/render-examples/phoenix_hello`'s own script (`mix deps.get
+  --only prod`, `MIX_ENV=prod mix compile`, `assets.build` + `assets.deploy`,
+  `mix phx.gen.release`, `mix release --overwrite`). `rel/` added to
+  `.gitignore` — nothing it generates is committed.
+- **`bin/deploy`** rewritten around the `render` CLI (`render deploys create
+  <service-id> --commit <sha> --wait --confirm`) in place of the previous
+  git-push-to-a-Gigalixir/Fly-remote mechanism; still no `$OPTS` on `prod` —
+  that omission is still the no-bypass enforcement, just against a different
+  underlying command. `bin/migrate` / `bin/remote` document the real (if not
+  fully non-interactive) `render ssh` + release-eval commands in place of
+  their previous host-agnostic stub text.
+- **`config/runtime.exs`** now falls back to Render's auto-populated
+  `RENDER_EXTERNAL_HOSTNAME` when `PHX_HOST` isn't set, so the `onrender.com`
+  subdomain resolves correctly with zero manual config.
+- `AGENTS.md`'s Deploy section and `TEMPLATE.md`'s "what a fresh checkout
+  still owns" updated to match; a stale `content/resources/article.ex` path
+  (the real file has no `resources/` segment) corrected in `AGENTS.md` while
+  in the same section.
+- None of this has been verified against a live Render account — see
+  `stacks/phoenix.md#ci-cd`'s new "Not verifiable" note above for exactly
+  what that would still need to confirm.
+
+---
+
+## 2026-09-02 — a starter template for the Phoenix binding, and hardening the doc it's built from
+
+Built `templates/phoenix/` the same way `templates/eleventy-netlify/` was
+proven out: generic placeholder content, independent of any real business,
+every mechanism claim held to compile-it-and-curl-it verification rather than
+plausible-looking prose. That process found `stacks/phoenix.md` — despite
+being "grounded in a real production codebase" — still carried several
+fabricated or imprecise APIs the same way the earlier `Plug.CSP` finding did.
+
+### stacks/phoenix.md
+
+- **`Oban.Cron` corrected to `Oban.Plugins.Cron`** (all three occurrences) —
+  the real plugin module, confirmed against Oban's fetched source.
+- **`ash_phoenix`/`AshPhoenix.Form` now named** as the required bridge between
+  an Ash resource and a LiveView `<.form>` — the doc's `forms` section needed
+  it to write a contact form at all and never named it.
+- `contexts-and-ash`: `config :app, ash_domains: [...]` is now documented as
+  required (a real compile warning otherwise, fatal under
+  `--warnings-as-errors`); `authorizers: [Ash.Policy.Authorizer]` is now
+  stated as required alongside a resource's `policies do` block;
+  `Ash.Seed.seed!/2` is documented as the policy-bypassing seed mechanism
+  (`Ash.Changeset.for_create` + `Ash.create!` correctly raises
+  `Ash.Error.Forbidden` with no actor — that's the policy working, not a bug,
+  but it means seed scripts need `Ash.Seed`); `simple_sat` recommended over
+  `picosat_elixir` as the SAT-solver backend for policy authorization — pure
+  Elixir, no C compiler dependency, more portable for a template baseline.
+- `theme`: notes that `mix phx.new`'s generated anti-FOUC inline script ships
+  with no nonce, which a strict CSP rejects outright — the template's script
+  now carries one.
+- `structured-data`: **critical finding** —
+  `<script type="application/ld+json">{raw(@json_ld)}</script>` renders the
+  literal text `{raw(@json_ld)}`, not the JSON, because HEEx's tokenizer
+  treats a `<script>` tag's body as opaque text and never invokes the `{}`
+  expression parser inside it. The classic EEx `<%= raw(@json_ld) %>` tag is
+  the fix — its tokenizer runs before HEEx's tag-aware parsing, so it still
+  works inside `<script>`. Verified by curling a real page and parsing the
+  response as JSON, both before (fails) and after (parses) the fix.
+- `sitemap-robots`: documents Cachex's real child-spec form
+  (`{Cachex, name: :x}`), flags that its cache is per-node in-memory — an
+  `Ash.Notifier`-triggered invalidation on the node that handled a write does
+  not reach a sibling node on a horizontally-scaled deploy — and calls out
+  the `robots.txt`/`static_paths()` shadowing gotcha: `Plug.Static`'s default
+  generated `static_paths()` includes `"robots.txt"`, which silently serves
+  the static file over a dynamic `RobotsController` route with no error.
+- `forms`: documents Hammer v7's real supervised-module API
+  (`use Hammer, backend: :ets`, `hit/3`) in place of the older functional
+  API; notes `get_connect_info/2` can only be called from `mount/3`, not from
+  a later `handle_event/3`; and flags that `Phoenix.LiveViewTest`'s simulated
+  connections don't derive `peer_data` from `conn.remote_ip` — a test-only
+  session key is the working escape hatch, not a `conn` override.
+- `domain-tests`: documents the Ecto Sandbox + LiveView-process visibility
+  gap — an `async: true` test's exclusive sandbox ownership isn't
+  automatically shared with a LiveView's own GenServer process, so a test can
+  observe a write as having succeeded while its own query still sees zero
+  rows; `Ecto.Adapters.SQL.Sandbox.allow/3` after `live/2` is the fix.
+- `the-gate`: documents two Mix config gotchas that make `mix check` behave
+  differently from `mix test` run directly — `preferred_envs: [check: :test]`
+  (without it, a custom alias's `mix test` step runs in `:dev`) and
+  `dialyzer: [plt_add_apps: [:ex_unit]]` (without it, Dialyzer fails once
+  `test/support/*.ex`'s `ExUnit` macro calls are analyzed under `:test`).
+- `security-headers`: notes Sobelow's `Config.Headers` and `XSS.Raw` checks
+  false-positive on this stack's CSP plug and JSON-LD `raw()` call
+  respectively, and that `.sobelow-conf` is the documented way to silence
+  them with reasoning attached, not a blanket `--skip`.
+- `repo-hygiene`: notes `mix phx.new` (1.8.x) now auto-generates its own
+  `AGENTS.md` with ecosystem usage-rules content — a project's house-style
+  block merges into that file rather than displacing it, still one prose-doc
+  slot.
+- `stack-baseline`: `ash_phoenix` documented as a required separate
+  dependency (not auto-installed by `mix igniter.install ash`); Boundary
+  noted as optional, not baseline; Tailwind + DaisyUI noted as shipping by
+  default from `phx.new` 1.8.x; added a standing warning that a written
+  version pin in this doc can drift from what Hex resolves today — re-check
+  at scaffold time, don't trust the pin.
+- `og-image` / `assets`: gain a `TODO — no reference implementation exists`
+  banner matching `a11y` / `internal-links` / `the-gate` / `compliance`'s
+  existing treatment — `mix og.gen` / `mix icons.gen` don't exist yet;
+  `templates/phoenix/` ships one hand-placed placeholder OG image instead.
+- `adopting`: "No starter template for this stack yet" replaced with a
+  pointer to `templates/phoenix/`; the new-project checklist updated to
+  reference every fix above.
+
+### templates/phoenix (new)
+
+- New starter template: an Ash domain layer (`Content.Article`, a policy,
+  and an `excerpt` calculation as the domain-tests sample), an `Inbox.Message`
+  contact-form target with a honeypot validation/change pair, the corrected
+  CSP-nonce security-headers plug, cached sitemap/robots controllers, an
+  `/audit` LiveView, an `AshPhoenix.Form`-backed contact form (honeypot +
+  Hammer rate limit), `.github/workflows/ci.yml`, `bin/deploy`. `mix check`
+  runs only real steps (compile --warnings-as-errors, format, credo --strict,
+  dialyzer, sobelow --config, deps.audit, ash.codegen --check, test) —
+  `a11y` / `links.check` / `whs.check` stay TODO, not faked into the alias.
+  No `bin/init` yet — `TEMPLATE.md` covers filling in the placeholders by
+  hand. Verified via a full cold-cache `mix check` run (fresh deps, fresh
+  Postgres, fresh compile) from the template's final repo location, twice.
+- **`config/dev.exs`'s `git_hooks` config is now guarded on `File.dir?(".git")`.**
+  Found the hard way: `git_hooks`' `only: [:dev]` dependency auto-installs
+  hooks on `mix deps.get`/`mix compile` by walking up to whatever repo
+  `git rev-parse --show-toplevel` finds — since `templates/phoenix/` has no
+  `.git` of its own inside this monorepo, running `templates/verify.sh`
+  installed real `pre-commit`/`pre-push` hooks into *the standard's own*
+  `.git/hooks`, breaking `git commit` here until removed by hand. The guard
+  only configures `git_hooks` once the directory has been copied out into a
+  real project and `git init`'d — which is when the auto-install is actually
+  wanted.
+- `index.json`'s `frameworks.phoenix.template` → `templates/phoenix/`;
+  `status` stays `draft` — that should mean full gate parity including a
+  compliance sweep, and the Elixir tooling package (the `whs-eleventy`
+  counterpart) is still a later phase.
+- `README.md`'s doc-map table gets a dedicated `templates/phoenix/` row; the
+  `eleventy-netlify` row's "phoenix: no template" note is removed.
+- `templates/verify.sh` and `.github/workflows/standard.yml` gain a
+  `mix.exs`-keyed branch (`mix deps.get`, `ecto.create`/`migrate` for dev and
+  test, `mix check`) — no `compliance --strict` call, since that tooling
+  doesn't exist for this stack yet.
+- `templates/new-project.sh` now checks for `bin/init` before running it and
+  prints a clear message instead of crashing when a stack (Phoenix, for now)
+  doesn't have one yet.
+- `bin/set-version` and `bin/check`'s version-agreement check now also cover
+  a template's `AGENTS.md` `standard-version` pin, not just `CLAUDE.md` —
+  needed because `templates/phoenix/` carries the house-style block in
+  `AGENTS.md` (`mix phx.new` generates its own `AGENTS.md`; the one-prose-doc
+  slot rule means the house-style block merges into it rather than adding a
+  second file), and the two checks previously only looked at `CLAUDE.md`.
+- `bin/check`'s sterility allowlist gains the Phoenix-ecosystem domains the
+  template's docs legitimately reference (`daisyui.com`, `tailwindcss.com`,
+  `heroicons.com`, `phoenixframework.org`, `elixirforum.com`, `fly.io`,
+  `github.io`, `hexdocs.pm`, `hex.pm`, `mozilla.org`) and broadens the prior
+  single-path `github.com/piercebarney/web-house-style` entry to a generic
+  `github.com`, matching how `netlify.com`/`netlify.app` are already allowed
+  generically rather than scoped to one account.
+
+---
+
 ## 2026-09-02 — closing the gap between the compliance grid and the Contracts it checks
 
 A pass through every chapter's actual enforcement, prompted by an outside
@@ -31,6 +488,17 @@ consistency defects the same pass turned up.
   to `# recommended — enables standard-version drift tracking (#compliance)`
   — `#compliance`'s own check already treats it as required; the doc
   contradicted the code.
+- **A "Feedback to the standard" spec, shipped as `feedback/README.md`** (a
+  minimal dated-note inbox — what is wrong · which project ·
+  `standard-version`), plus a House-style directive bullet and an
+  anti-pattern: a standard defect (a misfiring check, a `core.md` ↔ impl-doc
+  contradiction, a Contract that doesn't survive a real codebase) is a note
+  filed there, not a session-transcript casualty. `bin/check`'s sterile grep
+  covers the committed inbox; `bin/check` does not gate on it. Deliberately
+  minimal — no `bin/feedback` scaffold or CLI subcommand this pass; an
+  earlier, more automated version (a GitHub-issue subcommand) was built and
+  reverted as over-built for a one-adopting-project reality. Triage empties
+  the inbox into a `CHANGELOG` change or a one-line `wontfix`.
 
 ### docs — drift-guard registry sync
 

package/standard/core.md

@@ -1,6 +1,6 @@
 # Web project house style — CORE (stack-agnostic)
 
-**Version:** 2026-09-02 · **Status:** active
+**Version:** 2026-09-03 · **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
@@ -94,8 +94,13 @@ contents, and uses one mechanism per concern.
 a build-time schema gate hard-fails the build on invalid content.
 
 **Specs.**
-- User-visible copy (titles, descriptions, body prose, lists) is authored as
-  data, not embedded in markup. Templates render data and nothing else.
+- **Every** user-visible string is authored as data — collection entries and
+  standalone pages alike (an About page, a policy page, a marketing page).
+  Templates render data and nothing else. The only prose that may live in a
+  template is copy bound to a mechanism that same template implements — a
+  generated disclosure list's heading, a consent notice whose wording must track
+  real behaviour; the impl doc names these cases. The test: could a non-developer
+  rewrite this sentence without risking a guarantee? If yes, it is data.
 - A validator runs before the build completes and **exits non-zero** on any
   error, printing every error (not just the first), each as `path: expected X`.
 - Validation covers: required keys present; correct types; enum values; **unique
@@ -107,11 +112,21 @@ a build-time schema gate hard-fails the build on invalid content.
 - Where non-developers edit content, provide editor-time validation (a schema
   the editor understands) in addition to the build gate; a Git-backed CMS over
   the same data files is acceptable — a separate database for site content is
-  not. Where an **LLM agent** edits the data files directly, it follows a
-  documented per-project content-ops protocol: what it may change (the content
-  files, not code or structure), a pre-commit content check (the
-  content-relevant slice of the gate), and a `content:` commit convention. See
-  your stack's impl doc.
+  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.
+- 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.
 - **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.
@@ -121,7 +136,9 @@ a build-time schema gate hard-fails the build on invalid content.
 
 **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
-calculator whose copy says "18%" while the code uses 15%).
+calculator whose copy says "18%" while the code uses 15%). A written, authoritative
+reserved set is what lets a builder and a separate content operation work the
+same repo without overwriting each other or leaving a request unanswered.
 
 **Verify.** The gate fails the build on invalid content. The audit page shows
 validation status.
@@ -1283,12 +1300,14 @@ records the result. "The gate passing" is the definition of compliant.
 project), before non-trivial work. Ask five questions with defaults:
 
 1. **Framework?** Eleventy + Netlify *(default)* · Elixir/Phoenix *(when a
-   database or server-side state is in scope — `#beyond-this-standard`)* · other
-   *(→ no binding exists; use this file as principles and do what is idiomatic
-   for the technology)*. `stacks/sveltekit.md` is a **parked** stub — its
-   friction points and open questions are written, the per-section "how" is not;
-   it is not on offer here until a real project forces those decisions, so
-   treat SvelteKit as "other" for now.
+   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)*.
 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.)
@@ -1317,7 +1336,10 @@ 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
 `templates/concept-brief.md` (the idea, the answers above, a concept-level
-brand, the content model, layout notes) — `README.md` has the hand-off.
+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)
+filed *before* the build — resolved as a new binding, or the nearest stack with
+the compromise recorded.
 
 **Record** the result near the top of the project's `.claude/CLAUDE.md` /
 `AGENTS.md` as a `## House style` section — a directive paragraph plus a data
@@ -1359,13 +1381,26 @@ governs it and follow that chapter — the slugs are the index (a `<script>` →
 - production-url: https://example.com
 - content-type: tool           # tool | article  (article => feeds)
 - publishing-rate: ~5 pages/week
-- standard-version: 2026-09-02  # recommended — enables standard-version drift tracking (#compliance)
+- standard-version: 2026-09-03  # recommended — enables standard-version drift tracking (#compliance)
 ```
 
 If the section is absent, the assistant's first action is to run the flow above
 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
+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
+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.
+
 **Onboarding an existing project** — after recording the section, run
 `#compliance`. Every `FAIL` and `MANUAL` becomes a migration-backlog item,
 worked incrementally (the impl doc's migration path is the ordered version of