@mdwrk/mdwrkcom-content-pack 0.1.5

package/content/pages/packages/extension-runtime.md

@@ -0,0 +1,33 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/packages/extension-runtime/"
+title: "Extension Runtime Package | MdWrk"
+description: "The @mdwrk/extension-runtime package provides portable runtime utilities for governed MdWrk extension behavior."
+h1: "@mdwrk/extension-runtime"
+entity: "MdWrk"
+intent: "extension runtime package"
+contentType: "package"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "Use the extension runtime package when building governed commands, panes, settings, and integration surfaces."
+parent: "/packages/"
+related:
+  - "/packages/"
+  - "/packages/theme-contract/"
+  - "/proof/package-surfaces/"
+faqs:
+  - question: "What is @mdwrk/extension-runtime?"
+    answer: "It is the portable package for MdWrk extension runtime behavior, lifecycle, and host-facing contracts."
+---
+
+`@mdwrk/extension-runtime` provides portable runtime utilities for governed MdWrk extension behavior. It supports the package-level extension model behind commands, panes, settings, and integrations.
+
+Install:
+
+```bash
+npm install @mdwrk/extension-runtime
+```
+
+Use this package when extension behavior needs to stay explicit, inspectable, and compatible with MdWrk host surfaces.
+
+The runtime package keeps extension behavior out of undocumented client patches. A package author can reason about lifecycle, host context, compatibility, and trust policy as stable surfaces that can be documented, validated, and reused across delivery targets.

package/content/pages/packages/index.md

@@ -0,0 +1,42 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/packages/"
+title: "MdWrk Packages | Reusable Markdown Editor And Renderer Packages"
+description: "Explore MdWrk packages for Markdown rendering, React integration, editor components, theme contracts, and extension runtime behavior."
+h1: "Packages"
+entity: "MdWrk"
+intent: "mdwrk packages"
+contentType: "docs"
+updatedAt: "2026-05-12"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Use the packages hub to find the reusable MdWrk modules behind rendering, editing, theme contracts, and extension behavior."
+parent: "/"
+related:
+  - "/features/"
+  - "/answers/"
+  - "/proof/package-surfaces/"
+faqs:
+  - question: "What are MdWrk packages?"
+    answer: "MdWrk packages are reusable modules for Markdown rendering, editor behavior, theme contracts, extension runtime behavior, and related adoption paths."
+  - question: "Why does MdWrk separate packages from the product site?"
+    answer: "The package section makes reusable module boundaries explicit so teams can evaluate adoption without treating every capability as an app-only feature."
+---
+
+MdWrk packages are the reusable module surfaces behind the broader MdWrk product story. They help teams adopt rendering, editing, theming, and extension behavior without pulling in the full MdWrk application shell.
+
+## Current public package pages
+
+- [@mdwrk/markdown-renderer-core](/packages/markdown-renderer-core/) is the self-contained Markdown parsing and rendering surface for HTML output and preview pipelines.
+- [@mdwrk/markdown-renderer-react](/packages/markdown-renderer-react/) provides React bindings for MdWrk-aligned Markdown rendering.
+- [@mdwrk/markdown-editor-react](/packages/markdown-editor-react/) exposes React editor components for embedding MdWrk-style authoring surfaces.
+- [@mdwrk/theme-contract](/packages/theme-contract/) documents the governed token and compatibility contract for editor, preview, extension, and lander styling.
+- [@mdwrk/extension-runtime](/packages/extension-runtime/) covers the reusable runtime boundary for extension lifecycle and host-facing behavior.
+
+## Broader package families in the repo
+
+The public package pages cover only part of the current workspace package surface. The broader repo also includes the packaged workspace app, editor and renderer families, extension packages, shared utilities, lander packages, and the MdWrk content pack.
+
+## How to use this section
+
+Start here if you are evaluating MdWrk as a package platform rather than only as an end-user application. The package pages clarify install surfaces, public APIs, and how each reusable module fits into the broader Markdown workflow.

package/content/pages/packages/markdown-editor-react.md

