feat: content-loading - Add shared Markdown management foundations #352

Outcome

Provide validated, typed Markdown loading and a repository-native authoring, preview and publication workflow for the eight modules.

Verified context

Journal/eBook loaders target inconsistent paths; useContent.ts enables legacy WordPress sourcing. Root guidance describes editorial Markdown, while older guidelines prohibit importing protected reference content.

Scope

Resolve source authority and publication policy before connecting approved content. Build reusable collection/detail adapters, not eight separate CMS products.

Acceptance criteria

• Explicit approved decisions reconcile source paths, import restrictions, legacy WordPress fallback and public/draft eligibility.
• Shared parsing agrees with validation; stable IDs, lookup failures and missing manuscript sources produce actionable states.
• Representative fixtures cover all eight content classes and prove draft/operational Markdown exclusion.
• Editing, validation, preview, publication and rollback instructions are documented; reusable UI labels remain separate from editorial text.
• Module routing/players remain with their children; no external CMS, database, deployment or asset migration is introduced.

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-loading-foundations
• 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.

Branch instructions — batch 25 audit addendum

• Repository: lightspeedwp/ThisOneTimeOnAcidCom; implementing target: this shared-loading issue, counterpart GitHub issue 352.
• Proposed branch: feat/content-loading-foundations; 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. Never reset, rename or reuse unrelated governance branches.
• 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 files.
• Template: shared Feature template. Local routing suggests it/applies a label, not body insertion. Verify selection separately. No local/locked-template changes or automatic metadata/closing examples.
• Parent context: preserve hierarchy; omit coordination-parent identifiers/URLs from branches, PR metadata and coding prompts while effects remain unverified. Never use a parent as a native development/closing target.
• Allowed closing targets: none for this provisional contribution. Partial foundations 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 candidate plan, not architecture or implementation approval. Existing evidence inspected at D; new destinations proposed. Specification-first work is a prerequisite: agree exact numbered specification paths and obtain a revised preview before creation. Batches 23/24 already propose competing unreserved 003 paths; no number is allocated here. Required specification/research/plan/tasks and catalogue registration are not authorised through a placeholder path.

No moves/deletions. Specification allocation and exact specification-file plan remain unresolved, so this is not a complete implementation plan. Additional paths need revised preview/approval.

Source layout, parser, exports, preview mechanism, publication defaults, identity and HTML/URL trust remain decisions. Current journal/book runtime globs differ from tracked editorial paths, and runtime parsers differ from YAML/Zod script parsing. Do not copy assumptions or import Node-only validation into browser code. Prove draft/operational exclusion from shipped assets, not just visible lists. Fixtures must be explicitly test-only, not fabricated editorial facts.

Content scoping, website/operational schemas, validation and media contracts remain outstanding; applied guidance is not delivered code. Module routes, players and UI remain separate work. Keep reusable UI wording out of editorial bodies.

Exclude content migration, asset replacement, dependencies/configuration, protected guidance/fallback component, Supabase, attribution/changelog, managed workflows and external services. Resolve changelog handling separately. Repository-default prompt/report/task writes deferred under draft-only scope. No commands, installs, tests, builds, scripts, hooks or cloud operations performed. Exclude credentials/restricted material from public sync. Description approval changes no status, ownership, labels, hierarchy or PR associations and grants no implementation authority.