@mdwrk/mdwrkcom-content-pack 0.1.5

package/README.md

@@ -0,0 +1,39 @@
+# @mdwrk/mdwrkcom-content-pack
+
+**MdWrk public-site content distribution**
+
+<p align="center">
+  <a href="https://github.com/groupsum/markdown_workspace/blob/master/packages/content/mdwrkcom-content-pack/README.md"><img alt="Hits" src="https://visitor-badge.laobi.icu/badge?page_id=groupsum.markdown_workspace.packages_content_mdwrkcom_content_pack_README&amp;left_text=hits" /></a>
+  <a href="https://www.npmjs.com/package/@mdwrk/mdwrkcom-content-pack"><img alt="Downloads" src="https://img.shields.io/npm/dm/%40mdwrk%2Fmdwrkcom-content-pack?label=downloads" /></a>
+  <a href="../../../package.json"><img alt="Node" src="https://img.shields.io/badge/node-20.x%20%7C%2021.x%20%7C%2022.x-339933?logo=node.js&amp;logoColor=white" /></a>
+  <a href="../../../LICENSE"><img alt="License: Apache-2.0" src="https://img.shields.io/badge/license-Apache--2.0-blue.svg" /></a>
+</p>
+
+This package distributes the mdwrk.com source content tree, markdown data, public assets, and generated discovery artifacts.
+
+## Why
+Use it when you need the content itself as a package boundary rather than consuming the mdwrk.com app repository structure directly.
+
+## What
+- Source content and markdown data roots.
+- Sitemap definition path and generated discovery outputs.
+- Path helpers for consumers that need stable package-relative access.
+
+## Installation
+Node.js 20.x through 22.x, matching the workspace engine contract in the root package manifest.
+
+```bash
+npm install @mdwrk/mdwrkcom-content-pack
+```
+
+## Usage
+```ts
+import { mdwrkcomContentPack, resolveMdwrkcomContentPackPath } from "@mdwrk/mdwrkcom-content-pack";
+
+console.log(mdwrkcomContentPack.generatedArtifacts);
+console.log(resolveMdwrkcomContentPackPath(mdwrkcomContentPack.sitemapPath));
+```
+
+## Related
+- [Packages index](../../README.md) - family and package navigation
+- [Root README](../../../README.md) - repo overview

package/content/pages/answers/does-mdwrk-require-a-server.md

@@ -0,0 +1,27 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/answers/does-mdwrk-require-a-server/"
+title: "Does MdWrk Require A Server?"
+description: "MdWrk does not require a hosted server for normal Markdown editing; networked flows are explicit integrations."
+h1: "Does MdWrk require a server?"
+entity: "MdWrk"
+intent: "does mdwrk require a server"
+contentType: "faq"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "A direct answer for readers checking MdWrk's local-first editing boundary."
+parent: "/answers/"
+related:
+  - "/features/"
+  - "/answers/how-does-mdwrk-store-markdown-locally/"
+  - "/trust/privacy-boundary/"
+faqs:
+  - question: "Does MdWrk require a server?"
+    answer: "MdWrk does not require a hosted server for normal Markdown editing. Sync, package discovery, and deployment are explicit networked workflows."
+---
+
+MdWrk does not require a hosted server for normal Markdown editing. The product is designed around browser-based, local-first authoring where writing, preview, and workspace organization can remain available without a hosted authoring backend.
+
+Some workflows still use network services. Sync, repository operations, package discovery, and deployment are separate integration paths that go beyond the default editing boundary.
+
+That distinction is important because it lets teams evaluate MdWrk as a local-first writing tool first, then decide later which connected workflows they actually need.

package/content/pages/answers/how-do-mdwrk-theme-packs-work.md