@@ -0,0 +1,33 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/packages/markdown-editor-react/"
+title: "Markdown Editor React Package | MdWrk"
+description: "The @mdwrk/markdown-editor-react package provides React Markdown editor components for embedding MdWrk-style authoring surfaces."
+h1: "@mdwrk/markdown-editor-react"
+entity: "MdWrk"
+intent: "markdown editor react package"
+contentType: "package"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "Use the React editor package when another product needs a reusable Markdown authoring surface."
+parent: "/packages/"
+related:
+  - "/packages/"
+  - "/packages/markdown-renderer-react/"
+  - "/packages/theme-contract/"
+faqs:
+  - question: "What is @mdwrk/markdown-editor-react?"
+    answer: "It is the React editor package for embedding MdWrk-style Markdown authoring surfaces."
+---
+
+`@mdwrk/markdown-editor-react` provides React components for Markdown authoring. It is part of the package family that lets MdWrk behavior travel outside the main workspace client.
+
+Install:
+
+```bash
+npm install @mdwrk/markdown-editor-react
+```
+
+Use this package when a product needs editor behavior directly and does not need to adopt the entire MdWrk application shell.
+
+The editor package is part of the split package story. A consuming product can pair it with renderer packages, theme contracts, and its own content model while MdWrk continues to use the same family inside the flagship workspace.

package/content/pages/packages/markdown-renderer-core.md

@@ -0,0 +1,33 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/packages/markdown-renderer-core/"
+title: "Markdown Renderer Core Package | MdWrk"
+description: "The @mdwrk/markdown-renderer-core package provides self-contained Markdown parsing and rendering utilities for package-level preview and HTML output."
+h1: "@mdwrk/markdown-renderer-core"
+entity: "MdWrk"
+intent: "markdown renderer core package"
+contentType: "package"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "Use the renderer core package when a product needs Markdown parsing and HTML rendering without adopting the full MdWrk client."
+parent: "/packages/"
+related:
+  - "/packages/"
+  - "/packages/markdown-renderer-react/"
+  - "/proof/package-surfaces/"
+faqs:
+  - question: "What is @mdwrk/markdown-renderer-core?"
+    answer: "It is the package-level Markdown parsing and rendering surface used by MdWrk renderer workflows."
+---
+
+`@mdwrk/markdown-renderer-core` provides Markdown parsing and rendering utilities for package-level preview and HTML output. It is useful when a product needs MdWrk-aligned Markdown behavior without adopting the full workspace client.
+
+Install:
+
+```bash
+npm install @mdwrk/markdown-renderer-core
+```
+
+The package belongs to the reusable renderer family. The lander presents it as part of MdWrk product truth, while the portable lander packages only render the package-page shape, metadata, FAQ, and schema.
+
+Use this surface when the implementation needs Markdown behavior that can be tested, documented, and reused without importing the full client. The package keeps renderer adoption explicit, which helps product teams separate content parsing, HTML output, and application-specific presentation.

package/content/pages/packages/markdown-renderer-react.md

@@ -0,0 +1,33 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/packages/markdown-renderer-react/"
+title: "Markdown Renderer React Package | MdWrk"
+description: "The @mdwrk/markdown-renderer-react package provides React bindings for rendering Markdown through the same package family used by MdWrk."
+h1: "@mdwrk/markdown-renderer-react"
+entity: "MdWrk"
+intent: "markdown renderer react package"
+contentType: "package"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "Use the React renderer package when a product needs MdWrk-aligned Markdown rendering inside React."
+parent: "/packages/"
+related:
+  - "/packages/"
+  - "/packages/markdown-renderer-core/"
+  - "/packages/markdown-editor-react/"
+faqs:
+  - question: "What is @mdwrk/markdown-renderer-react?"
+    answer: "It is the React binding package for rendering Markdown through MdWrk's renderer family."
+---
+
+`@mdwrk/markdown-renderer-react` gives React applications a package-level route into MdWrk-aligned Markdown rendering. It pairs with the renderer core package and keeps rendering behavior reusable outside the full workspace client.
+
+Install:
+
+```bash
+npm install @mdwrk/markdown-renderer-react
+```
+
+Use this package when a product needs a React Markdown preview surface that can stay aligned with MdWrk examples, docs, and client behavior.
+
+The React package is intentionally described as a reusable surface instead of a hidden implementation detail. That makes package adoption clear for teams that need preview behavior inside another application while keeping MdWrk-specific product positioning in the content pack.

