sprint(versioned-agent-images): add side-effects, follow-up sprints, updated recommendation #15

Merged

disinto-admin merged 1 commit from architect/versioned-agent-images-followups into architect/versioned-agent-images

2026-04-11 10:20:08 +00:00

dev-bot commented

2026-04-11 10:09:58 +00:00

Collaborator

What this PR does

Enriches the existing sprint plan in sprints/versioned-agent-images.md with material discovered while applying the manual rollout for #641-#646, #669, and the related cleanup work on disinto-dev-box.

Additions

Side effects section — flags that this sprint indirectly closes #665 (edge cold-start race) by removing the runtime clone from edge, so a parallel #665 fix would be wasted work.
Four follow-up sprints under "What this sprint does not yet enable":
- A: disinto upgrade <version> subcommand for atomic client-side upgrades (the missing operator-facing entry point — without it, "upgrade harb to v0.3.0" stays a multi-step human operation)
- B: unify DISINTO_VERSION and AGENTS_IMAGE so there is a single version concept across image tag and in-container source
- C: migration framework for per-version breaking changes (CLAUDE_CONFIG_DIR migration, credential-helper cleanup, future schema changes)
- D: bootstrap-from-broken-state runbook for existing drifted client boxes (harb-dev-box specifically — currently at v0.2.0, months behind main)
Updated recommendation that sequences A and D as parallelizable, B as small cleanup depending on this sprint, C as deferable until first real migration. Plus an explicit "do not file separate forge issues for the follow-ups yet" note to keep the backlog clean while the sprint shape evolves.

What this PR deliberately does not do

Does not change the original sprint scope (4 files, ~80% gluecode, GHCR over Docker Hub). That recommendation stands.
Does not file forge issues for the follow-ups. They live in this document until the architect (or operator) is ready to commit to a sequence.
Does not modify any code. Doc-only PR; the actual implementation work is the architect-and-dev-bot collaboration that follows from this plan.

Why PR-into-the-architect-branch instead of into main

The architect branch is the working area for this sprint. Stacking my additions on top via PR keeps the architect agent (and operator review) in the loop without replacing or competing with the existing work. After review and any iteration, the architect branch can be merged into main as a single coherent sprint plan.

Context

Discovered while doing the disinto-dev-box rollout for #641-#646 and #669 today (2026-04-11). The architect already had the image-versioning piece mapped out; this PR adds the surrounding pieces that came up during the manual rollout — specifically, the gap between "we have versioned images" and "an operator on harb can run one command to upgrade cleanly".

## What this PR does Enriches the existing sprint plan in `sprints/versioned-agent-images.md` with material discovered while applying the manual rollout for #641-#646, #669, and the related cleanup work on disinto-dev-box. ## Additions 1. **Side effects section** — flags that this sprint indirectly closes #665 (edge cold-start race) by removing the runtime clone from edge, so a parallel #665 fix would be wasted work. 2. **Four follow-up sprints** under "What this sprint does not yet enable": - **A**: `disinto upgrade <version>` subcommand for atomic client-side upgrades (the missing operator-facing entry point — without it, "upgrade harb to v0.3.0" stays a multi-step human operation) - **B**: unify `DISINTO_VERSION` and `AGENTS_IMAGE` so there is a single version concept across image tag and in-container source - **C**: migration framework for per-version breaking changes (CLAUDE_CONFIG_DIR migration, credential-helper cleanup, future schema changes) - **D**: bootstrap-from-broken-state runbook for existing drifted client boxes (harb-dev-box specifically — currently at v0.2.0, months behind main) 3. **Updated recommendation** that sequences A and D as parallelizable, B as small cleanup depending on this sprint, C as deferable until first real migration. Plus an explicit "do not file separate forge issues for the follow-ups yet" note to keep the backlog clean while the sprint shape evolves. ## What this PR deliberately does not do - **Does not change the original sprint scope** (4 files, ~80% gluecode, GHCR over Docker Hub). That recommendation stands. - **Does not file forge issues for the follow-ups**. They live in this document until the architect (or operator) is ready to commit to a sequence. - **Does not modify any code**. Doc-only PR; the actual implementation work is the architect-and-dev-bot collaboration that follows from this plan. ## Why PR-into-the-architect-branch instead of into main The architect branch is the working area for this sprint. Stacking my additions on top via PR keeps the architect agent (and operator review) in the loop without replacing or competing with the existing work. After review and any iteration, the architect branch can be merged into main as a single coherent sprint plan. ## Context Discovered while doing the disinto-dev-box rollout for #641-#646 and #669 today (2026-04-11). The architect already had the image-versioning piece mapped out; this PR adds the surrounding pieces that came up during the manual rollout — specifically, the gap between "we have versioned images" and "an operator on harb can run one command to upgrade cleanly".

dev-bot added 1 commit 2026-04-11 10:09:59 +00:00

sprint(versioned-agent-images): add side-effects, four follow-up sprints, updated recommendation 3a172bcc86

Enriches the architect's existing sprint plan with:

1. Side effects: this sprint indirectly closes #665 (edge cold-start race) by
   removing the runtime clone — flagging so a parallel #665 fix isn't applied.

2. Four follow-up sprints that complete the client-box upgrade story:
   - A: 'disinto upgrade <version>' subcommand for atomic client-side upgrades
   - B: unify DISINTO_VERSION and AGENTS_IMAGE into one version concept
   - C: migration framework for breaking changes (per-version migration files)
   - D: bootstrap-from-broken-state runbook for existing drifted boxes (harb)

3. Updated recommendation that sequences the follow-ups against this sprint
   and notes #665 should not be fixed in parallel.

The original sprint scope (4 files, ~80% gluecode, GHCR) is unchanged and
remains tightly scoped. The follow-ups are deliberately kept inside this
document rather than filed as separate forge issues until the sprint plan is
ready to be broken into sub-issues by the architect.