@@ -0,0 +1,27 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/answers/how-do-mdwrk-theme-packs-work/"
+title: "How Do MdWrk Theme Packs Work?"
+description: "MdWrk theme packs target governed token and surface contracts so styling can travel across editor, preview, and lander surfaces."
+h1: "How do MdWrk theme packs work?"
+entity: "MdWrk"
+intent: "how do mdwrk theme packs work"
+contentType: "faq"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "A direct answer about MdWrk theme pack contracts and portable styling."
+parent: "/answers/"
+related:
+  - "/features/"
+  - "/packages/theme-contract/"
+  - "/packages/"
+faqs:
+  - question: "How do MdWrk theme packs work?"
+    answer: "MdWrk theme packs target governed token and surface contracts instead of patching product internals."
+---
+
+MdWrk theme packs target governed token and surface contracts so styling can travel across editor, preview, and lander surfaces. The goal is to keep visual customization portable instead of tying every theme to private implementation details.
+
+That contract-based approach helps package authors, extension authors, and product contributors work against stable styling surfaces. A theme can express product identity while the underlying reusable packages keep their generic behavior.
+
+In practice, theme packs make it easier to change appearance without rewriting renderer, editor, or extension logic.

package/content/pages/answers/how-does-mdwrk-store-markdown-locally.md

@@ -0,0 +1,27 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/answers/how-does-mdwrk-store-markdown-locally/"
+title: "How Does MdWrk Store Markdown Locally?"
+description: "MdWrk uses browser-local persistence for workspace state so authoring can remain device-local unless users choose an integration."
+h1: "How does MdWrk store Markdown locally?"
+entity: "MdWrk"
+intent: "how does mdwrk store markdown locally"
+contentType: "faq"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "A direct answer about MdWrk local persistence and storage boundaries."
+parent: "/answers/"
+related:
+  - "/features/indexeddb-markdown-storage/"
+  - "/answers/does-mdwrk-require-a-server/"
+  - "/trust/privacy-boundary/"
+faqs:
+  - question: "How does MdWrk store Markdown locally?"
+    answer: "MdWrk uses browser-local persistence for workspace state so normal authoring can remain local-first."
+---
+
+MdWrk uses browser-local persistence for workspace state so authoring can remain device-local unless the user chooses a workflow that moves content elsewhere. This keeps local writing, preview, and organization available as the default path.
+
+Local persistence does not remove export, sync, or repository workflows. It makes the storage boundary clearer by separating normal local editing from the moments when a user intentionally moves content across systems.
+
+That boundary is part of the broader MdWrk local-first model, where Markdown authoring starts on the device and connected workflows remain explicit choices.

package/content/pages/answers/index.md

@@ -0,0 +1,39 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/answers/"
+title: "MdWrk Answers | Markdown Questions And Direct Answers"
+description: "Read direct answers about MdWrk, local-first Markdown workflows, offline editing, local storage, and theme-pack behavior."
+h1: "Answers"
+entity: "MdWrk"
+intent: "mdwrk answers"
+contentType: "docs"
+updatedAt: "2026-05-12"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Use the answers hub when you want short, direct responses before moving into feature pages, package pages, or broader Markdown guides."
+parent: "/"
+related:
+  - "/markdown/"
+  - "/features/"
+  - "/packages/"
+faqs:
+  - question: "What belongs in the MdWrk answers section?"
+    answer: "The answers section covers direct MdWrk questions, local-first Markdown concepts, offline editing, storage boundaries, and theme-pack behavior."
+  - question: "How is an answers page different from a docs page?"
+    answer: "An answers page gives a short direct response first, then links into fuller docs, feature explanations, package pages, or related Markdown guides."
+---
+
+The MdWrk answers section is the direct-response layer of the site. It is meant for visitors, crawlers, and AI assistants that need a clear answer first and deeper product context second.
+
+## MdWrk answer pages
+
+- [What is a local-first Markdown workspace?](/answers/what-is-a-local-first-markdown-workspace/) explains the model behind local writing, preview, and organization before sync enters the workflow.
+- [What is an offline Markdown editor?](/answers/what-is-an-offline-markdown-editor/) defines offline Markdown editing and why it matters for everyday writing.
+- [Does MdWrk require a server?](/answers/does-mdwrk-require-a-server/) answers the core hosting question directly.
+- [How does MdWrk store Markdown locally?](/answers/how-does-mdwrk-store-markdown-locally/) explains the local persistence boundary.
+- [How do MdWrk theme packs work?](/answers/how-do-mdwrk-theme-packs-work/) covers token and surface contracts for portable styling.
+
+## Continue into broader guides
+
+Use the [Markdown guides](/markdown/) when the question is broader than MdWrk itself. That section explains Markdown concepts, syntax, editors, and common comparisons for general Markdown search intent.
+

