Values in the chip type enum
43
Rows in the catalog table
35
Chips with a component
29
Chips published and clickable
28
Use cases written by hand
69
Categories in the sort order
9
Categories with a chip in them
5
Four Numbers for the Same Thing
Start with the funnel, because every other page quotes a different figure and they are all correct. Forty-three is the enum, which includes names reserved for ideas that have not been built. Thirty-five have a row in the catalog table and therefore a card. Twenty-nine have a component that can actually render. Twenty-eight are marked published and clickable. The gaps are not mistakes, they are three different questions: what has a name, what has an entry, what has code.
It Is a Table, Not a File
The catalog reads from a database table with a display name, a description, a category, an icon and a published date per chip. That means a chip can be renamed or re-described or unpublished without a deploy. Separately, and confusingly, there is a registry file in the front end holding the twenty-nine render components and their sample payloads. Two lists, two owners, no constraint keeping them aligned. When they disagree you get exactly the odd cases below.
Four Tabs and No Search Box
Type groups by category. Use Case groups by what you are trying to make. Explore drops the categories entirely and pulls real chips out of real public slates into a masonry wall, so you see what people actually built rather than sample data. There is a fourth tab, Popular, and it takes no distinct code path at all: selecting it renders exactly what Type renders, with a different button highlighted. It is hidden behind a role, which is probably why nobody has noticed. There is no search field of any kind.
The Empty Categories
Nine categories are in the hardcoded sort order. Five have chips: Basic, Content, Productivity, Community, Organization. Collaboration, Commerce, Data and Integration have never had a single chip assigned. They are hidden at render because an empty group returns nothing, so the page looks fine while the data model carries four aspirational labels. They are also still offered in the admin dropdown, which is how you end up with a category nobody can find.
Unreleased Chips Are Shown by Default
There is a toggle for hiding them, and it starts off. Every visitor, signed in or not, sees the six chips with a card and no component, greyed and not clickable. The argument for that is a roadmap you do not have to write. The argument against is that it is a list of promises with no dates on it. It is the default because the toggle was added after the cards were.
Every Preview Is a Real Chip
The detail page for a chip does not show a screenshot. It builds a mock chip record with a sample payload, hands it to the same component the slate page uses, and renders it. What you are looking at on /chips/counter is a Counter chip, wired to nothing, with a fake author called Demo User. The chip below is that same component with the same sample treatment.
69use cases written by hand
Sixty-Nine Recipes
The Use Case tab is the largest piece of hand-written content in the feature: a couple of thousand lines listing arrangements like Recipe Card, Property Listing, Podcast Press Kit, Team Onboarding Guide, Memorial Page, Open Source Project Page. Each one names its chips in order and rewrites their description for that context, so Info in a Recipe Card is described differently from Info in a Freelancer Rate Card. It is unglamorous and it is the part that actually answers what do I do with these.
On a chip detail page today
Icon name and description
Published or unreleased tag
Category tag
A live rendered preview
A feedback button
Two related chips
The chext example for that chip
Its attribute list
Its content format
Copy to clipboard
The Documentation Is Already There
Those four unticked lines are not missing data. Every chip record carries a chext description, a chext example, its options and its content format, and all four are fetched and sitting in the props of the detail page unused. They render on one long combined page instead. Splitting them onto the per-chip pages is a small change that has not been made, and it is the single most useful thing that could happen to this feature.
Two Rows That Disagree with Themselves
Worth naming precisely. One published chip has no chext definition row at all, so it can be placed in the editor and not written in a file, and it silently vanishes from the syntax page because that page filters on having an example. And one chip has a component, a definition and an example but no published date and no icon, so its card is greyed while its page loads perfectly if you type the address. Both are rows in a table that nothing validates.
Indexed by Nobody
The whole /chips tree is on the noindex list, and there is no per-chip metadata branch, so twenty-eight content-rich pages are rendered on the server in full and then explicitly asked not to be indexed, sharing one generic title between them. There is a reasonable version of that decision and a version where it was set once and never revisited. This is the second one.
