Been building a local-first memory layer for LLMs (postgres + pgvector + hybrid search, MCP server so Claude can read/write memories across sessions). Added a web UI this week. Not a big deal on its own, except what it surfaced.

The system uses "spaces" to namespace memories — you have one for work, one for personal notes, whatever. Spaces are created intentionally. The API throws 404 on unknown ones, on purpose: the MCP server writes through the same path, and I didn't want Claude inventing typo-namespaces like defalut or wotk every time it misreads a prompt.

Fine for CLI. Fine for MCP. Not fine for a UI with a dropdown.

Got to the Ingest page in the browser. The space dropdown had one entry: default. The only way to create a new space was CLI or raw SQL. So I had to decide: hack it in the frontend, or go back and design the API properly.

Frontend hack would've been faster. But it would mean the UI could create something the API couldn't. Bad contract. So I added POST /api/spaces with regex validation, matching CLI command, frontend combobox. MCP stays read-only for creation — LLMs don't get to mint namespaces.

Second thing that came out of this: the first version of the frontend lowercased and hyphenated the space name before validating. Typed my space, got my-space silently. That's a trap. If someone types my space they want to know the system doesn't allow spaces — teach the constraint, don't hide it. Ripped out the normalization.

Also got a tip from another dev yesterday on X that I'm sitting on: default postgres maintenance_work_mem is 64MB, and for HNSW index builds on pgvector that's way too low — 1GB is the real target. Haven't hit the pain yet because the dataset is small, but it's the kind of thing that silently doubles build time at scale. Bumping it next release.

Anyone else hit the "UI reveals missing API" pattern? Feels like it should have a name — most of my backend design gaps have been caught by trying to build a thin client on top, not by writing more backend tests.