Fix the stale round-trip-test path in the generate-landing SKILL.md

The marketing landing becomes a tailorable per-client template — a typed LandingContent model rendered by LandingPage.astro; the Dossier render stays byte-for-byte identical; client instances are values of the same type, canonical in the client's own repo, generated by the generate-landing skill shipped the generate-landing skill (.claude/skills/generate-landing/SKILL.md), whose contract tells an authoring agent that the round-trip proof lives at packages/site/src/content/landing/dossier.roundtrip.test.ts.

The drift

That file does not exist. The real test is packages/site/test/landing-dossier-roundtrip.test.ts. Its own header comment is explicit about why:

Co-located under packages/site/test so the root vitest include glob (packages/*/test/) runs it in CI — moved here from src/content/landing/, where it was silently skipped (the glob only matches packages//test/).

So the skill was written against the pre-move path and never updated. An agent following the skill verbatim would Read a path that resolves to nothing — link rot in a contract document.

Expanded 2026-06-17 — the whole content model moved (DEC-0043 Phase 4)

What started as a single stale test path is now a broader path migration. Migrate chrome-light app surfaces to SvelteKit; docs stay on Astro/Starlight (two apps, one origin) Phase 4 moved the entire landing content model from packages/site/src/content/landing/ to packages/app/src/lib/content/landing/ (plain framework-agnostic TS — the SSOT), moved the tests to packages/app/test/, ported the components (LandingPage/HeroLoop/CaptureForm) to .svelte in @dossier/app, and replaced astro check with pnpm -F @dossier/app check and the Astro preview page with a SvelteKit route. So nearly every concrete path in SKILL.md — the contract (schema.ts), the reference instance (dossier.ts), the round-trip proof, the template files, and the Verify build commands — now points at the old packages/site location, and DEC-0037's prose (lines naming content/landing/{schema,dossier}.ts, LandingPage.astro, index.astro, content.config.ts) is stale the same way. The FDE surfaced this at migration time ("may break the generate-landing skill + a few knowledge refs … surfaced, not chased"); the log-auditor folded it into this existing task rather than filing a near-duplicate (single source of truth for the skill's link rot) and re-pointed the assignee to the Principal SvelteKit Engineer, who now owns the @dossier/app landing surface.

Why a task, not a fix-in-place

The skill is a contract document and DEC-0037 is a decision record; re-pointing every path to the new @dossier/app location, confirming each resolves, reconciling the decision prose, and confirming tokenizeOkf still resolves is a multi-reference pass with a small judgment (where the helper lives now) — better owned by the surface owner than patched blind by the auditor. Provenance: originally surfaced by the log-auditor auditing The marketing landing becomes a tailorable per-client template — a typed LandingContent model rendered by LandingPage.astro; the Dossier render stays byte-for-byte identical; client instances are values of the same type, canonical in the client's own repo, generated by the generate-landing skill (stale test path), expanded when Migrate chrome-light app surfaces to SvelteKit; docs stay on Astro/Starlight (two apps, one origin) moved the model; confidence: inferred (agent-verified against the filesystem, not human-curated).

Closed 2026-06-17

Re-pointed every path in .claude/skills/generate-landing/SKILL.md to the post-DEC-0043 homes — the contract/reference/round-trip under packages/app/src/lib/content/landing/ + packages/app/test/, the .svelte components, the examples/registry.ts registration, and the svelte-check / vite build / dev-only SvelteKit preview/[client] toolchain — and verified grep of the skill for the old packages/site/.astro/content.config/DOCS_ENABLED/@dossier/site strings returns 0. Reconciled The marketing landing becomes a tailorable per-client template — a typed LandingContent model rendered by LandingPage.astro; the Dossier render stays byte-for-byte identical; client instances are values of the same type, canonical in the client's own repo, generated by the generate-landing skill with a path-update note (preserving the historical ADR per the layered-history convention) and marked its routed follow-up resolved. The one open thread: a wording-softening edit for the tokenizeOkf helper was declined by the permission auto-classifier as agent-config modification — non-blocking (it's a function name, not a broken file path), left for explicit user OK. Closed by the Principal Forward Deployed Engineer.

Addendum 2026-06-17 — a related field-path drift fixed in place (task stays done)

The The marketing landing becomes a tailorable per-client template — a typed LandingContent model rendered by LandingPage.astro; the Dossier render stays byte-for-byte identical; client instances are values of the same type, canonical in the client's own repo, generated by the generate-landing skill landing polish pass (same day, after this task closed) relocated the hero artifact field from LandingContent.hero.artifact to LandingContent.okf.artifact (the real atom moved out of the hero and into the new OKF explainer beat). That made one cell of SKILL.md's field-source table — hero.artifact (line 37) — stale again. Because this task was already done and its scope was the packages/site → packages/app path migration (a different drift), the log-auditor did not re-open or recycle it (ids/states are not recycled). The one-token correction (hero.artifact → okf.artifact, plus a note that the field now lives on okf) was a fix-in-place the auditor owns; recorded here so the skill's link-rot history stays single-source-of-truth, and captured in the DEC-0037 content-contract-extension note. No code/contract resolves to a nonexistent path.