package/content/pages/packages/theme-contract.md

@@ -0,0 +1,33 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/packages/theme-contract/"
+title: "Theme Contract Package | MdWrk"
+description: "The @mdwrk/theme-contract package defines theme token and compatibility contracts for MdWrk editor, preview, extension, and lander surfaces."
+h1: "@mdwrk/theme-contract"
+entity: "MdWrk"
+intent: "theme contract package"
+contentType: "package"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "Use the theme contract package when styling needs to target governed tokens instead of private UI internals."
+parent: "/packages/"
+related:
+  - "/packages/"
+  - "/answers/how-do-mdwrk-theme-packs-work/"
+  - "/packages/extension-runtime/"
+faqs:
+  - question: "What is @mdwrk/theme-contract?"
+    answer: "It is the package that defines governed theme tokens and compatibility surfaces for MdWrk packages and apps."
+---
+
+`@mdwrk/theme-contract` defines theme token and compatibility contracts for MdWrk surfaces. It helps themes travel across editor, preview, extension, and lander experiences without patching private implementation details.
+
+Install:
+
+```bash
+npm install @mdwrk/theme-contract
+```
+
+This package anchors the difference between reusable visual shape and MdWrk-specific styling truth. Product theme packs can supply identity while generic packages keep stable token names.
+
+The contract matters for portability because themes should not depend on private app selectors. A product-specific theme can express its own visual system while editor, preview, extension, and lander packages continue to consume documented tokens.

package/content/pages/privacy.md

@@ -0,0 +1,41 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/privacy/"
+title: "MdWrk privacy policy for local-first Markdown workflows"
+description: "MdWrk privacy documentation explains the local-first storage model, explicit sharing boundaries, GitHub integration expectations, and extension trust policy."
+h1: "Privacy policy"
+entity: "MdWrk"
+intent: "MdWrk privacy policy"
+contentType: "privacy"
+updatedAt: "2026-05-04"
+author: CobyCloud
+subtitle: "MdWrk is documented as a privacy-first Markdown workspace that keeps authoring local by default and treats sync, export, integrations, and extensions as explicit user choices."
+faqs:
+  - question: "Does MdWrk upload documents by default?"
+    answer: "The public documentation should not imply default uploads. It should describe local storage and identify workflows that intentionally use networked services."
+parent: "/"
+related:
+  - "/security/"
+tags:
+  - privacy
+  - local-first
+  - policy
+---
+
+MdWrk's privacy policy is written around the local-first Markdown model. Public documentation should make clear that writing and previewing Markdown do not require a hosted document account as the default assumption.
+
+## Local Content Boundary
+
+Markdown documents, workspace state, and editor preferences should be described in terms of local control. If a workflow stores data in browser-managed storage, IndexedDB, filesystem-backed surfaces, or another local mechanism, the docs should say so plainly.
+
+## Explicit Sharing
+
+Export, GitHub sync, package installation, and extension workflows are deliberate actions. The privacy documentation should explain that these actions may cross the local boundary and should describe which external service or package is involved.
+
+## Extension Trust
+
+Extensions can add useful capabilities, but they also need trust and compatibility rules. MdWrk documents extension manifests, package identity, runtime expectations, and the idea that extension behavior should not be treated as automatically trusted.
+
+## Public Documentation
+
+The public privacy page is statically generated, indexable when policy allows, and mirrored into machine-readable artifacts. That makes the privacy posture inspectable before deployment.

package/content/pages/proof/browser-support.md

@@ -0,0 +1,22 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/proof/browser-support/"
+title: "Browser Support Proof | MdWrk"
+description: "MdWrk documents browser and PWA behavior as governed public product surfaces with static lander evidence."
+h1: "Browser support proof"
+entity: "MdWrk"
+intent: "mdwrk browser support proof"
+contentType: "docs"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "Browser support proof connects product claims to static pages, package surfaces, and verification artifacts."
+faqs:
+  - question: "How does MdWrk present browser support?"
+    answer: "MdWrk presents browser and PWA behavior through static pages, package documentation, and governed verification artifacts."
+---
+
+Browser support proof connects MdWrk's public product claims to static pages, package surfaces, and verification artifacts. The lander is expected to produce crawlable HTML, Markdown mirrors, sitemap entries, robots policy, LLM files, content indexes, and JSON-LD graph data.
+
+This page is intentionally a proof page rather than a marketing claim alone. It points readers toward the artifacts that make browser and PWA support inspectable.
+
+The reusable lander package owns proof-page rendering shape. MdWrk owns the browser support facts and the evidence language.