package/content/pages/answers/what-is-a-local-first-markdown-workspace.md

@@ -0,0 +1,27 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/answers/what-is-a-local-first-markdown-workspace/"
+title: "What Is A Local-First Markdown Workspace? | MdWrk"
+description: "A local-first Markdown workspace keeps normal writing, preview, and organization local while sync and hosted integrations remain optional paths."
+h1: "What is a local-first Markdown workspace?"
+entity: "MdWrk"
+intent: "what is a local-first markdown workspace"
+contentType: "faq"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "A direct answer for readers evaluating local-first Markdown writing tools and workspace behavior."
+parent: "/answers/"
+related:
+  - "/markdown/what-is-markdown/"
+  - "/features/"
+  - "/trust/privacy-boundary/"
+faqs:
+  - question: "What is a local-first Markdown workspace?"
+    answer: "It is an authoring environment where normal Markdown writing, preview, and organization work locally first, while sync and hosted integrations remain optional."
+---
+
+A local-first Markdown workspace is an authoring environment where normal writing, preview, and organization work locally first. Sync, repository, and hosted integrations can still exist, but they are optional paths rather than requirements for every edit.
+
+That model matters when teams want Markdown to stay usable during normal daily work even if a hosted service is unavailable. It also makes it easier to understand what stays on the device, what moves through sync, and what belongs to a publishing or repository workflow.
+
+MdWrk follows that approach by treating Markdown authoring, preview, and workspace organization as the default experience before optional networked workflows enter the picture.

package/content/pages/answers/what-is-an-offline-markdown-editor.md

@@ -0,0 +1,27 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/answers/what-is-an-offline-markdown-editor/"
+title: "What Is An Offline Markdown Editor? | MdWrk"
+description: "An offline Markdown editor lets authors write and preview Markdown without requiring a live hosted backend for normal editing."
+h1: "What is an offline Markdown editor?"
+entity: "MdWrk"
+intent: "what is an offline markdown editor"
+contentType: "faq"
+updatedAt: "2026-05-05"
+author: CobyCloud
+subtitle: "A direct answer for readers comparing offline Markdown tools and browser-based writing surfaces."
+parent: "/answers/"
+related:
+  - "/markdown/what-is-a-markdown-editor/"
+  - "/features/"
+  - "/compare/local-first-markdown-editors/"
+faqs:
+  - question: "What is an offline Markdown editor?"
+    answer: "It is a Markdown editor that keeps normal writing and preview available without requiring a live hosted authoring backend."
+---
+
+An offline Markdown editor lets authors write and preview Markdown without requiring a live hosted backend for normal editing. Offline capability matters for drafts, documentation, release notes, and note-taking workflows that should continue even when the network is unavailable.
+
+Most offline Markdown tools add different layers around that core idea. Some focus on a single document, while others add preview, file management, workspace organization, themes, or publishing workflows.
+
+MdWrk approaches offline editing as part of a broader local-first Markdown workspace, pairing browser-based authoring with preview, local persistence, and optional integration paths.

package/content/pages/blog/launch.md

