First-class collections, then typed custom fields per collection #71

Today

A collection is only a string on an entry (ContentEntry.collection).

• Studio shows only posts: the Articles screen hard-codes it.
• Agents can put entries into any collection through MCP (create_entry, collection: "events"), and Studio never shows them.
• RFC-0038 / ADR-0040 added the first per-collection setting, Site.collections.<key>.permalink.

Why it matters

Every platform people build real sites on has typed collections: Webflow CMS (pricing tied to CMS items), Framer CMS, Wix CMS, WordPress custom post types + ACF (about 2M active installs, unverified), Sanity, Payload and Strapi. Ghost is the exception, and its forum keeps asking for custom post types and fields (e.g. https://forum.ghost.org/t/allow-configuration-of-custom-post-types/13293). Common uses: events, team, portfolio and projects, jobs, products, docs, changelogs, testimonials, FAQs, locations.

Value for Cloudhal, highest first:

1. Collections people can see and use (first-class collections only). An agent's events entries appear in Studio, with labels and settings.
2. More reliable agents (custom fields).
   • Schema-constrained output beats free text: OpenAI reports 100% schema adherence with strict JSON-Schema output, against parseable-only JSON mode.
   • The policy engine can validate fields before approval, and the person approving reviews structured values.
   • The same direction elsewhere: Sanity's schema-aware Agent Actions, and Webflow's MCP server creating collections and items.
3. SEO structured data (custom fields). Typed fields map to schema.org JSON-LD: Event, JobPosting, Product, Recipe, FAQPage.
4. Date-driven automations (a date field): hide an event after it ends, close a job at validThrough. Fits RFC-0008 schedules.
5. Listings and filters for themes: sort and filter by a field. A per-collection sort setting gives part of it.
6. An opening for Ghost users who need more than posts and pages.

Proposed staging (each step an RFC/PR)

1. First-class collections:
   • extend Site.collections.<key> with labels and an icon per locale;
   • Studio sidebar entries and a "new collection" screen;
   • per-collection settings: permalink (done), taxonomies, feed, comments, sitemap, sort;
   • MCP list_collections and create_collection (with approval); the policy engine allows entries only in declared collections, once a migration declares the existing ones.
2. Typed custom fields (RFC):
   • field definitions per collection, values stored as JSON on the entry;
   • about 8 types: text, rich text, number, boolean, date/datetime, url, image, select;
   • all fields optional, validated by the precompiled validators;
   • Studio forms generated from the definitions;
   • the field schema exposed to agents through MCP;
   • decide per-field localization up front (Payload's localized: true).
3. Field presets: JSON-LD mapping (Event, JobPosting, FAQPage, Product, Recipe), a date-expiry automation, listings filtered by field, and a generic field renderer plus named slots for themes.
4. Later: reference fields, repeaters/blocks, and explicit, snapshotted migration ops for renaming a field or changing its type.

Risks to design for

• Field changes on existing entries. Strapi's builder loses data on rename. Keep fields additive and optional (AGENTS.md rule 3), and make renames an explicit migration op, never inferred from a diff.
• Field type sprawl. Start with about 8 types (Framer's API has about 12).
• Themes cannot know arbitrary fields. Give them a generic renderer plus slots.
• Performance. Keep fields as JSON on the entry (Wix caps an item at 512 KB) and index only sort/filter fields.

Sources: Webflow, Framer, Wix and Squarespace docs; the Ghost forum; Sanity Agent Actions; Payload localization; Strapi's feedback board; OpenAI structured outputs; Google's JobPosting structured data docs. Webflow's exact limits, Framer's plan caps and ACF's install count are unverified.