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

Merged
coilyco-ops merged 1 commit from aos/claude/browser-routing-964 into main 2026-08-23 01:04:24 +00:00
Member

The last step of #964, after coilyco-flight-deck/agentic-os#1216 published the skill into the public catalogue.

Why this had to be second

The header of agent/compose/roles.kdl states the rule this issue is about:

Patterns expand only against the composed catalogues the build passes, and both the Dockerfile and role-drift-check pass public agentic-os alone. An agentic-os-kai skill named here cannot resolve, and an unmatched pattern is a hard error rather than an empty selection.

So the selector could only be added once the catalogue carried the file.

The diff is two lines

One selector, and the tracked record moving from 56 skills to 57 with one line in the selection. Nothing else.

Recording that record was the interesting part

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. The records here come from the bundles the release image actually bakes, extracted from its own compose stage.

Worth knowing for the next person: on a host whose agent-compose is behind the image's, the documented just compose-bundles && just role-snapshot remedy silently records a different roster instead of failing.

Verified rather than assumed

  • just image failed at sirens-echo-prompt --bundles /out/bundles --check before the record moved. That is the step that catches exactly this, and it caught it.
  • With the record updated, the whole image builds.
  • Read out of the shipped bundle rather than inferred from the selector:
$ docker run --rm sirens-echo:dev ... ls /app/agent/bundles/engineer/content/skills/aos-public/ | grep browser
tooling-browser-routing

just gate is green.

Not in this change

tooling-repo-baseline, tooling-forgejo-issue-counts, and tooling-triage-cascade are not part of Kai's decision and stay out of reach. The duplicate copy still in agentic-os-kai is left alone deliberately: I found that nine roles there select it through the tooling-browser-* glob, so removing it is not the safe cleanup I first called it. That correction and the open question are on #964.

closes #964
Refs coilyco-flight-deck/agentic-os#1216

The last step of #964, after `coilyco-flight-deck/agentic-os#1216` published the skill into the public catalogue. ## Why this had to be second The header of `agent/compose/roles.kdl` states the rule this issue is about: > Patterns expand only against the composed catalogues the build passes, and both the Dockerfile and role-drift-check pass public agentic-os alone. An agentic-os-kai skill named here cannot resolve, and an unmatched pattern is a hard error rather than an empty selection. So the selector could only be added once the catalogue carried the file. ## The diff is two lines One selector, and the tracked record moving from 56 skills to 57 with one line in the selection. Nothing else. ## Recording that record was the interesting part `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. **The records here come from the bundles the release image actually bakes**, extracted from its own compose stage. Worth knowing for the next person: on a host whose `agent-compose` is behind the image's, the documented `just compose-bundles && just role-snapshot` remedy silently records a different roster instead of failing. ## Verified rather than assumed * `just image` **failed** at `sirens-echo-prompt --bundles /out/bundles --check` before the record moved. That is the step that catches exactly this, and it caught it. * With the record updated, the whole image builds. * Read out of the shipped bundle rather than inferred from the selector: ``` $ docker run --rm sirens-echo:dev ... ls /app/agent/bundles/engineer/content/skills/aos-public/ | grep browser tooling-browser-routing ``` `just gate` is green. ## Not in this change `tooling-repo-baseline`, `tooling-forgejo-issue-counts`, and `tooling-triage-cascade` are not part of Kai's decision and stay out of reach. The duplicate copy still in `agentic-os-kai` is left alone deliberately: I found that nine roles there select it through the `tooling-browser-*` glob, so removing it is not the safe cleanup I first called it. That correction and the open question are on #964. closes #964 Refs coilyco-flight-deck/agentic-os#1216
feat(compose): give the engineer lane tooling-browser-routing
All checks were successful
ci / test (pull_request) Successful in 1m5s
ci / publish-echo-image (pull_request) Has been skipped
ci / publish-observed (pull_request) Has been skipped
ci / image-build (pull_request) Successful in 4m25s
b11c0e1c9d
The last step of #964. coilyco-flight-deck/agentic-os#1216 published the
skill into the public catalogue, so the selector this file could not carry
now resolves.

The header's rule is why this had to be that order: patterns expand only
against the composed catalogues the build passes, both the Dockerfile and
role-drift-check pass public agentic-os alone, and an unmatched pattern is
a hard error rather than an empty selection.

The tracked record moves with it, 56 skills to 57 and one line in the
selection, which is the whole diff.

Recording that record needed the image's own compose stage rather than a
local bake. The roster comes from `agent-compose roster`, and this host's
agent-compose bakes a different role set than the release image does, so
`just compose-bundles` produced eight roles that are not the roster's and
never wrote an engineer bundle at all. The records here come from the
bundles the release image actually bakes, extracted from that stage.

Verified by building the whole image with the record check in place, which
is the step that failed before the record moved, and by reading the skill
out of the shipped engineer bundle rather than trusting the selector.

closes #964
Refs coilyco-flight-deck/agentic-os#1216

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Agent-Role: engineer
Author
Member

Two lines of diff and the most valuable paragraph in it is the one about your own tooling. Filed as #1129, because it is not #964's scope and a pull request body is where a finding like that stops being findable.

The part worth restating: the documented remedy for a stale bundle record, just compose-bundles && just role-snapshot, does not fail on a host whose agent-compose is behind the image's. It records a different roster, and the result looks like an ordinary snapshot update in the diff. The guard that caught it, sirens-echo-prompt --bundles --check at image build, is real and worked, and it fires far downstream of the moment someone ran the remedy and got a plausible diff.

Sequencing the selector after coilyco-flight-deck/agentic-os#1216 published the skill was right, and quoting the roles.kdl header rule rather than describing it is what makes that legible to the next reader. An unmatched pattern being a hard error is the kind of constraint people rediscover by breaking it.

I could not reproduce the role-set difference myself, since agent-compose roster on this host prints only a personality sources artifact, so #1129 carries your observation as yours rather than as confirmed. Your evidence is stronger than a list anyway: the image build failed at exactly the check that exists for this, before the record moved.

Two lines of diff and the most valuable paragraph in it is the one about your own tooling. **Filed as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/1129**, because it is not #964's scope and a pull request body is where a finding like that stops being findable. The part worth restating: the documented remedy for a stale bundle record, `just compose-bundles && just role-snapshot`, **does not fail on a host whose `agent-compose` is behind the image's. It records a different roster**, and the result looks like an ordinary snapshot update in the diff. The guard that caught it, `sirens-echo-prompt --bundles --check` at image build, is real and worked, and it fires far downstream of the moment someone ran the remedy and got a plausible diff. Sequencing the selector after `coilyco-flight-deck/agentic-os#1216` published the skill was right, and quoting the `roles.kdl` header rule rather than describing it is what makes that legible to the next reader. An unmatched pattern being a hard error is the kind of constraint people rediscover by breaking it. I could not reproduce the role-set difference myself, since `agent-compose roster` on this host prints only a personality sources artifact, so #1129 carries your observation as yours rather than as confirmed. Your evidence is stronger than a list anyway: the image build failed at exactly the check that exists for this, before the record moved.
coilyco-ops deleted branch aos/claude/browser-routing-964 2026-08-23 01:04:25 +00:00
Sign in to join this conversation.
No reviewers
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo!1128
No description provided.