Make project config the source of truth for runtime docs loading

[KayleeWilliams]

Problem

Leadtype’s artifact pipeline understands the full project config, including multiple collections, remote sync, inherited source config, mounts, navigation, and route prefixes. The human rendering path does not consume that project model as directly.

Today leadtype init writes both:

• docs/docs.config.ts with product identity and navigation; and
• lib/source.ts with a repeated contentDir, nav, and baseUrl passed to createDocsSource().

For multi-collection public docs apps, the gap is larger: artifact generation is first-class, while human rendering often needs custom MDX maps and app-specific source plumbing. This makes it possible for the rendered site and generated agent artifacts to disagree despite Leadtype’s “one content graph” goal.

Proposal

Add a project-level runtime primitive that loads the same resolved config/source graph used by generation. Possible API directions:

const project = await createDocsProject({ config: docsConfig });

const pages = await project.listPages();
const page = await project.loadPage(slug);
const navigation = await project.getNavigation();

or an equivalent createDocsSourceFromConfig() helper.

Framework adapters should accept this project/source object directly so consumers do not repeat content roots, navigation, mounts, prefixes, or collection wiring.

Required behavior

• Local single-source projects should become simpler than the current createDocsSource({ contentDir, nav, baseUrl }) scaffold.
• Multi-collection projects should expose one merged, route-aware page API with collection provenance.
• Remote sources should read from the resolved sync cache; runtime request handling must not unexpectedly clone or fetch repositories.
• Source-owned config inheritance must affect both human rendering and generated artifacts identically.
• Route collisions, missing sources, and stale caches must fail with actionable diagnostics.
• Lower-level createDocsSource() remains supported for custom integrations.

Framework integration

Update first-party adapters and examples so the normal path is:

1. load one project config;
2. create one resolved docs project/source;
3. pass it to Next/Fumadocs/Astro/Nuxt/SvelteKit/TanStack helpers;
4. render with the host app’s components and layout.

Leadtype should continue to own no rendered DOM or site theme. This is shared content/runtime state, not a move toward becoming a docs-site framework.

Acceptance criteria

• A single-repo app does not repeat contentDir, navigation, and route configuration outside its Leadtype config.
• A multi-collection app can list/load/render pages without a custom MDX map per collection.
• Human navigation and generated llms.txt / Agent Readability navigation come from the same resolved graph.
• Remote runtime loading is cache-only and clearly reports when sync is required.
• First-party framework adapters accept the project/source primitive.
• Existing lower-level source and adapter APIs remain compatible.
• At least the c15t and Leadtype public-docs apps dogfood the new path.

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}

[coderabbitai]

🔗 Related PRs

#59 - Restructure docs for agent-ready site workflow [merged]
#65 - Docs DX + agent-readability: init command, Search & AI/Concepts sections, example modernization [merged]
#77 - Align framework examples with shared docs UI [closed]
#79 - Add source config inheritance for remote docs [merged]
#81 - Improve docs routing and c15t framework dogfooding [closed]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!