@piercebarney/whs-eleventy 2026.10.21 → 2026.10.23

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@piercebarney/whs-eleventy",
-  "version": "2026.10.21",
+  "version": "2026.10.23",
   "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"
@@ -31,7 +31,7 @@
     "node": ">=22"
   },
   "dependencies": {
-    "@piercebarney/whs-core": ">=2026.10.21",
+    "@piercebarney/whs-core": ">=2026.10.23",
     "node-html-parser": "^9.0.2"
   },
   "devDependencies": {

package/standard/CHANGELOG.md

@@ -23,6 +23,266 @@ enforced, new *opt-in* chapters/capabilities, tooling-only changes — is
 
 ---
 
+## 2026-10-23 [non-breaking]
+
+Release 2b's first slice of SvelteKit stack parity
+(`BACKLOG.md#sveltekit-tooling-parity`): a status-only `@piercebarney/whs-sveltekit`
+package, `/whs:upgrade` for this stack, and the `SessionStart` drift hook —
+the same shape Eleventy's own drift tooling has, minus the compliance sweep
+(still to come). No behaviour change for Eleventy or Phoenix.
+
+**Action for SvelteKit projects (one-time bootstrap):** a project scaffolded
+before this release predates `/whs:upgrade`. Copy
+`templates/sveltekit-netlify/.claude/commands/whs/upgrade.md` and
+`templates/sveltekit-netlify/.claude/hooks/standard-drift.sh` into the
+project verbatim, add the `SessionStart` hook entry from
+`templates/sveltekit-netlify/.claude/settings.json` to the project's own
+`.claude/settings.json` (merged in without disturbing any other hook already
+configured there), add `"@piercebarney/whs-sveltekit": ">=2026.10.23"` to
+`devDependencies` and `"status": "whs status"` to `scripts` in
+`package.json`, then `npm install`. After this one-time step, `/whs:upgrade`
+handles every later release on its own.
+
+### packages/whs-sveltekit (new)
+
+A new, thin per-stack npm package (`@piercebarney/whs-sveltekit`,
+`>=2026.10.23` on `@piercebarney/whs-core`) — status only. `cli.js` supports
+`status` and `--version` (an unknown subcommand prints usage, matching
+`whs-eleventy`'s). `lib/status.js` wires `@piercebarney/whs-core`'s
+stack-agnostic `runStatus` with `instructionsFile: "AGENTS.md"`,
+`toolingName: "@piercebarney/whs-sveltekit"`, `bindingMarkers` for
+`### stacks/sveltekit-netlify.md`, `### stacks/sveltekit-netlify`, the
+legacy `### stacks/sveltekit.md`, `### templates/sveltekit-netlify`,
+`### packages/whs-sveltekit`, and `### packages/whs-core`, no dashboard
+(`null` loader), and an `upgradeHint` that names the bootstrap copy steps
+above when `.claude/commands/whs/upgrade.md` is absent from the project. No
+`compliance`, `doctor`, `a11y`, or link-check command exists yet — see
+`stacks/sveltekit-netlify.md#compliance` and the remaining scope on
+`BACKLOG.md#sveltekit-tooling-parity`. Tests cover: the pin read from
+`AGENTS.md`, SvelteKit sections surfacing while Eleventy-only sections
+don't, hook silence when current, and the `--version` string.
+
+### templates/sveltekit-netlify
+
+- `package.json` — `devDependencies` gains
+  `"@piercebarney/whs-sveltekit": "file:../../packages/whs-sveltekit"` and
+  `scripts` gains `"status": "whs status"`.
+- `.claude/hooks/standard-drift.sh` (new) — the same best-effort,
+  never-blocking `SessionStart` drift check Eleventy's own hook runs, via
+  `node_modules/.bin/whs status --hook`.
+- `.claude/settings.json` — a `SessionStart` entry running the new hook,
+  keeping every hook already configured there.
+- `.claude/commands/whs/upgrade.md` (new) — adapted from Eleventy's: reads
+  the `### core:`, `### stacks/sveltekit-netlify(.md)`,
+  `### templates/sveltekit-netlify`, `### packages/whs-sveltekit`,
+  `### packages/whs-core`, and `### module: <name>` CHANGELOG headings in
+  scope; step 3 builds its backlog from `npm run status`'s re-check rows
+  plus each in-scope entry's own "action for projects" prose, since no
+  `npm run compliance` exists yet (says so plainly, points at
+  `BACKLOG.md#sveltekit-tooling-parity`); the rest of the flow (agents,
+  block-or-proceed, verify, re-pin, never deploys) is unchanged from
+  Eleventy's.
+- `bin/init` — a new `pinTooling()` rewrites the `file:` dev dependency on
+  `@piercebarney/whs-sveltekit` to a `>=<dotted pin>` range matching
+  `AGENTS.md`'s `standard-version` and drops the lockfile before
+  `npm install`, same fix as Eleventy's `bin/init`.
+- `AGENTS.md` / `TEMPLATE.md` — mention `/whs:upgrade` and `npm run status`.
+
+### stacks/sveltekit-netlify.md
+
+Closes the "no drift tooling / no `/whs:upgrade`" banners in `#adopting` and
+partly in `#compliance`. `status` stays `draft` in `index.json` — compliance
+still isn't there.
+
+### .github/workflows/publish.yml, .claude/agents/sveltekit.md, .claude/hooks/agent-only.js, CLAUDE.md, templates/commands/whs/adopt.md
+
+- `.github/workflows/publish.yml` — a new `sveltekit` job (`needs: core`),
+  mirroring the `eleventy` job: root `npm ci`, check, tag↔version agreement,
+  `npm view` skip, `npm publish` from `packages/whs-sveltekit`. No-ops
+  cleanly if the package directory is absent, like `core`'s own job.
+- `.claude/agents/sveltekit.md` — territory gains `packages/whs-sveltekit/**`
+  (the thin per-stack package, mirroring how `eleventy` owns
+  `packages/whs-eleventy/`); `packages/whs-core/` stays the `tooling`
+  agent's territory, named explicitly so it's clear this agent doesn't touch
+  it.
+- Root `CLAUDE.md` and `.claude/hooks/agent-only.js`'s `DELEGATE_HINT`
+  (above the hand-copied marker only) — routing updated to name
+  `packages/whs-sveltekit` under `sveltekit` and to name both
+  `packages/whs-eleventy` and `packages/whs-sveltekit` as the packages
+  `packages/whs-core`'s stack-agnostic logic serves.
+- `templates/commands/whs/adopt.md` — the SvelteKit tier now also wires in
+  the `@piercebarney/whs-sveltekit` devDependency (`>=` the published
+  version), the `status` script, `.claude/hooks/standard-drift.sh` plus its
+  `SessionStart` settings entry, and `.claude/commands/whs/upgrade.md` —
+  the same status-only slice this release ships for a freshly-scaffolded
+  project.
+
+### BACKLOG.md
+
+- `sveltekit-tooling-parity` — notes `status` / `/whs:upgrade` / the drift
+  hook shipped in this release; remaining scope is the compliance sweep,
+  `/audit/` tabs, deploy preflight, `deploy.yml`, `.env.example`, and the
+  reduced-motion check-scope fix.
+- New `ready` entry `eleventy-status-package-markers` (source: request,
+  owner, filed 2026-09-29 — no `feedback/` note; found directly while
+  reviewing whs-sveltekit's status markers): `packages/whs-eleventy/lib/status.js`
+  has no `bindingMarkers` for `### packages/whs-eleventy` /
+  `### packages/whs-core`, so a package-only CHANGELOG date block yields
+  zero `whs status` rows for Eleventy (verified against the 2026-10-21
+  block) — fix is the same markers plus tests, and the "`status` is a
+  helper, not the ground truth" step-3 wording this release added to
+  SvelteKit's `upgrade.md`, ported to
+  `templates/eleventy-netlify/.claude/commands/whs/upgrade.md`.
+
+Nothing closes here — `sveltekit-tooling-parity` stays open for its
+remaining scope.
+
+## 2026-10-22 [breaking]
+
+Inbox triage release: fixes a SvelteKit `build.ts` bug that made the
+`#noindex` "Layer 1, verified working" claim false for the client bundle —
+"corrects a documented mechanism that didn't actually work," per this file's
+own breaking definition. Also lands the two-way `requests/` drawer +
+placeholder rule (`core.md#content-model`) across every stack, a new
+SvelteKit `pages` binding, and the CI/verify plumbing to actually run a
+SvelteKit add-on's tests.
+
+**Action for SvelteKit projects:** replace `src/lib/build.ts` with the
+version below and add the `envPrefix: ['VITE_', 'DEPLOY_TARGET']` line to
+`vite.config.ts`, as documented in `stacks/sveltekit-netlify.md#noindex` /
+`#config-idiom`. A project with `content-ops: reserved` should also adopt
+the two-way `requests/` wording (`requests/README.md`, `CONTENT.md`,
+`.claude/agents/content.md`).
+
+### core: content-model
+
+The escalation channel (`requests/`) is now explicitly **two-way**: content
+→ build (a structural change the content arm can't make) and build →
+content (the build needs content it isn't allowed to author — e.g. a schema
+gains a required field with no real copy behind it yet). A new
+**build → content placeholder rule** is the sole exception to the reserved
+set's read-only rule: the build writes only a clearly-marked `[COPY
+PENDING]` placeholder (never authored prose) into each newly-required
+field, flags the entry as a draft wherever the schema allows so it can't
+publish, and files the `requests/` note listing each field; the content arm
+replaces the placeholders and clears the draft flag. Verify line added: a
+production build contains no `[COPY PENDING]` text.
+
+### templates/sveltekit-netlify
+
+- **`src/lib/build.ts` / `vite.config.ts`** — `isProduction` now reads
+  `import.meta.env.DEPLOY_TARGET` instead of `process.env.DEPLOY_TARGET`,
+  with `envPrefix: ['VITE_', 'DEPLOY_TARGET']` added to `vite.config.ts` so
+  the existing `DEPLOY_TARGET` env var (unchanged — `bin/deploy`/CI keep
+  setting it the same way) is populated identically in the server bundle, a
+  real production client bundle, and the plain dev server. `process.env`
+  reads don't survive Vite's classic unbundled `vite dev` for client code at
+  all (crashes with `process is not defined`) and silently evaluate to `{}`
+  in a bundled client build (always `false`, regardless of the real
+  `DEPLOY_TARGET`) — so a production page kept re-adding the noindex meta
+  and showing draft links after hydration. `$env/static/public` was weighed
+  and rejected: it would need either renaming the var to
+  `PUBLIC_DEPLOY_TARGET` or widening `kit.env.publicPrefix`, a single string
+  that can't also keep matching `PUBLIC_`. `envPrefix` matches by
+  `startsWith`, not exact name, so this array exposes exactly
+  `DEPLOY_TARGET` to the client bundle — a future client-exposed var is
+  added by its own full name, never by widening either entry to a broad
+  prefix like `'DEPLOY_'`, which would inline every matching var, secret or
+  not.
+- **`.claude/agents/brand.md` / `stacks/sveltekit-netlify.md#styling`** —
+  the `tailwind-shadcn` recipe now documents `shadcn-svelte@1.7.0`'s real
+  `init` flow: a two-step preset menu (curated-list vs. one-by-one, then the
+  eight named presets with Vega pre-highlighted), followed by an unrelated
+  `layout.css` overwrite confirmation — not the single default-highlighted
+  prompt previously described. States plainly that the CLI is **not
+  pipe-scriptable** (clack's TUI needs a real pty; a plain pipe or `yes`
+  just hangs with no error) and gives an `expect` recipe that sizes the pty
+  with `stty rows/columns` before sending input and waits on rendered
+  anchor text per screen.
+- **Two-way `requests/`** — `requests/README.md`, `CONTENT.md`,
+  `.claude/agents/content.md` all now document both directions and the
+  placeholder rule, matching the `core.md#content-model` update above.
+- **`add-ons/pages/` (new)** — the `pages` marketing-blocks module's
+  SvelteKit binding (see `### module: pages` below): zod block schemas
+  (`hero`, `feature-list`, `cta`) plus a prose section and `include` marker,
+  a `Body.svelte` renderer and one Svelte component per block type
+  (structure-only, CSP-safe, no inline styles/scripts), the module's shared
+  `pages.schema.blocks.json` vendored byte-identical, a `CONTENT.pages.md`
+  addendum for reserved projects, and vitest tests against the module's
+  shared fixtures (`pages.blocks.test.ts`, 14 tests).
+
+### stacks/sveltekit-netlify.md
+
+`#noindex` Layer 1 and `#config-idiom` updated to match the `build.ts` fix
+above; the "verified working" claim now says it's checked after hydration
+in a real browser, not just a diff of two builds' prerendered `index.html`.
+`#content-model` mirrors the two-way `requests/` + placeholder rule.
+`#styling`'s `tailwind-shadcn` recipe corrected per the `shadcn-svelte`
+entry above.
+
+### module: pages
+
+New binding: `templates/sveltekit-netlify/add-ons/pages/`, following
+`modules/pages/MODULE.md` and mirroring the shape of
+`templates/eleventy-netlify/add-ons/pages/`. `modules/README.md`'s index
+now lists `sveltekit-netlify` for `pages`.
+
+### templates/eleventy-netlify / stacks/eleventy-netlify.md
+
+Wording-only recheck of the `#content-model` mirror for the two-way
+`requests/` + placeholder rule — no mechanism change.
+`templates/eleventy-netlify/requests/README.md`, `CONTENT.md`, and
+`.claude/agents/content.md` updated to match. Also corrects the **Drafts**
+bullet in `stacks/eleventy-netlify.md`: draft state is a `draft` boolean
+field on the content-model entry itself (`src/content/schema.js`), not
+frontmatter — each domain's directory-data file computes
+`isSuppressedDraft` and suppresses production/collection inclusion
+accordingly.
+
+### bin/check
+
+Sterility allowlist gains `shadcn-svelte\.com` alongside the existing
+CSS-tooling domains (`daisyui.com`, `tailwindcss.com`, `heroicons.com`) —
+it's the real CLI's own prompt text, quoted verbatim in
+`stacks/sveltekit-netlify.md`.
+
+### templates/verify.sh, .github/workflows/standard.yml
+
+Both now run a SvelteKit template's own `add-ons/*/*.test.*` files when
+present, matching the eleventy branch's `node --test
+add-ons/*/test/*.test.js` intent for this stack's runner (vitest). Neither
+`npm run check` nor the project's own `vite.config.ts` (its `test.projects`
+workspace scopes `include` to `src/**/*`) reaches add-on sources before
+they're copied into the project, so each now writes a throwaway vitest
+config (outside the template's own workspace-projects setup, so its
+`src/`-only `include` doesn't shadow it) scoped to `add-ons/**/*.{test,spec}.{js,ts}`
+and runs it with `npx vitest run --config <tmp file>` — no file under
+`templates/sveltekit-netlify/` changed. Verified against
+`add-ons/pages/pages.blocks.test.ts`: 14 tests pass.
+
+### BACKLOG.md
+
+- New `ready` entry `commit-early-often` (source: request, owner,
+  2026-09-28): a commit-cadence rule (distinct from `core.md`'s existing
+  commit-granularity rule), with the filed note's open questions carried
+  over verbatim.
+- `sveltekit-tooling-parity` gains `covenant-in-color` to `requested-by:`,
+  `reduced-motion-check-scope` to `aliases:`, and a line on the fix: `whs
+  compliance`'s `#a11y` reduced-motion check only scans `src/`, `static/`,
+  `scripts/` for CSS `transition`/`animation`, missing a root-level authored
+  stylesheet/script and JS-driven smooth scroll (`scrollIntoView({ behavior:
+  "smooth" })`) — folds into `whs-core`'s shared a11y check (CSS
+  `scroll-behavior`, a crude JS smooth-scroll match, and root-level
+  authored `*.css`/`*.js`) during Release 2b, not a per-stack fix.
+
+The `feedback/2026-09-27-reduced-motion-check-scope.md` and
+`needs/2026-09-28-commit-early-often.md` notes are folded/backlogged, not
+closed — no slug for either below.
+
+**Closes:** build-ts-process-env-in-client, shadcn-init-not-scriptable-by-pipe,
+requests-drawer-one-directional, sveltekit-pages-binding,
+sveltekit-envprefix-too-broad
+
 ## 2026-10-21 [non-breaking]
 
 Release 2a of SvelteKit stack parity (`BACKLOG.md#sveltekit-tooling-parity`):

package/standard/core.md

@@ -1,6 +1,6 @@
 # Web project house style — CORE (stack-agnostic)
 
-**Version:** 2026-10-21 · **Status:** active
+**Version:** 2026-10-23 · **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
@@ -127,18 +127,31 @@ a build-time schema gate hard-fails the build on invalid content.
   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.
+  through the project's escalation channel, never a direct edit — the sole
+  exception is the placeholder rule below. 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. 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
+  outside that set; a `content:` commit convention; and a **two-way escalation
+  channel** for anything structural, so a blocked request is recorded, not
+  lost — content → build when the content arm needs a structural change it
+  isn't allowed to make itself; build → content when the build needs content
+  it isn't allowed to author (a schema gains a required field whose real copy
+  must come from the reserved content operation). 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.
+- **Build → content placeholder rule** is the sole exception to the reserved
+  set's read-only rule above. Filing a build → content request does not block
+  the build on an answer: it files a build → content escalation note listing
+  every affected field, writes only a clearly-marked `[COPY PENDING]`
+  placeholder — never authored prose — into exactly those fields, and flags
+  the entry as a draft wherever the schema allows so it can't publish. The
+  content arm supplies the real copy, replaces each placeholder, and clears
+  the draft flag.
 - **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.
@@ -165,7 +178,7 @@ 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.
+validation status. A production build contains no `[COPY PENDING]` text.
 
 **Implementation.** See your stack's impl doc, same slug.
 
@@ -1541,7 +1554,7 @@ governs it and follow that chapter — the slugs are the index (a `<script>` →
 - content-type: tool           # tool | article  (article => feeds)
 - add-ons: none                # or: comma list of modules/ packs no field above implies (calculator, glossary, pages) — see modules/README.md
 - publishing-rate: ~5 pages/week
-- standard-version: 2026-10-21  # recommended — enables standard-version drift tracking (#compliance)
+- standard-version: 2026-10-23  # recommended — enables standard-version drift tracking (#compliance)
 
 <!-- optional, present only while a filed need is unresolved -->
 ### Waiting on the standard