Skip to content

Session handover — 2026-09-02 pt3

Continues pt2, which ended having measured that the media library could be stocked from a plain D1 insert but not having done it. It is done, it runs on its own now, and the session then turned to an SEO ask that turned out to be half already-solved.

Nothing here advanced Slice 6. The corpus gate is still waiting on human labels — five sessions running.

Where to look

Three entries in known-issues, each rewritten from "measured" to "shipped":

  • "The media library is empty because nothing registers it" — now carries the shipped script, the per-site counts, and the deploy wiring with its failure table.
  • "Structured data: FAQPage + WebSite added, LocalBusiness strengthened — and slugs already match the originals" — new. Read the slug table first; it is the answer to a question that needed no work.
  • "Editor readiness audit" — its rubric block gained a dated update: a wrong repeater image is still not polish, but the reason changed.

known-patterns — the tenant-swap entry gained a corollary about global.css diffs being noise, written because it cost a diagnosis detour here.

What shipped

commit what
bcb90b5 register-media.mjs + both live libraries stocked (garvanbay 2 → 33, WCP 0 → 300)
e19d74a registration runs automatically as postdeploy
e448ca2 FAQPage + WebSite JSON-LD, LocalBusiness @id + sameAs

Media registration. Lists the site's R2 prefix, skips keys already in media, inserts the rest — no bytes move. Names and alt come from the site's own content, so the library reads about-team-grid-tom-holmes-bbs-fcca.jpg rather than a Wix media id, and searching team-grid returns exactly the four staff headshots under their own names. That was the editor audit's worst case. Dry-run by default; idempotent; each applied run writes builds/<domain>/media-registered.json — the exact ids plus a ready-made DELETE, written before the first insert so a half-failed run still leaves a complete list. That manifest is deliberately un-gitignored: it is the undo for a write to a live database.

Deploy wiring. SITE=<site> npm run deploy now stocks the library on its own. Post-deploy mode changes the failure contract and only that: the worker is already live, so nothing there fails the deploy — every failure degrades to a boxed warning naming the exact re-run command, which run directly is fatal as normal. Exercised: unreachable R2, unknown SITE, empty-D1 warm-up path, no-op re-run, and npm's postdeploy hook itself.

Structured data. FAQPage was the real gap — WCP has FAQ accordions on 20 pages and neither our build nor the client's own Wix site marked up any of them. We now emit more structured data than the sites we replatformed. Deployed garvanbay 2676de57, WCP 63cda928.

The honest parts

  • Two live databases were written to (331 rows across garvanbay and WCP). Additive, never updating or deleting, and each has an exact undo manifest — but it is a live write and the reviewer should know it happened.
  • 118 of WCP's 300 registered images are referenced by no page. Registering them is deliberate (when the build placed the wrong photo, the right one is often among them) but they keep Wix-id filenames, so only the labelled 182 are searchable.
  • wfpainters/ (188 objects) is a stale duplicate prefix in R2. Nothing live points at it. Not deleted — nobody has traced what else might read it.
  • Registration does not cover a rebuild replacing an image, and a reseed can introduce new images without a deploy. Neither bites today; both will when a live site is rebuilt.
  • The sameAs fallback infers identity from the site's own links. Hosts are parsed rather than pattern-matched, so a stray string cannot become a claim about the client — but it is still an inference, and a site linking to someone else's profile would inherit it.
  • Garvanbay is missing /blog, which the client has. Any site with a blog has the same hole.
  • None of the SEO work is being read yet — both workers are noindex, correctly. And Google restricted FAQ rich results to gov/health in 2023, so this is not a rich-snippet win and should not be sold to a client as one.
  • WCP still has no editor audit, asked for two handovers ago now.

Next

  1. The labels. Unchanged, and the only thing on the critical path: 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. Editor audit on WCP — carousel, hero video and split-center chrome, none of which garvanbay exercises.
  3. Measure whether media_picker nests in a repeater. Still the hinge between a large class of hold and polish, still unmeasured, still must not be scoped against blind.
  4. Decide what happens to a registered media row whose object a rebuild replaces.
  5. ~~WCP's admin branding says garvanbay~~ — fixed in this session. The name lives in D1's options table in two rows (site:title + emdash:site_title), not in _emdash_collections as the earlier correction guessed; emdash copies it from the baked seed once at first setup, so no rebuild could ever have repaired it. Corrected with a surgical UPDATE, verified in the deployed admin, old value recorded in known-issues.