@@ -0,0 +1,42 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/updates/launch/"
+title: "MdWrk launch notes for a static local-first Markdown lander"
+description: "The MdWrk launch article explains why the public lander is compiled from Markdown into static HTML, JSON-LD, LLM indexes, and Markdown mirrors."
+h1: "MdWrk launch notes"
+entity: "MdWrk"
+intent: "MdWrk launch story"
+contentType: "update"
+updatedAt: "2026-05-04"
+author: CobyCloud
+publishedAt: "2026-05-04"
+subtitle: "The MdWrk launch story centers on a local-first Markdown workspace and a public lander that compiles Markdown into static, verifiable, machine-readable artifacts before deployment."
+faqs:
+  - question: "Why does the MdWrk lander compile static HTML?"
+    answer: "Static HTML makes the primary public content readable before JavaScript, which supports search, accessibility, answer engines, and deployment-independent verification."
+parent: "/"
+related:
+  - "/docs/quickstart/"
+tags:
+  - launch
+  - static
+  - markdown
+---
+
+MdWrk's public launch story is not only about a Markdown editor. It is also about how the product explains itself. The public lander uses Markdown files as source content, validates frontmatter, builds a normalized registry, and produces static artifacts that can be verified before the production domain is live.
+
+## Static Before Runtime
+
+The first principle is that public content should not require a browser application shell. If a crawler, assistant, or user downloads the raw HTML response, the primary content should already be present in the page.
+
+## Machine-Readable By Default
+
+The build emits JSON-LD, sitemap data, robots policy, LLM index files, a content index, and Markdown mirrors. These artifacts are generated from the same registry so content identity, metadata, and links stay aligned.
+
+## Why It Matters
+
+A Markdown product should be able to prove its own documentation quality. MdWrk uses the compiler to check source validity, static readability, SEO signals, answer visibility, AI-oriented artifacts, and internal links without depending on production deployment.
+
+## What Comes Next
+
+The static compiler can grow as the content set grows. The important contract is already clear: Markdown body content remains the article, frontmatter remains metadata, and answer or FAQ metadata must be visibly rendered when used for structured data.

package/content/pages/compare/index.md

@@ -0,0 +1,39 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/compare/"
+title: "MdWrk Compare | Markdown Editor Comparisons"
+description: "Compare MdWrk with Markdown editors and workspace tools by local-first behavior, browser delivery, package reuse, extension boundaries, and proof artifacts."
+h1: "Compare MdWrk"
+entity: "MdWrk"
+intent: "compare mdwrk"
+contentType: "comparison"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Use this comparison hub to choose the right Markdown workspace by storage defaults, authoring model, extension boundaries, and public proof."
+related:
+  - "/compare/local-first-markdown-editors/"
+  - "/compare/mdwrk-vs-obsidian/"
+  - "/compare/mdwrk-vs-typora/"
+  - "/compare/mdwrk-vs-vscode-markdown/"
+faqs:
+  - question: "What should I compare before choosing MdWrk?"
+    answer: "Compare storage defaults, offline behavior, browser and PWA support, preview quality, extension boundaries, package reuse, export needs, and public proof artifacts."
+  - question: "Why does MdWrk need a comparison index?"
+    answer: "The comparison index gives users, crawlers, and AI assistants a canonical hub for MdWrk comparison pages instead of forcing them to infer structure from individual articles."
+---
+
+Compare MdWrk by the boundaries that matter for Markdown work: local-first authoring, browser delivery, package reuse, extension trust, preview behavior, and machine-readable proof. This page is the canonical comparison hub for the MdWrk marketing site.
+
+## Comparison pages
+
+- [Local-first Markdown Editors](/compare/local-first-markdown-editors/) compares Markdown tools by storage defaults, offline behavior, preview policy, package reuse, and public proof.
+- [MdWrk vs Obsidian](/compare/mdwrk-vs-obsidian/) frames MdWrk against a graph-oriented personal knowledge management workflow.
+- [MdWrk vs Typora](/compare/mdwrk-vs-typora/) compares browser/PWA workspace behavior with a focused desktop Markdown editor.
+- [MdWrk vs VS Code Markdown](/compare/mdwrk-vs-vscode-markdown/) compares a dedicated Markdown workspace with editor-centered Markdown authoring.
+
+## Evaluation criteria
+
+Use the same criteria across comparison pages: where documents live by default, whether normal authoring works offline, how preview behavior is handled, how extensions are governed, whether package surfaces are reusable, and whether the public site emits sitemap, robots, LLM, content index, and JSON-LD artifacts.
+
+This comparison index keeps the `/compare/` route structural, crawlable, and useful before a visitor chooses a specific alternative.

package/content/pages/compare/local-first-markdown-editors.md