package/content/pages/proof/markdown-support.md

@@ -0,0 +1,22 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/proof/markdown-support/"
+title: "Markdown Support Proof | MdWrk"
+description: "MdWrk aligns Markdown editing and preview behavior with reusable renderer and editor package surfaces."
+h1: "Markdown support proof"
+entity: "MdWrk"
+intent: "mdwrk markdown support proof"
+contentType: "docs"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "Markdown support proof keeps the product page, renderer package, editor package, and static examples aligned."
+faqs:
+  - question: "How does MdWrk prove Markdown support?"
+    answer: "MdWrk links Markdown support claims to renderer and editor packages, examples, documentation, and generated public artifacts."
+---
+
+Markdown support proof keeps MdWrk's product page, renderer package, editor package, and static examples aligned. The public site should not make Markdown claims that are disconnected from package behavior.
+
+The renderer and editor package families are the most important reusable surfaces for Markdown behavior. They let the product, docs, examples, and future integrations rely on a common implementation story.
+
+This proof page is product-specific. The portable lander package only supplies the proof matrix and page rendering shape.

package/content/pages/proof/package-surfaces.md

@@ -0,0 +1,22 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/proof/package-surfaces/"
+title: "Package Surfaces Proof | MdWrk"
+description: "MdWrk exposes reusable package surfaces separately from the MdWrk-specific marketing and documentation content pack."
+h1: "Package surfaces proof"
+entity: "MdWrk"
+intent: "mdwrk package surfaces proof"
+contentType: "docs"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "Package surface proof explains the split between generic lander packages and MdWrk-specific content truth."
+faqs:
+  - question: "What does package surface proof show?"
+    answer: "It shows that reusable packages own shape and behavior while MdWrk content owns product claims, positioning, pages, and proof language."
+---
+
+Package surfaces proof explains the split between generic lander packages and MdWrk-specific content truth. The reusable package family owns contracts, compiler behavior, React sections, schema builders, SEO utilities, theme tokens, and Markdown/frontmatter bridging.
+
+MdWrk owns product name, positioning, claims, features, FAQs, comparison facts, package descriptions, proof language, screenshots, CTAs, and docs links. That separation makes the lander package reusable across other product websites.
+
+This proof page is also a guardrail. Future product packs should be able to reuse the lander engine without inheriting MdWrk-specific prose or package claims.

package/content/pages/security.md

@@ -0,0 +1,38 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/security/"
+title: "MdWrk security notes for packages, extensions, and static docs"
+description: "MdWrk security notes explain package boundaries, extension trust, static content verification, robots policy, and deployable artifact checks."
+h1: "Security notes"
+entity: "MdWrk"
+intent: "MdWrk security documentation"
+contentType: "security"
+updatedAt: "2026-05-04"
+author: CobyCloud
+subtitle: "MdWrk security documentation focuses on package boundaries, extension trust, static build verification, link integrity, and public artifacts that can be inspected before deployment."
+parent: "/"
+related:
+  - "/privacy/"
+tags:
+  - security
+  - verification
+  - extensions
+---
+
+MdWrk security documentation explains how the public lander and product surfaces should be reviewed. The static compiler is part of that posture because it verifies source content and generated artifacts before deployment.
+
+## Package Boundaries
+
+Reusable packages should have clear responsibilities. Editor, renderer, extension host, theme contract, and static lander surfaces should not blur into one unreviewable runtime.
+
+## Extension Trust
+
+Extensions need explicit trust policy. The documentation should describe manifest metadata, compatibility expectations, package identity, and how users can reason about what an extension is allowed to do.
+
+## Static Artifact Verification
+
+The public lander build verifies HTML, links, JSON-LD, sitemap output, robots policy, LLM index files, Markdown mirrors, and the content registry. These checks help prevent empty app shells or hidden primary content from being treated as deployable.
+
+## Deployment Smoke Checks
+
+Production URL checks are post-deploy smoke checks. They should verify that the deployed response contains expected content, but they should not be required to create a valid deployable artifact.

