Summary
bun run mship-tools:check fails on staging today, independent of any open PR. Regenerating the copilot tool catalog strips maxLength: 4096 and maxItems: 100 from the VFS cp / mkdir / mv / rm schemas, so the checked-in files carry bounds the generator cannot reproduce.
$ bun run mship-tools:check
error: Generated tool catalog is stale. Run: bun run mship-tools:generate
Affected entries in apps/sim/lib/copilot/generated/tool-catalog-v1.ts and tool-schemas-v1.ts:
| Tool |
Property |
Constraint lost on regenerate |
Cp, Mv |
destination |
maxLength: 4096 |
Cp, Mv |
sources |
maxItems: 100, items.maxLength: 4096 |
Mkdir, Rm |
paths |
maxItems: 100, items.maxLength: 4096 |
Root cause
The constraints were hand-edited into the generated files and never added to the generator's actual input.
scripts/sync-tool-catalog.ts:8 reads its source of truth from a sibling repository:
const DEFAULT_CATALOG_PATH = resolve(ROOT, '../copilot/copilot/contracts/tool-catalog-v1.json')
That contract contains zero occurrences of maxItems on any branch of the copilot repo (main, master, staging all check out at 0). The bounds exist only in this repo's generated output, which is stamped:
// AUTO-GENERATED FILE. DO NOT EDIT.
// Generated from copilot/contracts/tool-catalog-v1.json
They were introduced by #5273 (improvement(external-endpoints): v2 versions with clean signatures), which touched only the two generated files:
$ git log -S "maxItems: 100" --oneline -- apps/sim/lib/copilot/generated/tool-catalog-v1.ts
263e3ca67e improvement(external-endpoints): v2 versions with clean signatures ... (#5273)
$ git show 263e3ca67e --stat -- apps/sim/lib/copilot/generated/
apps/sim/lib/copilot/generated/tool-catalog-v1.ts | 14 ++++++++++----
apps/sim/lib/copilot/generated/tool-schemas-v1.ts | 10 ++++++++++
So this is not a generator defect — the generator is faithfully reproducing its input. The bounds are a good change that was applied to the wrong artifact, leaving them unreproducible and permanently divergent.
Why it has gone unnoticed
mship-tools:check is not wired into CI or check:audits:
$ grep -rn "mship-tools:check" .github/ scripts/run-audits.ts
(no matches)
check:audits runs 27 audits and passes; this is not one of them. Nothing fails when the catalog drifts.
Suggested fix
- Add the
maxLength / maxItems bounds to copilot/contracts/tool-catalog-v1.json in the copilot repo, so mship-tools:generate emits them.
- Regenerate here and confirm the diff is empty.
- Decide whether
mship-tools:check should join check:audits. It reads from a sibling repo that is not present in CI, which is likely why it was left out — if so, the check may only be meaningful locally, and that is worth stating explicitly so the next person does not "fix" the drift by regenerating and silently dropping the bounds.
⚠️ Until (1) lands, do not run bun run mship-tools:generate to resolve the failing check — it removes the bounds. The checked-in file is the better of the two.
Found during the post-merge audit in #6751; unrelated to that PR and deliberately left untouched there.
Summary
bun run mship-tools:checkfails onstagingtoday, independent of any open PR. Regenerating the copilot tool catalog stripsmaxLength: 4096andmaxItems: 100from the VFScp/mkdir/mv/rmschemas, so the checked-in files carry bounds the generator cannot reproduce.Affected entries in
apps/sim/lib/copilot/generated/tool-catalog-v1.tsandtool-schemas-v1.ts:Cp,MvdestinationmaxLength: 4096Cp,MvsourcesmaxItems: 100,items.maxLength: 4096Mkdir,RmpathsmaxItems: 100,items.maxLength: 4096Root cause
The constraints were hand-edited into the generated files and never added to the generator's actual input.
scripts/sync-tool-catalog.ts:8reads its source of truth from a sibling repository:That contract contains zero occurrences of
maxItemson any branch of the copilot repo (main,master,stagingall check out at 0). The bounds exist only in this repo's generated output, which is stamped:They were introduced by #5273 (
improvement(external-endpoints): v2 versions with clean signatures), which touched only the two generated files:So this is not a generator defect — the generator is faithfully reproducing its input. The bounds are a good change that was applied to the wrong artifact, leaving them unreproducible and permanently divergent.
Why it has gone unnoticed
mship-tools:checkis not wired into CI orcheck:audits:check:auditsruns 27 audits and passes; this is not one of them. Nothing fails when the catalog drifts.Suggested fix
maxLength/maxItemsbounds tocopilot/contracts/tool-catalog-v1.jsonin the copilot repo, somship-tools:generateemits them.mship-tools:checkshould joincheck:audits. It reads from a sibling repo that is not present in CI, which is likely why it was left out — if so, the check may only be meaningful locally, and that is worth stating explicitly so the next person does not "fix" the drift by regenerating and silently dropping the bounds.bun run mship-tools:generateto resolve the failing check — it removes the bounds. The checked-in file is the better of the two.Found during the post-merge audit in #6751; unrelated to that PR and deliberately left untouched there.