Skip to content

Session handover — 2026-09-02 pt2

Continues pt1, which ended with the 0.35.0 branch unmerged and garvanbay unprepared. Both are closed. The session then turned on a question the owner raised before any labelling starts: the website team will be asked to score output — can they actually fix what they mark? Three measurements answer it, and one live exposure was closed on the way.

Short version: words yes, pictures mostly no — and the picture half turns out to be a missing database row, not a missing feature.

Where to look

  • known-issues, read in this order:
  • "Editor readiness audit" — what an operator can actually change in the deployed admin, and the scoring rubric that falls out of it. That rubric, not the bug list, is the output that matters for Slice 6.
  • "Fix-it test — can an operator take the corpus's WORST site to shippable?" — the audit executed end-to-end on bkalarms (composite 76, the corpus floor). Text defect fixed by editor alone; image defect blocked.
  • "The media library is empty because nothing registers it" — measured on live garvanbay: emdash serves whatever storage_key a media row carries, so pipeline images can be listed in the editor's library by a plain D1 insert, no re-upload. What it fixes and what it does not.
  • "Per-site static build hardcodes noindex,nofollow" — carries a dated correction: the old line "so CMS-served pages are indexable" was true, and was the exposure.
  • "emdash 0.35.0 rollout" — updated with garvanbay's result and the node_modules-vs-package.json trap that cost a deploy.
  • known-patterns — the leftover-local-server entry gained the mechanism: stopping a background task does not kill its process tree, and a sweep filtered by working directory misses the survivors (npm workspaces hoist).

What shipped

commit what
4804d1b garvanbay recovery anchors taken before touching it — D1 export, Time Travel bookmark, rollback version id
f340d89 correction: garvanbay does have a wix_site_id (wiki had said otherwise since 2026-07-13)
5740de9 garvanbay upgraded to emdash 0.35.0 — migrations 050 → 070, content identical (10 pages / 1 global / 87 revisions), render identical to the pre-upgrade capture, same build hash as WCP
00bb608 editor readiness audit written up
046757f noindex gate for the whole CMS lane, opt-IN per site

The 0.35.0 branch is merged into master and pushed — the drift pt1 flagged as "the one actively dangerous item" is gone.

The noindex gate, since it touches every future site: Base.astro emits noindex, nofollow and src/pages/robots.txt.ts serves Disallow: / unless the site's descriptor says "indexable": true. The flag rides from sites/<site>.jsonc through emit-wrangler.mjs into a wrangler var, and into the build via a Vite define — Astro inlines PUBLIC_* at build time, so a runtime var alone would not have worked. Default is off, so a new corpus site or demo inherits protection without anyone remembering. Verified live on both: emdash.dcathal.org and wcp.dcathal.org return the meta tag and a disallowing robots.txt. Deployed versions now garvanbay 3cbf5996, WCP d9103259.

bkalarms was added as a local-only site (sites/bkalarms.jsonc + seed/bkalarms.json) for the fix-it test — TODO_PROVISION account/AUD, synthetic D1 id, nothing on Cloudflare.

The honest parts

  • A deploy went out believing it was 0.35.0 and was 0.28.1. A killed npm install had rolled node_modules back while package.json and the lockfile read 0.35.0. It deployed cleanly with the right render — the only tells were the admin footer and migrations not running. Check the installed version, not the declared one.
  • The media-library test wrote to garvanbay's live D1. One row, inserted to prove the point, then deleted; the library is back to its original 2 items and nothing on the site changed. Doing that on a live reference site was avoidable and should not become the habit.
  • The editor findings are from the rendered admin, not the schema. They describe what 0.35.0 shows an operator today, not what Block-Kit could be configured to show.
  • The repeater-picker question is still UNTESTED. Whether media_picker can nest inside a repeater is the hinge for converting a large class of hold into polish, and nobody has measured it. Do not scope a slice against it without measuring first.
  • WCP was not audited — carousel, hero video and split-center chrome are unexercised by garvanbay. The owner asked for WCP next and it did not happen.
  • Nothing here advanced Slice 6 itself. The corpus gate is still waiting on human labels.

Next

  1. The labels — unchanged as the sole Slice-6 blocker, and now with a written rubric behind them: open calibration/review.html, label the 15 SHIP candidates, save calibration/labels.csv, then fit-calibration → review → promote only if fitted:true and precision holds.
  2. Run the same editor audit on WCP before the team is asked to score anything.
  3. Measure whether media_picker nests in a repeater. One command's worth of evidence decides whether the grid/gallery image problem is a fix or a permanent constraint.
  4. Decide where media registration belongs (build step vs deploy step), how it behaves on rebuild, and whether alt text is seeded with it — worth more to the team than thumbnails. Measurement is banked; no slice scoped.
  5. Still open from pt1: WCP's admin branding says garvanbay (a D1 settings row — surgical, never a reseed).