package/content/pages/trust/privacy-boundary.md

@@ -0,0 +1,22 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/trust/privacy-boundary/"
+title: "Privacy Boundary | MdWrk"
+description: "MdWrk keeps normal authoring local-first and makes sync, export, repository movement, and hosted integrations explicit boundaries."
+h1: "Privacy boundary"
+entity: "MdWrk"
+intent: "mdwrk privacy boundary"
+contentType: "privacy"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "The privacy boundary explains what stays local by default and when content intentionally crosses into an integration."
+faqs:
+  - question: "What is MdWrk's privacy boundary?"
+    answer: "MdWrk keeps normal Markdown authoring local-first and treats sync, export, repository movement, and hosted integrations as explicit boundaries."
+---
+
+MdWrk's privacy boundary starts with local-first authoring. Normal Markdown writing, preview, and workspace organization should be understandable without requiring a hosted authoring backend.
+
+That does not mean every workflow is offline-only. Sync, export, repository movement, package discovery, and deployment can cross a network boundary, but those paths should be visible choices rather than hidden defaults.
+
+This trust page belongs to the MdWrk content pack. The reusable lander engine renders trust and proof pages without knowing this specific privacy position.

package/data/article-metadata.schema.json

@@ -0,0 +1,111 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://mdwrk.com/schemas/article-metadata.schema.json",
+  "title": "MdWrk Article Metadata Header",
+  "description": "Frontmatter metadata schema for MdWrk documentation and product update articles.",
+  "type": "object",
+  "oneOf": [
+    {
+      "title": "Documentation article metadata",
+      "type": "object",
+      "required": [
+        "title",
+        "slug",
+        "section",
+        "sectionOrder",
+        "order",
+        "toc",
+        "date",
+        "status",
+        "excerpt"
+      ],
+      "properties": {
+        "title": { "$ref": "#/$defs/nonEmptyString" },
+        "subtitle": { "$ref": "#/$defs/subtitle" },
+        "slug": {
+          "type": "string",
+          "pattern": "^[a-z0-9][a-z0-9/-]*$"
+        },
+        "section": { "$ref": "#/$defs/nonEmptyString" },
+        "sectionOrder": { "$ref": "#/$defs/numericString" },
+        "order": { "$ref": "#/$defs/integerString" },
+        "toc": {
+          "type": "string",
+          "enum": ["true", "false"]
+        },
+        "date": { "$ref": "#/$defs/isoDate" },
+        "status": { "$ref": "#/$defs/articleStatus" },
+        "excerpt": { "$ref": "#/$defs/excerpt" },
+        "author": { "$ref": "#/$defs/nonEmptyString" },
+        "displayAuthor": { "type": "boolean" },
+        "featuredImage": { "$ref": "#/$defs/imagePath" },
+        "featuredImageAlt": { "$ref": "#/$defs/nonEmptyString" },
+        "relatedApis": { "$ref": "#/$defs/commaList" }
+      },
+      "additionalProperties": false
+    },
+    {
+      "title": "Product update article metadata",
+      "type": "object",
+      "required": [
+        "title",
+        "date",
+        "status",
+        "author",
+        "excerpt"
+      ],
+      "properties": {
+        "title": { "$ref": "#/$defs/nonEmptyString" },
+        "subtitle": { "$ref": "#/$defs/subtitle" },
+        "date": { "$ref": "#/$defs/isoDate" },
+        "status": { "$ref": "#/$defs/articleStatus" },
+        "author": { "$ref": "#/$defs/nonEmptyString" },
+        "excerpt": { "$ref": "#/$defs/excerpt" },
+        "featuredImage": { "$ref": "#/$defs/imagePath" },
+        "featuredImageAlt": { "$ref": "#/$defs/nonEmptyString" }
+      },
+      "additionalProperties": false
+    }
+  ],
+  "$defs": {
+    "nonEmptyString": {
+      "type": "string",
+      "minLength": 1
+    },
+    "excerpt": {
+      "type": "string",
+      "minLength": 40,
+      "maxLength": 280
+    },
+    "subtitle": {
+      "type": "string",
+      "minLength": 20,
+      "maxLength": 280
+    },
+    "isoDate": {
+      "type": "string",
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$"
+    },
+    "integerString": {
+      "type": "string",
+      "pattern": "^\\d+$"
+    },
+    "numericString": {
+      "type": "string",
+      "pattern": "^\\d+(?:\\.\\d+)?$"
+    },
+    "articleStatus": {
+      "type": "string",
+      "enum": ["draft", "published"]
+    },
+    "commaList": {
+      "type": "string",
+      "minLength": 1
+    },
+    "imagePath": {
+      "type": "string",
+      "minLength": 1,
+      "pattern": "^(https?://|/)[^\\s]+$"
+    }
+  }
+}

