coilyco-gaming/sirens-echo
Watch
3
0
Code Issues 153 Pull requests Projects Releases Packages 2 Wiki Activity Actions

sirens-deep: configuration to operate in guild channels, not DM-only #135

New issue
Open
opened 2026-08-12 09:28:13 +00:00 by coilyco-ops · 11 comments
coilyco-ops commented 2026-08-12 09:28:13 +00:00
Member
Copy link

Requested

Give Deep a configuration option that lets it read and respond in guild channels. Today it is DM-only.

Current state

From coilyco-bridge/deploy/services/sirens-echo/deploy/sirens-deep-values.yaml:

- name: SIRENS_ECHO_DISCORD_DM_ENABLED
  value: "true"

The file's own comment is explicit about the boundary:

Deep carries its own Discord application, separate from the Community bot, and its ingress is direct messages only. The DM_ENABLED switch buys the gateway's DirectMessages intent and nothing else: the file named by SIRENS_ECHO_ACCESS_POLICY is the gate, and a file policy never takes the environment path's open-DM widening.

Why this is not a values-only change

DM_ENABLED buys the DirectMessages gateway intent. Guild channel messages require different intents (GuildMessages, plus MessageContent to see bodies). Unless that path already exists in the application, this needs code in sirens-echo before any values toggle has an effect.

Deployment-side follow-on once the app supports it:

  • a SIRENS_ECHO_DISCORD_GUILD_ENABLED-shaped switch (name TBD) in sirens-deep-values.yaml
  • an allowlist of permitted channel IDs in the access policy at /etc/sirens-deep/access-policy.yaml (ConfigMap sirens-deep-access-policy)

Target channel

deep — 1537024102886277210, in guild 1300204416229441587.

Related

Addressing behavior in guild channels is specified separately; that issue depends on this one.

Acceptance

  • Deep receives and responds to a message in 1537024102886277210.
  • Deep continues to respond in DM (no regression to the existing lane).
  • Deep does not respond in any guild channel absent from the access policy allowlist.
  • ward exec helm-template-sirens-deep passes and rendered/sirens-deep-bundle.txt is regenerated (pre-commit hook ties the two).

Next owner

Engineer.

## Requested Give Deep a configuration option that lets it read and respond in guild channels. Today it is DM-only. ## Current state From `coilyco-bridge/deploy/services/sirens-echo/deploy/sirens-deep-values.yaml`: ```yaml - name: SIRENS_ECHO_DISCORD_DM_ENABLED value: "true" ``` The file's own comment is explicit about the boundary: > Deep carries its own Discord application, separate from the Community bot, and its ingress is direct messages only. The DM_ENABLED switch buys the gateway's DirectMessages intent and nothing else: the file named by SIRENS_ECHO_ACCESS_POLICY is the gate, and a file policy never takes the environment path's open-DM widening. ## Why this is not a values-only change `DM_ENABLED` buys the DirectMessages gateway intent. Guild channel messages require different intents (GuildMessages, plus MessageContent to see bodies). Unless that path already exists in the application, this needs code in `sirens-echo` before any values toggle has an effect. Deployment-side follow-on once the app supports it: - a `SIRENS_ECHO_DISCORD_GUILD_ENABLED`-shaped switch (name TBD) in `sirens-deep-values.yaml` - an allowlist of permitted channel IDs in the access policy at `/etc/sirens-deep/access-policy.yaml` (ConfigMap `sirens-deep-access-policy`) ## Target channel `deep` — `1537024102886277210`, in guild `1300204416229441587`. ## Related Addressing behavior in guild channels is specified separately; that issue depends on this one. ## Acceptance - Deep receives and responds to a message in `1537024102886277210`. - Deep continues to respond in DM (no regression to the existing lane). - Deep does not respond in any guild channel absent from the access policy allowlist. - `ward exec helm-template-sirens-deep` passes and `rendered/sirens-deep-bundle.txt` is regenerated (pre-commit hook ties the two). ## Next owner Engineer.
coilyco-ops commented 2026-08-12 10:33:01 +00:00
Author
Member
Copy link

The premise is wrong, and in the useful direction

DM_ENABLED buys the DirectMessages gateway intent. Guild channel messages require different intents (GuildMessages, plus MessageContent to see bodies). Unless that path already exists in the application, this needs code in sirens-echo before any values toggle has an effect.

That path already exists. internal/community/agent.go, NewAgent:

session.Identify.Intents = discordgo.IntentsGuilds |
    discordgo.IntentsGuildMessages |
    discordgo.IntentsMessageContent
if cfg.DiscordDMEnabled {
    session.Identify.Intents |= discordgo.IntentsDirectMessages
}

Guild intents are unconditional whenever Discord is enabled. DM_ENABLED only adds the DirectMessages intent. So Deep is already listening on guild channels at the gateway. It is DM-only because nothing admits a guild message downstream, not because it cannot see one.

The rest of the path is also already there

  • AccessPolicy models guilds: with a per-guild channels allowlist, users, roles, and optional per-guild rate limits (internal/community/access.go).
  • Evaluate gates a guild summon on exactly that, and returns denied_guild for a guild absent from the policy. Fails closed.
  • summonedLocally requires a mention or a reply to Deep before a guild message becomes a turn. A DM is a summon by definition, a guild message is not.
  • Thread messages resolve their parent channel against the same allowlist, with the lookup rate-limited.

What that means for this issue

There is no SIRENS_ECHO_DISCORD_GUILD_ENABLED and none is needed. The access policy file is the guild switch. Adding a guilds: entry for 1300204416229441587 with channels: ["1537024102886277210"] to the sirens-deep-access-policy ConfigMap should be sufficient, with no image change.

Each acceptance criterion maps to something already implemented:

  • responds in 1537024102886277210 - the channel allowlist admits it, and a mention summons it
  • still responds in DM - direct_messages.allow is evaluated separately and is untouched
  • does not respond in an unlisted guild channel - accessDeniedChannel and accessDeniedGuild, both fail-closed
  • helm-template-sirens-deep and the rendered bundle - deploy-side, unchanged by this reading

Bounded by what I did not verify

I read this repository only. I have not read the deployed sirens-deep-access-policy ConfigMap, so I cannot say whether it currently carries a guilds: block, an empty one, or only direct_messages. I have not verified live behavior, and the file's own comment about a file policy refusing the environment path's open-DM widening is worth re-reading against legacyOpenDMs before editing it.

Next owner

Deploy or Ops, not Engineer. If adding the guild entry does not produce a response, that comes back here with the trace and I will take it as a real code gap.

## The premise is wrong, and in the useful direction > `DM_ENABLED` buys the DirectMessages gateway intent. Guild channel messages require different intents (GuildMessages, plus MessageContent to see bodies). Unless that path already exists in the application, this needs code in `sirens-echo` before any values toggle has an effect. That path already exists. `internal/community/agent.go`, `NewAgent`: ```go session.Identify.Intents = discordgo.IntentsGuilds | discordgo.IntentsGuildMessages | discordgo.IntentsMessageContent if cfg.DiscordDMEnabled { session.Identify.Intents |= discordgo.IntentsDirectMessages } ``` Guild intents are unconditional whenever Discord is enabled. `DM_ENABLED` only *adds* the DirectMessages intent. So Deep is already listening on guild channels at the gateway. It is DM-only because nothing admits a guild message downstream, not because it cannot see one. ## The rest of the path is also already there * `AccessPolicy` models `guilds:` with a per-guild `channels` allowlist, `users`, `roles`, and optional per-guild rate limits (`internal/community/access.go`). * `Evaluate` gates a guild summon on exactly that, and returns `denied_guild` for a guild absent from the policy. Fails closed. * `summonedLocally` requires a mention or a reply to Deep before a guild message becomes a turn. A DM is a summon by definition, a guild message is not. * Thread messages resolve their parent channel against the same allowlist, with the lookup rate-limited. ## What that means for this issue There is no `SIRENS_ECHO_DISCORD_GUILD_ENABLED` and none is needed. The access policy file *is* the guild switch. Adding a `guilds:` entry for `1300204416229441587` with `channels: ["1537024102886277210"]` to the `sirens-deep-access-policy` ConfigMap should be sufficient, with no image change. Each acceptance criterion maps to something already implemented: * responds in `1537024102886277210` - the channel allowlist admits it, and a mention summons it * still responds in DM - `direct_messages.allow` is evaluated separately and is untouched * does not respond in an unlisted guild channel - `accessDeniedChannel` and `accessDeniedGuild`, both fail-closed * `helm-template-sirens-deep` and the rendered bundle - deploy-side, unchanged by this reading ## Bounded by what I did not verify I read this repository only. I have not read the deployed `sirens-deep-access-policy` ConfigMap, so I cannot say whether it currently carries a `guilds:` block, an empty one, or only `direct_messages`. I have not verified live behavior, and the file's own comment about a file policy refusing the environment path's open-DM widening is worth re-reading against `legacyOpenDMs` before editing it. ## Next owner Deploy or Ops, not Engineer. If adding the guild entry does not produce a response, that comes back here with the trace and I will take it as a real code gap.
coilyco-ops commented 2026-08-12 11:54:12 +00:00
Author
Member
Copy link

Handling: engineer opens the deploy PR, Kai merges and verifies

Direction from Kai, 2026-08-12 session.

The previous comment's conclusion — "Next owner: Deploy or Ops, not Engineer" — is accepted on the technical reading and adjusted on the handoff, because this is on the August 19 critical path and should not sit waiting for a queue it is not in.

Split of work:

  • Engineer writes the change in coilyco-bridge/deploy: a guilds: entry for 1300204416229441587 with channels: ["1537024102886277210"] in the sirens-deep-access-policy ConfigMap, plus the regenerated rendered/sirens-deep-bundle.txt that the pre-commit hook ties to it. That repository's workflow is pull-request-and-merge and director-gated, so a PR is the normal path regardless.
  • Kai merges and performs the live check.

The engineer runs in a sealed ephemeral clone with no live-cluster access and must not iterate against the rollout. If adding the guild entry does not produce a response, that returns here with a trace and is taken as a real code gap, exactly as the previous comment proposed.

Confirmed unchanged

No SIRENS_ECHO_DISCORD_GUILD_ENABLED is being added. The access policy file is the guild switch.

Before touching the file

The previous comment flagged one thing it had not verified and it is worth doing first: re-read the values file's own comment about a file policy refusing the environment path's open-DM widening, against legacyOpenDMs. The DM lane must not regress — it is an explicit acceptance criterion here and the only lane Deep has today.

Related

#136 (per-channel addressing) changes Channels from a flat allowlist of ID strings to a list of objects, as a hard cutover with no dual-path parsing. If both land in the same window, this file should be written in the new shape directly rather than written flat and rewritten days later. Coordinate the two.

Priority

Demo track, week to August 19. The demo happens in this channel.

## Handling: engineer opens the deploy PR, Kai merges and verifies Direction from Kai, 2026-08-12 session. The previous comment's conclusion — "Next owner: Deploy or Ops, not Engineer" — is accepted on the technical reading and adjusted on the handoff, because this is on the August 19 critical path and should not sit waiting for a queue it is not in. **Split of work:** - **Engineer** writes the change in `coilyco-bridge/deploy`: a `guilds:` entry for `1300204416229441587` with `channels: ["1537024102886277210"]` in the `sirens-deep-access-policy` ConfigMap, plus the regenerated `rendered/sirens-deep-bundle.txt` that the pre-commit hook ties to it. That repository's workflow is `pull-request-and-merge` and director-gated, so a PR is the normal path regardless. - **Kai** merges and performs the live check. The engineer runs in a sealed ephemeral clone with no live-cluster access and **must not** iterate against the rollout. If adding the guild entry does not produce a response, that returns here with a trace and is taken as a real code gap, exactly as the previous comment proposed. ## Confirmed unchanged No `SIRENS_ECHO_DISCORD_GUILD_ENABLED` is being added. The access policy file is the guild switch. ## Before touching the file The previous comment flagged one thing it had not verified and it is worth doing first: re-read the values file's own comment about a file policy refusing the environment path's open-DM widening, against `legacyOpenDMs`. The DM lane must not regress — it is an explicit acceptance criterion here and the only lane Deep has today. ## Related #136 (per-channel addressing) changes `Channels` from a flat allowlist of ID strings to a list of objects, as a **hard cutover with no dual-path parsing**. If both land in the same window, this file should be written in the new shape directly rather than written flat and rewritten days later. Coordinate the two. ## Priority Demo track, week to August 19. The demo happens in this channel.
coilyco-ops commented 2026-08-12 12:14:52 +00:00
Author
Member
Copy link

The unknown from the analysis comment is now answered

That comment closed with an honest bound:

I have not read the deployed sirens-deep-access-policy ConfigMap, so I cannot say whether it currently carries a guilds: block, an empty one, or only direct_messages.

Only direct_messages. The entire file:

data:
  access-policy.yaml: |
    schema: coilyco-harness.access.v1
    direct_messages:
      allow:
        - "318190481467244544"

Its header states the intent plainly: "No guild entry is the point: Deep answers direct messages from the listed account and refuses every guild summon, including from a guild its bot identity was installed into. Adding a guild is a deliberate edit here."

So the change is purely additive — a new guilds: block, not an edit to an existing one — and there is no risk of disturbing an existing guild grant because there is none. The DM lane is a separate key and is untouched by adding a sibling.

Write it in #136's shape

#136 changes channels from a flat list of ID strings to a list of objects with an addressing field. Since this file has no channels at all today, the first guilds: block should be written in the new object shape directly:

guilds:
  "1300204416229441587":
    channels:
      - id: "1537024102886277210"
        addressing: mention

mention is the default and the demo does not need implicit addressing to work, so this lands safely ahead of #136's code change and needs no rewrite afterward. Flipping to implicit later is a one-word edit.

If #136's parser is not in the image yet when this rolls out, write the flat form and accept the rewrite — but check first, because the ordering is avoidable.

Still true

Everything else in the analysis comment holds: guild intents are unconditional, AccessPolicy already models guilds and channels, Evaluate fails closed on an unlisted guild, and summonedLocally requires a mention or a reply. No SIRENS_ECHO_DISCORD_GUILD_ENABLED is needed.

The one thing that comment flagged as worth re-reading before editing — the values file's note about a file policy refusing the environment path's open-DM widening, checked against legacyOpenDMs — still stands and is still unverified.

## The unknown from the analysis comment is now answered That comment closed with an honest bound: > I have not read the deployed `sirens-deep-access-policy` ConfigMap, so I cannot say whether it currently carries a `guilds:` block, an empty one, or only `direct_messages`. **Only `direct_messages`.** The entire file: ```yaml data: access-policy.yaml: | schema: coilyco-harness.access.v1 direct_messages: allow: - "318190481467244544" ``` Its header states the intent plainly: *"No guild entry is the point: Deep answers direct messages from the listed account and refuses every guild summon, including from a guild its bot identity was installed into. Adding a guild is a deliberate edit here."* So the change is **purely additive** — a new `guilds:` block, not an edit to an existing one — and there is no risk of disturbing an existing guild grant because there is none. The DM lane is a separate key and is untouched by adding a sibling. ## Write it in #136's shape #136 changes `channels` from a flat list of ID strings to a list of objects with an `addressing` field. Since this file has no channels at all today, the first `guilds:` block should be **written in the new object shape directly**: ```yaml guilds: "1300204416229441587": channels: - id: "1537024102886277210" addressing: mention ``` `mention` is the default and the demo does not need implicit addressing to work, so this lands safely ahead of #136's code change and needs no rewrite afterward. Flipping to `implicit` later is a one-word edit. If #136's parser is not in the image yet when this rolls out, write the flat form and accept the rewrite — but check first, because the ordering is avoidable. ## Still true Everything else in the analysis comment holds: guild intents are unconditional, `AccessPolicy` already models guilds and channels, `Evaluate` fails closed on an unlisted guild, and `summonedLocally` requires a mention or a reply. No `SIRENS_ECHO_DISCORD_GUILD_ENABLED` is needed. The one thing that comment flagged as worth re-reading before editing — the values file's note about a file policy refusing the environment path's open-DM widening, checked against `legacyOpenDMs` — still stands and is still unverified.
coilyco-ops commented 2026-08-12 17:12:54 +00:00
Author
Member
Copy link

This is now the only thing between the portfolio and a working demo

Direction from Kai, 2026-08-12 session.

Everything else demo-facing has landed today: #98, #122, #143 through #147, #148, #150, #151, #153. #136, #153, and #81 all wait on this issue, and it is deploy-gated rather than build-gated.

Grant table decision: ward-exec to Kai's principal only

#154 changed what this issue has to carry. CheckExecutionAdmission now refuses executing jobs on any widened surface unless a declared grant table is present and grants ward-exec to somebody. Opening the guild without one silently disables everything #143–#147 built.

So the deploy change is two things, not one:

  1. The guilds: entry for 1300204416229441587 / channel 1537024102886277210.
  2. A grant table granting ward-exec to 318190481467244544 and to nobody else.

Everyone else in that channel is admitted for conversation and cannot cause execution. That keeps the requester set for executing work at one person while the conversational surface widens, which is the property #145's original sequencing warning was protecting — now enforced by grants rather than by there being only one requester at all.

Per #154's own Complete when: a grant table granting ward-exec to nobody refuses with a reason, so an empty table is not a safe middle ground. Grant it to Kai or expect execution off.

Write it in #136's object shape

Per the earlier comment, and now with the grant table alongside:

guilds:
  "1300204416229441587":
    channels:
      - id: "1537024102886277210"
        addressing: mention

addressing: mention is the default and the demo does not need implicit addressing to work, so this lands safely ahead of #136's code change and needs no rewrite. Flipping to implicit later is a one-word edit.

Check whether #136's parser is in the deployed image before using the object form; if not, use the flat form and accept the rewrite.

Split of work, unchanged

  • Engineer opens the PR in coilyco-bridge/deploy, including the regenerated rendered/sirens-deep-bundle.txt that the pre-commit hook ties to it. Sealed clone, so no live verification.
  • Kai merges and performs the live check.

If Deep does not respond after the entry lands, that returns here with a trace and is taken as a real code gap.

One thing still unverified by anyone

The values file's comment about a file policy refusing the environment path's open-DM widening, checked against legacyOpenDMs. The DM lane must not regress — it is an explicit acceptance criterion and it is the only lane Deep has today. Worth reading before the edit rather than after.

Also now depends on this

  • #153 — agent-to-agent recognition. Deep cannot meet a counterpart in a channel it cannot see. Kai's call there is disclosure + register.
  • #81 — the identity eval's agent-to-agent axis, which carries the only three-model sweep.
  • #136 — per-channel addressing.
## This is now the only thing between the portfolio and a working demo Direction from Kai, 2026-08-12 session. Everything else demo-facing has landed today: #98, #122, #143 through #147, #148, #150, #151, #153. **#136, #153, and #81 all wait on this issue**, and it is deploy-gated rather than build-gated. ## Grant table decision: `ward-exec` to Kai's principal only #154 changed what this issue has to carry. `CheckExecutionAdmission` now refuses executing jobs on any widened surface **unless a declared grant table is present and grants `ward-exec` to somebody**. Opening the guild without one silently disables everything #143–#147 built. So the deploy change is **two things, not one**: 1. The `guilds:` entry for `1300204416229441587` / channel `1537024102886277210`. 2. A grant table granting **`ward-exec` to `318190481467244544` and to nobody else**. Everyone else in that channel is admitted for conversation and cannot cause execution. That keeps the requester set for *executing* work at one person while the conversational surface widens, which is the property #145's original sequencing warning was protecting — now enforced by grants rather than by there being only one requester at all. Per #154's own **Complete when**: a grant table granting `ward-exec` to nobody refuses with a reason, so an empty table is not a safe middle ground. Grant it to Kai or expect execution off. ## Write it in #136's object shape Per the earlier comment, and now with the grant table alongside: ```yaml guilds: "1300204416229441587": channels: - id: "1537024102886277210" addressing: mention ``` `addressing: mention` is the default and the demo does not need implicit addressing to work, so this lands safely ahead of #136's code change and needs no rewrite. Flipping to `implicit` later is a one-word edit. Check whether #136's parser is in the deployed image before using the object form; if not, use the flat form and accept the rewrite. ## Split of work, unchanged * **Engineer** opens the PR in `coilyco-bridge/deploy`, including the regenerated `rendered/sirens-deep-bundle.txt` that the pre-commit hook ties to it. Sealed clone, so no live verification. * **Kai** merges and performs the live check. If Deep does not respond after the entry lands, that returns here with a trace and is taken as a real code gap. ## One thing still unverified by anyone The values file's comment about a file policy refusing the environment path's open-DM widening, checked against `legacyOpenDMs`. The DM lane must not regress — it is an explicit acceptance criterion and it is the only lane Deep has today. Worth reading before the edit rather than after. ## Also now depends on this * **#153** — agent-to-agent recognition. Deep cannot meet a counterpart in a channel it cannot see. Kai's call there is disclosure + register. * **#81** — the identity eval's agent-to-agent axis, which carries the only three-model sweep. * **#136** — per-channel addressing.
coilyco-ops commented 2026-08-12 17:16:47 +00:00
Author
Member
Copy link

Deploy change is up: coilyco-bridge/deploy#396

One guild entry in sirens-deep-access-policy.yml for guild 1300204416229441587, channel 1537024102886277210, and the principal. It is director-gated in that repo and it is a service-path change, so merging it rolls Deep — I have not merged it.

Confirming the premise correction

This issue says guild channels need different intents and therefore code in sirens-echo first. They do not. GuildMessages and MessageContent are already unconditional whenever Discord is enabled, DM_ENABLED only adds the DirectMessages intent, and AccessPolicy has always modelled guilds. The entry was the whole change.

Verified against the parser rather than by inspection

I extracted the embedded policy from the ConfigMap and ran this repository's LoadAccessPolicy and Evaluate over it:

  • the principal is admitted in 1537024102886277210
  • an unlisted account in that channel is refused
  • an unlisted channel is not admitted directly
  • another guild is refused as denied_guild
  • the DM lane is unchanged, and an unlisted account is still refused there
  • no counterpart agent is admitted, so bot accounts stay refused

The file uses only fields that predate today's schema additions, so it parses on the currently deployed image as well as the pinned one. No ordering hazard against an image roll.

The guild names its channel and members explicitly rather than all, so widening who may summon Deep there stays an edit in that file rather than a Discord invite.

Two incidental fixes the gate forced

main on deploy was already failing its own artifact hook: reconcile bumped the image pin to a6b6930 without recomposing. Recomposing picks up #149, so the artifact now carries eight role sections.

That broke validate-bundle-artifact.py, which compared a whole-file skill total against a per-role verify line — correct only while exactly one bundle was baked. Now compared per role section, as multisets, since verify lines are in bake order and role sections are alphabetical.

The acceptance items I cannot close

Three of the four need live observation, which I do not have:

  • Deep receives and responds in 1537024102886277210
  • Deep continues to respond in DM
  • Deep does not respond in an unlisted guild channel

ward exec helm-template-sirens-deep has no equivalent verb in the deploy repo; the bundle gate is compose-review-sirens-deep plus render-sirens-deep, and both pass along with the full pre-commit-all.

After merge, someone with live access should confirm the pod restarts cleanly rather than failing policy load, then walk the three behaviours above. Listed on the PR.

## Deploy change is up: coilyco-bridge/deploy#396 One guild entry in `sirens-deep-access-policy.yml` for guild `1300204416229441587`, channel `1537024102886277210`, and the principal. It is director-gated in that repo and it is a service-path change, so **merging it rolls Deep** — I have not merged it. ## Confirming the premise correction This issue says guild channels need different intents and therefore code in `sirens-echo` first. They do not. `GuildMessages` and `MessageContent` are already unconditional whenever Discord is enabled, `DM_ENABLED` only *adds* the DirectMessages intent, and `AccessPolicy` has always modelled guilds. The entry was the whole change. ## Verified against the parser rather than by inspection I extracted the embedded policy from the ConfigMap and ran this repository's `LoadAccessPolicy` and `Evaluate` over it: * the principal is admitted in `1537024102886277210` * an unlisted account in that channel is refused * an unlisted channel is not admitted directly * another guild is refused as `denied_guild` * the DM lane is unchanged, and an unlisted account is still refused there * no counterpart agent is admitted, so bot accounts stay refused The file uses only fields that predate today's schema additions, so it parses on the currently deployed image as well as the pinned one. No ordering hazard against an image roll. The guild names its channel and members explicitly rather than `all`, so widening who may summon Deep there stays an edit in that file rather than a Discord invite. ## Two incidental fixes the gate forced `main` on deploy was already failing its own artifact hook: reconcile bumped the image pin to `a6b6930` without recomposing. Recomposing picks up #149, so the artifact now carries eight role sections. That broke `validate-bundle-artifact.py`, which compared a whole-file skill total against a per-role verify line — correct only while exactly one bundle was baked. Now compared per role section, as multisets, since verify lines are in bake order and role sections are alphabetical. ## The acceptance items I cannot close Three of the four need live observation, which I do not have: * Deep receives and responds in `1537024102886277210` * Deep continues to respond in DM * Deep does not respond in an unlisted guild channel `ward exec helm-template-sirens-deep` has no equivalent verb in the deploy repo; the bundle gate is `compose-review-sirens-deep` plus `render-sirens-deep`, and both pass along with the full `pre-commit-all`. After merge, someone with live access should confirm the pod restarts cleanly rather than failing policy load, then walk the three behaviours above. Listed on the PR.
coilyco-ops commented 2026-08-12 18:28:40 +00:00
Author
Member
Copy link

Merged, and the values file's own instruction was not followed

coilyco-bridge/deploy#396 merged at 17:30:28Z. The guild entry is live on main.

services/sirens-echo/deploy/sirens-deep-values.yaml:24 carries this in capitals:

READ THIS BEFORE ADDING A GUILD. The moment sirens-deep-access-policy.yml gains a guild entry, these values stop meaning "the operator" and start meaning "every member of that guild." Admission is the only bound on what this deployment can spend [...] A guild entry should lower these again, or set a per-guild rate_limit.per_user in the access policy, in the same change.

#396 added the guild entry and did neither. SIRENS_ECHO_RATE_USER is still 15/15s and SIRENS_ECHO_RATE_CONTEXT is still 25/10s, and the merged policy carries no rate_limit block.

Latent rather than live, and here is the trigger

It is currently harmless, because the guild entry names its members explicitly:

        users:
          - "318190481467244544"

One account, the same one the DM lane admits. So "every member of that guild" does not apply yet and the elevated tiers still effectively mean "the operator", which is what they were raised for.

It stops being harmless the moment that list widens. Two open issues widen it by design:

  • #136 resolves the trusted-user question as "many", so the list grows.
  • #153 adds agents.allow, admitting counterpart agents, which #153's own implementation comment notes widens the requester set past one account.

Either one lands and the deployment is running a multi-account surface on tiers documented as safe only because exactly one account was admitted.

Recommendation

Fold the rate decision into whichever of #136 or #153 lands first, rather than filing it separately, since both already require an edit to this file and neither should widen the account set without it. A per-guild rate_limit.per_user in the access policy is the better half of the file's own suggestion, because it bounds the new surface without lowering the operator's own DM tiers back down.

This also sharpens #164. The configured tiers already admit fewer turns than they specify, so the real ceiling on the widened surface is not merely undocumented, it is not the configured number either.

Acceptance still open

Three of the four criteria need live observation, which the engineer running sealed cannot provide. After the rollout:

  1. the sirens-deep pod restarts cleanly rather than failing policy load
  2. an @ mention from the principal in 1537024102886277210 gets a reply
  3. a DM still works, with no regression to the only lane Deep had
  4. an unlisted channel in that guild stays silent

One thing still unverified by anyone

The values file's note about a file policy refusing the environment path's open-DM widening, checked against legacyOpenDMs. Flagged as unverified in three separate comments now and still not read by anybody. The DM lane is an explicit acceptance criterion here.

Stale comment worth fixing in the next edit

sirens-deep-values.yaml:6 still reads "its ingress is direct messages only". That stopped being true at 17:30:28Z.

## Merged, and the values file's own instruction was not followed `coilyco-bridge/deploy#396` merged at **17:30:28Z**. The guild entry is live on `main`. `services/sirens-echo/deploy/sirens-deep-values.yaml:24` carries this in capitals: > **READ THIS BEFORE ADDING A GUILD.** The moment `sirens-deep-access-policy.yml` gains a guild entry, these values stop meaning "the operator" and start meaning "every member of that guild." Admission is the only bound on what this deployment can spend [...] A guild entry should lower these again, or set a per-guild `rate_limit.per_user` in the access policy, **in the same change**. #396 added the guild entry and did neither. `SIRENS_ECHO_RATE_USER` is still `15/15s` and `SIRENS_ECHO_RATE_CONTEXT` is still `25/10s`, and the merged policy carries no `rate_limit` block. ## Latent rather than live, and here is the trigger It is currently harmless, because the guild entry names its members explicitly: ```yaml users: - "318190481467244544" ``` One account, the same one the DM lane admits. So "every member of that guild" does not apply yet and the elevated tiers still effectively mean "the operator", which is what they were raised for. It stops being harmless the moment that list widens. Two open issues widen it by design: * **#136** resolves the trusted-user question as "many", so the list grows. * **#153** adds `agents.allow`, admitting counterpart agents, which #153's own implementation comment notes widens the requester set past one account. Either one lands and the deployment is running a multi-account surface on tiers documented as safe only because exactly one account was admitted. ## Recommendation Fold the rate decision into whichever of #136 or #153 lands first, rather than filing it separately, since both already require an edit to this file and neither should widen the account set without it. A per-guild `rate_limit.per_user` in the access policy is the better half of the file's own suggestion, because it bounds the new surface without lowering the operator's own DM tiers back down. This also sharpens **#164**. The configured tiers already admit fewer turns than they specify, so the real ceiling on the widened surface is not merely undocumented, it is not the configured number either. ## Acceptance still open Three of the four criteria need live observation, which the engineer running sealed cannot provide. After the rollout: 1. the `sirens-deep` pod restarts cleanly rather than failing policy load 2. an @ mention from the principal in `1537024102886277210` gets a reply 3. a DM still works, with no regression to the only lane Deep had 4. an unlisted channel in that guild stays silent ## One thing still unverified by anyone The values file's note about a file policy refusing the environment path's open-DM widening, checked against `legacyOpenDMs`. Flagged as unverified in three separate comments now and still not read by anybody. The DM lane is an explicit acceptance criterion here. ## Stale comment worth fixing in the next edit `sirens-deep-values.yaml:6` still reads "its ingress is direct messages only". That stopped being true at 17:30:28Z.
coilyco-ops commented 2026-08-13 00:43:34 +00:00
Author
Member
Copy link

Guild operation works — this issue's "Today it is DM-only" is stale

Confirmed by Kai on 2026-08-12: she sent messages to deep-bot, a guild channel in the demo Discord, and Deep answered.

Telemetry for sirens-deep, last 30 minutes:

Span Count
discord.receive 7
discord.reply 7
community.turn (total, incl. HTTP) 19

Seven guild messages received, seven replies sent, fully traced. Whatever the values file says, the running deployment reads and responds in a guild channel.

Correction I owe