@@ -0,0 +1,27 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/compare/local-first-markdown-editors/"
+title: "Local-First Markdown Editors | MdWrk Comparison"
+description: "Compare local-first Markdown editors by storage defaults, browser/PWA support, preview behavior, package reuse, and extension boundaries."
+h1: "Local-first Markdown editors"
+entity: "MdWrk"
+intent: "local-first markdown editors"
+contentType: "comparison"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Use this page to evaluate Markdown tools by local-first authoring and portable product surfaces."
+faqs:
+  - question: "What should I compare in local-first Markdown editors?"
+    answer: "Compare storage defaults, offline behavior, preview quality, package reuse, extension boundaries, and export or sync policy."
+---
+
+Local-first Markdown editors should be evaluated by more than whether they can open a Markdown file. The practical questions are storage defaults, offline behavior, preview policy, package reuse, extension boundaries, and how clearly sync or export crosses a user-controlled boundary.
+
+| Criteria | MdWrk | Other local-first editors |
+| --- | --- | --- |
+| Storage default | MdWrk centers browser-local workspace behavior for normal authoring. | Storage models vary by tool and should be inspected directly. |
+| Package reuse | MdWrk documents reusable renderer, editor, theme, extension, and lander packages. | Many tools focus on app behavior rather than portable packages. |
+| Public proof | MdWrk emits static content, sitemap, robots, LLM files, content indexes, and JSON-LD. | Public proof artifacts vary widely. |
+
+Choose the editor whose boundaries match the workflow. MdWrk is strongest when local-first browser authoring and package adoption should work together.

package/content/pages/compare/mdwrk-vs-obsidian.md

@@ -0,0 +1,27 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/compare/mdwrk-vs-obsidian/"
+title: "MdWrk Vs Obsidian | Local-First Markdown Comparison"
+description: "Compare MdWrk and Obsidian for local-first Markdown writing, package reuse, workspace behavior, privacy boundaries, and extensions."
+h1: "MdWrk vs Obsidian"
+entity: "MdWrk"
+intent: "mdwrk vs obsidian"
+contentType: "comparison"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Use this comparison when local-first Markdown authoring, package reuse, and extension contracts matter."
+faqs:
+  - question: "When should I choose MdWrk over Obsidian?"
+    answer: "Choose MdWrk when browser/PWA authoring, reusable package surfaces, and governed extension contracts matter more than graph-oriented personal knowledge management."
+---
+
+MdWrk is best evaluated as a local-first Markdown workspace and package platform. Obsidian is widely used for personal knowledge management and linked note collections. This page frames the practical difference for authors and developers evaluating Markdown workflows.
+
+| Criteria | MdWrk | Obsidian |
+| --- | --- | --- |
+| Local-first authoring | Browser and PWA-centered Markdown workspace with local persistence as a core boundary. | Local Markdown files are central, with a different app and plugin model. |
+| Package reuse | Renderer, editor, theme, extension, and lander packages are documented as reusable surfaces. | Typically evaluated as an app and plugin ecosystem first. |
+| Extension contracts | Governed package and manifest surfaces keep extension behavior explicit. | Plugin behavior follows Obsidian's ecosystem and product model. |
+
+Choose MdWrk when you need browser availability, reusable package adoption, governed extension contracts, and static product documentation that explains the boundary clearly.

package/content/pages/compare/mdwrk-vs-typora.md

