Repository navigation
Runtime tool-package pins resolve to a published version, never * (CL-7389) - #643
Merged
Merged
Conversation
Covers the new resolvePinnedVersion resolver (highest published version among a tenant's, or its ancestor's, corbits-tools registry tarballs; fails closed when the registry or package is absent) and withAgentToolPackagePin's rejection of a "*" version. Updates the existing create/capability-add route tests, which previously asserted the old hardcoded "*" pin, to resolve real versions through their fake asset services instead.
…-7389) The three runtime sites that pinned a tool package by name only (create_agent's toolPackagePins, guided capability-add on both the tenant-session and workflow-run capability routes) hardcoded version "*" — a new tarball landing in the tenant's corbits-tools registry would silently change what an already-deployed specialist runs, with no record of the change. Adds resolvePinnedVersion, which resolves a bare package name against the tenant's (possibly inherited) corbits-tools package-registry asset and picks the highest published version among its tarballs, throwing the same CapabilityOutOfInventoryError the guided-capability-add inventory check already throws when the registry or package is absent — every caller's existing 4xx mapping covers it with no new wiring. withAgentToolPackagePin now rejects a "*" version outright as a second line of defense. A plain redeploy never re-resolves an existing pin's version; only a newly added or newly created pin does.
Documents resolvePinnedVersion and why every runtime pin this package writes resolves to a concrete version rather than "*".
Covers the confirmed critique findings on the versioned-pins work: a PUT that only edits name/prompt must never re-touch tool-package pins even after a newer tarball lands; re-adding an already-pinned package via guided capability-add must keep its stored version rather than silently bumping; NonWildcardToolPackagePin must reject any non-exact version (latest, ^1, ~1.2, >=1.0.0, 1.x, empty), not just "*"; resolvePinnedVersion must prefer the highest stable version over a higher-sorting prerelease; and a multi-pin create must share one registry lookup and tarball listing across all of its pins instead of doing one round trip per pin.
- resolvePinnedVersion now prefers the highest STABLE published version;
a prerelease only wins when the registry carries no stable version for
the package at all.
- NonWildcardToolPackagePin now requires an exact semver.valid version,
rejecting any range or tag ("*", "latest", "^1", "~1.2", ">=1.0.0",
"1.x", empty) instead of just the literal "*".
- Guided capability-add re-adding a package already pinned on the
definition keeps its existing stored version and skips registry
resolution entirely, so a newer tarball landing in the registry never
silently bumps an existing pin; the commit message no longer claims an
add in that case. Resolution still happens for a genuinely new pin.
- createAgentDefinitionCore and guided capability-add now share one
createPinnedVersionResolver per call, so a multi-pin create pays for
one registry-asset lookup and one tarball listing total, not one per
pin.
Documents the exact-version narrowing, the stable-over-prerelease preference, the shared per-call registry resolver, and that both a plain redeploy and a re-add of an already-pinned package leave the stored pin version untouched.
TheGreatAxios
force-pushed
the
cl-7389-versioned-pins
branch
from
September 5, 2026 01:26
4b4a860 to
ac40f16
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes CL-7389
Runtime tool-package pins resolve to a concrete, published version —
never
*or any other range/tag — so a later tarball landing in atenant's registry never silently changes what an already-deployed
specialist runs.
Critique follow-ups in this update
re-touches tool-package pins, even after a newer tarball lands in the
registry (zero registry listing calls during that PUT).
definition now keeps its existing stored version instead of silently
bumping to the registry's newest tarball — resolution only happens for
a genuinely new pin. An explicit re-pin/bump is a separate, explicit
action this does not add.
NonWildcardToolPackagePinnow requires an exactsemver.validversion, rejecting
*,latest,^1,~1.2,>=1.0.0,1.x, andempty — not just the literal
*.resolvePinnedVersionnow prefers the highest stable publishedversion; a prerelease only wins when the registry carries no stable
version for the package at all.
create_agent/POST /agent-definitionscall now shares onecreatePinnedVersionResolveracross all of its pins, so a five-pincreate costs one registry-asset lookup and one tarball listing total,
not one per pin.
packages/agent-directory/README.mddocuments the redeploy and re-addsemantics.