package/data/content-sitemap.yaml

@@ -0,0 +1,31 @@
+content:
+  - id: legal/privacy
+    file: ./markdown/legal/privacy.md
+  - id: legal/terms
+    file: ./markdown/legal/terms.md
+  - id: blog/client-split-out-backstory
+    file: ./markdown/blog/client-split-out-backstory.md
+  - id: blog/markdown-workspace-launch
+    file: ./markdown/blog/markdown-workspace-launch.md
+  - id: blog/responsive-authoring-and-export
+    file: ./markdown/blog/responsive-authoring-and-export.md
+  - id: blog/pwa-install-and-zoom-controls
+    file: ./markdown/blog/pwa-install-and-zoom-controls.md
+  - id: blog/governed-releases-and-package-docs
+    file: ./markdown/blog/governed-releases-and-package-docs.md
+  - id: blog/extension-compatibility-and-publish-gates
+    file: ./markdown/blog/extension-compatibility-and-publish-gates.md
+  - id: blog/screenshot-matrix-and-browser-sidebars
+    file: ./markdown/blog/screenshot-matrix-and-browser-sidebars.md
+  - id: blog/retained-client-versions-and-desktop-shell
+    file: ./markdown/blog/retained-client-versions-and-desktop-shell.md
+  - id: blog/desktop-release-and-android-verification
+    file: ./markdown/blog/desktop-release-and-android-verification.md
+  - id: blog/workspace-files-and-git-ops-packages
+    file: ./markdown/blog/workspace-files-and-git-ops-packages.md
+  - id: blog/extension-host-rollout
+    file: ./markdown/blog/extension-host-rollout.md
+  - id: blog/docs-surface-realignment
+    file: ./markdown/blog/docs-surface-realignment.md
+  - id: blog/settings-simplification-for-daily-flow
+    file: ./markdown/blog/settings-simplification-for-daily-flow.md

package/data/content.ts

@@ -0,0 +1,55 @@
+import { parseMarkdown } from '../utils/markdownParser';
+import { isPublishedMetadata } from '../utils/publication';
+import sitemapRaw from './content-sitemap.yaml?raw';
+
+interface ContentSitemapEntry {
+  id: string;
+  file: string;
+}
+
+const parseContentSitemap = (raw: string): ContentSitemapEntry[] => {
+  const entries: ContentSitemapEntry[] = [];
+  const lines = raw.split('\n').map(line => line.trim()).filter(Boolean);
+
+  let current: Partial<ContentSitemapEntry> = {};
+
+  for (const line of lines) {
+    if (line.startsWith('- id:')) {
+      if (current.id && current.file) {
+        entries.push({ id: current.id, file: current.file });
+      }
+      current = { id: line.replace('- id:', '').trim() };
+      continue;
+    }
+
+    if (line.startsWith('file:')) {
+      current.file = line.replace('file:', '').trim();
+    }
+  }
+
+  if (current.id && current.file) {
+    entries.push({ id: current.id, file: current.file });
+  }
+
+  return entries;
+};
+
+const rawContentFiles = import.meta.glob('./markdown/**/*.md', {
+  eager: true,
+  query: '?raw',
+  import: 'default'
+}) as Record<string, string>;
+
+const sitemapEntries = parseContentSitemap(sitemapRaw);
+
+export const contentFiles = sitemapEntries.reduce<Record<string, string>>((acc, entry) => {
+  const content = rawContentFiles[entry.file];
+  if (content) {
+    const { metadata } = parseMarkdown(content);
+    if (!isPublishedMetadata(metadata)) {
+      return acc;
+    }
+    acc[entry.id] = content;
+  }
+  return acc;
+}, {});