ApiSurfaceAudit

Method: enumerated exports from each package's index.ts/index.tsx, then searched all import sites in creatorsgarten.org/src (pinned to contentsgarten@2.1.0 / @contentsgarten/html@1.3.0) and in the three in-repo reference apps (wiki.creatorsgarten.org, wiki.wonderful.software, contentsgarten.netlify.app).

Headline finding: creatorsgarten.org — the real-world production consumer this audit cares most about — touches exactly one export of the core contentsgarten package: ContentsgartenRouter, and only as a type, for tRPC client inference. It never instantiates the engine; it's a pure remote HTTP client against a separately-hosted contentsgarten instance. Everything else in the core package's API surface exists only for the three apps that live inside this monorepo.

contentsgarten (core)

Export	creatorsgarten.org	internal apps	status
ContentsgartenRouter (const+type)	type-only, for tRPC client	used (type + runtime via localLink)	used
Contentsgarten (class)	—	used	internal-only
createContentsgarten	—	used	internal-only
handleContentsgartenRequest	—	used	internal-only
GetPageResult (type)	—	used	internal-only
testing.createFakeInstance	—	used (netlify's "fake backend" test mode)	internal-only
CreateContextInput, createContextFromRequest	—	—	unused anywhere
PageRef, LaxPageRef, PageRefRegex	—	—	unused anywhere
defineConfig	—	—	unused anywhere (all 3 apps pass a plain object literal to createContentsgarten)
ContentsgartenUserConfig + 5 sub-interfaces (GitHubUserConfig, GitHubAppAuthUserConfig, FirebaseUserConfig, CustomJwtAuthUserConfig, MongoDBUserConfig)	—	—	unused anywhere (never imported by name; config objects are inline literals)
testing.* other than createFakeInstance	—	—	unused externally (internal test scaffolding only)

@contentsgarten/html

• Html (component) + MarkdownCustomComponents (type) — used by creatorsgarten.org and all 3 internal apps.
• isWikiLink — used only by wiki.creatorsgarten.org → internal-only.
• DirectiveType, LinkProps — unused anywhere.

@contentsgarten/client-utils

• FirebaseAuthProvider (class), ContentsgartenAuthProvider (type) — used by wiki.creatorsgarten.org and wiki.wonderful.software only.
• ContentsgartenUser (type) — not imported by name anywhere.
• creatorsgarten.org does not depend on this package at all — it has its own separate auth flow (an authgarten cookie), not the Firebase-popup flow this package implements. A whole published package with zero adoption by the real-world consumer.

@contentsgarten/server-utils

• localLink — its only export, used by all 3 internal apps (running tRPC against a same-process router without HTTP). Already minimal, nothing to trim.

@contentsgarten/markdown

Exports renderMarkdown, processMarkdown, MarkdownProcessingResult, Heading, WikiLink, MarkdownRenderer, directives. Published independently on npm, but no consumer — internal or external — imports it directly. It's consumed only as a workspace dependency of the core contentsgarten package (markdown→HTML rendering happens server-side inside the engine; consumers receive pre-rendered HTML). Candidate to stop publishing standalone unless there's a known external consumer outside this audit's scope.

Prioritized trim candidates

1. defineConfig, PageRef, LaxPageRef, PageRefRegex, CreateContextInput, createContextFromRequest — dead exports, zero consumers anywhere. Safest first cut.
2. ContentsgartenUserConfig + its 5 sub-interfaces — never imported by name; keep the shape internal to createContentsgarten's parameter type instead of exporting each variant.
3. DirectiveType, LinkProps (@contentsgarten/html) — unused types, easy removal.
4. testing namespace beyond createFakeInstance — internal test scaffolding leaking into the public API surface.
5. @contentsgarten/client-utils as a whole — creatorsgarten.org doesn't use it; only 2 of 3 dogfooding apps do, for a Firebase popup-auth pattern that may itself be legacy. Worth asking whether this needs to stay a published package vs. becoming example code.
6. @contentsgarten/markdown — publish status looks like leftover infrastructure; no direct external or internal-app consumer found.

Dependency-weight flag (qualitative, not exhaustive)

Core contentsgarten bundles octokit, mongodb, @keyv/redis, liquidjs, openapi-trpc, axios, jose unconditionally — full GitHub+MongoDB+Redis+Liquid-templating+OpenAPI-gen+JWT stacks ship regardless of which storage/auth backend a consumer actually configures. Since creatorsgarten.org never even instantiates the class (pure HTTP client), all of this weight is irrelevant to its bundle but currently inseparable from the package's type surface. Worth a follow-up look at whether backends can become optional/peer dependencies.