GeezerVison

Stacked on #6569 → #6568 → #6567 → #6565 → #6560. Review only this PR's own commits; merge after its parents.

A skill whose existing name matches a built-in returned 400 on every save, with no in-product way out except renaming it.

Cause

updateSkill ran builtinNameCollision(params.name) in the field-validation block before resolveEditableSkill loaded the canonical row — so the persisted name was not yet in scope and the guard could not compare against it. It fired on any update carrying a name, changed or not.

Reachable from the real client: the skill modal sends updates: { name, description, content } — always the full object, including an unchanged name. (The detail page sends only changed fields and was unaffected, so the "skill modal" framing is the accurate one.)

Not theoretical

Built-in skills shipped in #4923; this guard shipped in #5273. In between, operations.ts merged built-ins with BUILTIN_SKILLS.filter((b) => !dbNames.has(b.name.toLowerCase())), so a workspace skill named research, create-table, deploy-workflow, or connect-integration was freely creatable and simply shadowed the built-in. Those rows are now stuck.

Fix

The guard moves to after resolveEditableSkill and fires only when params.name !== resolved.skill.name. Comparison is exact, so research → Research still counts as a rename into a collision and is rejected. Error shape is unchanged (OrchestrationError('validation', …), identical to the create path). Creating a new skill with a built-in name still 400s.

Layer choice: the shared updateSkill orchestration primitive, not updateSkillUseCase. The two surfaces diverge today — v2 PATCH /api/v2/skills/[id] and Copilot go through the use case, but internal POST /api/skills calls performUpdateSkill directly. updateSkill is the single chokepoint both reach and the layer where the canonical row is loaded; placing it in the use case would have left the internal path broken.

Side effect: a non-editor attempting a colliding rename now gets 403 rather than 400 — correct, since authorization should precede business validation.

Pre-existing issue, not fixed here

POST /api/skills bypassing updateSkillUseCase skips that use case's authorization and semantic audit — an Application Operation Boundary violation worth its own ticket. This fix is placed so the two surfaces cannot disagree on this rule regardless.

Test 1 (unchanged colliding name succeeds) goes red on revert. Tests 2 and 3 are regression guards that pass with and without the fix — proven capable of failing by neutering builtinNameCollision. type-check · biome · 44 tests · check:api-validation — all pass.