@@ -0,0 +1,27 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/compare/mdwrk-vs-typora/"
+title: "MdWrk Vs Typora | Markdown Workspace Comparison"
+description: "Compare MdWrk and Typora for local-first Markdown writing, live preview, package reuse, workspace organization, and extension surfaces."
+h1: "MdWrk vs Typora"
+entity: "MdWrk"
+intent: "mdwrk vs typora"
+contentType: "comparison"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Use this comparison when choosing between a workspace and a focused Markdown editor."
+faqs:
+  - question: "When should I choose MdWrk over Typora?"
+    answer: "Choose MdWrk when workspace organization, browser/PWA delivery, package reuse, and extension contracts matter more than a minimal single-document writing surface."
+---
+
+MdWrk and Typora fit different Markdown workflows. Typora is commonly associated with focused document writing. MdWrk presents Markdown as a workspace with preview, organization, package surfaces, themes, and extensions.
+
+| Criteria | MdWrk | Typora |
+| --- | --- | --- |
+| Workspace model | Project-oriented browser/PWA workspace with package and extension documentation. | Focused Markdown editing experience. |
+| Package reuse | Editor and renderer package families are part of the public product story. | Usually adopted as an application rather than a reusable package platform. |
+| Extensions | Governed extension runtime and package contracts are visible surfaces. | Extension behavior is not the center of the product comparison. |
+
+Choose MdWrk when the Markdown workflow extends beyond a single document and needs product, package, and extension surfaces to remain aligned.

package/content/pages/compare/mdwrk-vs-vscode-markdown.md

@@ -0,0 +1,27 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/compare/mdwrk-vs-vscode-markdown/"
+title: "MdWrk Vs VS Code Markdown | Markdown Workspace Comparison"
+description: "Compare MdWrk and VS Code Markdown workflows for writing, preview, local-first behavior, package reuse, and extension contracts."
+h1: "MdWrk vs VS Code Markdown"
+entity: "MdWrk"
+intent: "mdwrk vs vscode markdown"
+contentType: "comparison"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "Use this comparison when deciding whether Markdown authoring should live in a focused workspace or inside a general code editor."
+faqs:
+  - question: "When should I choose MdWrk over VS Code Markdown?"
+    answer: "Choose MdWrk when Markdown writing, preview, local-first workspace behavior, and package reuse should be the primary product surface."
+---
+
+VS Code is a broad development environment with Markdown capabilities. MdWrk makes Markdown authoring, preview, local-first workspace behavior, themes, and package reuse the center of the product.
+
+| Criteria | MdWrk | VS Code Markdown |
+| --- | --- | --- |
+| Product focus | Markdown workspace, preview, packages, and extensions are the core surface. | Markdown is one capability inside a general IDE. |
+| Local-first story | Browser/PWA workspace behavior and local persistence are explicit. | Local behavior depends on editor setup and extensions. |
+| Package adoption | MdWrk documents reusable editor and renderer package surfaces directly. | Extension and editor behavior are tied to the VS Code ecosystem. |
+
+Choose MdWrk when the audience is writing and publishing Markdown rather than primarily editing source code.

package/content/pages/docs/extensions.md

@@ -0,0 +1,34 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/docs/extensions/"
+title: "MdWrk extensions documentation for workspace developers"
+description: "MdWrk extension docs explain manifests, host boundaries, runtime surfaces, capability expectations, and trust policy for Markdown workspace extensions."
+h1: "Extensions"
+entity: "MdWrk"
+intent: "learn MdWrk extensions"
+contentType: "docs"
+updatedAt: "2026-05-04"
+author: CobyCloud
+subtitle: "MdWrk extensions are documented as governed workspace integrations with manifest metadata, runtime boundaries, compatibility checks, and explicit user trust policy."
+parent: "/docs/quickstart/"
+related:
+  - "/docs/theme-packs/"
+tags:
+  - extensions
+  - docs
+  - runtime
+---
+
+Extensions let MdWrk describe additional workspace capabilities without turning the product into an unbounded runtime. The docs should explain what an extension can do, how it identifies itself, and how trust is represented.
+
+## Manifest Metadata
+
+The extension manifest is the first durable contract. It should describe identity, compatibility, capabilities, and package expectations in a way that can be reviewed before activation.
+
+## Runtime Surface
+
+Runtime surfaces may include panels, settings, commands, or workspace views. The documentation should connect these surfaces back to the local-first Markdown workflow rather than presenting extensions as unrelated widgets.
+
+## Trust And Compatibility
+
+Extension trust should be explicit. Users and operators need to understand which package is being used, what it can access, and whether the version is compatible with the current workspace.

package/content/pages/docs/quickstart.md

