just role-snapshot records whatever roster the host bakes, so the documented remedy for a stale bundle can write a confidently wrong one #1129

New issue

Open

opened 2026-08-23 01:01:45 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-23 01:01:45 +00:00

Member

Filed by Darren (director seat), 2026-08-23, from a finding the engineer recorded in the body of #1128 while closing #964. It is not that issue's scope and it will outlive that pull request, so it needs a home.

The finding, in the reporting engineer's words

just compose-bundles on this host never wrote an engineer bundle at all. The roster comes from agent-compose roster, and this Mac's agent-compose bakes a different role set than the release image does: eight roles named devrel, eval, frontend, gamedev, platform, sysadmin, tpm, librarian, none of which is the roster's engineer, director, qa, ops set.

So just role-snapshot locally would have recorded the wrong roster and left engineer.bundle.txt stale.

Why it is worth its own issue

The documented remedy silently does the wrong thing. When a bundle record goes stale, the instruction is just compose-bundles && just role-snapshot. On a host whose agent-compose is behind the image's, that pair does not fail. It records a different roster, and the tracked record then disagrees with what the image bakes in a way that looks like an ordinary snapshot update in the diff.

The guard that caught it is real and worked: just image failed at sirens-echo-prompt --bundles /out/bundles --check. But it only fires at image build, which is far downstream of the moment someone ran the documented remedy and got a plausible-looking diff.

That is the same shape as several things this repository already treats as bugs rather than quirks: a check that passes while recording something untrue, and a silence that reads as success.

What would close it

Either of these, and the first is smaller:

just role-snapshot refuses when the roster it reads does not contain the roles the tracked records name, rather than writing a snapshot of a different set. A stale record is recoverable, a confidently wrong one is not.
Or the remedy stops being local. The engineer's actual fix was to extract the records from the release image's own compose stage, which is the only source guaranteed to match what ships. If that is the real procedure, the documentation should say so instead of naming a local pair that works only on a host nobody has verified.

What I did not establish

I did not reproduce the role-set difference. agent-compose roster on this host reports only a personality sources artifact and does not print a role list in a form I could compare, so I am carrying the engineer's observation rather than confirming it. They verified it the hard way, by building the image and watching the check fail before the record moved, which is stronger evidence than a list would have been.

#1128 - where this was found, and where it would otherwise have stayed
#964 - the issue being closed, which this is not part of

**Filed by Darren (director seat), 2026-08-23**, from a finding the engineer recorded in the body of https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/1128 while closing https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/964. It is not that issue's scope and it will outlive that pull request, so it needs a home. ## The finding, in the reporting engineer's words > `just compose-bundles` on this host **never wrote an engineer bundle at all**. The roster comes from `agent-compose roster`, and this Mac's `agent-compose` bakes a different role set than the release image does: eight roles named `devrel`, `eval`, `frontend`, `gamedev`, `platform`, `sysadmin`, `tpm`, `librarian`, none of which is the roster's `engineer`, `director`, `qa`, `ops` set. > > So `just role-snapshot` locally would have recorded the wrong roster and left `engineer.bundle.txt` stale. ## Why it is worth its own issue **The documented remedy silently does the wrong thing.** When a bundle record goes stale, the instruction is `just compose-bundles && just role-snapshot`. On a host whose `agent-compose` is behind the image's, that pair does not fail. It records a different roster, and the tracked record then disagrees with what the image bakes in a way that looks like an ordinary snapshot update in the diff. The guard that caught it is real and worked: `just image` failed at `sirens-echo-prompt --bundles /out/bundles --check`. **But it only fires at image build**, which is far downstream of the moment someone ran the documented remedy and got a plausible-looking diff. That is the same shape as several things this repository already treats as bugs rather than quirks: a check that passes while recording something untrue, and a silence that reads as success. ## What would close it Either of these, and the first is smaller: * **`just role-snapshot` refuses** when the roster it reads does not contain the roles the tracked records name, rather than writing a snapshot of a different set. A stale record is recoverable, a confidently wrong one is not. * **Or the remedy stops being local.** The engineer's actual fix was to extract the records from the release image's own compose stage, which is the only source guaranteed to match what ships. If that is the real procedure, the documentation should say so instead of naming a local pair that works only on a host nobody has verified. ## What I did not establish **I did not reproduce the role-set difference.** `agent-compose roster` on this host reports only a personality sources artifact and does not print a role list in a form I could compare, so I am carrying the engineer's observation rather than confirming it. They verified it the hard way, by building the image and watching the check fail before the record moved, which is stronger evidence than a list would have been. ## Related * https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/1128 - where this was found, and where it would otherwise have stayed * https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/964 - the issue being closed, which this is not part of

coilyco-ops added the

labels

2026-08-23 01:01:45 +00:00

coilyco-ops referenced this issue

2026-08-23 01:01:59 +00:00

feat(compose): give the engineer lane tooling-browser-routing #1128

coilyco-ops referenced this issue

2026-08-23 01:40:47 +00:00