Repository navigation
INTR-725 Remove tool package pins and the pinned tool package - #257
Merged
FarinM merged 15 commits intoNov 5, 2026
Merged
Conversation
Production deploys a workflow from its source, so nothing reads a folded definition's launch body or builds one any more. The reader, the test-only builder behind it and the single-step assembly they shared had no caller outside their own tests.
A pin gives a step no tools: a step's tools come only from its agent's evaluated factories. The field only carried dead data through agent definitions, the inert projection and the launch spec, so drop it and the column that stored it. A definition that still sets the field now projects to a different wire hash, so the probe cache version moves to stop a cached approval outliving it.
Deploy and probe both emptied a closure's top-level list so the loader would import nothing, and deploy also ran an apply protocol whose retention and failure bookkeeping it never used. Calling the eval-free layout directly says what both paths want, and the production tarball fetcher it needs stands alone now.
Nothing in production has called it since a step's tools started coming only from its agent's evaluated factories. The apply protocol beneath it, with its deploy-id retention and its active-deploy-id commit, only served it, so the two go together, along with the failure categories only they raised.
Both production paths lay a closure out without importing it, so importing a package's tool entry, prefixing its tool names and reconciling its credential declarations could only be reached from tests. A step's tools come from its agent's evaluated factories, bare-named. The content-identity helper only built that import's URL, so it goes too.
Nothing reads a package's interchange.credentials. A tool declares its credentials through defineTool, so the field would let an author declare handles nothing checks.
Nothing in this package loads tools any more, so its loader naming described code that is gone.
The evict contract says a poisoned extraction cannot be reused, but it relied on the tarball being gone. An extraction that finds the tree on disk never reads the tarball, so a new caller got the poisoned tree once the bytes were put back, even while an older reader kept it from being removed. With a reader on the tree it can neither be removed nor reused, so the extraction fails loudly and the deploy can retry. Waiting would not work, since the caller's own pin holds a reference to the entry. With only pins on it nothing is walking the tree, so the extraction removes it and unpacks the re-fetched bytes. A cap sweep's pending entry stays reusable because its tree is good.
A step's tools are its agent's evaluated factories, and a credential consumer is one factory's id. Nothing materializes them and no package name is involved, so the old names sent readers looking for code that is gone. Real package names elsewhere keep their name.
No caller reached a second registry: every deploy path builds a map holding one source, and the Hub's scope routing setting was never read. That setting read as if it kept @intX packages off the default registry, which it did not, so it goes along with the map and default name that only served it.
Errors carried the failing package in a field nothing reads, and some messages left it out, so a failed deploy named only the workflow. The name now goes in the message and the field is gone.
Only that package raises or reads them, and the runtime validator on @intx/types was called only by its own test. A plain union next to the error says the same thing. The new name drops "deploy apply", since probes raise these too.
A deployment keeps one closure and callers only need its package directory back, so a random directory per apply separates nothing and its path has no reader. The apply now clears that directory itself, so callers no longer have to and nothing an earlier attempt left can mix into the layout.
Nothing outside tests read them, and they only echoed the platform filter, so a test asserting on them could pass with nothing on disk. The tests now check the store itself.
These tarballs existed so an agent could pin a tool package. With pins gone nothing reads them: a workflow imports its tools and bundles or depends on them. The seed and the dev script stop creating and filling the asset, and the packer and publish scripts go with them. Uploading your own tarballs to a package-registry asset still works.
FarinM
force-pushed
the
intr-725-remove-tool-package-pins-and-the-pinned-tool-package
branch
from
November 5, 2026 22:07
d8b831a to
89a1b92
Compare
FarinM
deleted the
intr-725-remove-tool-package-pins-and-the-pinned-tool-package
branch
November 5, 2026 23:19
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.
Summary
A step's tools come only from its agent's evaluated factories, so a tool package pin gave a step nothing. This removes the pins, the materializer that applied them, the tool loader's import path, and the built-in tarball publishing that only existed to serve them.
The Hub still freezes a workflow's closure, and the sidecar still lays it out without importing any of it.
What changes
toolPackagePinsis gone from definitions, the session service and the launch spec. Migration0119drops its column.materializeToolPackages,applyAtomicandcreateToolLoaderare gone. Deploy and probe callmaterializeClosuredirectly.createClosureResolvernow takes one{ source }.<instanceDir>/packages/and clears it itself.extractTarballno longer hands out a poisoned extraction once the bytes are put back.maketargets, the seed step andbin/dev's publish step are gone.package-registryassets, tarball deploys and the@intx/tools-*packages stay.ToolLoaderErroris nowClosureMaterializationError,StepToolMaterializationis nowStepToolRuntime, and the loader modules are renamed.Breaking changes
toolPackagePinsgets a new wire hash, so it needs a new approval and a redeploy. Nothing in this repo sets it.@intx/tool-packaging,@intx/types,@intx/workflow-deployand@intx/hub-sessions.make builtins,make publish-builtins,--no-publish-builtinsand theHUB_ADMIN_*andHUB_TENANT_*settings are gone.Verification
make allexits 0 (10200, 255 and 1511 tests pass, 0 fail).