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

the agent should respond to replies #205

New issue
Closed
opened 2026-08-12 23:22:25 +00:00 by coilysiren · 7 comments
coilysiren commented 2026-08-12 23:22:25 +00:00
Owner
Copy link
No description provided.
coilyco-ops commented 2026-08-13 03:45:48 +00:00
Member
Copy link

CLAIM — Angie (ENG) at 2026-08-13T03:47Z, 20 minute hold. Paired with #212 because both are the same summon predicate.

The issue body is empty, so I am reading the title literally: a member replying to one of Echo's messages should be treated as addressing Echo, without needing an explicit mention.

Early read of internal/community/agent.go is that this already works, by two paths:

  • summonedLocally returns summoned when message.ReferencedMessage.Author.ID is the bot's own ID, straight off the Gateway payload with no API call.
  • when the payload carries a MessageReference but no resolved ReferencedMessage, it defers to summonedByReference, which fetches the referenced message and compares the author. That path is rate limited through the lookup admission gate.

If that holds up, the honest outcome here is a regression test plus a note on what the observed failure actually was, not a code change. A reply that did not get answered would then have been stopped by something else, most likely channel scope, access policy, or admission, and I would rather find that than declare this shipped.

Reporting either way.

**CLAIM — Angie (ENG)** at 2026-08-13T03:47Z, 20 minute hold. Paired with https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/212 because both are the same summon predicate. The issue body is empty, so I am reading the title literally: a member replying to one of Echo's messages should be treated as addressing Echo, without needing an explicit mention. Early read of `internal/community/agent.go` is that this already works, by two paths: - `summonedLocally` returns summoned when `message.ReferencedMessage.Author.ID` is the bot's own ID, straight off the Gateway payload with no API call. - when the payload carries a `MessageReference` but no resolved `ReferencedMessage`, it defers to `summonedByReference`, which fetches the referenced message and compares the author. That path is rate limited through the lookup admission gate. If that holds up, the honest outcome here is a regression test plus a note on what the observed failure actually was, not a code change. A reply that did not get answered would then have been stopped by something else, most likely channel scope, access policy, or admission, and I would rather find that than declare this shipped. Reporting either way.
coilyco-ops commented 2026-08-13 03:50:02 +00:00
Member
Copy link

VERIFIED ALREADY WORKING — Angie (ENG). No code change, and I want to be plain that this is a finding rather than a fix.

Replies already summon. I asserted the behavior against the unmodified code and all three cases pass:

  • a reply to one of this service's own messages summons, read straight off the Gateway payload with no API call
  • a reply aimed at another member does not summon
  • a reply whose payload carries only a reference id defers to a lookup that compares the author, and that lookup goes through the admission gate so a busy channel cannot turn replies into a stream of API calls

Those assertions are now committed in internal/community/agent_test.go as part of 8669f09, so the behavior is pinned rather than merely observed today.

So if a reply went unanswered in practice, the summon predicate was not the cause. The likely candidates, in the order the runtime applies them:

  1. channel scope. Echo answers in its configured channel, and a reply in another channel is dropped before summoning is considered.
  2. access policy, on guild, channel, user, or role.
  3. the exchange limiter, if the reply came from another bot.
  4. admission and rate limiting, which returns a cooldown notice rather than an answer.
  5. the duplicate gate, if the message id had already been handled.

Each of those records a distinct reason through RecordAccess or RecordAdmission, so a specific unanswered reply is diagnosable from telemetry rather than by guessing.

Closing as already shipped, now with regression coverage. Please reopen with the channel and rough timestamp if you have a concrete reply that went unanswered — that would be a real defect in one of the five gates above, and worth chasing with the actual reason code rather than re-examining the reply path.

**VERIFIED ALREADY WORKING — Angie (ENG).** No code change, and I want to be plain that this is a finding rather than a fix. Replies already summon. I asserted the behavior against the unmodified code and all three cases pass: - a reply to one of this service's own messages summons, read straight off the Gateway payload with no API call - a reply aimed at another member does not summon - a reply whose payload carries only a reference id defers to a lookup that compares the author, and that lookup goes through the admission gate so a busy channel cannot turn replies into a stream of API calls Those assertions are now committed in `internal/community/agent_test.go` as part of `8669f09`, so the behavior is pinned rather than merely observed today. **So if a reply went unanswered in practice, the summon predicate was not the cause.** The likely candidates, in the order the runtime applies them: 1. channel scope. Echo answers in its configured channel, and a reply in another channel is dropped before summoning is considered. 2. access policy, on guild, channel, user, or role. 3. the exchange limiter, if the reply came from another bot. 4. admission and rate limiting, which returns a cooldown notice rather than an answer. 5. the duplicate gate, if the message id had already been handled. Each of those records a distinct reason through `RecordAccess` or `RecordAdmission`, so a specific unanswered reply is diagnosable from telemetry rather than by guessing. Closing as already shipped, now with regression coverage. **Please reopen with the channel and rough timestamp if you have a concrete reply that went unanswered** — that would be a real defect in one of the five gates above, and worth chasing with the actual reason code rather than re-examining the reply path.
coilyco-ops commented 2026-08-13 04:04:11 +00:00
Member
Copy link

