Every built-in capability seed's AiCapability upsert uses:
update: { isSystem: true },
create: { …, functionDefinition, … },The update branch omits functionDefinition, so once a capability row exists, any later change to its function schema never propagates on re-seed — the DB (and therefore the MCP tool list / what the LLM sees) keeps advertising the original schema forever.
Affects the seeds that upsert AiCapability: call_external_api, run_workflow, upload_to_storage, send_message_to_channel, model_auditor, pattern_advisor.
Why it's easy to miss
The parity tests pin class ↔ seed constant, not seed constant ↔ DB row. Everything is green while the live tool is stale. We hit this in a downstream fork: added a parameter to a capability, all tests passed, but the MCP schema on both dev and prod never showed the new field until we fixed the seed's update branch.
Suggested fix
Re-sync functionDefinition on the update branch for isSystem capabilities (it's code-owned — it must track the class), while leaving admin-editable fields (name / description / isActive) untouched:
update: { isSystem: true, functionDefinition: <thatDef> },A regression test that runs the seed unit against a mock prisma and asserts the update branch carries functionDefinition prevents recurrence.
The same "update branch drops code-owned fields" shape may affect other seeded system config (e.g. built-in agents' prompts) — worth an audit.
Every built-in capability seed's
AiCapabilityupsert uses:The
updatebranch omitsfunctionDefinition, so once a capability row exists, any later change to its function schema never propagates on re-seed — the DB (and therefore the MCP tool list / what the LLM sees) keeps advertising the original schema forever.Affects the seeds that upsert
AiCapability:call_external_api,run_workflow,upload_to_storage,send_message_to_channel,model_auditor,pattern_advisor.Why it's easy to miss
The parity tests pin class ↔ seed constant, not seed constant ↔ DB row. Everything is green while the live tool is stale. We hit this in a downstream fork: added a parameter to a capability, all tests passed, but the MCP schema on both dev and prod never showed the new field until we fixed the seed's update branch.
Suggested fix
Re-sync
functionDefinitionon the update branch forisSystemcapabilities (it's code-owned — it must track the class), while leaving admin-editable fields (name/description/isActive) untouched:A regression test that runs the seed unit against a mock prisma and asserts the update branch carries
functionDefinitionprevents recurrence.The same "update branch drops code-owned fields" shape may affect other seeded system config (e.g. built-in agents' prompts) — worth an audit.