Isolate the Zola adapter behind Typikon's neutral contract

[forkwright]

Finding

Typikon's proposed v2 boundary conflates framework-neutral semantics with renderer support that no current consumer requires. The two direct consumers are both Zola/Tera sites. A2Z remains an Eleventy site with a documented but unexecuted migration to Zola/Typikon, and there is no Astro consumer.

Evidence

At Typikon faaa36fe6f0c492d4c63b242616860977101de02, rendering primitives live under Zola theme paths and there is no isolated adapter package or cross-adapter fixture.

At Ardent Leatherworks a38adcc4c7e5a4fafe40da7938eeb137cd0f8e8c and Ardent Tools 889dd8165eb1c3a86c763590f8e154c374a2948d, config.toml selects theme = "typikon"; each repository has a themes/typikon gitlink pinned at 871669ea6ab6988eab53a38d804f384136e672dc and a .gitmodules URL for forkwright/typikon.

At A2Z b038ae6097dc37c1e2a6f7ad002dec4ff172bc10, package.json uses Eleventy, there is no Typikon submodule or dependency, and PLAN-zola-conversion.md explicitly describes the conversion to Zola/Typikon as target state rather than completed state. No tracked file in this four-repository cohort establishes an Astro consumer.

Why this matters

A framework-neutral semantic contract is valuable; speculative renderer packages are not evidence of portability. Promising Astro and Eleventy without a real dependent creates three maintenance surfaces, invites framework mechanics into the kernel, and spends verification effort on imagined demand instead of the library boundary the current sites need.

Desired correction

Publish one explicit Zola 0.22.1 adapter over a framework-neutral typed kernel. Keep content and provenance models, design tokens, assets, providers, compatibility metadata, and quality receipts independent of Tera. Make supported-adapter metadata fail closed and name only adapters backed by a real consumer and conformance receipt.

Done when Leather and Tools exercise the same canonical Zola adapter without broad base-layout shadows; adapter-local mechanics cannot leak into the neutral model; A2Z either completes its documented Zola migration or an explicit D-065 decision establishes a different real dependency; and no Astro or Eleventy support claim is published without a live consumer, canonical fixture, and release receipt.

Program: ardent-web-triad. Refs #55 #60.

[forkwright]

Premise re-verified 2026-08-21 and it still holds — which is worth recording, because two of this
issue's siblings (#68, #69) have gone stale and a reader checking one might assume the set had moved
together.

forkwright/a2z-tree-site still ships .eleventy.js and package.json at its repository root. The
migration to Zola/Typikon remains documented and unexecuted, and there is still no Astro consumer. So
the two direct consumers are both Zola/Tera, exactly as filed.

The consequence is the part worth stating plainly, because this issue argues against its own
program. Isolating a Zola adapter behind a neutral contract buys portability for a renderer no
consumer uses. Until A2Z actually migrates — or a genuinely non-Zola consumer appears — the work
would add an indirection layer whose only client is hypothetical, and every future change would pay
the boundary's cost without anything crossing it.

That reads to me as a defer with a stated non-size rationale, not a backlog item awaiting
capacity: the trigger is a second renderer existing, and it is checkable (.eleventy.js disappearing
from A2Z, or a new consumer declaring a non-Zola engine). Recommend recording that trigger on this
issue so the next planning pass does not re-litigate it from scratch, and so it activates on evidence
rather than on someone remembering.

This bears on #65 too: the "framework-neutral typed authority" is the same bet. The typed-kernel half
stands on its own merits — one authority instead of JSON, Python, shell, Tera and prose independently
maintained — but the framework-neutral half inherits this issue's problem.