Design decision — trigger surfaces (anchor)

Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-12. Anchor for the trigger-surface cluster: #212.

Decided — all four surfaces ship

  1. Direct @-mention — current baseline.
  2. Replies to Echo's messages — this issue. A user replying to Echo gets an answer without re-mentioning it.
  3. Edits that add a mention — #212.
  4. Unmentioned thread follow-ups — inside a thread Echo is already part of, it answers with no mention at all.

Kai took the whole set, including the most permissive option. Echo becomes a conversational participant rather than a summoned tool.

⚠️ Loop risk — must be designed for before surface 4 ships

Surface 4 removes the mention requirement, which is currently the only thing guaranteeing a human meant to talk to Echo. Two failure modes follow directly:

  • Echo replying to itself. Its own thread messages are thread messages.
  • Bot-to-bot loops. There is a translator bot in these channels (#198). Echo speaks, translator bot translates, Echo sees an unmentioned thread message and answers, translator bot translates that. Nothing in the four surfaces above stops this, and it runs until someone notices.

Requirements: Echo never responds to its own messages. Echo does not respond to other bots on the unmentioned-follow-up surface — a bot must @-mention Echo explicitly to get a reply. A per-thread reply-rate ceiling is strongly advised as a backstop.

Whoever implements surface 4 owns these guards. Shipping it without them is how a community channel becomes unusable at 3am, and unlike most defects here it degrades other people's space rather than just Echo's output quality.

Interaction with persistence

Surface 4 makes the context model load-bearing: with no mention, the in-window history is the only thing telling Echo whether a message is even for it. See the hybrid model in #194.

Sequencing suggestion

Surfaces 2 and 3 are low-risk and independently shippable. Surface 4 needs the guards above. Do not bundle them into one change — a good early pickup is 2 and 3 alone.

## Design decision — trigger surfaces (anchor) Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-12. Anchor for the trigger-surface cluster: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/212. ### Decided — all four surfaces ship 1. **Direct @-mention** — current baseline. 2. **Replies to Echo's messages** — this issue. A user replying to Echo gets an answer without re-mentioning it. 3. **Edits that add a mention** — https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/212. 4. **Unmentioned thread follow-ups** — inside a thread Echo is already part of, it answers with no mention at all. Kai took the whole set, including the most permissive option. Echo becomes a conversational participant rather than a summoned tool. ### ⚠️ Loop risk — must be designed for before surface 4 ships Surface 4 removes the mention requirement, which is currently the only thing guaranteeing a human meant to talk to Echo. Two failure modes follow directly: - **Echo replying to itself.** Its own thread messages are thread messages. - **Bot-to-bot loops.** There is a translator bot in these channels (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/198). Echo speaks, translator bot translates, Echo sees an unmentioned thread message and answers, translator bot translates that. Nothing in the four surfaces above stops this, and it runs until someone notices. **Requirements:** Echo never responds to its own messages. Echo does not respond to other bots on the unmentioned-follow-up surface — a bot must @-mention Echo explicitly to get a reply. A per-thread reply-rate ceiling is strongly advised as a backstop. Whoever implements surface 4 owns these guards. Shipping it without them is how a community channel becomes unusable at 3am, and unlike most defects here it degrades other people's space rather than just Echo's output quality. ### Interaction with persistence Surface 4 makes the context model load-bearing: with no mention, the in-window history is the only thing telling Echo whether a message is even for it. See the hybrid model in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/194. ### Sequencing suggestion Surfaces 2 and 3 are low-risk and independently shippable. Surface 4 needs the guards above. Do not bundle them into one change — a good early pickup is 2 and 3 alone.
coilysiren commented 2026-08-13 04:04:50 +00:00
Author
Owner
Copy link

reopening to double check delphi's clarification was addressed

especially the ⚠️ Loop risk

reopening to double check delphi's clarification was addressed especially the `⚠️ Loop risk`
coilyco-ops commented 2026-08-13 04:24:57 +00:00
Member
Copy link

Answering the reopen — Angie (ENG). Delphi's loop-risk requirements, checked against the code rather than asserted.

Short answer: all three guards exist and already cover surfaces 2 and 3. Surface 4 is not implemented, so its risk is not live.

Delphi's requirement Where it lives Status
Echo never responds to its own messages eligibleMessage, agent.go — rejects when message.Author.ID == session.State.User.ID holds
A bot must @-mention Echo explicitly to get a reply eligibleMessage — rejects message.Author.Bot unless policy.PermitsAgent(message.Author.ID), an explicit deployment allowlist holds, and stricter than asked
Per-thread reply-rate ceiling exchangeLimiter, counterpart.go — max 4 consecutive agent-authored turns per channel in a 10 minute window holds

Two details worth having, since they answer the requirement more exactly than the summary does.

The bot guard is stricter than "must @-mention". A bot that is not on the agents.allow list is dropped at eligibility, before summoning is even considered, so it cannot reach Echo by mentioning it either. The translator bot on #198 gets no reply from Echo on any surface unless someone deliberately allowlists it. That is the guard Delphi asked for, applied one step earlier than requested.

The ceiling is already per-thread. A Discord thread carries its own channel ID, and exchangeLimiter keys on channel ID, so "per channel" and "per thread" are the same bound here. It also resets on any human-authored turn, which is the right shape: a person joining ends the run rather than being counted against it. The counter refreshes its timestamp while a pair keeps trying, so a bot pair cannot wait out the window mid-exchange and resume.

Surface 3, edits, inherits all of this rather than bypassing it. onMessageEdit runs its three edit-specific gates and then calls the same admitMessage path a new message uses, in the same order: eligibility, exchange limiter, access policy, admission, summon, duplicate. I deliberately did not give edits their own path, which is why there is nothing separate to audit here.

What is genuinely not covered. Surface 4, unmentioned thread follow-ups, is not implemented. It is tracked as #239 and it is the one that removes the mention requirement, so it is where Delphi's warning actually bites. The three guards above are necessary for it but I would not call them sufficient without looking at it properly, because surface 4 also lets a human thread message with no mention pull Echo in, and none of the guards above bound that.

Following Delphi's sequencing note, I am not bundling surface 4 into this. Closing again since the reopen question is answered for surfaces 2 and 3. Reopen once more if you want the guard audit written as tests rather than as this comment, which is a fair thing to want and something I did not do.

**Answering the reopen — Angie (ENG).** Delphi's loop-risk requirements, checked against the code rather than asserted. **Short answer: all three guards exist and already cover surfaces 2 and 3. Surface 4 is not implemented, so its risk is not live.** | Delphi's requirement | Where it lives | Status | | --- | --- | --- | | Echo never responds to its own messages | `eligibleMessage`, `agent.go` — rejects when `message.Author.ID == session.State.User.ID` | **holds** | | A bot must @-mention Echo explicitly to get a reply | `eligibleMessage` — rejects `message.Author.Bot` unless `policy.PermitsAgent(message.Author.ID)`, an explicit deployment allowlist | **holds, and stricter than asked** | | Per-thread reply-rate ceiling | `exchangeLimiter`, `counterpart.go` — max 4 consecutive agent-authored turns per channel in a 10 minute window | **holds** | Two details worth having, since they answer the requirement more exactly than the summary does. **The bot guard is stricter than "must @-mention".** A bot that is not on the `agents.allow` list is dropped at eligibility, before summoning is even considered, so it cannot reach Echo by mentioning it either. The translator bot on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/198 gets no reply from Echo on any surface unless someone deliberately allowlists it. That is the guard Delphi asked for, applied one step earlier than requested. **The ceiling is already per-thread.** A Discord thread carries its own channel ID, and `exchangeLimiter` keys on channel ID, so "per channel" and "per thread" are the same bound here. It also resets on any human-authored turn, which is the right shape: a person joining ends the run rather than being counted against it. The counter refreshes its timestamp while a pair keeps trying, so a bot pair cannot wait out the window mid-exchange and resume. **Surface 3, edits, inherits all of this rather than bypassing it.** `onMessageEdit` runs its three edit-specific gates and then calls the same `admitMessage` path a new message uses, in the same order: eligibility, exchange limiter, access policy, admission, summon, duplicate. I deliberately did not give edits their own path, which is why there is nothing separate to audit here. **What is genuinely not covered.** Surface 4, unmentioned thread follow-ups, is not implemented. It is tracked as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/239 and it is the one that removes the mention requirement, so it is where Delphi's warning actually bites. The three guards above are necessary for it but I would not call them sufficient without looking at it properly, because surface 4 also lets a *human* thread message with no mention pull Echo in, and none of the guards above bound that. Following Delphi's sequencing note, I am not bundling surface 4 into this. Closing again since the reopen question is answered for surfaces 2 and 3. Reopen once more if you want the guard audit written as tests rather than as this comment, which is a fair thing to want and something I did not do.
coilyco-ops commented 2026-08-13 04:25:35 +00:00
Member
Copy link

Correction to my own comment, in your favour — Angie (ENG).

I offered to write the guard audit as tests and said I had not done it. I should have checked first: all three guards are already pinned by existing tests, so the audit exists and I understated it.

Guard Test
Echo never answers itself, and an unnamed bot is dropped at eligibility TestOnlyANamedCounterpartAgentIsAdmitted, counterpart_test.go
Agent-to-agent runs are bounded, per channel, and a human turn resets the run TestAnAgentExchangeIsBounded
A capped pair cannot wait out the window and resume TestACappedExchangeDoesNotResumeByRetrying

That last one is the guard I would have been most worried about and least likely to think of, and it was already there. So the loop protection for surfaces 2 and 3 is regression-tested, not just present.

One thing that is genuinely not pinned by a test, stated plainly: that the edit surface routes through those guards. It does, because onMessageEdit calls the same admitMessage function rather than duplicating the sequence, so it inherits them by construction rather than by assertion. That is a structural property a unit test would not add much confidence to, but it is a code-reading claim rather than a measured one, and you should weigh it as such.

Closing. Surface 4 stays with #239, which is where Delphi's warning actually applies, and I am picking that up next with the guards as an explicit requirement rather than an afterthought.

**Correction to my own comment, in your favour — Angie (ENG).** I offered to write the guard audit as tests and said I had not done it. I should have checked first: **all three guards are already pinned by existing tests**, so the audit exists and I understated it. | Guard | Test | | --- | --- | | Echo never answers itself, and an unnamed bot is dropped at eligibility | `TestOnlyANamedCounterpartAgentIsAdmitted`, `counterpart_test.go` | | Agent-to-agent runs are bounded, per channel, and a human turn resets the run | `TestAnAgentExchangeIsBounded` | | A capped pair cannot wait out the window and resume | `TestACappedExchangeDoesNotResumeByRetrying` | That last one is the guard I would have been most worried about and least likely to think of, and it was already there. So the loop protection for surfaces 2 and 3 is regression-tested, not just present. **One thing that is genuinely not pinned by a test, stated plainly:** that the edit surface routes through those guards. It does, because `onMessageEdit` calls the same `admitMessage` function rather than duplicating the sequence, so it inherits them by construction rather than by assertion. That is a structural property a unit test would not add much confidence to, but it is a code-reading claim rather than a measured one, and you should weigh it as such. Closing. Surface 4 stays with https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/239, which is where Delphi's warning actually applies, and I am picking that up next with the guards as an explicit requirement rather than an afterthought.
coilyco-ops commented 2026-08-13 14:32:20 +00:00
Member
Copy link

Confirmed under the new identity — the surface list is closed

Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-13.

Kai has redefined Echo as a full community space (#227). Asked whether that means Echo may post unprompted, she chose reactive only.

Echo never speaks first. She rejected initiating on server events (a member starts streaming, a milestone lands) and rejected initiating freely.

What that settles

The four surfaces recorded above are the complete list, and they remain complete under the new identity:

  1. Direct @-mention
  2. Replies to Echo's messages
  3. Edits that add a mention
  4. Unmentioned thread follow-ups

No announcement feature, no event notifier, no welcome message, no "someone is streaming Eco right now" post. Every one of those is a plausible thing to build for a "community space" and none of them is approved. Recording it explicitly so nobody infers a proactive surface from the identity change — the phrase invites it and the decision excludes it.

Echo participates richly, but always because someone addressed it.

Why this is a good pairing

Reactive-only is what keeps the identity change cheap. A participating agent that also initiates would put Echo's own judgment in charge of when members' notifications fire — tier 3 under #179, and hard to bound. Staying reactive means the guards already specified in #172 remain sufficient rather than needing a new class of rate control.

It also keeps surface 4 the riskiest thing here, which it already was.

## Confirmed under the new identity — the surface list is closed Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-13. Kai has redefined Echo as a **full community space** (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/227). Asked whether that means Echo may post unprompted, she chose **reactive only**. **Echo never speaks first.** She rejected initiating on server events (a member starts streaming, a milestone lands) and rejected initiating freely. ### What that settles **The four surfaces recorded above are the complete list**, and they remain complete under the new identity: 1. Direct @-mention 2. Replies to Echo's messages 3. Edits that add a mention 4. Unmentioned thread follow-ups **No announcement feature, no event notifier, no welcome message, no "someone is streaming Eco right now" post.** Every one of those is a plausible thing to build for a "community space" and none of them is approved. Recording it explicitly so nobody infers a proactive surface from the identity change — the phrase invites it and the decision excludes it. Echo participates richly, but always because someone addressed it. ### Why this is a good pairing Reactive-only is what keeps the identity change cheap. A participating agent that also initiates would put Echo's own judgment in charge of when members' notifications fire — tier 3 under https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/179, and hard to bound. Staying reactive means the guards already specified in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/172 remain sufficient rather than needing a new class of rate control. It also keeps surface 4 the riskiest thing here, which it already was.
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
2 participants
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#205
No description provided.