Skip to content

feat(bundle): record what an import wrote, so registering the folder back can tell an edit - #353

Closed
earakely-scale wants to merge 1 commit into
mainfrom
feat/bundle-import-record-v2
Closed

earakely-scale wants to merge 1 commit into
mainfrom
feat/bundle-import-record-v2

Conversation

@earakely-scale

Copy link
Copy Markdown
Collaborator

Why

agent-env bundle register (next PR) writes a bundle folder into the configured store. When the folder was made by bundle init, register needs four things:

  • to map each folder back to the store id and version it came from;
  • to know which store that was;
  • to tell an untouched folder from an edited one, so registering an unedited import writes nothing;
  • to read each task's source version, to copy back the user-scoped fields bundle init left out.

Today's provenance.json has the entity and image ids, but not the task map for evals, nothing about the store, and nothing about the files.

What changes

provenance.json gets "schema": 2 and also holds:

  • tasks: each task file with the store's task id and version, for task and eval imports alike. eval: the eval file with its id and version, or null.
  • store: a sha256 of the configured document store's config section. It tells one store from another (another machine's local store, another Mongo database) without naming where either is. The file still holds no store location.
  • files: each file the import wrote, except the README and provenance.json, keyed by its path in the folder, as its content hash. An executable file gets +x appended; only the execute bit is kept, so git's 644/755 and a different umask don't read as edits. Register compares the folder against this to tell an edit from the stored version. Contexts are pruned and lock-pinned on import, so the stored entity's own digests can't tell that.

The pinned store references move from store to pinned. Nothing reads the file yet. The ledger's file hash moves to _fs.file_sha256, so both use one helper.

Tests

  • Task import: the record holds the schema, the task map and a null eval, and every file written with the right hash. The +x case is checked with a context holding an executable run.sh. The text holds no file:// and no home path.
  • Eval import: each task file maps to its stored id and version, and the eval maps to its own.
  • Fingerprint: a different configured store gives a different fingerprint, and the same store the same one.
  • Bundle tier: tst/unit/bundle passes, 928.

Draft until the register PR's e2e confirms this record holds everything register reads.

🤖 Generated with Claude Code

…back can tell an edit

provenance.json, schema 2, now also holds:
- the task map, each task file with the store's task id and version, and the eval's;
- a fingerprint of the configured document store's section, which tells one store
  from another without naming where either is;
- each file the import wrote, as its content hash (+x when executable).

The pinned store references move from "store" to "pinned". Nothing reads the file yet.
The file hash the ledger computes moves to _fs, so both use one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@earakely-scale

Copy link
Copy Markdown
Collaborator Author

Shelved together with #356, which carried this commit. The import record v2 only serves registering an imported folder back, so it waits with it. The branch is kept.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant