feat: give the CoilyCo profile its Steam and Forgejo MCPs #110

Merged

coilysiren merged 1 commit from feat/deep-steam-mcp into main

2026-08-11 17:27:00 +00:00

coilyco-ops commented

2026-08-11 17:24:47 +00:00

Member

Gives Deep the Steam surface requested in coilyco-bridge/deploy#357, and restores the Forgejo surface its namespace was already running. Deep is becoming more like Echo, so the CoilyCo profile loosens from an asserted empty roster to a deliberately selected one.

Two surfaces

steam - a plain outbound-HTTPS reader, no write surface. New deployment in coilyco-bridge/deploy#361.
forgejo - the same repository-fixed guardfile Echo uses. Issues, comments, and labels on coilyco-gaming/sirens-echo, with no body edit, delete, reopen, pin, pull-request, repository, organization, or account tool.

Forgejo needed no deploy change. The sirens-deep namespace has been running that MCP with SIRENS_ECHO_FORGEJO_MCP_URL set since the lane was built, but no definition named the server, so the pod served nothing and Deep answered with tool_count: 0.

The invariant this overturns

TestCoilyCoDefinitionHasNoDomainSpecificSurface asserted len(definition.MCPServers) == 0, and AGENTS.md said the profile "begins with no MCP or automatic write surface". This is a deliberate reversal, not an oversight.

The guardrail is rewritten rather than deleted. TestCoilyCoDefinitionSelectsDeploymentResolvedSurfaces asserts:

exactly the two named servers
each resolving from url_env, never a literal URL that would pin one cluster
still no channel
still no issue_tracker

That last one is the part still genuinely guarded. Echo names the server as its issue_tracker and gets an automatic knowledge-gap reporter that files issues when a turn ends. Deep does not. A Forgejo write from Deep happens because the model chose a tool, never as a side effect of answering.

Fixtures

The three LoadConfig tests that use this definition and expect success now supply both addresses. Fixtures that expect an error, and every fixture on the Echo definition, are untouched.

Documentation

Corrected where this change and the Discord ingress in coilyco-bridge/deploy#356 made it wrong, across docs/sirens-echo-tools.md, docs/response-profiles.md, and AGENTS.md. The profile is no longer HTTP-only, no longer empty-rostered, and its channel is empty because deployment owns routing rather than because there is no ingress. Both docs are at their 80-line cap.

Merge order

LoadConfig fails startup on a definition naming an unset URL variable. coilyco-bridge/deploy#361 carries SIRENS_ECHO_STEAM_MCP_URL and must land first. Merged in the other order, Deep crashloops until deploy catches up. Forgejo has no such ordering constraint.

Verification

ward exec policy-check, prompt-check, vet, test, and pre-commit-all all pass. Rendered prompt snapshots are unchanged, since the prompt describes tool use generically and never enumerates servers.

🤖 Generated with Claude Code

Gives Deep the Steam surface requested in `coilyco-bridge/deploy#357`, and restores the Forgejo surface its namespace was already running. Deep is becoming more like Echo, so the CoilyCo profile loosens from an asserted empty roster to a deliberately selected one. ## Two surfaces * **steam** - a plain outbound-HTTPS reader, no write surface. New deployment in `coilyco-bridge/deploy#361`. * **forgejo** - the same repository-fixed guardfile Echo uses. Issues, comments, and labels on `coilyco-gaming/sirens-echo`, with no body edit, delete, reopen, pin, pull-request, repository, organization, or account tool. Forgejo needed no deploy change. The `sirens-deep` namespace has been running that MCP with `SIRENS_ECHO_FORGEJO_MCP_URL` set since the lane was built, but no definition named the server, so the pod served nothing and Deep answered with `tool_count: 0`. ## The invariant this overturns `TestCoilyCoDefinitionHasNoDomainSpecificSurface` asserted `len(definition.MCPServers) == 0`, and `AGENTS.md` said the profile "begins with no MCP or automatic write surface". This is a deliberate reversal, not an oversight. The guardrail is rewritten rather than deleted. `TestCoilyCoDefinitionSelectsDeploymentResolvedSurfaces` asserts: * exactly the two named servers * each resolving from `url_env`, never a literal URL that would pin one cluster * still no channel * still **no `issue_tracker`** That last one is the part still genuinely guarded. Echo names the server as its `issue_tracker` and gets an automatic knowledge-gap reporter that files issues when a turn ends. Deep does not. A Forgejo write from Deep happens because the model chose a tool, never as a side effect of answering. ## Fixtures The three `LoadConfig` tests that use this definition and expect success now supply both addresses. Fixtures that expect an error, and every fixture on the Echo definition, are untouched. ## Documentation Corrected where this change and the Discord ingress in `coilyco-bridge/deploy#356` made it wrong, across `docs/sirens-echo-tools.md`, `docs/response-profiles.md`, and `AGENTS.md`. The profile is no longer HTTP-only, no longer empty-rostered, and its channel is empty because deployment owns routing rather than because there is no ingress. Both docs are at their 80-line cap. ## Merge order `LoadConfig` **fails startup** on a definition naming an unset URL variable. `coilyco-bridge/deploy#361` carries `SIRENS_ECHO_STEAM_MCP_URL` and must land first. Merged in the other order, Deep crashloops until deploy catches up. Forgejo has no such ordering constraint. ## Verification `ward exec policy-check`, `prompt-check`, `vet`, `test`, and `pre-commit-all` all pass. Rendered prompt snapshots are unchanged, since the prompt describes tool use generically and never enumerates servers. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

coilyco-ops added 1 commit

2026-08-11 17:24:47 +00:00

feat: give the CoilyCo profile a read-only Steam MCP

ci / test (pull_request) Successful in 35s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

5f9c5ebc05

Deep is becoming more like Echo, so the profile loosens from an asserted
empty roster to a deliberately selected read-only one.

TestCoilyCoDefinitionHasNoDomainSpecificSurface asserted len(MCPServers)
== 0. Rather than delete the guardrail, it becomes
TestCoilyCoDefinitionSelectsOnlyReadOnlySurfaces and asserts the intended
shape: exactly one server, named steam, resolving its address from
deployment rather than a literal URL, and still no issue tracker and no
channel. The write surface stays the thing under guard.

Three LoadConfig fixtures use this definition and expect success, so they
supply the selected MCP address. The fixtures that expect an error, and
the ones on the Echo definition, are untouched.

Documentation is corrected where this change and the recent Discord
ingress made it wrong: the profile is no longer HTTP-only, no longer
empty-rostered, and its channel is empty because deployment owns routing
rather than because there is no ingress.

Deployment must supply SIRENS_ECHO_STEAM_MCP_URL before this lands, since
LoadConfig fails startup on a definition naming an unset URL variable.
coilyco-bridge/deploy#361 carries that variable.

Refs coilyco-bridge/deploy#357

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>

coilyco-ops requested review from coilysiren

2026-08-11 17:24:47 +00:00

coilysiren merged commit 5758f66de1 into main

2026-08-11 17:27:00 +00:00

coilysiren referenced this pull request from a commit

2026-08-11 17:27:01 +00:00

Merge pull request 'feat: give the CoilyCo profile a read-only Steam MCP' (#110) from feat/deep-steam-mcp into main

coilyco-ops changed title from ~~feat: give the CoilyCo profile a read-only Steam MCP~~ to feat: give the CoilyCo profile its Steam and Forgejo MCPs

2026-08-11 17:30:45 +00:00

coilyco-ops referenced this pull request

2026-08-11 22:59:27 +00:00

feat: give the Sirens Deep profile its Forgejo MCP #113