Repository navigation
test(migration): gate the OpenCode agent-kit migration #480
Description
Intent
Create the regression gate and migration sequencing for moving acq run opencode . from core-agent/base-image assumptions to the ADR-0030 agent-kit/devenv model.
Scope
- Define the migration sequence for preserving current
acq run opencode .behavior while moving behavior into kits. - Gate each step with regression checks that preserve the stability contract from ADR-0030.
- Cover
--clone,ACQ_CLONE,ACQ_WORKSPACE,ACQ_EXTRA_KITSordering,acq exec/acq shelllogin-shell behavior,ACQ_IMAGE, and boot-timevolumes:. - Incorporate or reference the login.gov team-kit
scripts/verifypath where available. - Keep unresolved merge semantics and BYO-image contract decisions deferred until the increments that require them.
Acceptance Criteria
- There is a clear order for landing implementation PRs.
- Each migration step has a named verification command or live-check requirement.
acq run opencode .remains stable from the user's perspective until an explicitly documented migration point.- Regressions in the stability contract block acceptance of affected increments.
Orchestration Notes
Implementation should be done by an authoring sub-agent and reviewed by an independent adversarial review sub-agent. Review findings must be addressed before the increment is accepted.
Activity
wz-gsa commentedon Oct 1, 2026
AI-assisted (OpenCode). A real OpenCode agent kit now exists to gate against: GSA-TTS/agentic-coding-patterns#455 (depends on #454, a small schema prerequisite) — see the longer comment on #485 for what it does and doesn't yet cover.
Relevant to this issue's specific scope items:
ACQ_EXTRA_KITSordering — fix(msb): point the --clone scratch's origin at the source checkout's remote #455's kit is aninstall-phase, root, create-time-once command (notstartup), chosen deliberately to match the goose-server pattern (a single prebuilt binary tarball needs no toolchain, so there's no create-vs-startup safety tension the way there is for openchamber's native-module npm dependency — see the kit's ownspec.yamlheader). Worth confirming this phase choice composes correctly with whatever ordering guarantee this issue's migration-sequence needs forACQ_EXTRA_KITS.scripts/verify: an offline gate (schema/registry validation + a live negative test asserting a wrong SHA-256 pin genuinely refuses to install anything, not just a syntax check) plus an opt-inRUN_ACQ=1live end-to-end check (creates a real sandbox, asserts the pinned binary is on PATH and reports the pinned version). Could plug directly into whatever this issue's "named verification command" structure ends up being, or inform it.acq.backends/msb.sh's_acq_msb_install_agent/ACQ_MSB_OPENCODE_PKG), flagged on feat(opencode): move OpenCode install and entrypoint into an agent kit #485 as the remaining half of that issue's acceptance criteria. Likely belongs in whichever increment this issue's migration sequence puts last (keepingacq run opencode .stable until the kit path is proven, per this issue's own acceptance criteria), rather than landing it alongside the kit itself.scripts/verifyis independently runnable right now, before any sequencing/gating work lands, if that's useful for validating the kit in isolation ahead of wiring it into this issue's actual gate.Two independent adversarial reviews (security + QA/accuracy) already ran against #455 and every finding was fixed before it was opened, per this issue's own "Orchestration Notes" requirement.
mogul commentedon Oct 6, 2026
Implemented and shipped in v4.0.0 via #474 (with corrective #549). Covered by test/bats/140-opencode-migration-gate.bats. The PR's
Closes:footer did not auto-close this because the collapsed-stack squash merge dropped the closing keyword references; closing manually now that the work is onmainand released.