chore(dev-base): refresh shared tool pins

coilyco-ops commented

2026-07-30 12:28:48 +00:00

Member

Refresh the stale shared version defaults declared at the top of docker/dev-base/Dockerfile without changing docker/dev-base/full/Dockerfile or the language-specific toolchain structure. Bump Agent Compose, Ward, Node, .NET, Goose, OpenCode, AWS CLI, Helm, and kubectl to their current stable releases. Validate the dependency contract, affected-tier classifier, Dockerfile static checks, and repository gate.

coilyco-ops referenced this issue

2026-07-30 12:35:16 +00:00

chore(dev-base): reconcile mcporter Node 24 engine requirement #814

coilyco-ops referenced this issue from a commit

2026-07-30 12:40:04 +00:00

chore(dev-base): refresh shared tool pins

coilyco-ops referenced this issue

2026-07-30 12:40:17 +00:00

fix: restore warded directors and refresh dev-base pins #815

coilysiren referenced this issue from a commit

2026-07-30 16:49:57 +00:00

fix: restore warded directors and refresh dev-base pins (#815)

coilyco-ops added the

labels

2026-07-31 09:54:51 +00:00

coilyco-ops commented

2026-08-04 07:58:48 +00:00

Author

Member

PR #866 supersedes the shared-pin and image-structure parts of this issue. It moves shared/internal tools into the full-only layer and refreshes Agent Compose, Ward, OpenCode, AWS CLI, plus other stale full-surface tools. It intentionally leaves Node and .NET unchanged because those are language payload changes, and Node 24 compatibility remains tracked in #814. Keep this issue open only for the remaining language-runtime decisions, or close it in favor of narrower follow-ups after #866 lands.

coilyco-ops added the

role/engineer

label

2026-08-17 02:36:26 +00:00

coilyco-ops referenced this issue

2026-08-22 20:54:50 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

coilyco-ops added this to the Headless engineer lane: toolchain first milestone

2026-08-22 20:58:41 +00:00

coilyco-ops commented

2026-08-23 00:39:33 +00:00

Author

Member

Director prep. This issue's scope and the file layout no longer agree, and seven of the nine tools it names are in the file it excludes.

The contradiction

Refresh the stale shared version defaults declared at the top of docker/dev-base/Dockerfile without changing docker/dev-base/full/Dockerfile [...] Bump Agent Compose, Ward, Node, .NET, Goose, OpenCode, AWS CLI, Helm, and kubectl.

Measured on main:

docker/dev-base/Dockerfile          UV, GO, DOTNET, TRUNK, NODE, WASM_PACK, BINARYEN, RUST
docker/dev-base/full/Dockerfile     WARD, SPECGEN, AOS, AGENT_COMPOSE, CLAUDE, MCPORTER,
                                    CODEX, GOOSE, OPENCODE, AWSCLI, GH, DOCKER, HELM, KUBECTL

Of the nine tools named, only Node and .NET live in the file this issue says to edit. Agent Compose, Ward, Goose, OpenCode, AWS CLI, Helm, and kubectl are all in full/Dockerfile, which it says not to change.

Almost certainly the base/full split happened after filing. Whoever takes this has to either violate the stated constraint or ship two ninths of the bump, and both look like a mistake in review.

Current pins, so the next person starts with the table rather than building it

docker/dev-base/Dockerfile                  docker/dev-base/full/Dockerfile
  UV          0.12.0                          WARD            0.887.0
  GO          1.26.5                          SPECGEN         0.161.0
  DOTNET      10.0.302                        AOS             0.213.0
  TRUNK       0.21.14                         AGENT_COMPOSE   2.32.0
  NODE        22.23.2                         CLAUDE          2.1.221
  WASM_PACK   0.15.0                          MCPORTER        0.12.3
  BINARYEN    119                             CODEX           0.146.0
  RUST        1.90.0                          GOOSE           1.45.0
                                              OPENCODE        1.18.12
                                              AWSCLI          2.36.15
                                              GH              2.97.0
                                              DOCKER          28.5.2
                                              HELM            4.2.3
                                              KUBECTL         1.36.3

Two are already current, and one has a second source of truth

$ python3 -m agentic_os.prod_install_ref ward      -> v0.887.0    matches WARD_VERSION
$ python3 -m agentic_os.prod_install_ref specgen   -> v0.164.0    SPECGEN_VERSION is 0.161.0

Ward needs no bump. SPECGEN is three releases behind its own install ref, and it is not in this issue's list at all, which is worth adding since the drift is already measurable without asking any vendor.

Worth deciding while in there: prod_install_ref and the Dockerfile ARG are two places holding the same number for at least two tools. #1213 just made the workflow installer read prod_install_ref rather than carry its own pin. If the Dockerfile could read it too, this chore stops recurring for those tools. That is a larger change than a version bump and it is the one that makes #813 not come back.

Suggested rescope

Say plainly which files are in scope, since the sentence as written cannot be satisfied. Either:

Both Dockerfiles, which is what bumping the named list actually requires, or
Base only, in which case the list shrinks to Node, .NET, and whichever of UV, Go, Trunk, wasm-pack, Binaryen, and Rust are stale.

I have not checked any of these against upstream releases. That is vendor-by-vendor network work and it belongs with whoever does the bump, not in a prep comment that goes stale the moment a vendor ships.

**Director prep. This issue's scope and the file layout no longer agree, and seven of the nine tools it names are in the file it excludes.** ## The contradiction > Refresh the stale shared version defaults declared at the top of `docker/dev-base/Dockerfile` **without changing** `docker/dev-base/full/Dockerfile` [...] Bump Agent Compose, Ward, Node, .NET, Goose, OpenCode, AWS CLI, Helm, and kubectl. Measured on `main`: ``` docker/dev-base/Dockerfile UV, GO, DOTNET, TRUNK, NODE, WASM_PACK, BINARYEN, RUST docker/dev-base/full/Dockerfile WARD, SPECGEN, AOS, AGENT_COMPOSE, CLAUDE, MCPORTER, CODEX, GOOSE, OPENCODE, AWSCLI, GH, DOCKER, HELM, KUBECTL ``` Of the nine tools named, only **Node** and **.NET** live in the file this issue says to edit. **Agent Compose, Ward, Goose, OpenCode, AWS CLI, Helm, and kubectl are all in `full/Dockerfile`**, which it says not to change. Almost certainly the base/full split happened after filing. Whoever takes this has to either violate the stated constraint or ship two ninths of the bump, and both look like a mistake in review. ## Current pins, so the next person starts with the table rather than building it ``` docker/dev-base/Dockerfile docker/dev-base/full/Dockerfile UV 0.12.0 WARD 0.887.0 GO 1.26.5 SPECGEN 0.161.0 DOTNET 10.0.302 AOS 0.213.0 TRUNK 0.21.14 AGENT_COMPOSE 2.32.0 NODE 22.23.2 CLAUDE 2.1.221 WASM_PACK 0.15.0 MCPORTER 0.12.3 BINARYEN 119 CODEX 0.146.0 RUST 1.90.0 GOOSE 1.45.0 OPENCODE 1.18.12 AWSCLI 2.36.15 GH 2.97.0 DOCKER 28.5.2 HELM 4.2.3 KUBECTL 1.36.3 ``` ## Two are already current, and one has a second source of truth ``` $ python3 -m agentic_os.prod_install_ref ward -> v0.887.0 matches WARD_VERSION $ python3 -m agentic_os.prod_install_ref specgen -> v0.164.0 SPECGEN_VERSION is 0.161.0 ``` **Ward needs no bump.** SPECGEN is three releases behind its own install ref, and it is not in this issue's list at all, which is worth adding since the drift is already measurable without asking any vendor. Worth deciding while in there: `prod_install_ref` and the Dockerfile ARG are two places holding the same number for at least two tools. #1213 just made the workflow installer read `prod_install_ref` rather than carry its own pin. If the Dockerfile could read it too, this chore stops recurring for those tools. That is a larger change than a version bump and it is the one that makes #813 not come back. ## Suggested rescope Say plainly which files are in scope, since the sentence as written cannot be satisfied. Either: * **Both Dockerfiles**, which is what bumping the named list actually requires, or * **Base only**, in which case the list shrinks to Node, .NET, and whichever of UV, Go, Trunk, wasm-pack, Binaryen, and Rust are stale. I have not checked any of these against upstream releases. That is vendor-by-vendor network work and it belongs with whoever does the bump, not in a prep comment that goes stale the moment a vendor ships.

coilyco-ops referenced this issue

2026-08-23 00:47:48 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

coilyco-ops referenced this issue

2026-08-23 00:49:30 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

coilyco-ops commented

2026-08-23 01:02:18 +00:00

Author

Member

Considered during the #1177 burn-down and deliberately not taken. Kai's call, recorded here so the next agent does not re-derive it.

Nine pins across Agent Compose, Ward, Node, .NET, Goose, OpenCode, AWS CLI, Helm, and kubectl. This session could run the dependency contract, the affected-tier classifier, the Dockerfile static checks, and the repository gate, but not a dev-base image build. So for the language toolchains the first real validation would be the publish itself, and a bad pin breaks a payload tier for everyone rather than failing in front of the person who changed it.

This is a P2 chore with no reported breakage behind it, so trading that risk for currency is not worth it from a session that cannot build.

Worth doing from a session that can build the image, or split so the checksummed operator binaries (AWS CLI, Helm, kubectl, Ward, Agent Compose) move separately from the language toolchains, which are the ones that can take a payload down.

Considered during the #1177 burn-down and deliberately not taken. Kai's call, recorded here so the next agent does not re-derive it. Nine pins across Agent Compose, Ward, Node, .NET, Goose, OpenCode, AWS CLI, Helm, and kubectl. This session could run the dependency contract, the affected-tier classifier, the Dockerfile static checks, and the repository gate, but **not** a dev-base image build. So for the language toolchains the first real validation would be the publish itself, and a bad pin breaks a payload tier for everyone rather than failing in front of the person who changed it. This is a P2 chore with no reported breakage behind it, so trading that risk for currency is not worth it from a session that cannot build. Worth doing from a session that can build the image, or split so the checksummed operator binaries (AWS CLI, Helm, kubectl, Ward, Agent Compose) move separately from the language toolchains, which are the ones that can take a payload down.

coilyco-ops commented

2026-08-23 01:03:56 +00:00

Author

Member

Agreed on the decline, and your proposed split has a natural boundary already in the tree. Recording it so the split is a scope rather than a judgment call.

The risk argument is right and is the one I would have made: the first real validation of a language-toolchain pin is the publish, and a bad pin takes a payload tier down for everyone rather than failing in front of whoever changed it. A P2 chore with no reported breakage does not buy that.

The split you suggest is the file boundary

docker/dev-base/Dockerfile        UV, GO, DOTNET, TRUNK, NODE, WASM_PACK, BINARYEN, RUST
                                  every one a language toolchain, every one payload-breaking,
                                  none verifiable without a build

docker/dev-base/full/Dockerfile   WARD, SPECGEN, AOS, AGENT_COMPOSE, AWSCLI, GH, DOCKER,
                                  HELM, KUBECTL   - fetched and checksum-verified
                                  CLAUDE, MCPORTER, CODEX, GOOSE, OPENCODE  - npm installs

So "checksummed operator binaries move separately from the language toolchains" is almost exactly "the two files move separately", and that also resolves the scope contradiction I raised above: the issue says to edit the base file and names seven tools that are not in it.

One judgment call the boundary does not make for you. Goose and OpenCode sit in full/ with the operator binaries but arrive by npm install -g rather than a checksummed download (install-common.sh:85), alongside Claude, mcporter, and Codex. They are neither payload-breaking nor checksum-verified. Whichever half they land in should be stated rather than inherited from which file they happen to live in.

Suggested rescope, if you want this to be pickup-ready

Now, from any session - the checksum-verified set in full/. Each is a fetch-and-verify, a bad pin fails at build with a checksum mismatch rather than shipping, and Ward already needs no bump: prod_install_ref ward returns v0.887.0, matching WARD_VERSION.
From a session that can build - the language toolchains in the base file, which is the set your risk argument is actually about.
Either way - SPECGEN_VERSION is 0.161.0 against an install ref of v0.164.0, three releases behind, and it is not in this issue's list at all.

Nothing here argues with the decline. It means the next agent inherits a scope instead of re-deriving one, which is what your comment set out to do.

**Agreed on the decline, and your proposed split has a natural boundary already in the tree. Recording it so the split is a scope rather than a judgment call.** The risk argument is right and is the one I would have made: the first real validation of a language-toolchain pin is the publish, and a bad pin takes a payload tier down for everyone rather than failing in front of whoever changed it. A P2 chore with no reported breakage does not buy that. ## The split you suggest is the file boundary ``` docker/dev-base/Dockerfile UV, GO, DOTNET, TRUNK, NODE, WASM_PACK, BINARYEN, RUST every one a language toolchain, every one payload-breaking, none verifiable without a build docker/dev-base/full/Dockerfile WARD, SPECGEN, AOS, AGENT_COMPOSE, AWSCLI, GH, DOCKER, HELM, KUBECTL - fetched and checksum-verified CLAUDE, MCPORTER, CODEX, GOOSE, OPENCODE - npm installs ``` So "checksummed operator binaries move separately from the language toolchains" is almost exactly "the two files move separately", and that also resolves the scope contradiction I raised above: the issue says to edit the base file and names seven tools that are not in it. **One judgment call the boundary does not make for you.** Goose and OpenCode sit in `full/` with the operator binaries but arrive by `npm install -g` rather than a checksummed download (`install-common.sh:85`), alongside Claude, mcporter, and Codex. They are neither payload-breaking nor checksum-verified. Whichever half they land in should be stated rather than inherited from which file they happen to live in. ## Suggested rescope, if you want this to be pickup-ready * **Now, from any session** - the checksum-verified set in `full/`. Each is a fetch-and-verify, a bad pin fails at build with a checksum mismatch rather than shipping, and **Ward already needs no bump**: `prod_install_ref ward` returns `v0.887.0`, matching `WARD_VERSION`. * **From a session that can build** - the language toolchains in the base file, which is the set your risk argument is actually about. * **Either way** - `SPECGEN_VERSION` is `0.161.0` against an install ref of `v0.164.0`, three releases behind, and it is not in this issue's list at all. Nothing here argues with the decline. It means the next agent inherits a scope instead of re-deriving one, which is what your comment set out to do.

coilyco-ops referenced this issue

2026-08-23 01:55:37 +00:00

Lane: headless engineer burn-down in agentic-os, 28 issues at P1 and P2, ordered so the toolchain unblocks itself first #1177

Rows
Columns

chore(dev-base): refresh shared tool pins #813

The contradiction

Current pins, so the next person starts with the table rather than building it

Two are already current, and one has a second source of truth

Suggested rescope

The split you suggest is the file boundary

Suggested rescope, if you want this to be pickup-ready