@@ -0,0 +1,48 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/docs/quickstart/"
+title: "MdWrk quickstart - Write and preview Markdown locally"
+description: "Start using MdWrk by understanding the local-first workspace model, the Markdown editor and renderer surfaces, and where public static docs fit."
+h1: "MdWrk quickstart"
+entity: "MdWrk"
+intent: "learn how to start using MdWrk"
+contentType: "docs"
+updatedAt: "2026-05-04"
+author: CobyCloud
+locale: "en"
+localeGroup: "docs-quickstart"
+subtitle: "Start with MdWrk by opening the workspace, writing Markdown in the source editor, checking rendered preview, and using docs to understand local storage, export, and extension boundaries."
+faqs:
+  - question: "What should new MdWrk users read first?"
+    answer: "New users should read the quickstart, offline Markdown editor page, and local-first workspace page before exploring extension and theme documentation."
+parent: "/"
+related:
+  - "/docs/extensions/"
+tags:
+  - docs
+  - quickstart
+  - markdown
+---
+
+This quickstart explains the public MdWrk model before deployment. It does not depend on the production domain being live, and it does not require a client-side application shell to explain the product.
+
+## Create Your First Document
+
+Begin with a Markdown document and keep the source text readable. MdWrk treats Markdown as portable content, so the document should remain useful outside a single hosted service or proprietary editor state.
+
+1. Create or open a Markdown file in the local workspace.
+2. Add a title, short introduction, and at least one structured section.
+3. Save the file as plain Markdown so the source remains portable.
+4. Preview the rendered output before sharing or exporting.
+
+## Preview The Result
+
+Use preview to check headings, lists, links, code blocks, and document structure. The renderer is part of the package story, so public docs should describe the rendered result in terms that developers and authors can inspect.
+
+## Understand Local Boundaries
+
+MdWrk is described as local-first and privacy-first. That means the docs should explain what stays local, when export happens, when sync may contact an external service, and how extensions fit into the trust model.
+
+## Continue Through The Docs
+
+After this page, read the extension docs, theme pack docs, and comparison pages. The static lander generates HTML, Markdown mirrors, JSON-LD, sitemap data, robots policy, and LLM index files from the same content registry.

package/content/pages/docs/theme-packs.md

@@ -0,0 +1,34 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/docs/theme-packs/"
+title: "MdWrk theme packs documentation for Markdown workspace styling"
+description: "MdWrk theme pack docs explain theme contracts, token surfaces, visual boundaries, and how Markdown workspace styling remains inspectable."
+h1: "Theme packs"
+entity: "MdWrk"
+intent: "learn MdWrk theme packs"
+contentType: "docs"
+updatedAt: "2026-05-04"
+author: CobyCloud
+subtitle: "MdWrk theme packs document the token and styling contract for workspace presentation so visual changes can be inspected without changing Markdown source content."
+parent: "/docs/quickstart/"
+related:
+  - "/docs/extensions/"
+tags:
+  - themes
+  - docs
+  - styling
+---
+
+Theme packs describe how MdWrk presents the Markdown workspace without changing the underlying Markdown source. The documentation separates content, rendering, and theme behavior so users know what is styling and what is document data.
+
+## Theme Contract
+
+A theme should define visual tokens, layout behavior, syntax colors, and component styling boundaries. It should not rewrite public content or hide important text from crawlers and readers.
+
+## Syntax Color
+
+Code block syntax colors must be visible in generated HTML when the renderer emits token classes. Lander themes define different color variables for light and dark modes, while the static compiler keeps source content readable.
+
+## Extension Relationship
+
+Theme packs may be delivered through extension surfaces, but the documentation should explain which package owns the contract and how the workspace applies the visual layer.

package/content/pages/es/docs/quickstart.md

