feat(schemas): add a fail-closed consumer schema registry

[forkwright]

Finding

typikon-validate recognized only six built-in content classes. Any file whose frontmatter set a template typikon does not ship — or whose path a consumer wanted to route independently — fell through classify() to page.schema.json, whose extra object accepted any additional field without checking its type. A typo such as kanon_ci = "false" (string, not boolean) was schema-valid and became truthy wherever a consumer template did bool(...) on it.

Evidence

• bin/typikon-validate (pre-fix) classify(): TEMPLATE_SCHEMA_MAP covered only faq.html/sizing-guide.html; every other custom template fell through path-based routing to page.
• schemas/page.schema.json and schemas/section.schema.json (pre-fix): extra.additionalProperties: true — any field beyond the named ones passed unchecked.
• docs/AGENTIC.md:20 (unchanged by this PR): "Do not invent fields. If a frontmatter field is not in the schema, do not write it." — the permissive extra directly contradicted typikon's own stated contract.

Desired correction (delivered)

• schemas/page.core.schema.json, schemas/section.core.schema.json: open building blocks (no additionalProperties/unevaluatedProperties anywhere) holding every field the closed wrappers declare.
• schemas/page.schema.json, schemas/section.schema.json: rewritten as thin closed wrappers — allOf: [{$ref: <core>}] plus a second allOf+$ref on extra, each closed once with unevaluatedProperties: false.
• schemas/journal-entry.schema.json, schemas/product.schema.json: extra.additionalProperties flipped true → false directly (no consumer needs to extend these yet).
• bin/typikon-validate: load_consumer_registry() reads <consumer-root>/schemas/registry.toml; classify() raises UnregisteredTemplateError for a template neither typikon's own nor registered.
• 15 cases in ci/check-consumer-schema-registry.py, each invoking the real CLI as a subprocess against a throwaway consumer tree.
• docs/SCHEMAS.md, docs/AGENTIC.md, CLAUDE.md (+ _llm/decisions.toml, _llm/glossary.toml): document the registry and the composition pattern.

---

Adversarial review found this incomplete. Three findings, addressed below — all three, no scope reduction.

Finding 1 — the issue's own Done-when was unverified: no real consumer was ever run through the mechanism

Correct. The original PR built the registry, closed the schemas, and proved it against synthetic fixtures — but never ran the actual validator against either real typikon consumer's actual content. That gap is now closed, against both real consumers, with the evidence a reviewer needs to disprove it:

forkwright/ardent-site (Ardent Leatherworks) — no custom templates, so it needs no registry, but closing page/section/journal-entry/product is a real behavior change for it. Running this branch's validator against a fresh clone of its real content, pre-fix:

{"file": "content/_index.md", "schema": "section", "pointer": "/extra", "error": "Unevaluated properties are not allowed ('template' was unexpected)"}
{"file": "content/sizing/_index.md", "schema": "section", "pointer": "/extra", "error": "Unevaluated properties are not allowed ('seo_title' was unexpected)"}
{"checked": 23, "passed": 21, "failed": 2}

Both are real, previously-undetectable bugs this PR's closure surfaces — not this repo's content to fix silently:

1. content/_index.md had template = "index.html" nested inside [extra] by mistake (a TOML authoring error — the real top-level template field was therefore unset, silently falling back to a section default, while the stray extra.template did nothing). Fixed in forkwright/ardent-site#35.
2. section.core.schema.json never declared seo_title, even though templates/section.html, templates/index.html, and templates/journal-section.html (typikon's own theme, not consumer-specific — verified by reading all three) all read section.extra.seo_title | default(value=section.title), the same override page.core already declares. Fixed here in this PR (schemas/section.core.schema.json) — a real omission in the schema this PR itself introduces, not a pre-existing issue.

With both fixed, this branch's validator against ardent-site's real content:

{"checked": 23, "passed": 23, "failed": 0}

ardent-tools/ardent-tools-site (Ardent Tools — the consumer issue #60 names by its five templates: home, consulting, evidence, systems index, system dossier; the reviewer correctly found no such repo in the forkwright org, because it lives under the separate ardent-tools org, not forkwright — confirmed real via gh api repos/ardent-tools/ardent-tools-site and its actual templates/consulting.html, templates/evidence.html, templates/system.html, templates/systems.html). It had zero schema registration for any of its six custom templates. Running this branch's validator against its real content, pre-fix:

{"file": "content/about.md", "pointer": "/template", "error": "custom template 'about.html' has no schema registration..."}
... (20 of 26 real content files failed the same way — every home/about/consulting/evidence/systems-index/system-dossier page)
{"checked": 26, "passed": 6, "failed": 20}

ardent-tools/ardent-tools-site#146 adds schemas/registry.toml plus one schema per custom template, each composing this PR's page.core.schema.json/section.core.schema.json and closed with unevaluatedProperties: false — field shapes derived by parsing every real content file with tomllib, not by inspection (schemas/system-dossier.schema.json's extra.demo reflects the actual union of fields across all 7 real system pages, including the planned-recording-vs-published-cast field split, and repo/kanon_ci/license are optional because the real content/systems/kanon.md omits all three). With that PR's schemas in place, this branch's validator against the real content:

{"checked": 26, "passed": 18, "failed": 8}

The remaining 8 are a real, honestly-disclosed limitation, not swept under the rug. content/writing/*.md sets no explicit template; it relies on Zola's page_template cascade (content/writing/_index.md sets page_template = "journal-entry.html"), which classify() does not simulate — a gap independent of the registry, pre-existing, and newly exposed (not created) by this PR's closure of page.schema.json. Filed as #159 with full repro; a reviewer can confirm it's real and confirm it's out of #60's scope (registering known discriminators, not resolving Zola's template-inheritance semantics before that lookup starts).

Every existing fixture (examples/sample-blog, examples/sample-shop) still validates clean and unchanged — {"checked": 5, "passed": 5} / {"checked": 9, "passed": 9}.

Finding 2 — classify() let a registry entry's extends silently disagree with what a file structurally is

Correct, and reproduced. A path_prefix (or template) entry registered extends = "page" unconditionally overrode section classification for any _index.md a path also matched — base = "section" was computed, then discarded on any registry hit, with no check that the entry's extends agreed with what the file structurally is.

Reproduced against the pre-fix committed classifier (git show HEAD~2:bin/typikon-validate before this PR's fix commits) with a path_prefix = "systems/" (extends="page") entry and a content/systems/_index.md shaped to coincidentally satisfy the page-extending schema (title + extra.ardent.repo_url, nothing section-specific):

$ python3 <pre-fix bin/typikon-validate> <fixture>
{"checked": 1, "passed": 1, "failed": 0}

Silently validated clean — a section file checked against the wrong schema, with nothing surfacing the mismatch, exactly as the finding describes. A second fixture (no section-only fields, just sort_by) instead produced a misleading "'sort_by' was unexpected" error — technically a failure, but for the wrong reason, pointing a maintainer at deleting a real field rather than at the actual defect (the registry entry itself).

Fix: classify() now computes the file's structural kind (section for _index.md, page for everything else — Zola's own distinction) before either match path, and raises MismatchedExtendsError when a template or path_prefix hit's extends disagrees with it. validate_file() converts that to the same JSONL-failure shape as UnregisteredTemplateError.

Negative fixtures, wired into ci/check-consumer-schema-registry.py (now 15 cases, run every CI pass):

• "path_prefix registered extends=page silently matching a _index.md (structurally section) — fails closed, not a silent pass" — the exact reproduction above.
• "registered template applied to a _index.md (structurally section) — mismatched extends fails closed" — the template-discriminator analog (the finding's parenthetical "(or template)").

$ python3 ci/check-consumer-schema-registry.py
{"checked": 15, "passed": 15, "failed": 0}

Both new cases fail if the extends-check is reverted — verified by running them against the pre-fix classifier above.

Finding 3 — untagged comments

Correct, and fixed: bin/typikon-validate's COMPOSABLE_CORE_SLUGS rationale block now opens # WHY:; ci/check-consumer-schema-registry.py:128's case-format comment is now # NOTE:. (The reviewer noted this was pre-existing noncompliance elsewhere in the file, not introduced by this diff, and non-blocking — fixed anyway since it was cheap and in a file this PR is already touching.)

---

What a reviewer would have to disprove

• bin/typikon-validate examples/sample-blog and examples/sample-shop still exit 0 with {"failed": 0}.
• python3 ci/check-consumer-schema-registry.py genuinely exercises the CLI and all 15 assertions hold, including the two new MismatchedExtendsError cases (revert the extends-check in classify() and cases 14–15 fail; that's the test proving the fix, not just documenting it).
• python3 ci/check-triad-schema.py still passes 4/4.
• Running this branch's bin/typikon-validate against a fresh clone of forkwright/ardent-site (main + ardent-site#35) returns {"checked": 23, "passed": 23, "failed": 0}.
• Running this branch's bin/typikon-validate against a fresh clone of ardent-tools/ardent-tools-site (main + ardent-tools-site#146) returns {"checked": 26, "passed": 18, "failed": 8}, and every one of the 8 failures is under content/writing/, matching typikon#159 exactly (not the six templates Add a fail-closed consumer schema registry #60 is about).
• That section.core.schema.json's new seo_title field is genuinely read by typikon's own theme (grep -n "extra\.seo_title" templates/section.html templates/index.html templates/journal-section.html), not a speculative addition.
• That ardent-site#35's one-line move (template out of [extra]) doesn't change rendering: grep -rn "extra\.template\b" themes/typikon/templates/ in that repo returns no matches, so nothing read the stray field being removed.

Companion PRs (both needed for the "both real consumers pass" claim to be checkable independently of this repo)

• forkwright/ardent-site#35 — homepage template frontmatter placement fix.
• ardent-tools/ardent-tools-site#146 — registers all six custom templates against this PR's registry mechanism.
• forkwright/typikon#159 — the page_template-cascade gap this verification pass found and disclosed rather than silently leaving unhandled or hidden.

Closes #60