Skip to content

mship-tools:check is stale on staging: regenerating strips maxLength/maxItems from the VFS cp/mkdir/mv/rm schemas #6755

Description

@waleedlatif1

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

  1. Add the maxLength / maxItems bounds to copilot/contracts/tool-catalog-v1.json in the copilot repo, so mship-tools:generate emits them.
  2. Regenerate here and confirm the diff is empty.
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions