For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /docs/web/content.md (or send Accept: text/markdown).
Content management
Typed CMS entries with a free lifecycle and a public read boundary.
Beginner walkthrough
Prerequisites: Read the two beginner guides below, finish Web local setup, and open this monorepo at its root in your editor. Web settings belong in apps/web/.env.local; Next.js does not read the root .env. /dashboard in the default fake mode is a no-database demo; /auth needs a migrated database.
Quick terms: a workspace is one team's separate users, data, and settings. The server is the trusted backend; keep provider keys out of browser and phone code. A migration is a versioned database change that creates or updates tables. An AI model is the engine that answers; the model catalog is the server's list of available model IDs and prices. A provider is an outside service such as an AI, email, or billing service. An entitlement is a grant that lets a workspace use a feature. A webhook is a message one service sends to another service's URL.
1. Sign in as a workspace owner or admin, open /content, and use the form to create a post, page, doc, or report with a unique slug. Save it as a draft, then publish it.
2. Confirm the status changes to published; a duplicate slug or member without management access should fail.
3. For a gated test, use required_entitlement=ai.reference-task; without a verified grant, the page must show only its teaser.
For custom code, start with the supplied prompts/README.md and copy the closest prompt: prompts/new-app-screen.md for an app screen or prompts/new-landing-page.md for a public page. For server, database, or provider work, give your coding agent this guide's task and ask it to read AGENTS.md, .ai/PROJECT_CONTEXT.md, and matching .ai/ mirrors; inspect the exact source files named here; list files and checks before editing; preserve workspace ownership and server-only secrets; and show you the diff. Tell it the behavior you want, input and output fields, allowed roles, expected success and errors, and the test account, provider, or device. Use sample values; never paste a real secret.
Create workspace entries
The /content manager handles post, page, doc and report entries. content_entry rows have draft/published/archived state, workspace-scoped slugs and authorship. Management actions require the appropriate owner/admin role.
This CMS is separate from the kit's typed public docs/blog catalog in src/resources. A product can render CMS entries through its own page composition.
Gate the body on the server
required_entitlement is nullable: unset entries are ungated. For gated entries, server-only content-queries.ts projects readable content or a locked teaser with an empty body. content-access.ts owns the projection; never trust a client-supplied entitlement claim.
Publishing emits content.published; scheduled digests can summarize the publishing team's recent entries. Authored content also participates in account export.
Verify publishing and access
Test draft visibility, publish/archive transitions, duplicate slugs, wrong workspace, free entries and inactive paid grants. Use the paywall block for presentation while the server remains responsible for access.
Setup and configuration
The /content workspace surface manages CMS entries — post, page, and doc are the suggested types, but the column accepts any URL-safe product type (lowercase letters, digits, dashes, underscores, up to 64 characters). The content_entry table scopes every row by workspaceId, stamps createdBy, and keeps slugs unique per workspace and type.
Entries move through a free draft ↔ published ↔ archived lifecycle — evaluateContentStatusChange in src/content.ts rejects invalid or unchanged transitions, and publishedAt stamps on first publish and survives later unpublishes so readers keep the original date.
/content workspace CMS surface
src/content.ts input + lifecycle rules
src/content-actions.ts member+ mutations
content_entry workspaceId, type, slug, statusImplementation workflow
Members and above author entries — every mutation resolves the session, the active workspace, and at least a member role through requireWorkspaceWriter (workspace-access.ts), so guests stay read-only. normalizeContentEntryInput validates type, a 1–255 character title, and a URL-safe slug before any write.
listPublishedContentEntries is the deliberate public read boundary: it takes an explicit workspaceId, needs no session, and returns published rows only — the path storefront pages, blogs, and docs use to render workspace content. Publishing emits a content.published outbound webhook, and authored entries join the GDPR data export.
Verification and troubleshooting
Exercise a draft → publish → archive round trip, a duplicate slug inside the same type, and a cross-workspace read. Confirm the public boundary never returns drafts or another workspace's rows, and that content.published fires once per publish action.