T-5CZO-version-bump-suggestions

State: planning/proposed · Impact: medium · Complexity: small

Goal

A plugin’s published manifest already records the closure hash it was built from, but nothing compares that hash against the vault’s current closure to say “this changed since you last published, and the version string didn’t move.” This task adds that comparison as a callout with a one-click ap-version bump.

Today

Location	Role today
solutions/agent-pants/crates/agent-adapt-core/src/manifest.rs#ManifestEntry	source_hash (over the closure), emitted_hash (over the written bytes) and published_at, recorded per emitted file at a destination root
solutions/agent-pants/crates/agent-adapt-core/src/status.rs#PublishState	The five-state comparison (NeverPublished/Current/Stale/Conflict/Unknown) already dry-runs a publish and reads the manifest per unit; nothing surfaces the plugin’s own ap-version alongside that answer
solutions/agent-pants/crates/agent-adapt-core/src/export.rs#plugin_version	Reads ap-version (via PluginOverrides.version) for the rendered pack manifest’s "version" field; defaults to 0.1.0 when absent
solutions/determined/experiences/agent-pants/app/utils/fieldSpec.ts#ap-version	The field’s spec entry; kinds: ['plugin'] only — a marketplace has no ap-version field of its own
solutions/determined/experiences/agent-pants/app/components/ApPublishPreviewPanel.vue	The dry-run preview a plugin note already shows; no version-aware callout
solutions/determined/experiences/agent-pants/app/components/ApBuildPanel.vue	The whole-vault build/check flow; no per-plugin version callout either

Proposed

When a plugin’s dry-run preview (or the build check) finds its members’ rendered closure differs from what the last-published manifest recorded, and the plugin’s ap-version frontmatter has not moved since that publish, a callout offers a one-click patch/minor/major bump that writes the new ap-version value to the note. The rule reads existing data only — ManifestEntry.source_hash for the closure comparison, plugin_version’s current ap-version reading for the “unchanged” half — no new hash is introduced.

Approach

1. Add a comparison, in or beside status.rs, for one plugin: gather the ManifestEntry rows the destination manifest holds for that plugin’s member files, and compare each against a fresh dry run’s projected source_hash. Open decision: whether this runs per member file (reusing status_of’s existing per-unit dry run and aggregating to “any member changed”) or needs a new plugin-level manifest entry — resolve by checking whether status_of’s current granularity already covers every member, not only the plugin’s own identity note.
2. The manifest does not record which ap-version was live at the last publish. Decide whether to add that field to ManifestEntry (a schema bump under SCHEMA_VERSION) or to derive “unchanged” some other way; record the choice made during implementation, since the template’s placeholder cannot stand in for it.
3. Expose the comparison’s verdict (members changed, version unchanged) over the same transport path ApPublishPreviewPanel.vue already reads.
4. Add the callout to ApPublishPreviewPanel.vue for a plugin note, and to ApBuildPanel.vue per plugin in the build report; each option applies a semver bump to ap-version and writes it back through the existing note-write path.
5. Add unit tests over the three cases (members changed + version unchanged → callout; members changed + version bumped → no callout; nothing changed → no callout) and a Playwright assertion that clicking a bump option writes the new ap-version.

Areas

Area	Note
solutions/agent-pants/crates/agent-adapt-core/src/status.rs	Add the members-changed / version-unchanged comparison
solutions/agent-pants/crates/agent-adapt-core/src/manifest.rs	Record the published ap-version per entry, if the comparison needs it (see Approach step 2)
solutions/determined/experiences/agent-pants/app/components/ApPublishPreviewPanel.vue	Version-bump callout for a plugin note
solutions/determined/experiences/agent-pants/app/components/ApBuildPanel.vue	Version-bump callout per stale plugin in the build report

Acceptance criteria

• AC-1: A plugin whose rendered members differ from the last-published manifest, with ap-version unchanged since that publish, shows a bump callout in the preview panel.
• AC-2: The build report shows the same callout per plugin that meets the rule.
• AC-3: Clicking patch, minor or major applies the matching semver bump to the note’s ap-version and the note re-reads with the new value.
• AC-4: A plugin whose ap-version already moved, or whose members are unchanged, shows no callout.
• AC-5: Unit tests cover the three cases in AC-1 and AC-4.

Out of scope

• The commit-time half of version suggestions (a git-aware bump prompt at commit) — T-L7YP-git-panel-commit-with-validation.
• Marketplace-level versioning; ap-version exists only on plugin notes per fieldSpec.ts.
• Any bump rule for skill, command or agent notes, which carry no ap-version field.

Dependencies

• none

Discovery context

From the user’s planning request of 2026-09-07: “publishing a changed container suggests a version bump.” The “Target tracking” section of solutions/agent-pants/docs/vault/design/publishing-model.md documents the closure/manifest model this rule builds on, and names the closed five-state set this task’s comparison must not invent a sixth answer alongside.

---

← Back to Tasks