Give Sirens Deep first-class knowledge of its own guardfile

coilyco-ops commented

2026-08-11 23:40:41 +00:00

Member

Outcome

Sirens Deep can accurately describe its own authority when challenged, without being handed prose that drifts from the deployed guardfile.

Why

The August 19 stream asks outright how permissions should work when someone borrows an agent. Deep is the only agent on that panel whose authority is declarative and reviewable, so this is the question Kai is best positioned to answer.

Answering it well needs more than the tool list. The agent already sees its granted tools as schemas. What it does not have is the shape of the denial: paths fixed to one repository with no owner or repo argument to redirect, and edits and deletes denied by absence rather than by an explicit rule. Deny-by-absence is the interesting part and it is invisible from the tool list alone.

The trap this has to avoid

A hand-written skill describing the guardfile is a description of a document, not a description of live authority. The two drift the moment either changes. An agent confidently misdescribing its own boundaries on a permanent public recording is worse than an agent that declines to describe them.

So the skill is generated from the KDL. It is not written by hand.

Shape

Source is the guardfile at services/sirens-echo/forgejo-mcp.mcp.kdl in coilyco-bridge/deploy, which both lanes mount.
Output is a skill under Deep's local_skill_roots, currently .agents/skills/coilyco-general.
Regeneration is verified, so a guardfile edit that does not refresh the skill fails rather than going quietly stale.
No new tool grant. This is knowledge about authority, not authority.

Layer context

Four layers hold Deep's boundary: network controls, the ward KDL, harness config, and prose instruction. The KDL is the layer worth teaching the agent and the layer worth talking about on stream. Network controls cannot be shown, harness config is YAML anyone could have written, and prose instruction is exactly the mechanism everyone else relies on and that does not hold under pressure.

Out of scope

Any new MCP server or write grant. See coilyco-bridge/deploy#365.

## Outcome Sirens Deep can accurately describe its own authority when challenged, without being handed prose that drifts from the deployed guardfile. ## Why The August 19 stream asks outright how permissions should work when someone borrows an agent. Deep is the only agent on that panel whose authority is declarative and reviewable, so this is the question Kai is best positioned to answer. Answering it well needs more than the tool list. The agent already sees its granted tools as schemas. What it does not have is the shape of the denial: paths fixed to one repository with no owner or repo argument to redirect, and edits and deletes denied by absence rather than by an explicit rule. Deny-by-absence is the interesting part and it is invisible from the tool list alone. ## The trap this has to avoid A hand-written skill describing the guardfile is a description of a document, not a description of live authority. The two drift the moment either changes. An agent confidently misdescribing its own boundaries on a permanent public recording is worse than an agent that declines to describe them. So the skill is generated from the KDL. It is not written by hand. ## Shape - Source is the guardfile at `services/sirens-echo/forgejo-mcp.mcp.kdl` in `coilyco-bridge/deploy`, which both lanes mount. - Output is a skill under Deep's `local_skill_roots`, currently `.agents/skills/coilyco-general`. - Regeneration is verified, so a guardfile edit that does not refresh the skill fails rather than going quietly stale. - No new tool grant. This is knowledge about authority, not authority. ## Layer context Four layers hold Deep's boundary: network controls, the ward KDL, harness config, and prose instruction. The KDL is the layer worth teaching the agent and the layer worth talking about on stream. Network controls cannot be shown, harness config is YAML anyone could have written, and prose instruction is exactly the mechanism everyone else relies on and that does not hold under pressure. ## Out of scope Any new MCP server or write grant. See `coilyco-bridge/deploy#365`.

coilysiren commented

2026-08-12 02:48:18 +00:00

Owner

Not "its own guardfile"

I meant the guardfiles of its various MCPs, and how guardfiles work in general

Not "its own guardfile" I meant the guardfiles of its various MCPs, and how guardfiles work in general

coilyco-ops referenced this issue

2026-08-12 11:20:20 +00:00

Sirens Deep can claim to be a person, and nothing stops it #148

coilyco-ops referenced this issue

2026-08-12 11:53:23 +00:00

Sirens Deep: compose a real Agent Compose identity, selected by one deploy string #98

coilyco-ops commented

2026-08-12 11:53:33 +00:00

Author

Member

Scope corrected, and cleared to build

Direction from Kai, 2026-08-12 session.

Priority: top of queue for the week to August 19, alongside #98.

The scope in this issue's title was wrong

Kai's correction stands: not Deep's own guardfile, but the guardfiles of its various MCPs, and how guardfiles work in general. The issue body should be read with that substitution throughout.

What to build

Two artifacts, deliberately different in kind.

One generated skill per guardfile in Deep's roster. The roster at sirens-deep-mcp-roster.yml names two servers, forgejo and steam, so that is two generated skills today and however many the roster carries tomorrow. Each describes that server's real grants and — the interesting half — its denials: paths fixed to one repository with no owner or repo argument to redirect, edits and deletes denied by absence rather than by an explicit rule.
One hand-written skill explaining what a guardfile is as a mechanism. Deny-by-absence, fixed paths, no redirect argument, the difference between a grant and a schema. This one is written by hand because the concept does not drift — only the specifics do.

The split is the point. The trap this issue names — "a hand-written skill describing the guardfile is a description of a document, not a description of live authority" — applies to the specifics, not to the mechanism. Generating the specifics and writing the concept puts each one where it cannot go stale.

Unchanged from the issue body

Source is the guardfile set the lanes mount, services/sirens-echo/forgejo-mcp.mcp.kdl and its siblings in coilyco-bridge/deploy.
Output goes under Deep's local_skill_roots, currently .agents/skills/coilyco-general.
Regeneration is verified. A guardfile edit that does not refresh the generated skills fails rather than going quietly stale.
No new tool grant. This is knowledge about authority, not authority.

## Scope corrected, and cleared to build Direction from Kai, 2026-08-12 session. **Priority: top of queue** for the week to August 19, alongside #98. ## The scope in this issue's title was wrong Kai's correction stands: not Deep's own guardfile, but **the guardfiles of its various MCPs, and how guardfiles work in general**. The issue body should be read with that substitution throughout. ## What to build **Two artifacts, deliberately different in kind.** 1. **One generated skill per guardfile in Deep's roster.** The roster at `sirens-deep-mcp-roster.yml` names two servers, `forgejo` and `steam`, so that is two generated skills today and however many the roster carries tomorrow. Each describes that server's real grants and — the interesting half — its denials: paths fixed to one repository with no owner or repo argument to redirect, edits and deletes denied by absence rather than by an explicit rule. 2. **One hand-written skill explaining what a guardfile *is* as a mechanism.** Deny-by-absence, fixed paths, no redirect argument, the difference between a grant and a schema. This one is written by hand because the concept does not drift — only the specifics do. The split is the point. The trap this issue names — "a hand-written skill describing the guardfile is a description of a document, not a description of live authority" — applies to the specifics, not to the mechanism. Generating the specifics and writing the concept puts each one where it cannot go stale. ## Unchanged from the issue body - Source is the guardfile set the lanes mount, `services/sirens-echo/forgejo-mcp.mcp.kdl` and its siblings in `coilyco-bridge/deploy`. - Output goes under Deep's `local_skill_roots`, currently `.agents/skills/coilyco-general`. - **Regeneration is verified.** A guardfile edit that does not refresh the generated skills fails rather than going quietly stale. - **No new tool grant.** This is knowledge about authority, not authority.

coilyco-ops referenced this issue

2026-08-12 11:58:10 +00:00

Per-requester authority: a job acts as the principal who asked for it #150

coilyco-ops referenced this issue

2026-08-12 11:58:33 +00:00

Attribution: every effect is traceable to the principal who requested it #151

coilyco-ops referenced this issue

2026-08-12 12:03:44 +00:00

Per-requester authority: a job acts as the principal who asked for it #150

coilyco-ops commented

2026-08-12 12:13:47 +00:00

Author

Member

Correction: Deep has one guardfile, not two

My comment above says the roster names forgejo and steam, "so that is two generated skills today." That is wrong. Steam has no guardfile and is not supposed to have one.

coilyco-bridge/deploy/services/sirens-echo/deploy/sirens-deep-steam-mcp.yml, in its own header:

The image is a plain outbound-HTTPS reader with no write surface, so it needs no ward-mcp guardfile in front of it. Deep's Forgejo MCP is wrapped because Forgejo has issue and label mutation to bound. Steam has none.

Confirmed against the tree: the only guardfiles in services/sirens-echo/ are forgejo-mcp.mcp.kdl and discord-mcp.mcp.kdl, and Deep's roster carries only forgejo and steam. So Deep composes exactly one generated skill today, from the Forgejo guardfile.

This improves the material rather than thinning it

