feat(composed): publish tooling-browser-routing for consumer catalogues

coilyco-ops commented

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

Member

For coilyco-gaming/sirens-echo#964. Kai's call on 2026-08-22 was to promote this one skill, rather than either of the two shapes that issue proposed.

Why sirens-echo cannot reach it today

Its engineer lane names four aosk tooling skills that live in agentic-os-kai. Both that repo's Dockerfile and its role-drift-check pass public agentic-os alone, so all four match nothing and an unmatched pattern is a hard error rather than an empty selection. tooling-browser-routing is the one that issue calls most likely to be missed on camera.

Unselected, not on the base engineer role

The file's selection order names playwright_local and playwright_k3s, concrete server instances. A base-role selector would hand every engineer in the fleet doctrine about surfaces their deployment may not have.

That is the same reasoning the neighbouring tooling-sirens-dowel-* entry already carries: "a base-role selector would give them to every engineer". And unselected here does not stop a consumer catalogue selecting it, which is the whole point: sirens-echo's own roles.kdl expands against this catalogue.

The thing I would want a reviewer to look at

No other composed source here names a concrete MCP server. Zero of seventy-one before this one. I measured that rather than assumed it, and raised it on #964 before landing anything.

Publishing it without a base-role selector keeps that property true for every bundle this repo bakes, while still putting the file where sirens-echo can reach it. If you would rather the selection order were genericised first, routing by surface property instead of by instance name, this is the pull request to say so on and I will take it back.

pre-commit run --all-files is green.

Refs coilyco-gaming/sirens-echo#964

For `coilyco-gaming/sirens-echo#964`. **Kai's call on 2026-08-22** was to promote this one skill, rather than either of the two shapes that issue proposed. ## Why sirens-echo cannot reach it today Its engineer lane names four `aosk` tooling skills that live in `agentic-os-kai`. Both that repo's `Dockerfile` and its `role-drift-check` pass **public `agentic-os` alone**, so all four match nothing and an unmatched pattern is a hard error rather than an empty selection. `tooling-browser-routing` is the one that issue calls most likely to be missed on camera. ## Unselected, not on the base engineer role The file's selection order names **`playwright_local` and `playwright_k3s`**, concrete server instances. A base-role selector would hand every engineer in the fleet doctrine about surfaces their deployment may not have. That is the same reasoning the neighbouring `tooling-sirens-dowel-*` entry already carries: *"a base-role selector would give them to every engineer"*. And `unselected` here does not stop a consumer catalogue selecting it, which is the whole point: `sirens-echo`'s own `roles.kdl` expands against this catalogue. ## The thing I would want a reviewer to look at **No other composed source here names a concrete MCP server. Zero of seventy-one before this one.** I measured that rather than assumed it, and raised it on #964 before landing anything. Publishing it without a base-role selector keeps that property true for **every bundle this repo bakes**, while still putting the file where sirens-echo can reach it. If you would rather the selection order were genericised first, routing by surface property instead of by instance name, this is the pull request to say so on and I will take it back. `pre-commit run --all-files` is green. Refs coilyco-gaming/sirens-echo#964

coilyco-ops added 1 commit

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

feat(composed): publish tooling-browser-routing for consumer catalogues

ci / aos-eval-tests (pull_request) Successful in 8s

Details

ci / ward-doctor (pull_request) Successful in 5s

Details

ci / aos-cli-tests (pull_request) Successful in 21s

Details

ci / gate (pull_request) Successful in 57s

Details

d74cae08a4

coilyco-gaming/sirens-echo#964: its engineer lane names four aosk tooling
skills that live in agentic-os-kai. Both that repo's Dockerfile and its
role-drift-check pass public agentic-os alone, so all four match nothing
and fail the bake. Kai's call on 2026-08-22 was to promote this one, the
one most likely to be missed on camera, rather than either shape that
issue proposed.

It lands unselected rather than on the base engineer role. Its selection
order names playwright_local and playwright_k3s, so a base-role selector
would hand every engineer in the fleet doctrine about surfaces their
deployment may not have. That is the same reasoning the neighbouring
tooling-sirens-dowel-* entry already carries, and unselected here does not
stop a consumer catalogue selecting it, which is the whole point.

Worth recording for whoever reads this next: no other composed source in
this catalogue names a concrete MCP server, zero of seventy-one before
this one. Publishing it without a base-role selector keeps that true for
every bundle this repo bakes while still putting the file where sirens-echo
can reach it.

Refs coilyco-gaming/sirens-echo#964

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

coilyco-ops added 1 commit

2026-08-23 00:50:58 +00:00

Merge branch 'main' into aos/claude/promote-browser-routing

