ApiSurfaceAudit

Method: enumerated exports from each package's index.ts/index.tsx, then searched all import sites in creatorsgarten.org's source (pinned to contentsgarten@2.1.0 / @contentsgarten/html@1.3.0) and in the apps living inside this monorepo.

Consumer tiers, per dtinth (corrected twice): there is no "internal only" tier — every app that consumes contentsgarten counts as a real production consumer, whether or not it happens to live in this monorepo:

• creatorsgarten.org (separate repo) — external.
• wiki.creatorsgarten.org — external. Colocated in this repo purely for deployment convenience; can split into its own repo any time.
• contentsgarten.netlify.app ("Contentsgarten wiki") — also external. It's a live site that powers the actual contentsgarten-wiki content repo (the one backing wiki.creatorsgarten.org's content!) and dogfoods the public API in production — not just a demo/throwaway.
• wiki.wonderful.software was defunct and has been removed from the repo (#474). Its usages below are historical context only, not live.

(First pass wrongly called wiki.creatorsgarten.org "internal." Second pass fixed that but still wrongly called contentsgarten.netlify.app "internal/dogfooding-only." Both undersold how much of the API surface is real, load-bearing, external usage.)

Headline finding: creatorsgarten.org touches exactly one export of the core contentsgarten package — ContentsgartenRouter, type-only, for tRPC client inference. It's a pure remote HTTP client against a separately-hosted contentsgarten instance. The other two sites each self-host a full engine instance (createContentsgarten, handleContentsgartenRequest) — wiki.creatorsgarten.org with GitHub App auth + MongoDB + Firebase + a custom JWT authorizer, contentsgarten.netlify.app with its own GitHub App + MongoDB + Redis

• Firebase setup. Nearly the entire core API surface is real, externally-consumed, production code.

contentsgarten (core)

Export	creatorsgarten.org	wiki.creatorsgarten.org	contentsgarten.netlify.app	status
ContentsgartenRouter (const+type)	type-only, for tRPC client	type + runtime via localLink	type + runtime via localLink	used
Contentsgarten (class), createContentsgarten, handleContentsgartenRequest	—	used — self-hosts a full instance (GitHub App + MongoDB + Firebase + custom JWT)	used — self-hosts a full instance (GitHub App + MongoDB + Redis + Firebase)	used
GetPageResult (type)	—	used	used	used
testing.createFakeInstance	—	—	used — powers a "fake backend" test mode for local dev against contentsgarten.netlify.app	used (test tooling for a live site)
CreateContextInput, createContextFromRequest	—	—	—	unused anywhere
PageRef, LaxPageRef, PageRefRegex	—	—	—	unused anywhere
defineConfig	—	—	—	unused anywhere (every consumer passes 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 by any consumer (deeper test-scaffolding exports, not reached even by contentsgarten.netlify.app's own fake-backend mode)

@contentsgarten/html

• Html (component) + MarkdownCustomComponents (type) — used by all three sites.
• isWikiLink — used by wiki.creatorsgarten.org.
• DirectiveType, LinkProps — unused anywhere.

@contentsgarten/client-utils

• FirebaseAuthProvider (class), ContentsgartenAuthProvider (type) — used by wiki.creatorsgarten.org for its Firebase-popup sign-in flow. Live production code, not dead weight.
• ContentsgartenUser (type) — not imported by name anywhere.
• creatorsgarten.org doesn't depend on this package — it has its own separate auth flow (an authgarten cookie), unrelated to this package's Firebase-popup pattern. Different product, different auth needs — not evidence this package is unused.

@contentsgarten/server-utils

• localLink — its only export, used by both wiki.creatorsgarten.org and contentsgarten.netlify.app (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 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

Unchanged by either correction — none of these were ever used by any of the three sites:

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 — deeper test scaffolding exports that not even contentsgarten.netlify.app's own fake-backend mode reaches.
5. @contentsgarten/markdown — publish status looks like leftover infrastructure; no direct consumer found.

Not trim candidates, despite earlier passes flagging them: @contentsgarten/client-utils (live for wiki.creatorsgarten.org's auth) and everything in the core package used by Contentsgarten/createContentsgarten/handleContentsgartenRequest (load-bearing for both wiki.creatorsgarten.org and contentsgarten.netlify.app).

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. This is dead weight only for a pure-HTTP-client consumer like creatorsgarten.org — both other sites genuinely use the GitHub+MongoDB(+ Firebase or +Redis) backends, so this isn't dead weight repo-wide. Still worth a follow-up look at whether backends can become optional/peer dependencies, so HTTP-client-only consumers like creatorsgarten.org aren't forced to pull them in.