feat: content-validation - Add schema-aware validation and migration #350

Outcome

Provide one schema-aware validation entry point with controlled migration support.

Verified context

Journal validation already exists. scripts/export-to-markdown.ts targets src/content and writes journal-post, while editorial sources use content/ and current validation expects journal-entry.

Scope

Dispatch website and operational files to approved S1/S2 schemas; preserve existing commands. Separate local validation from any future centrally managed CI adoption.

Acceptance criteria

• Discovery handles profile paths, READMEs and nested structures, excluding generated/vendor files.
• Invalid YAML, fields, classifications, duplicate identities and relationships produce file/field diagnostics and non-zero failure status.
• Migration defaults to dry-run, reports exact changes and preserves bodies, IDs, assets and provenance; application requires separate approval.
• Exporter/path discrepancies are handled explicitly; tests and applicable build/check results are recorded, including failures.
• No Node-only validation dependency enters browser bundles and no central workflow is edited.

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/content-validation-pipeline
• 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 executable validation and controlled migration. Schema files alone do not establish enforcement; applying migrations requires separate approval.

1. Which approved schemas and path rules determine dispatch for website content versus operational Markdown?
2. Which generated, vendor and other excluded paths must discovery omit?
3. Which duplicate-identity and relationship rules should validation enforce?
4. What exact changes, preserved-content evidence and unresolved conflicts must a migration dry-run report?
5. Who approves applying a migration, and what reviewed dry-run evidence must that approval cover?

Branch instructions — batch 24 audit addendum

• Repository: lightspeedwp/ThisOneTimeOnAcidCom; implementing target: this validation issue, counterpart GitHub issue 350.
• Proposed branch: feat/content-validation-pipeline; base: refreshed develop, checked at 4ecdb26d9655a48bf000a7c89da2f70383edce87 (D). Organisation baseline: 8f28eca80bff198879f7aaf496717dc0551bb32e (O).
• Branch state: proposed new branch, not created/reused. No matching live branch or exact-head PR found. Refresh before implementation; reuse requires verified equivalent scope.
• Naming: local guide, validator and organisation strategy authorise feat/type-scope-title. Static inspection only; no validator executed. Older no-conventions claims conflict with current evidence.
• Template: shared Feature template. Local workflow suggests it/applies a label, not body loading. Verify selection separately; no local/locked-template changes or automatic adoption of metadata/closing examples.
• Parent context: preserve hierarchy; omit coordination-parent identifiers/URLs from branches, PR metadata and coding prompts while association effects remain unverified. Never use parent as native development/closing target.
• Allowed closing targets: none for this bounded contribution. Partial validation/dry-run work cannot close the issue; future references/associations require separate review.
• Governance PR346 is context, not delivered infrastructure or reuse branch. No implementation, branch/PR operations, execution, merge or deployment authorised.

Expected file changes

Provisional first contribution: local validation and non-writing migration planning only. Existing evidence inspected at D; destinations proposed.

Specification allocation is unresolved: the catalogue’s next number is 003, also proposed and unreserved in batch 23. The 003 paths below are alternatives, not reservations. Agree allocation before creation; changed paths need revised preview/approval. Generic specification-directory/numeric-branch examples do not override repository conventions.

Website/operational schemas, source scoping and media-reference contracts remain outstanding. Batch 23 guidance is not delivered schemas. Verify exports before coding; do not invent operational-schema paths or copy governance schemas wholesale.

Preserve journal commands/payloads. Diagnose content-path, journal-discriminator, README and nested-path differences; do not run/alter exporter or convert records silently. Agree generated/vendor exclusions explicitly; ignore rules alone do not settle them.

No moves/deletions, content application/migration, loaders/routes, indexes, JSON-LD, dependencies/configuration, hooks, protected assets/references, fallback component, Supabase, attribution/changelog, managed workflows or external services included. Resolve changelog handling separately. Repository-default prompt/report/task writes deferred under draft-only scope. No commands, installs, tests, builds, hooks, scripts or cloud operations performed. Extra paths/material scope changes require revised preview and approval. Exclude credentials/restricted material from public sync. Description approval changes no status, owner, labels, hierarchy or PR associations and grants no implementation authority.