feat: support Cursor SDK model params in proof#178
Conversation
Co-authored-by: Tony <tonyketcham@users.noreply.github.com>
Co-authored-by: Tony <tonyketcham@users.noreply.github.com>
- Add @deprecated JSDoc to createModelResolver (silently discards params) - Render modelSelection.params in canvas template (was serialized but unused) - Fix variant tiebreaker: prefer catalog default on score ties - De-duplicate defaultVariant() call in chooseMatchingVariant Change-Id: Ic8dfe2ddc37948affb1b6849428f0a9439daa170
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Found 2 medium-risk issues in the new model-selection support:
parseDAG()/validateModelMap()now canonicalize string model overrides into{ id }objects, which changes the observable return shape of the exported parsing helpers for string-only inputs.- Param validation assumes
Cursor.models.list()always populatesparameters, but the SDK marks that field optional, so models that expose onlyvariantswould reject otherwise valid param selections.
Sent by Cursor Automation: Flatbread PR Review
| throw new Error(`${label}.${key} must be a non-empty string.`); | ||
| } | ||
| models[key as Complexity] = value.trim(); | ||
| models[key as Complexity] = validateModelSelection( |
There was a problem hiding this comment.
validateModelMap() is part of the public parsing surface, and this assignment changes its runtime output shape for every string-only override. Before this PR, parseDAG({ models: { LOW: "composer-2" } }) produced dag.models.LOW === "composer-2"; after this change the same input becomes { id: "composer-2" }. That is an observable API break for JS callers and any tooling that round-trips parsed DAGs. Since the new resolver path can normalize later, I think we should preserve raw strings here and defer canonicalization until resolution time.
| label: string | ||
| ): void { | ||
| const definitions = new Map( | ||
| (catalogItem.parameters ?? []).map((param) => [param.id, param]) |
There was a problem hiding this comment.
This assumes Cursor.models.list() always includes parameters, but the SDK type marks parameters and variants as independently optional. If a model publishes only variants, every requested param will now fail with does not support param ... even though the variant list itself contains valid params. Can we infer the allowed ids/values from variants when parameters is absent, or only run this strict check when explicit parameter definitions are present?
2 participants
Summary of changes
Adds SDK-style model selections to Proof DAG/model-file config so complexity mappings can specify
{ id, params }, validates those selections againstCursor.models.list()at run time, and expands partial param selections to valid preset variants before creating Cursor SDK agents.Closes #
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Does this introduce any non-backwards compatible changes?
Does this include any user config changes?