feat: blog - Render source-backed articles and honest metadata #369

Outcome

Connect rich article rendering to approved Markdown and truthful metadata.

Verified context

BlogPostPage.tsx already renders rich content and FAQs but generates random local engagement values.

Scope

Reuse the renderer, map author/images and align optional FAQs; do not introduce analytics infrastructure.

Acceptance criteria

• Article body and metadata match source Markdown with supported formatting/links.
• Author/image mapping and missing optional sections behave correctly.
• FAQ handling follows the shared FAQ contract.
• Fabricated engagement is removed or explicitly identified as demonstration data under an approved UI decision; focused tests cover article/unknown-slug states.

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/blog-article-rendering
• 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 16 audit addendum

• Repository: lightspeedwp/ThisOneTimeOnAcidCom.
• Implementing target: this article-rendering issue; verified GitHub counterpart: issue 369.
• Proposed branch: feat/blog-article-rendering; base: refreshed develop, checked at 4ecdb26d9655a48bf000a7c89da2f70383edce87 (D). Organisation baseline: 8f28eca80bff198879f7aaf496717dc0551bb32e (O).
• Branch state: proposed new branch, not created or verified for reuse. Absent from inspected remote branches; exact-head PR search returned no matches and no matching open implementation PR identified. Refresh before creation.
• Naming: local guide, validator and organisation strategy authorise feat/type-scope-title convention. Static inspection only; no validator executed.
• PR template: shared Feature template. Canonical routing and local workflow agree. Automation suggests a template and applies a label, not body insertion. Native inheritance/named-template loading unverified. Create no templates or automatic labels; omit example closing clauses.
• Preserve earlier guidance and hierarchy. Omit coordination-parent identifiers, titles and URLs from branches, PR metadata and coding prompts; no parent development associations.
• Allowed closing targets: none currently. Partial work must not close the issue; future references/native associations require separate review.
• Governance PR346 is context only, not delivered infrastructure, approval or a reuse branch. No implementation, branch operations, PR changes, merge or deployment authorised.

Expected file changes

Provisional implementation plan, not completed code. Existing files inspected at D; new tests proposed in inspected directories.

No moves or deletions. Shared foundations, adapter and routing remain Todo; plans are not delivered dependencies. Shared FAQ formatting/schema behaviour requires an approved handoff; do not substitute global FAQs silently.

Complete specification-first approval before implementation. No blog specification verified in inspected catalogue/directories. Constitution ratification/amendment-history ambiguity and stale root-guide runtime/testing/branch/editorial-import statements need explicit decisions, not incidental documentation repair.

Current Jest discovers JavaScript under scripts/tests, not the proposed TypeScript unit test. Testing-infrastructure changes require separate approval; no configuration/dependency edits included.

Exclude editorial rewriting, protected assets/references, shared FAQ redesign, Supabase, analytics infrastructure, deployment, workflows, locked governance and changelog edits. Resolve changelog handling separately. No installs, scripts, hooks, tests, builds or cloud operations performed. Existing criteria unchanged; additional paths/material scope changes require revised preview and approval. Exclude credentials/restricted content from public sync. Description approval changes no status, owner, labels, hierarchy or PR associations and grants no implementation authority.