The generated-skill count drops, but the thing worth saying on August 19 gets sharper. Deep's two MCPs are governed differently and for a stated reason: one is wrapped because it can mutate, the other is unwrapped because it cannot. That is deny-by-absence operating one level up from the guardfile — at the question of whether a server needs a guardfile at all.

So the hand-written concept skill should cover both levels:

Within a guardfile — fixed paths with no owner or repo argument to redirect, and edits and deletes denied by absence.
Across the roster — a server with no write surface is not wrapped, and that is a judgement recorded in the deployment rather than a gap.

An agent that can explain why one of its tools has no guardfile is making a stronger claim about its own authority than one that just recites a grant list.

What the generator must handle

Since the mapping from roster entry to guardfile is not one-to-one, the generator needs a defined answer for a roster server with no guardfile — describing it as ungoverned-because-read-only, rather than silently omitting it or failing. Omission is the bad outcome: a skill that lists one server when the agent reaches two is a description that drifts on day one.

The source material is better than expected

forgejo-mcp.mcp.kdl carries typed, constrained argument bounds, not just path fixing:

can list issue {
    path "/repos/coilyco-gaming/sirens-echo/issues"
    query {
        field "limit" type="integer" minimum=1 maximum=3 required=#true
        ...
    }
}

And its header states the deny-by-absence rule directly. Generating an accurate skill from this is a formatting exercise, not an interpretation one.

One thing the generator must carry through: that file's own warning that editing it changes Echo and Deep, because both MCP releases mount the same file.

## Correction: Deep has one guardfile, not two My comment above says the roster names `forgejo` and `steam`, "so that is two generated skills today." **That is wrong.** Steam has no guardfile and is not supposed to have one. `coilyco-bridge/deploy/services/sirens-echo/deploy/sirens-deep-steam-mcp.yml`, in its own header: > The image is a plain outbound-HTTPS reader with no write surface, so it needs no ward-mcp guardfile in front of it. Deep's Forgejo MCP is wrapped because Forgejo has issue and label mutation to bound. Steam has none. Confirmed against the tree: the only guardfiles in `services/sirens-echo/` are `forgejo-mcp.mcp.kdl` and `discord-mcp.mcp.kdl`, and Deep's roster carries only `forgejo` and `steam`. So **Deep composes exactly one generated skill today**, from the Forgejo guardfile. ## This improves the material rather than thinning it The generated-skill count drops, but the thing worth saying on August 19 gets sharper. Deep's two MCPs are governed differently and for a stated reason: one is wrapped because it can mutate, the other is unwrapped because it cannot. That is deny-by-absence operating one level up from the guardfile — at the question of whether a server needs a guardfile at all. So the hand-written concept skill should cover **both levels**: 1. Within a guardfile — fixed paths with no owner or repo argument to redirect, and edits and deletes denied by absence. 2. Across the roster — a server with no write surface is not wrapped, and that is a judgement recorded in the deployment rather than a gap. An agent that can explain why *one* of its tools has no guardfile is making a stronger claim about its own authority than one that just recites a grant list. ## What the generator must handle Since the mapping from roster entry to guardfile is not one-to-one, the generator needs a defined answer for a roster server with no guardfile — describing it as ungoverned-because-read-only, rather than silently omitting it or failing. Omission is the bad outcome: a skill that lists one server when the agent reaches two is a description that drifts on day one. ## The source material is better than expected `forgejo-mcp.mcp.kdl` carries typed, constrained argument bounds, not just path fixing: ```kdl can list issue { path "/repos/coilyco-gaming/sirens-echo/issues" query { field "limit" type="integer" minimum=1 maximum=3 required=#true ... } } ``` And its header states the deny-by-absence rule directly. Generating an accurate skill from this is a formatting exercise, not an interpretation one. One thing the generator must carry through: that file's own warning that **editing it changes Echo and Deep**, because both MCP releases mount the same file.

coilyco-ops referenced this issue

2026-08-12 12:14:23 +00:00

Per-requester authority: a job acts as the principal who asked for it #150

coilyco-ops referenced this issue

2026-08-12 12:15:20 +00:00

Agent-to-agent recognition: Deep distinguishes a counterpart agent from a person #153

coilyco-ops referenced this issue from a commit

2026-08-12 12:37:17 +00:00

feat(guardfile): generate the agent's knowledge of its own authority

coilyco-ops closed this issue

2026-08-12 12:37:17 +00:00

coilyco-ops referenced this issue