content-model: frontmatter - Add schemas for eight website classes #348

Outcome

Implement repository-owned frontmatter contracts for Podcasting, Journaling, Blog, Videos, Events, eBook, Website pages and FAQs.

Verified context

scripts/journal-schema.ts already contains journal/eBook Zod contracts; existing Markdown uses several discriminators and inconsistent shapes. #347 records the broader scoping intent. The organisation schema is governance-oriented, not a website model.

Scope

Define common fields and separate per-type profiles, preserving compatibility and documenting decisions before migration. Evaluate the reference schema; do not copy it wholesale.

Acceptance criteria

• All eight profiles specify field types, requiredness, identities, relationships, taxonomy, media references and publication rules.
• Existing journal/eBook contracts and legacy discriminators have explicit compatibility mappings and valid/invalid examples.
• Frontmatter, runtime objects and public JSON-LD remain separate contracts; asset references reuse content-model: media-library - Define the asset catalogue and provenance model #279/content-model: media-library - Finalise the asset catalogue schema #289 scope.
• Representative schema tests cover approved contracts without inventing missing manuscript or metadata.

Boundaries and sources

Creation defines work only; it does not start implementation. Preserve unrelated code, protected assets, editorial wording and existing records. Do not fabricate content, identity, media, manuscript chapters, dates or engagement data. Use approved repository-native authoring, validation, preview and publication decisions; do not provision an external CMS or database. Existing editorial verification remains with its current issues. All acceptance criteria remain unchecked until evidenced.

Repository evidence was inspected on develop at 4ecdb26d9655a48bf000a7c89da2f70383edce87. Recheck before implementation; no build or browser tests were run for this draft. Follow repository instructions and applicable Spec Kit requirements. Paths below refer to this repository.

Sources: repository instructions, application, editorial content.

Branch instructions

• Repository: lightspeedwp/ThisOneTimeOnAcidCom
• Proposed branch: feat/frontmatter-website-schemas
• Base: develop
• Naming policy: local guide, validator, organisation strategy.
• Pull request template: Organisation .github/PULL_REQUEST_TEMPLATE/pr_feature.md, per inspected local routing; recheck before opening a PR.
• Constraints: Preserve unrelated changes; do not force-push, merge or deploy. Complete applicable Spec Kit requirements before implementation.
• Conflicts or missing evidence: Proposed branch, not an existing branch; collision freedom is unverified. Recheck current branch routing and open governance changes, including PR automation: repo-governance - Add governance automation and validation #346. Older instructions claim branch rules are absent; the inspected local guide and executable validator establish the current convention. This draft creates no branch or pull request.

Unanswered clarification questions

These questions clarify the schema contracts; they do not approve migration or resolve existing branch-policy conflicts.

1. Which source paths and discriminators identify each of the eight website classes?
2. Which fields are common or type-specific, and which are required or optional?
3. What identity, relationship, taxonomy, media-reference and publication rules are approved for each class?
4. Which legacy discriminators and journal/eBook shapes must remain compatible, with what valid and invalid examples?
5. Who approves the contracts and compatibility decisions before dependent validation or migration work proceeds?

Branch instructions — batch 23 audit addendum

• Repository: lightspeedwp/ThisOneTimeOnAcidCom; implementing target: this eight-class frontmatter-schema issue, counterpart GitHub issue 348.
• Proposed branch: feat/frontmatter-website-schemas; base: refreshed develop, checked at 4ecdb26d9655a48bf000a7c89da2f70383edce87 (D). Organisation baseline: 8f28eca80bff198879f7aaf496717dc0551bb32e (O).
• Branch state: proposed new branch, not created/reused. No matching live branch/exact-head PR found. Refresh before implementation; verify equivalent scope before proposing reuse. No automatic rename/reset/reuse of governance work.
• Naming: local guide, validator and organisation strategy authorise feat/type-scope-title. Naming inspected statically, not executed. Older no-conventions claims conflict with current files.
• Template: shared Feature template. Local routing suggests it/applies a label, not proof of inherited body loading. Verify selection separately; no local templates, locked-template changes or automatic metadata adoption.
• Parent context: preserve hierarchy; omit coordination-parent identifiers/URLs from branches, PR metadata and coding prompts while association effects remain unverified. Never use the parent as a native development/closing target.
• Allowed closing targets: none currently. Partial work cannot close the issue; future references/associations require separate review.
• Governance PR346 is context, not delivered infrastructure or reuse branch. No repository edits, branch/PR operations, execution, merge or deployment authorised.

Expected file changes

Provisional approval-gated plan, not implementation authority. Existing paths inspected at D; new destinations proposed. Specification number 003 is the inspected next catalogue number, not reserved: confirm allocation before work. A changed destination requires revised preview/approval.

No moves/deletions. Resolve content versus exporter path differences, journal discriminators, date/tag formats, FAQ/page identity, draft defaults and eBook variants before coding. Example URLs, metrics and placeholders are not verified facts.

Content-model scoping and initial/final media modelling remain outstanding dependencies, not delivered contracts. Reuse reviewed media-reference decisions; do not invent them or copy organisation governance schemas wholesale.

Exclude content migration, loaders, routes, JSON-LD, package/configuration changes, asset replacement, protected fallback component, Supabase, attribution/changelog, locked governance and managed workflows. Resolve changelog handling separately. No commands, installs, tests, builds, validators, hooks, scripts or cloud operations performed. Additional paths/material changes need revised preview and approval. Exclude credentials/restricted material from public sync. Description approval changes no status, ownership, labels, hierarchy or PR associations and grants no implementation authority.