Studio: AI models settings, @embed and @decide in the schema editor, and the /v1 API

Start with the schema editor entry point in src/features/instance/applications/components/SchemaEditorView/FieldRow.tsx and the settings save flow in src/hooks/useRollingConfigUpdate.tsx; read the linked Harper source files to understand the supported settings and directives. Map the work across model settings, schema editing, and the /v1 controls, noting the Harper version gates and Fabric managed entries. Done means the acceptance criteria pass, including hidden keys, saved settings, and usable API and schema controls; adding customer models depends on HM#279.

Problem

Harper can call AI models: embeddings (turning text into vectors), generative models (writing text) and, from 5.3, decisions (picking a value). Apps use them through models.embed(), models.generate() and models.decide(), through the @embed and @decide schema directives, and through an OpenAI-style /v1 API. On Fabric, Fabric sets up some models behind the scenes. Studio shows none of this. A customer can't see which models their instance has, can't add their own, can't add @embed or @decide in the schema editor, and can't turn on the /v1 API without the raw settings editor.

What core already provides (harper)

• The models settings block (5.1+). Each entry has a name (apps use default unless they pick another) and a backend:
  • embedding and generative entries use ollama, openai, anthropic or bedrock
  • decision entries (5.3+) use the generative backend, which decides with a generative entry
  • apiKey can be a ${ENV_VAR} placeholder instead of the key itself
  • any entry can name a fallback
  • from 5.3, Harper reloads models from the settings file without a restart
• @embed(source, model) (5.1+) on a vector field fills it from another field whenever a record is written, and indexes it for vector search.
• @decide(source, ...) (5.3+) on a String, Boolean or Int field fills it from another field using a decision model. A String field needs values, and an Int field needs minimum and maximum. Optional arguments: model, confidence, decision and instructions. If the model can't decide, the write fails.
• The /v1 API (5.2+): /v1/embeddings, /v1/chat/completions and /v1/models.
  • Off by default. It's turned on with modelsGateway.enabled.
  • It's served only while REST is running, which an app's own rest: true or a root rest section turns on.
  • All three need an admin user.
• Source (v5.3.4): configValidator.ts, graphql.ts, v1/index.ts, bootstrap.ts.

On Fabric today

• Fabric writes model entries on new instances:
  • On a GPU host: the host's embedding models (by default embedding.default, plus embedding.multimodal when the host runs one), and generative.default when the host is set up for it.
  • On other instances: embedding.default, routed to the nearest GPU host. That route doesn't work across hosts yet (HM#178).
• Fabric replaces the whole models block, so a customer's own entries are wiped. That's fixed by HM#279, and adding models in Studio waits on it.

What to build

• An "AI models" section in instance settings, shown only on Harper 5.1+ and only to admin users.
• Show the instance's models: for each kind, list each entry's name, backend and model, and mark the ones Fabric manages. Never show an apiKey or token.
• Add, edit and remove the customer's own models (Harper 5.3+, once HM#279 lands):
  • pick a kind, a name and a backend, then the backend's fields
  • accept a key or a ${ENV_VAR} placeholder in apiKey, and never show a saved key back
  • save to Harper's settings. No restart is needed, since Harper reloads models from 5.3
  • don't offer to edit or remove entries Fabric manages
• Schema editor: Studio's schema editor offers neither directive today (FieldRow.tsx). Offer only model names the instance has.
  • @embed on vector fields: source field and model.
  • @decide on String, Boolean and Int fields, on Harper 5.3+: source field, model, and values or a range.
• /v1 API (Harper 5.2+):
  • Turn it on or off, and show its address on the instance's HTTPS address.
  • Save with Studio's existing settings save and restart (useRollingConfigUpdate.tsx).
  • If no app or root setting turns on REST, say that /v1 won't answer until one does.
• Show Harper's own error when it refuses a setting or a schema.
• Explain, next to the controls:
  • which models Fabric provides on this instance, and that Fabric manages them
  • @decide fails the write when the model can't decide
  • the /v1 API needs an admin user

Acceptance criteria

• A customer can see which models their instance has, without seeing any key.
• Once HM#279 lands, a customer can add their own model on Harper 5.3+, and it's still there after Fabric's next pass.
• A customer can add @embed and @decide fields in the schema editor, and records written afterwards get the derived values.
• A customer can turn the /v1 API on and reach it at the address Studio shows.

Dependencies

• Adding the customer's own models waits on HM#279.
• Studio already reads and saves settings through Fabric's command channel, and that requires "update" permission on the cluster in Fabric.