Governance

The plugin is the source of truth for reusable component runtime. bootstrap.php loads the registry, parsers, shortcodes, and renderers. registry.php defines the active az_visual identities. shortcodes.php routes authored content into the correct parser and renderer. az-components.css and az-docs.css own component-level presentation. The theme shell owns templates, shell spacing, archive framing, site header and footer, and the Geometries of Use page pattern.

Shortcodes remain the structural authoring layer wherever the plugin runtime is in use. az_visual and az_docs are the two active shortcode entry points. The parser contract decides what fields, lists, sections, and media are valid for a family. The renderer decides how that parsed structure becomes output. Live content should not be repaired by pasting ad hoc HTML into a page when a runtime family already exists and owns that structure.

Renderers are the presentation layer, not the authoring model. They are allowed to format, label, group, and lay out already-parsed content, but they should not invent unsupported content structures. Recent repairs in the project have kept that distinction explicit: case-study media and support-rail content were restored by tracing parser output into renderer output rather than by changing authored content.

Not every solved page becomes a reusable component family. Case studies, tabbed readers, ecosystem, law, and docs are reusable runtime families because they have stable parser and renderer contracts. Geometries of Use is different. It is a validated facilitation specimen assembled through a theme pattern and dedicated template, and should be documented as a page specimen rather than as a plugin runtime family.

Dormant or removed paths should not remain implied as active runtime. In the current system, docs-as-visual and wiki-as-visual are not active features and should not be documented that way. The presence of legacy files or internal IDs is not enough to treat a feature as live. Active status depends on an actual reachable runtime path plus evidence of real use or validated specimen intent.

The docs pages themselves are part of governance. They are authored through az_docs and should only describe what the local target runtime proves. Live page usage, active registry paths, validated component families, and confirmed specimens belong in the docs. Unresolved ideas, removed routes, and unvalidated abstractions should stay out until there is real evidence.

Because the architecture is split across shell, parser, renderer, CSS, and JS, maintenance still depends on tracing problems one layer at a time. A broken output should be checked in order: authored content, parser contract, renderer mapping, HTML output, CSS ownership, and JS enhancement. That layer discipline is part of governance because it keeps the runtime truthful and prevents page-specific patching from replacing the system.

Track documented system changes as a small version ledger so renderer, content, and specimen changes stay attributable.