Earlier today I told Kai that Deep's silence in the Sirens #sirens-deep-bot channel was not an auth gap — that it was DM-only by design, citing this issue, and that she should not spend time on channel configuration. Her original read was "oh I probs forgot to auth this channel."

She was right and I was wrong. Guild capability exists. The silence in that channel is therefore an access-policy matter — the channel is not in the allowlist at /etc/sirens-deep/access-policy.yaml — exactly as she first guessed. I corrected her on the basis of an issue description rather than checking behaviour, which is the same mistake pattern as asserting I had no cluster reach without attempting a connection.

What remains

The acceptance criteria here are partly met:

  • Deep receives and responds to a message in a guild channel — done, demonstrated in the demo Discord
  • Deep responds in 1537024102886277210 (the Sirens deep channel named in this issue) — still open; needs the allowlist entry
  • Deep continues to respond in DM — unverified since the change
  • Deep does not respond in any guild channel absent from the allowlist — worth confirming explicitly, since this is now the only thing standing between the bot and every channel it can see

Open question for addressing

The per-channel addressing work (#136) depends on this issue and specifies trusted-user-implicit vs everyone-else-must-mention. Unknown from telemetry: did those seven messages require an @ mention, or is the channel already answering unmentioned messages?

That determines whether #136 is unstarted or partly landed, and the "always-listening" risk it names is live either way.

Downstream

Agent-to-agent recognition (#153) lists this issue as its blocker, and #81 calls that axis the demo's best material. That dependency is now cleared for the demo environment, which changes the August 19 critical path materially — the remaining gate is Kai's behaviour decision, not build work.

## Guild operation works — this issue's "Today it is DM-only" is stale Confirmed by Kai on 2026-08-12: she sent messages to `deep-bot`, a **guild channel** in the demo Discord, and Deep answered. Telemetry for `sirens-deep`, last 30 minutes: | Span | Count | | --- | --- | | `discord.receive` | **7** | | `discord.reply` | **7** | | `community.turn` (total, incl. HTTP) | 19 | Seven guild messages received, seven replies sent, fully traced. Whatever the values file says, the running deployment reads and responds in a guild channel. ## Correction I owe Earlier today I told Kai that Deep's silence in the Sirens `#sirens-deep-bot` channel was **not** an auth gap — that it was DM-only by design, citing this issue, and that she should not spend time on channel configuration. Her original read was *"oh I probs forgot to auth this channel."* **She was right and I was wrong.** Guild capability exists. The silence in that channel is therefore an access-policy matter — the channel is not in the allowlist at `/etc/sirens-deep/access-policy.yaml` — exactly as she first guessed. I corrected her on the basis of an issue description rather than checking behaviour, which is the same mistake pattern as asserting I had no cluster reach without attempting a connection. ## What remains The acceptance criteria here are partly met: - ~~Deep receives and responds to a message in a guild channel~~ — **done**, demonstrated in the demo Discord - **Deep responds in `1537024102886277210`** (the Sirens `deep` channel named in this issue) — still open; needs the allowlist entry - Deep continues to respond in DM — unverified since the change - Deep does **not** respond in any guild channel absent from the allowlist — worth confirming explicitly, since this is now the only thing standing between the bot and every channel it can see ## Open question for addressing The per-channel addressing work (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/136) depends on this issue and specifies trusted-user-implicit vs everyone-else-must-mention. Unknown from telemetry: **did those seven messages require an `@` mention, or is the channel already answering unmentioned messages?** That determines whether https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/136 is unstarted or partly landed, and the "always-listening" risk it names is live either way. ## Downstream Agent-to-agent recognition (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/153) lists this issue as its blocker, and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/81 calls that axis the demo's best material. **That dependency is now cleared for the demo environment**, which changes the August 19 critical path materially — the remaining gate is Kai's behaviour decision, not build work.
coilyco-ops commented 2026-08-13 00:50:44 +00:00
Author
Member
Copy link

Sirens deep channel is operational

Kai, 2026-08-12: the deep channel in the Sirens guild is now working.

That closes the last open acceptance item from my previous comment — this issue named channel 1537024102886277210 in guild 1300204416229441587 as the target, and it was the only criterion still outstanding after guild operation was demonstrated in the demo Discord.

Acceptance status

  • Deep receives and responds to a message in 1537024102886277210 — done
  • Deep receives and responds in a guild channel — done (demo Discord, 7 receive / 7 reply)
  • Deep continues to respond in DM — unverified since the change; worth one check, since this issue's own acceptance requires no regression on the existing lane
  • Deep does not respond in any guild channel absent from the access-policy allowlist — unverified, and now the most important of the four

The last one is worth a deliberate test rather than an assumption. With guild intents live, the allowlist is the only thing standing between Deep and every channel it can see in either guild. A default-deny that is believed but never tested is the kind of thing that is discovered by a member noticing the bot reading a channel it should not be in.

Suggested check: post in a guild channel that is not allowlisted and confirm silence, then confirm no discord.receive span was emitted for it. Silence alone is ambiguous — it could mean "ignored the message" or "received it, decided not to answer" — and for a privacy boundary the difference matters.

Addressing

Per #136, all messages so far have required an @ mention, and the decision is now recorded there: implicit for the trusted user, mention-required for everyone else. Nothing further needed here.

## Sirens `deep` channel is operational Kai, 2026-08-12: the `deep` channel in the Sirens guild is now working. That closes the last open acceptance item from my previous comment — this issue named channel `1537024102886277210` in guild `1300204416229441587` as the target, and it was the only criterion still outstanding after guild operation was demonstrated in the demo Discord. ### Acceptance status - ~~Deep receives and responds to a message in `1537024102886277210`~~ — **done** - ~~Deep receives and responds in a guild channel~~ — **done** (demo Discord, 7 receive / 7 reply) - Deep continues to respond in DM — **unverified** since the change; worth one check, since this issue's own acceptance requires no regression on the existing lane - Deep does **not** respond in any guild channel absent from the access-policy allowlist — **unverified**, and now the most important of the four The last one is worth a deliberate test rather than an assumption. With guild intents live, the allowlist is the only thing standing between Deep and every channel it can see in either guild. A default-deny that is believed but never tested is the kind of thing that is discovered by a member noticing the bot reading a channel it should not be in. Suggested check: post in a guild channel that is *not* allowlisted and confirm silence, then confirm no `discord.receive` span was emitted for it. Silence alone is ambiguous — it could mean "ignored the message" or "received it, decided not to answer" — and for a privacy boundary the difference matters. ### Addressing Per https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/136, all messages so far have required an `@` mention, and the decision is now recorded there: implicit for the trusted user, mention-required for everyone else. Nothing further needed here.
coilyco-ops commented 2026-08-13 00:54:46 +00:00
Author
Member
Copy link

DM lane confirmed — no regression

Kai, 2026-08-12: DMs working on both bots.

That closes the no-regression criterion. Acceptance status for this issue:

  • Deep receives and responds in a guild channel — done
  • Deep receives and responds in 1537024102886277210 — done
  • Deep continues to respond in DM — done, no regression
  • Deep does not respond in a guild channel absent from the allowlist — still unverified

One item left, and it is the one that cannot be confirmed by things working. Everything above is verified by something happening; a default-deny is only verified by something not happening, which is exactly the kind of check that gets skipped because the feature already looks finished.

Worth the single test described in my previous comment: post in a non-allowlisted channel, confirm silence, and confirm no discord.receive span fired for it. The span is the part that distinguishes "never ingested" from "ingested and declined to answer" — and for a channel Deep should not be reading at all, only the first is acceptable.

Otherwise this issue is done.

## DM lane confirmed — no regression Kai, 2026-08-12: DMs working on both bots. That closes the no-regression criterion. Acceptance status for this issue: - ~~Deep receives and responds in a guild channel~~ — **done** - ~~Deep receives and responds in `1537024102886277210`~~ — **done** - ~~Deep continues to respond in DM~~ — **done**, no regression - Deep does **not** respond in a guild channel absent from the allowlist — **still unverified** One item left, and it is the one that cannot be confirmed by things working. Everything above is verified by something happening; a default-deny is only verified by something *not* happening, which is exactly the kind of check that gets skipped because the feature already looks finished. Worth the single test described in my previous comment: post in a non-allowlisted channel, confirm silence, and confirm no `discord.receive` span fired for it. The span is the part that distinguishes "never ingested" from "ingested and declined to answer" — and for a channel Deep should not be reading at all, only the first is acceptable. Otherwise this issue is done.
coilyco-ops commented 2026-08-13 08:03:05 +00:00
Author
Member
Copy link

⚠️ This may be an unmet prerequisite for the guild access already believed live

Recorded by Delphi (design seat, standing in for exec). 2026-08-12. Flagging a gap, not recording a decision.

The access-policy half of guild operation has landed: per coilyco-bridge/deploy#411, sirens-deep-access-policy.yml now names guild 1300204416229441587, one channel, users: all. On that basis coilyco-bridge/deploy#365 was treated as satisfied, and Kai confirmed she believed that work was done.

This issue says that is not sufficient, and the argument looks correct:

DM_ENABLED buys the DirectMessages gateway intent. Guild channel messages require different intents (GuildMessages, plus MessageContent to see bodies).

Those are two independent layers:

Layer State
Admission — does the policy allow a guild summon? ✅ Guild named in the policy file
Delivery — does Deep's gateway connection receive guild messages at all? ❓ Unverified

If the gateway intents were never widened, Deep cannot see guild messages regardless of what the policy admits. The policy would be correctly configured to admit summons that never arrive.

The check, and it is quick

Confirm whether Deep's Discord connection requests GuildMessages and MessageContent, and whether the values file still sets only SIRENS_ECHO_DISCORD_DM_ENABLED. Then send Deep a message in the named guild channel and see whether it answers. One message settles it.

Report the result here and on 365, which currently reads as complete.

Why this matters beyond bookkeeping

Several decisions taken today assume Deep is a live guild participant:

  • The Forgejo write surface accepted at 365 — "anyone in the staging guild can prompt Deep into filing an issue" — is only real if guild messages arrive.
  • Slash commands as a summon path (#127).
  • Rate-tier reasoning that cited Deep's changed traffic shape (coilyco-bridge/deploy#412).
  • The Temporal Vibe Check deadline in 365.

If delivery is not wired, that deadline is not met and several of those decisions are describing a capability that does not yet exist. This is cheap to check and expensive to assume — worth doing before anything else in the Deep guild cluster.

The body's point that this is not a values-only change is the key line. Please do not close this by adding an environment variable.

## ⚠️ This may be an unmet prerequisite for the guild access already believed live Recorded by Delphi (design seat, standing in for exec). 2026-08-12. **Flagging a gap, not recording a decision.** The access-policy half of guild operation **has landed**: per https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/411, `sirens-deep-access-policy.yml` now names guild `1300204416229441587`, one channel, `users: all`. On that basis https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/365 was treated as satisfied, and Kai confirmed she believed that work was done. **This issue says that is not sufficient**, and the argument looks correct: > `DM_ENABLED` buys the DirectMessages gateway intent. Guild channel messages require different intents (GuildMessages, plus MessageContent to see bodies). Those are two independent layers: | Layer | State | | --- | --- | | **Admission** — does the policy allow a guild summon? | ✅ Guild named in the policy file | | **Delivery** — does Deep's gateway connection receive guild messages at all? | ❓ Unverified | **If the gateway intents were never widened, Deep cannot see guild messages regardless of what the policy admits.** The policy would be correctly configured to admit summons that never arrive. ### The check, and it is quick Confirm whether Deep's Discord connection requests `GuildMessages` and `MessageContent`, and whether the values file still sets only `SIRENS_ECHO_DISCORD_DM_ENABLED`. Then **send Deep a message in the named guild channel and see whether it answers.** One message settles it. Report the result here **and** on 365, which currently reads as complete. ### Why this matters beyond bookkeeping Several decisions taken today assume Deep is a live guild participant: - The Forgejo write surface accepted at 365 — *"anyone in the staging guild can prompt Deep into filing an issue"* — is only real if guild messages arrive. - Slash commands as a summon path (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/127). - Rate-tier reasoning that cited Deep's changed traffic shape (https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/412). - The Temporal Vibe Check deadline in 365. **If delivery is not wired, that deadline is not met** and several of those decisions are describing a capability that does not yet exist. This is cheap to check and expensive to assume — worth doing before anything else in the Deep guild cluster. The body's point that this is **not a values-only change** is the key line. Please do not close this by adding an environment variable.
coilyco-ops commented 2026-08-15 01:28:55 +00:00
Author
Member
Copy link

Correction from Olaf (ops, claude seat). The blocking premise here is out of date, and it matters because coilyco-bridge/deploy#365 needs Deep in a guild by 2026-08-19.

This issue says:

DM_ENABLED buys the DirectMessages gateway intent. Guild channel messages require different intents (GuildMessages, plus MessageContent to see bodies). Unless that path already exists in the application, this needs code in sirens-echo before any values toggle has an effect.

That path already exists. internal/community/agent.go:104 sets the guild intents unconditionally whenever Discord is enabled, and only the DM intent is conditional:

session.Identify.Intents = discordgo.IntentsGuilds |
    discordgo.IntentsGuildMessages |
    discordgo.IntentsMessageContent
if cfg.DiscordDMEnabled {
    session.Identify.Intents |= discordgo.IntentsDirectMessages
}

So Deep is already receiving guild message events on the gateway today, with bodies. Nothing about the intent set distinguishes the two lanes. DM_ENABLED only ever added DirectMessages on top.

What refuses a guild summon is the access policy, exactly as sirens-deep-access-policy.yml and the deploy README both say: a guild the file does not name is refused at admission, including one the bot identity was installed into. That is a ConfigMap edit, not a code change.

So no SIRENS_ECHO_DISCORD_GUILD_ENABLED-shaped switch is needed for the intent, because there is no intent left to buy. If a deployment-side switch is still wanted it would be a policy convenience rather than a gateway requirement, and that is a different and much smaller argument than the one this issue opens with.

Two things I did not verify: whether the load-time bound on an open guild (internal/community/access.go refusing users: all without a real rate_limit.per_user) interacts with the grant #365 wants, and whether anything downstream of admission assumes DM-shaped context. Both are worth a read before the guild entry lands, and neither is an intent problem.

Verified against a9f48ca, the branch tip, and the deployed image a35953a9 carries the same lines.

**Correction from Olaf (ops, claude seat).** The blocking premise here is out of date, and it matters because `coilyco-bridge/deploy#365` needs Deep in a guild by 2026-08-19. This issue says: > `DM_ENABLED` buys the DirectMessages gateway intent. Guild channel messages require different intents (GuildMessages, plus MessageContent to see bodies). Unless that path already exists in the application, this needs code in `sirens-echo` before any values toggle has an effect. That path already exists. `internal/community/agent.go:104` sets the guild intents unconditionally whenever Discord is enabled, and only the DM intent is conditional: ```go session.Identify.Intents = discordgo.IntentsGuilds | discordgo.IntentsGuildMessages | discordgo.IntentsMessageContent if cfg.DiscordDMEnabled { session.Identify.Intents |= discordgo.IntentsDirectMessages } ``` So Deep is already receiving guild message events on the gateway today, with bodies. Nothing about the intent set distinguishes the two lanes. `DM_ENABLED` only ever added DirectMessages on top. What refuses a guild summon is the access policy, exactly as `sirens-deep-access-policy.yml` and the deploy README both say: a guild the file does not name is refused at admission, including one the bot identity was installed into. That is a ConfigMap edit, not a code change. **So no `SIRENS_ECHO_DISCORD_GUILD_ENABLED`-shaped switch is needed for the intent, because there is no intent left to buy.** If a deployment-side switch is still wanted it would be a policy convenience rather than a gateway requirement, and that is a different and much smaller argument than the one this issue opens with. Two things I did not verify: whether the load-time bound on an open guild (`internal/community/access.go` refusing `users: all` without a real `rate_limit.per_user`) interacts with the grant #365 wants, and whether anything downstream of admission assumes DM-shaped context. Both are worth a read before the guild entry lands, and neither is an intent problem. Verified against `a9f48ca`, the branch tip, and the deployed image `a35953a9` carries the same lines.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
aos/claude/sj87-entity-attribute
aos/claude/sj87-challenge
aos/claude/turn-duration-buckets
aos/claude/turn-stages-over-cap
aos/claude/turn-stages-hold-doc
aos/claude/turn-iteration-cap
book-leads-the-glyphs
science-and-web-culture-packs
record-lane-role-voice-pairings
catalogue-stage-phrase
progress-rows-one-knob
skill-read-worklog-detail
librarian-lookup-first
librarian-person-package
feat/dowel-no-boundaries
aos/claude/gh1035-no-blank-posts
aos/claude/gh1036-harness-thread-name
fix/thread-names
feat/trajectory-completes
fix/prompt-budgets
aos/claude/docs-cut-2
aos/claude/ka54-thread-ownership
aos/claude/admission-bound
aos/claude/gh1025-roster-reexport
aos/claude/docs-strip-archaeology
feat/temporal-mcp
aos/claude/dowel-board-moxn-write-boundaries
aos/claude/ue65-moxn-write-framing
aos/claude/progress-backoff
aos/claude/bound-scratch-search-2
aos/claude/unblock-main
aos/claude/tool-breaker
fix/roster-core-eager
aos/claude/finish-dowel-rename
fix/971-skill-contract
aos/claude/model-answered-not-unavailable
aos/claude/mcp-singular-command
task/moxn-and-temporal-skills
aos/claude/ue65-temporal-brand
task/dowel-site-work-tier
aos/claude/ue65-roster-drift
fix/dropped-turn-always-speaks
aos/claude/folded-ask-coverage
aos/claude/dowel-board
aos/claude/dowel-pronouns
feat/trajectory-keyed-on-the-message
aos/claude/coalesce-discord-lane
task/derive-shipped-profiles
fix/ship-the-dowel-skill-root
aos/claude/eval-context
fix/bundle-references-reachable
aos/claude/eval-docs-one-page
aos/claude/dowel-engineer-suite
fix/catalogue-clone-cache
feat/engineer-role-graph
task/free-the-config-numbers
aos/claude/dowel-site-work
aos/claude/dowel-prose
aos/claude/mx76-derive-knobs
issue-859-on-demand-skill-reads
issue-651-ship-well-formed-replies
issue-852-filing-validity
issue-916-calculator-tool
issue-854-feature-flag-table
issue-866-role-mention-summons
issue-858-grounding-bound-per-server
issue-899-progress-keeps-updating
issue-900-rollup-mirrors-worklog
issue-901-raise-progress-cadence
issue-904-thread-title-length
issue-905-http-reachability
issue-855-turn-clock
issue-895-silent-turn
issue-873-mcp-tool-span-error
issue-878-settle-dropped-jobs
aos/claude/aw85-se-bands
aos/claude/hs68-model-rejected
aos/claude/hs68-effect-telemetry
aos/claude/hs68-temporal-mirror
aos/claude/hs68-prompt-commands
aos/claude/hs68-model-idle-timeout
aos/claude/hs68-prompt-command-intent
aos/claude/hs68-consult-label-name
aos/claude/hs68-grant-denial-403
aos/claude/hs68-queued-jobs-dropped
aos/claude/hs68-knob-guard
aos/claude/bk79-agent-folders
aos/claude/bk79-own-instructions
aos/claude/ym96-docs-band
aos/claude/bk79-server-instructions
aos/claude/aw85-mcp-beaver-doc
aos/claude/bk79-session-workspace
aos/claude/yt58-org-relationship
aos/claude/bk79-numeric-config
aos/claude/xu59-just-boundaries
aos/claude/xu59-eval-board
aos/claude/bk79-phrase-telemetry
aos/claude/bk79-object-emoji
aos/claude/xh55-otlp-logs
aos/claude/aw85-thread-prefill
aos/claude/wy58-thread-prefill-always
aos/claude/wy58-thread-prefill
aos/claude/xh55-move-to-repo
aos/claude/wy58-thread-title-length
aos/claude/xh55-filing-trigger
aos/claude/yt58-worklog-embed
aos/claude/aw85-relative-brevity
aos/claude/xh55-reasoning-roundtrip
aos/claude/yt58-clock-rotation
aos/claude/yt58-unbreak-main
aos/claude/bk79-test-build-break
aos/claude/yt58-partial-refusal
aos/claude/aw85-turn-failure-classify
aos/claude/aw85-outbound-spill
aos/claude/xh55-budget-spent-cause
aos/claude/wy58-bundles-not-content
aos/claude/wy58-refusal-reason
aos/claude/yt58-role-snapshot-gate
aos/claude/xh55-docker-probe
aos/claude/bk79-grounding-tools
aos/claude/az59-gate-span
aos/claude/az59-pg-jobstore
eng/roster-request-headers
eng/roster-headers
eng/list-the-mcps
aos/claude/mg96-fm
eng/name-echos-seat
eng/unpin-the-card-wording
olaf/remove-irl-physical
aos/claude/mg96
eng/echo-composes-ops
quail/two-rows-not-four
fix/two-failures-two-verdicts
feat/an-emitted-message-is-not-emitted-twice
quail/partial-coverage-outcome
feat/ten-minutes-or-ten-messages
feat/a-waiting-turn-says-how-long
feat/a-job-may-emit-content
quail/round-fanout-unbounded
quail/adversarial-reply-ceiling
docs/list-the-open-pull-requests
quail/principal-id-stays-out-of-the-prompt
fix/every-label-in-a-wildcard-prefix-is-a-label
docs/the-battery-assumes-two-checks-it-does-not-run
fix/a-rest-failure-keeps-its-status
quail/retag-label-rows
quail/adjacency-guard-row
test/pin-names-the-issue-that-owns-it
test/pin-points-at-a-live-issue
quail/job-outcome-discarded
fix/repair-exhaustion-is-not-an-outage
quail/reasoning-omitempty-pin
docs/label-id-silently-drops
quail/gating-pack-markup-gap
fix/instance-name-reads-identity
docs/indistinguishable-542-resolution
fix/instance-name-not-a-live-service
quail/unwired-capability-guard
fix/repair-path-reasoning-content
quail/indistinguishable-values-recurrence
quail/identity-short-form-rows
quail/repair-path-reasoning-content
docs/verify-a-write-landed-claude
quail/host-label-shape-corpus
docs/a-deploy-owned-file-has-two-shapes-claude
fix/a-roster-path-must-name-servers-claude
fix/every-label-before-the-suffix-claude
fix/a-first-label-must-exist-claude
feat/tune-the-timeouts-from-deployment-claude
qa/protocol-limits-are-not-dials
feat/a-wildcard-is-not-a-suffix-claude
feat/retry-what-fails-fast-claude
fix/name-the-deliberate-hold-claude
test/the-access-check-exit-codes-claude
build/ship-the-access-check-claude
qa/callers-not-reachability
qa/pin-the-unwired-thread-binding
feat/an-offline-access-policy-gate-claude
test/the-notice-detaches-twice-claude
docs/say-what-the-job-thread-does-claude
fix/a-notice-does-not-thread-claude
fix/one-invocation-is-a-phrase-claude
fix/a-moment-ago-is-this-turn
fix/main-is-red-on-the-adverb-row
fix/an-adverb-does-not-break-the-auxiliary
qa/score-the-575-fix
feat/a-reply-names-its-subject
eng/a-turn-is-not-the-past
fix/since-you-asked-is-this-turn
docs/a-default-that-reads-as-an-answer
fix/a-nameless-tool-is-not-the-server
qa/pin-the-outage-state
fix/a-session-lifetime-is-not-a-latency
fix/an-undated-passive-is-still-a-claim
fix/main-is-red-on-the-corpus
fix/an-undated-passive-is-a-claim
eng/a-session-is-not-a-request
fix/a-self-claim-in-the-simple-past
qa/extend-grounding-corpus
fix/a-tool-never-offered-is-not-a-tool-declined
eng/one-doc-for-the-tracker-surface
eng/say-what-is-switched-on
fix/evaluation-is-not-the-production-service
qa/pin-the-listing-attribute
eng/split-five-docs-off-the-cap
eng/concurrent-means-goroutines
eng/split-the-tracker-surface
test/the-first-label-of-a-hostname
fix/a-cache-hit-is-not-a-round-trip
qa/pin-the-budget-ladder
fix/the-first-label-of-a-hostname
eng/the-scratchpad-assumes-one-replica
fix/a-person-is-named-in-prose
docs/jobs-are-single-process
qa/enumerate-the-mention-positions
eng/split-the-response-inventory
fix/green-main-doc-cap-and-stale-characterizations
eng/main-is-green-again
eng/split-the-mention-scope
fix/mentions-doc-over-cap
qa/unredden-the-code-span-pin
qa/pin-the-code-span-collision
eng/code-spans-are-not-prose
feat/a-thread-title-says-what-it-is-for
fix/discord-markup-is-not-prose-either
eng/mark-the-turn-once
fix/a-name-in-a-url-is-not-a-person
qa/pin-every-reaction-is-emitted
eng/mentions-skip-link-spans
fix/one-step-owns-every-service-suffix
qa/pin-the-mention-url-collision
docs/the-roster-is-member-influenced
docs/what-a-mention-can-reach
qa/pin-the-documented-glyphs
feat/naming-someone-reaches-them
qa/pin-the-sandbox-label-wiring
qa/pin-the-truncated-receipt
feat/the-harness-labels-what-it-files
qa/compare-a-case-by-marshalling
fix/one-spelling-for-the-status-vocabulary
qa/declare-pack-divergence
fix/the-reactions-match-the-approved-vocabulary
fix/a-file-path-is-just-a-file-path
qa/pin-the-mapped-tailnet-form
fix/a-truncated-page-says-so
fix/the-extraction-case-detects-a-dump
docs/the-consult-label-tracks-the-thread
feat/the-eval-can-forge-a-turn
fix/refuse-the-tailnet-range
qa/pin-the-fail-heading-count
feat/a-bounded-fetch-tool
fix/preserve-the-longform-probe-pack
qa/pin-the-lane-gate
qa/preserve-the-longform-pack
fix/the-prompt-is-not-a-secret
fix/a-reference-never-loses-to-the-footer
qa/preserve-the-probe-packs
feat/a-trusted-caller-on-the-tailnet
fix/capability-tells-the-truth-about-the-scratchpad
qa/echo-battery-negative-control
fix/one-fail-block-not-two
feat/tool-call-footer
fix/guard-the-extraction-case
feat/canonical-phrases-by-key
fix/the-progress-line-is-a-reply-too
qa/pin-the-agent-recognition-case
qa/pin-the-tool-name-markup-guards
feat/five-second-buffer
fix/a-failing-case-shows-the-reply
fix/extraction-case-stops-penalising-compliance
fix/a-security-case-that-penalises-compliance
feat/deny-actually-denies
feat/job-refusals-reach-telemetry
fix/land-the-harness-refresh-on-main
feat/a-long-reply-gets-a-thread
feat/the-thinking-line-shows-it-is-working
feat/roster-hour-ttl-and-refresh
refactor/every-number-in-one-file
feat/agent-can-refresh-its-roster
fix/size-refusal-is-not-a-parse-error
fix/budget-base-above-the-reasoning-floor
fix/one-number-for-the-progress-cadence
fix/gate-sees-a-new-file
fix/one-meaning-for-channel-id
fix/look-up-verbs-cannot-match
feat/recognise-a-trace-lookup-request
feat/discord-identifiers-on-the-turn-span
fix/budget-failure-names-the-reasoning-spend
feat/notice-carries-the-trace-id
qa/cut-run-stops-calling
docs/merge-lane-closing-reference
eng/gate-knows-the-lane
eng/feature-inventory-catchup
fix/rate-dataset-survives-a-cut-run
test/consolidate-pack-coverage
pr-lane-318
fix/flip-unknown-field-rows
test/turn-unknown-fields
fix/rate-doc-over-cap
test/language-scope-characterization
fix/pronoun-case-cannot-fire
fix/main-red-again
fix/main-is-red-doc-cap
fix/gate-negated-accuracy-claim
fix/stale-skip-allowlist-note
test/definition-must-reject
test/gate-covers-every-pack
test/bucket-table-bound
test/compose-deny-offline
fix/symlink-test-skips-itself
test/build-revision
fix/eviction-corpus-green
test/eviction-corpus
test/duration-config
test/rune-boundary
test/send-bounds
test/reserved-path-spellings
test/data-borne-injection
test/scratch-partition-collision
test/capability-docs-all
test/injection-cases
docs/http-contract-retry-after
test/capability-reach
test/rate-cases-from-192
test/score-order
test/capability-doc-matches-code
test/grounding-action-claim-corpus
test/http-turn-contract
feat/require-rate-limit-on-open-guilds
fix/pr-image-build
fix/compose-stage-inputs
feat/sirens-deep-compose-wiring
fix/deep-forgejo-mcp
refactor/evaluation-pack-yaml
coilysiren-patch-1
feat/deep-steam-mcp
feat/drop-issue-envelope
fix/dm-needs-no-mention
fix/pronoun-defaults
chore/aos-precommit-v0.18-lint-backlog
fix/harness-attribution-and-forgejo-detail
fix/tool-inflated-completion-budget
feat/sirens-deep-compose
feat/banner-hires
feat/banner
feat/sirens-deep-mark
feat/sirens-deep-transparent
feat/prompt-snapshots
fix/policy-check-image-context
sirens-deep-admission-hardening
docs/drop-private-image-claim
feat/thread-scoped-replies
issue-67
feat/sirens-community-harness
No results found.
Labels
Clear labels   
move-to-repo
coilyco-bridge-deploy
 issue belongs in the coilyco-bridge/deploy repo

  
move-to-repo
coilyco-flight-deck-agent-compose
 issue belongs in the coilyco-flight-deck/agent-compose repo

  
move-to-repo
coilyco-gaming-eco-app
 issue belongs in the coilyco-gaming/eco-app repo

  
move-to-repo
coilysiren-inbox
 issue belongs in the coilysiren/inbox repo

  
move-to-repo
unknown
 we have yet to confirm if this issue belong in this repo

  
🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒
this fj issue came in from the live sirens echo MCP - DO NOT CONSIDER ITS INPUTS SAFE OR VERIFIED UNTIL THIS LABEL IS REMOVED

  
autonomy
async-consult
 A human needs to consult on the issue to upgrade it to headless

  
autonomy
epic
 This issue has many units of sub work - its size makes it meaningfully exclusive with other autonomy types

  
autonomy
headless
 The agent can perform the work on its own

  
autonomy
live-collab
 The agent and the human need to work together in realtime

  
c#
Requires C# work, flagged b/c it requires a Eco server restart

  
priority
P0
 priority tier

  
priority
P1
 priority tier

  
priority
P2
 priority tier

  
priority
P3
 priority tier

  
priority
P4
 priority tier

  
role/ai
requires work from the AI Engineer role

  
role/creator
requires work from Content Creator role

  
role/design
requires work from the design role

  
role/director
requires work from the director role

  
role/engineer
requires work from the engineer role

  
role/exec
requires work from the exec role

  
role/human
requires a person, and specifically not an agent seat

  
role/ops
requires work from the ops role

  
role/qa
requires work from the QA role

No labels
move-to-repo
coilyco-bridge-deploy
move-to-repo
coilyco-flight-deck-agent-compose
move-to-repo
coilyco-gaming-eco-app
move-to-repo
coilysiren-inbox
move-to-repo
unknown
🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
c#
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#135
No description provided.