[earakely-scale]

Why

agent-env bundle init writes a stored task into a folder you can run and edit. Registering that folder back should keep the task what it was. The folder's entities should go back to the ids they came from, and an untouched folder should write nothing. An edit should re-version only what it reaches, without losing the fields the import left out.

Stacked on #355 (bundle register), and it includes #353's commit (the import record v2), which this is the reader of. If you'd rather review one PR for the import side, close #353 and merge this after #355.

What it does

When the folder's provenance.json records an import from the configured store (its store fingerprint matches):

• Ids: each entity, image, task and eval takes the store id it was imported from. An imported task's outputs keep the names its file gives them, as the stored task did. Only ids register makes up are held to the registry id rule, so a source id like nightly/regression passes.

• Untouched folders write nothing: a write whose files are as the import wrote them keeps the version it was imported at, as long as everything it needs is kept at the versions they were imported at too. The ledger records that version, so later runs compare digests as usual. The files compared are:

  • a task's or eval's file;
  • an image's build context;
  • an env's or agent's toml, or the whole folder for an env type written from its folder;
  • every file of an artifact or skill.

  This compares against the import's file hashes, not the stored entity's digests, because import prunes contexts and pins their installs.

• Edits re-version only the edited write and what references it.

• Re-grafting: each imported task's steps get back the user-scoped fields the import left out, such as the agent, env vars, sandbox type and model. They come from the stored version, matched by step id and type, wherever the folder doesn't set them. A shared store's credential and loopback-URL checks skip these fields, since the store holds them already.

• A version someone else wrote since the folder was imported: an untouched entry still keeps the version it was imported at, and an edit writes the store's next version.

A folder imported from another store, or recorded by an older agent-env, registers as a new bundle with prefix ids, and the run says why.

Verification

Unit tests: tst/unit/bundle/register_imports_test.py, 8 tests, plus #353's import-record tests. They cover:

• an unedited import writes nothing, keeps every version, and records rows;
• an edit re-versions only the edited artifact and its task, and gives back the agent and env vars;
• a re-grafted field isn't refused as a credential on a shared store;
• an untouched entry keeps its imported version, and an edit writes past a version the store wrote since;
• an edited Dockerfile pushes a new image and rewrites its env;
• another store's import, and an older record, register as new bundles;
• an imported task's output keeps its name.

The full unit tier passes: 10,912 passed. One a2a staging timing test failed once under load (the run took 15 minutes instead of 2) and passes 3/3 alone; this PR doesn't touch it.

Open-source stores on an agent-environments-admin VM (Mongo, SeaweedFS S3, and a TLS registry with auth):

• echo-mcp registered, then imported from those stores with bundle init. Registering the folder back, as a dry run and for real, kept every entity at its source id and v1, writing nothing.
• A git clone of the imported folder on another path still registered as untouched.
• Editing the check re-versioned only the check and the task, v2 ran, score 1.0.
• An edited Dockerfile gave image, env and task new versions, and the new task ran, score 1.0.
• After another write took the check to v3, an edit was refused, then written as v4 with --adopt. (That refusal came from an ownership check since dropped; an edit now writes v4 directly.)
• No version was written twice, no pending rows were left, and no secret text appeared in any results.

Dev stage, from a laptop, since the dev cluster isn't reachable from the admin VM:

• The fd3965-e2e-echo-smoke task feat(bundle): agent-env bundle register writes a bundle into the configured stores #355's e2e registered was imported and registered back untouched, writing nothing.
• Its edit wrote only the check and the task, v2. The new version got back the sandbox_type: local the import had dropped, and ran on a Modal VM, score 1.0.
• The real task-rocket-prospecting-christina-rivera-v1 (v7) was imported with --include-scope user and dry-run registered. All 21 writes showed as unchanged at their source versions, and nothing was written. The writes are 9 MCP-server envs and their images, the multi-env, the claude-code-cli agent (v74) and its image, the universe artifact, and the task.
• A plain import of rocket fails in bundle init itself. Two of its stored build contexts hold several Dockerfiles and record none, which import already refuses without --include-scope user.

🤖 Generated with Claude Code

Confidence Score: 5/5

The changes appear safe to merge; no new blocking issue was found.

Summary

Lets imported folders register back under their source IDs and versions, while restoring task settings omitted during import.

• Imported folders record which store and files they came from.
• Registering an unchanged import keeps its source IDs and versions.
• Registration restores task fields that bundle init left out.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Imported folder] --> B[Read matching import record]
  B --> C[Restore omitted task settings]
  C --> D[Plan selected writes]
  D --> E[Match source IDs and compare files]
  E --> F{Files and dependencies unchanged?}
  F -->|Yes| G[Reuse imported version]
  F -->|No| H[Write next version]

Loading

_{Reviews (13) · Last reviewed commit: "refactor(bundle): gather what an import ..." · Reviewed by Greptile}

[earakely-scale]

Shelving this for now. Registering an imported folder back in place isn't needed yet. It's mostly a hub workflow, and that work hasn't started; it may handle editing stored tasks differently. The branch stays at e71ec77, with CI green, Greptile 5/5 and the dev round trip passed, in case we pick it up.