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

Merged

coilysiren merged 1 commit from fix/deep-forgejo-mcp into main

2026-08-11 23:03:16 +00:00

coilyco-ops commented

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

Member

Deep gets the Forgejo MCP its namespace has been running all along.

What happened

This change was written once already, as the second commit on the feat/deep-steam-mcp branch behind #110. It never reached main. The PR had already been merged when that commit was pushed, so the push landed on a closed PR's branch and went nowhere. git log -S "SIRENS_ECHO_FORGEJO_MCP_URL" -- agent/sirens-deep.yaml returns nothing on main, which is how the loss was found.

The consequence has been live since: sirens-deep-forgejo-mcp runs, SIRENS_ECHO_FORGEJO_MCP_URL is set, and no definition names the server, so the pod serves nothing.

This is the lost commit cherry-picked onto current main, with three conflicts resolved in main's favour where it had moved:

the profile identity is now Sirens Deep of Coilyco
the test keeps main's TestSirensDeep... prefix rather than the old TestCoilyCo... one
TestLoadConfigRejectsAHalfConfiguredPrincipal, added after this work was first written, loads the same definition and needed the second address

The surface

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. Every route is fixed to that one repository.

issue_tracker stays empty, which is the part still genuinely guarded. Echo names the server there 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.

No deploy change

SIRENS_ECHO_FORGEJO_MCP_URL has been set on the Deep lane since it was built, and the MCP pod is running. Nothing on the deploy side moves.

Verification

ward exec vet, test, policy-check, prompt-check, and pre-commit-all all pass.

🤖 Generated with Claude Code

Deep gets the Forgejo MCP its namespace has been running all along. ## What happened This change was written once already, as the second commit on the `feat/deep-steam-mcp` branch behind #110. It never reached `main`. The PR had already been merged when that commit was pushed, so the push landed on a closed PR's branch and went nowhere. `git log -S "SIRENS_ECHO_FORGEJO_MCP_URL" -- agent/sirens-deep.yaml` returns nothing on `main`, which is how the loss was found. The consequence has been live since: `sirens-deep-forgejo-mcp` runs, `SIRENS_ECHO_FORGEJO_MCP_URL` is set, and no definition names the server, so the pod serves nothing. This is the lost commit cherry-picked onto current `main`, with three conflicts resolved in `main`'s favour where it had moved: * the profile identity is now `Sirens Deep of Coilyco` * the test keeps `main`'s `TestSirensDeep...` prefix rather than the old `TestCoilyCo...` one * `TestLoadConfigRejectsAHalfConfiguredPrincipal`, added after this work was first written, loads the same definition and needed the second address ## The surface 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. Every route is fixed to that one repository. `issue_tracker` stays empty, which is the part still genuinely guarded. Echo names the server there 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. ## No deploy change `SIRENS_ECHO_FORGEJO_MCP_URL` has been set on the Deep lane since it was built, and the MCP pod is running. Nothing on the deploy side moves. ## Verification `ward exec vet`, `test`, `policy-check`, `prompt-check`, and `pre-commit-all` all pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

coilyco-ops added 1 commit

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

feat: give the Sirens Deep profile its Forgejo MCP

ci / test (pull_request) Successful in 53s

Details

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

Details

bb1b34ae52

The sirens-deep namespace has been running a Forgejo MCP with
SIRENS_ECHO_FORGEJO_MCP_URL set since the lane was built, but no
definition ever named the server, so the pod served nothing and Deep
answered without that surface.

This is 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.

issue_tracker stays empty, which is the part still under guard. Echo
names the server there and gets an automatic knowledge-gap reporter.
Deep does not, so a Forgejo write happens because the model chose a tool
and never because a turn ended.

The profile test asserts both servers resolve their address from
deployment rather than a literal URL, and that no issue tracker appears.
Every fixture loading this definition supplies both addresses, including
the half-configured-principal case added after this change was first
written and lost.

No deploy change: the variable has been set since the lane was built.

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 22:59:27 +00:00