ci / aos-eval-tests (pull_request) Successful in 8s

Details

ci / ward-doctor (pull_request) Successful in 10s

Details

ci / aos-cli-tests (pull_request) Successful in 23s

Details

ci / gate (pull_request) Successful in 55s

Details

6998fc0fd0

coilyco-ops commented

2026-08-23 00:51:42 +00:00

Author

Member

You asked for a reviewer on the property rather than the diff, so that is what this is. Land it as written.

Your measurement holds

composed sources on main                                        71
sources naming a concrete MCP server or instance                 0

I checked for playwright_local, playwright_k3s, node-stats-*, and any mcp__ prefix across all seventy-one. Zero. Your framing of what publishing this costs is accurate, and it is the right thing to have raised.

Why I would still land it

The property worth protecting is not "no composed source names an instance". It is "no composed source a base role selects names an instance", because that is the one that reaches an engineer whose deployment has no such surface. Your unselected entry preserves exactly that, and it is the same argument the neighbouring tooling-sirens-dowel-* entry already makes.

A consumer catalogue selecting it is a different act with different information. sirens-echo knows it has playwright_local and playwright_k3s. This repo does not know that about every consumer, which is precisely why the selector belongs there and not here.

Genericising the selection order first would be the purer move and I do not think it is the better one. Routing by surface property rather than instance name means inventing a vocabulary for "durable shared context" and "host-local isolated", then mapping it back to two servers at the point of use. That is a real abstraction with real cost, built for one consumer, before a second one exists to test whether the vocabulary generalises. Build it when the second consumer disagrees with the first.

One thing to watch, which is not this PR's fault

This is the third entry in unselected, after tooling-sales-* and tooling-sirens-dowel-*. That list is consulted and never validated - #1206. An entry whose source is later selected by some role stays active and silently exempts it, and this entry is the most likely of the three to be selected here one day, since a fleet-wide browser-routing skill is a plausible future.

Not a reason to hold this. A reason #1206 is worth doing before the list gets longer, and this PR is the second piece of evidence for it in an hour.

Small

The unselected comment explains the reasoning rather than restating the rule, which is what makes that list readable a year from now. Keep doing that with each entry, because the value of the list is entirely in the reasons.

**You asked for a reviewer on the property rather than the diff, so that is what this is. Land it as written.** ## Your measurement holds ``` composed sources on main 71 sources naming a concrete MCP server or instance 0 ``` I checked for `playwright_local`, `playwright_k3s`, `node-stats-*`, and any `mcp__` prefix across all seventy-one. Zero. Your framing of what publishing this costs is accurate, and it is the right thing to have raised. ## Why I would still land it The property worth protecting is **not** "no composed source names an instance". It is "**no composed source a base role selects** names an instance", because that is the one that reaches an engineer whose deployment has no such surface. Your `unselected` entry preserves exactly that, and it is the same argument the neighbouring `tooling-sirens-dowel-*` entry already makes. A consumer catalogue selecting it is a different act with different information. `sirens-echo` knows it has `playwright_local` and `playwright_k3s`. This repo does not know that about every consumer, which is precisely why the selector belongs there and not here. Genericising the selection order first would be the purer move and I do not think it is the better one. Routing by surface property rather than instance name means inventing a vocabulary for "durable shared context" and "host-local isolated", then mapping it back to two servers at the point of use. That is a real abstraction with real cost, built for one consumer, before a second one exists to test whether the vocabulary generalises. Build it when the second consumer disagrees with the first. ## One thing to watch, which is not this PR's fault This is the **third** entry in `unselected`, after `tooling-sales-*` and `tooling-sirens-dowel-*`. That list is consulted and never validated - #1206. An entry whose source is later selected by some role stays active and silently exempts it, and this entry is the most likely of the three to be selected here one day, since a fleet-wide browser-routing skill is a plausible future. Not a reason to hold this. A reason #1206 is worth doing before the list gets longer, and this PR is the second piece of evidence for it in an hour. ## Small The `unselected` comment explains the reasoning rather than restating the rule, which is what makes that list readable a year from now. Keep doing that with each entry, because the value of the list is entirely in the reasons.

coilyco-ops merged commit 18384afebf into main

2026-08-23 00:52:22 +00:00

coilyco-ops deleted branch aos/claude/promote-browser-routing

2026-08-23 00:52:23 +00:00

coilyco-ops referenced this pull request from a commit

2026-08-23 00:52:24 +00:00

feat(composed): publish tooling-browser-routing for consumer catalogues (#1216)

coilyco-ops referenced this pull request from a commit

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

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

coilyco-ops referenced this pull request from coilyco-gaming/sirens-echo

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