@@ -0,0 +1,50 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/es/docs/quickstart/"
+title: "MdWrk inicio rapido para escribir y previsualizar Markdown local"
+description: "Empieza con MdWrk entendiendo el modelo local-first, el editor Markdown, la vista previa y el papel de la documentacion estatica publica."
+h1: "Inicio rapido de MdWrk"
+entity: "MdWrk"
+intent: "aprender como empezar con MdWrk"
+contentType: "docs"
+updatedAt: "2026-05-06"
+author: CobyCloud
+locale: "es"
+translationOf: "/docs/quickstart/"
+localeGroup: "docs-quickstart"
+subtitle: "Empieza con MdWrk abriendo el espacio de trabajo, escribiendo Markdown en el editor fuente, revisando la vista previa renderizada y usando la documentacion para entender almacenamiento local, exportacion y extensiones."
+faqs:
+  - question: "Que deberian leer primero los nuevos usuarios de MdWrk?"
+    answer: "Los nuevos usuarios deberian leer el inicio rapido, la pagina del editor Markdown sin conexion y la pagina del espacio local-first antes de explorar extensiones y temas."
+parent: "/"
+related:
+  - "/docs/quickstart/"
+  - "/docs/extensions/"
+tags:
+  - docs
+  - quickstart
+  - markdown
+---
+
+Este inicio rapido explica el modelo publico de MdWrk antes de la implementacion. No depende de que el dominio de produccion este activo y no requiere que una aplicacion cliente renderice la pagina para explicar el producto.
+
+## Crea Tu Primer Documento
+
+Empieza con un documento Markdown y conserva el texto fuente como contenido legible. MdWrk trata Markdown como contenido portable, por eso el documento debe seguir siendo util fuera de un servicio alojado o de un estado propietario del editor.
+
+1. Crea o abre un archivo Markdown en el espacio de trabajo local.
+2. Agrega un titulo, una introduccion breve y al menos una seccion estructurada.
+3. Guarda el archivo como Markdown plano para que el origen siga siendo portable.
+4. Revisa la vista previa renderizada antes de compartir o exportar.
+
+## Revisa La Vista Previa
+
+Usa la vista previa para comprobar encabezados, listas, enlaces, bloques de codigo y estructura del documento. El renderizador forma parte de la historia de paquetes, asi que la documentacion publica debe describir el resultado renderizado con terminos que desarrolladores y autores puedan inspeccionar.
+
+## Entiende Los Limites Locales
+
+MdWrk se describe como local-first y privacy-first. Eso significa que la documentacion debe explicar que permanece local, cuando ocurre la exportacion, cuando la sincronizacion puede contactar un servicio externo y como entran las extensiones en el modelo de confianza.
+
+## Continua Por La Documentacion
+
+Despues de esta pagina, lee la documentacion de extensiones, paquetes de temas y comparaciones. El lander estatico genera HTML, espejos Markdown, JSON-LD, datos de sitemap, politica robots y archivos de indice LLM desde el mismo registro de contenido.

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

@@ -0,0 +1,25 @@
+---
+schema: "mdwrk.page.v1"
+slug: "/features/extension-runtime/"
+title: "Extension Runtime | MdWrk"
+description: "MdWrk extensions use governed runtime, manifest, compatibility, and trust surfaces instead of patching the client directly."
+h1: "Extension runtime"
+entity: "MdWrk"
+intent: "markdown workspace extension runtime"
+contentType: "feature"
+updatedAt: "2026-05-05"
+author: CobyCloud
+displayAuthor: false
+subtitle: "The MdWrk extension runtime gives package authors a documented way to add commands, panes, settings, and integrations."
+faqs:
+  - question: "What is the MdWrk extension runtime?"
+    answer: "The extension runtime is the governed host surface for adding commands, panes, settings, and integrations to MdWrk."
+  - question: "Do extensions patch the client directly?"
+    answer: "No. Extensions are expected to use documented manifests, compatibility rules, lifecycle hooks, and trust boundaries."
+---
+
+The MdWrk extension runtime gives package authors a governed way to extend the workspace. Instead of patching the client directly, extensions describe their contribution through documented package and manifest surfaces.
+
+This matters for trust and portability. Runtime lifecycle, compatibility metadata, installable artifacts, and host context stay explicit, which makes extension behavior easier to inspect and easier to verify.
+
+The reusable lander package does not contain any MdWrk extension claim. MdWrk-specific extension facts live here in the content pack, while the lander packages render feature pages generically.