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

Replies to threads you created should always summon you #750

New issue
Closed
opened 2026-08-13 22:34:51 +00:00 by coilyco-ops-gaming · 4 comments
coilyco-ops-gaming commented 2026-08-13 22:34:51 +00:00
Member
Copy link

When a member replies to a thread that was originally started by sirens-echo, the harness should treat that reply as a direct summon of the agent rather than routing it through normal channel logic.

This ensures the agent is aware of follow-up context in its own threads and can respond appropriately without requiring an explicit @mention on every subsequent message in the thread.

Resolved spec (design pass, 2026-08-15)

Kai's answer to Angie's one-word question is yes. Build the narrow version.

Build

  1. In summonedLocally, summon when the message arrives in a thread whose discordgo.Channel.OwnerID is the bot user.
  2. Leave mention and reply-to-Echo exactly as they are. agent.go:717 already covers reply-to-Echo and is not touched.
  3. Leave the access-policy check ahead of the summon check untouched.
  4. Per-thread-starter scoping was considered and rejected. Any member's message in an Echo-owned thread summons, not only the member the thread was opened for.

No expiry. An Echo-created thread stays summonable for its life. A quiet-period cutoff at 24 hours, at 1 hour, and riding Discord's own archive window were all considered and rejected. This is deliberate, so do not add a timer as a defensive measure.

Accepted consequence, stated so nobody treats it as a regression - in a thread Echo opened, two members talking to each other each summon a turn, and an old thread can wake her on a passing message. Rate limits and the pending cap still apply, so this is throttled rather than unbounded.

Measure before building - whether session.State reliably holds thread channels, or whether ownership costs a REST lookup per message in a thread. Angie flagged this as a real cost question and explicitly did not check it. Measure it, report the number here, and build if it is cheap. If it is a REST call per message, say so before shipping rather than after.

Acceptance

  • An ordinary message with no mention, in a thread Echo created, produces a turn.
  • The same message in a thread a member created does not.
  • Mention and reply-to-Echo behaviour is unchanged. Regression-test both.
  • The access-policy refusal still fires ahead of the summon decision.

Provenance - this arrived as a SANDBOXED member-influenced filing. Kai has now confirmed it as a decision, so it is a specification rather than a report.

When a member replies to a thread that was originally started by sirens-echo, the harness should treat that reply as a direct summon of the agent rather than routing it through normal channel logic. This ensures the agent is aware of follow-up context in its own threads and can respond appropriately without requiring an explicit @mention on every subsequent message in the thread. --- ## Resolved spec (design pass, 2026-08-15) **Kai's answer to Angie's one-word question is yes.** Build the narrow version. **Build** 1. In `summonedLocally`, summon when the message arrives in a thread whose `discordgo.Channel.OwnerID` is the bot user. 2. Leave mention and reply-to-Echo exactly as they are. `agent.go:717` already covers reply-to-Echo and is not touched. 3. Leave the access-policy check ahead of the summon check untouched. 4. Per-thread-starter scoping was considered and rejected. Any member's message in an Echo-owned thread summons, not only the member the thread was opened for. **No expiry.** An Echo-created thread stays summonable for its life. A quiet-period cutoff at 24 hours, at 1 hour, and riding Discord's own archive window were all considered and rejected. This is deliberate, so do not add a timer as a defensive measure. **Accepted consequence, stated so nobody treats it as a regression** - in a thread Echo opened, two members talking to each other each summon a turn, and an old thread can wake her on a passing message. Rate limits and the pending cap still apply, so this is throttled rather than unbounded. **Measure before building** - whether `session.State` reliably holds thread channels, or whether ownership costs a REST lookup per message in a thread. Angie flagged this as a real cost question and explicitly did not check it. Measure it, report the number here, and build if it is cheap. If it is a REST call per message, say so before shipping rather than after. **Acceptance** * An ordinary message with no mention, in a thread Echo created, produces a turn. * The same message in a thread a member created does not. * Mention and reply-to-Echo behaviour is unchanged. Regression-test both. * The access-policy refusal still fires ahead of the summon decision. **Provenance** - this arrived as a `SANDBOXED` member-influenced filing. Kai has now confirmed it as a decision, so it is a specification rather than a report.
coilyco-ops commented 2026-08-13 22:37:00 +00:00
Member
Copy link

Claiming. Angie (ENG), seat claude. 20 minutes from this comment, after the one minute buffer.

New, unclaimed, and squarely in the admission path. Checking two things during the buffer before I write anything:

Whether the harness can already tell. A reply in a thread Echo created is a fact the runtime may or may not hold at summon time. If it does not, this is a different and larger change than it reads.

Whether widening summon here is safe. The summon check is one of seven admission checks and it decides what Echo answers at all. Scoped to threads Echo itself created it is narrow, but I want to state the blast radius rather than assume it, because a summon that fires without a mention is the shape that floods a channel.

Recording that this arrived as a SANDBOXED filing, so the request is member-influenced. That does not make it wrong, and I am treating the described behaviour as a report rather than a specification.

Open pull requests checked first: none.

**Claiming. Angie (ENG), seat `claude`. 20 minutes from this comment, after the one minute buffer.** New, unclaimed, and squarely in the admission path. Checking two things during the buffer before I write anything: **Whether the harness can already tell.** A reply in a thread Echo created is a fact the runtime may or may not hold at summon time. If it does not, this is a different and larger change than it reads. **Whether widening summon here is safe.** The summon check is one of seven admission checks and it decides what Echo answers at all. Scoped to threads Echo itself created it is narrow, but I want to state the blast radius rather than assume it, because a summon that fires without a mention is the shape that floods a channel. Recording that this arrived as a **SANDBOXED** filing, so the request is member-influenced. That does not make it wrong, and I am treating the described behaviour as a report rather than a specification. Open pull requests checked first: none.
coilyco-ops commented 2026-08-13 22:38:15 +00:00
Member
Copy link

Feasible, and I am not building it, because it widens what Echo answers at all. Angie (ENG), seat claude. Releasing the claim, adding consult.

What already works

A reply to one of Echo's messages summons her today, with no mention, agent.go:717:

if message.ReferencedMessage != nil && message.ReferencedMessage.Author != nil {
    return message.ReferencedMessage.Author.ID == botID, false
}

So the follow-up case this asks about is covered whenever the member uses Discord's reply. What is not covered is an ordinary message in the thread, addressed to nobody.

Feasible, and here is the mechanism

threadForReply starts the thread on the member's message, so the parent is not Echo's and cannot be the signal. Thread ownership can be: discordgo.Channel.OwnerID is the user who created the thread, which is Echo's bot user for every thread she opens.

The runtime already reads the channel for other reasons (agent.go:683, agent.go:1375, thread.go:89), so the lookup is not new. The change is a few lines in summonedLocally.

Why I am not writing them

This widens the summon contract, which is one of seven admission checks and the one deciding what Echo answers at all. Scoped to her own threads it is narrow, and it is still a change from "answer when addressed" to "answer everything here".

Concretely, in a thread Echo opened, two members talking to each other would each summon a turn. Rate limits and the pending cap still apply, so this is throttled rather than unbounded, but the first-order behaviour is that Echo joins a conversation nobody addressed.

That may well be what you want in her own threads. It is a product decision rather than a defect, and this arrived as a member-influenced SANDBOXED filing rather than as your instruction, so I am not treating it as one.

What would make it mine

One word. If the answer is yes, the narrow version is: summon when the message is in a thread whose OwnerID is the bot, leaving mention and reply-to-Echo exactly as they are, and leaving the access-policy check ahead of it untouched. One claim.

Worth pairing with a decision on whether an Echo-created thread should also stop summoning after some quiet period, because a thread is durable and this makes it permanently live.

Not in scope, and worth stating

I did not check whether session.State reliably holds thread channels or whether this costs a REST lookup per message in a thread. That is a real cost question and I would measure it before building, not before you decide.

**Feasible, and I am not building it, because it widens what Echo answers at all. Angie (ENG), seat `claude`. Releasing the claim, adding `consult`.** ## What already works A reply **to one of Echo's messages** summons her today, with no mention, `agent.go:717`: ```go if message.ReferencedMessage != nil && message.ReferencedMessage.Author != nil { return message.ReferencedMessage.Author.ID == botID, false } ``` So the follow-up case this asks about is covered whenever the member uses Discord's reply. What is **not** covered is an ordinary message in the thread, addressed to nobody. ## Feasible, and here is the mechanism `threadForReply` starts the thread on the **member's** message, so the parent is not Echo's and cannot be the signal. Thread **ownership** can be: `discordgo.Channel.OwnerID` is the user who created the thread, which is Echo's bot user for every thread she opens. The runtime already reads the channel for other reasons (`agent.go:683`, `agent.go:1375`, `thread.go:89`), so the lookup is not new. **The change is a few lines in `summonedLocally`.** ## Why I am not writing them **This widens the summon contract**, which is one of seven admission checks and the one deciding what Echo answers at all. Scoped to her own threads it is narrow, and it is still a change from *"answer when addressed"* to *"answer everything here"*. Concretely, in a thread Echo opened, two members talking to each other would each summon a turn. Rate limits and the pending cap still apply, so this is throttled rather than unbounded, but the first-order behaviour is that Echo joins a conversation nobody addressed. That may well be what you want in her own threads. **It is a product decision rather than a defect**, and this arrived as a member-influenced `SANDBOXED` filing rather than as your instruction, so I am not treating it as one. ## What would make it mine One word. If the answer is yes, the narrow version is: **summon when the message is in a thread whose `OwnerID` is the bot**, leaving mention and reply-to-Echo exactly as they are, and leaving the access-policy check ahead of it untouched. One claim. Worth pairing with a decision on whether an Echo-created thread should also **stop** summoning after some quiet period, because a thread is durable and this makes it permanently live. ## Not in scope, and worth stating I did not check whether `session.State` reliably holds thread channels or whether this costs a REST lookup per message in a thread. That is a real cost question and I would measure it before building, not before you decide.
coilyco-ops commented 2026-08-18 22:31:05 +00:00
Member
Copy link

Still unimplemented as of b740233 on main (2026-08-18 22:09). Verified against the source, not the thread. Raised again by Kai today, who reports Dowel never answering comments in threads and has now asked for this three times.

Current state, checked rather than assumed

  • OwnerID appears nowhere in the Go source.
  • summonedLocally is unchanged and still has exactly three paths: a DM, a mention of the bot user or a role it holds, and a Discord reply whose referenced message the bot authored.
  • This issue has not been touched since the design pass on 2026-08-15.

So the resolved spec in the body above is still the plan of record and nothing has been built against it.

The measurement precondition is now satisfied

The spec says to measure whether session.State reliably holds thread channels, or whether ownership costs a REST lookup per message, and to report the number here before building. That was never reported, and it is the one thing the spec said had to happen first.

It is cheap:

  • resolveChannel (agent.go:763) already resolves cached-state-first with a REST fallback.
  • thread.go:162 already calls session.State.Channel(...).IsThread() on the message path with no API call.

The ownership read is the same cached lookup the message path already performs. Cached hit in the common case, with the existing REST fallback only on a miss. That precondition is met and should not block the build again.

Why this keeps reading as done

Three things landed tonight whose titles describe this and do not implement it:

  • #975 feat(coalesce): give the batching lane the Discord summon path
  • #983 fix(coalesce): tell the model a folded ask is several comments
  • #976 turn the coalescing lane on

The coalescing lane sits downstream of the summon gate. summonedLocally decides at agent.go:598; submitSummon runs at agent.go:966. Coalescing only sees messages that already summoned.

Concretely: three mentions in a thread now fold into one answer covering all three. Three plain comments in a thread are still rejected at the gate and coalescing never sees them. Same words, opposite half of the pipeline.

#987 fix(turns): a dropped turn always tells the member is the same kind of near-miss. It covers turns that started, and a message that never summons never starts one.

One addition worth making to the spec before it is built

The spec's accepted consequence is that any member's message in a bot-owned thread summons a turn. On the August 19 lane that includes other builders' agents posting in a shared channel, so two agents in a Dowel-owned thread can summon each other in a loop, on camera, on a lane already at a 32.9s median turn (#932).

Suggest the auto-summon path ignore messages authored by other bot accounts. Mention and reply-to-own-message keep working for bots, so nothing an agent deliberately addresses to Dowel is lost. That is a small clause the current spec does not have.

Freeze status

Not one of the six on #929, and not on the #981 demo board, so as written it is behind August 20. Kai can lift it for this item in one comment if she wants it for the stream.

The observability half, which is why this took three asks to surface, is filed separately.

**Still unimplemented as of `b740233` on main (2026-08-18 22:09). Verified against the source, not the thread.** Raised again by Kai today, who reports Dowel never answering comments in threads and has now asked for this three times. ## Current state, checked rather than assumed * `OwnerID` appears **nowhere** in the Go source. * `summonedLocally` is unchanged and still has exactly three paths: a DM, a mention of the bot user or a role it holds, and a Discord reply whose referenced message the bot authored. * This issue has not been touched since the design pass on 2026-08-15. So the resolved spec in the body above is still the plan of record and nothing has been built against it. ## The measurement precondition is now satisfied The spec says to measure whether `session.State` reliably holds thread channels, or whether ownership costs a REST lookup per message, and to report the number here before building. That was never reported, and it is the one thing the spec said had to happen first. It is cheap: * `resolveChannel` (`agent.go:763`) already resolves cached-state-first with a REST fallback. * `thread.go:162` already calls `session.State.Channel(...).IsThread()` on the message path with no API call. The ownership read is the same cached lookup the message path already performs. Cached hit in the common case, with the existing REST fallback only on a miss. That precondition is met and should not block the build again. ## Why this keeps reading as done Three things landed tonight whose titles describe this and do not implement it: * #975 `feat(coalesce): give the batching lane the Discord summon path` * #983 `fix(coalesce): tell the model a folded ask is several comments` * #976 turn the coalescing lane on The coalescing lane sits **downstream** of the summon gate. `summonedLocally` decides at `agent.go:598`; `submitSummon` runs at `agent.go:966`. Coalescing only sees messages that already summoned. Concretely: three mentions in a thread now fold into one answer covering all three. Three plain comments in a thread are still rejected at the gate and coalescing never sees them. Same words, opposite half of the pipeline. #987 `fix(turns): a dropped turn always tells the member` is the same kind of near-miss. It covers turns that started, and a message that never summons never starts one. ## One addition worth making to the spec before it is built The spec's accepted consequence is that any member's message in a bot-owned thread summons a turn. On the August 19 lane that includes **other builders' agents** posting in a shared channel, so two agents in a Dowel-owned thread can summon each other in a loop, on camera, on a lane already at a 32.9s median turn (#932). Suggest the auto-summon path ignore messages authored by other bot accounts. Mention and reply-to-own-message keep working for bots, so nothing an agent deliberately addresses to Dowel is lost. That is a small clause the current spec does not have. ## Freeze status Not one of the six on #929, and not on the #981 demo board, so as written it is behind August 20. Kai can lift it for this item in one comment if she wants it for the stream. The observability half, which is why this took three asks to surface, is filed separately.
coilyco-ops commented 2026-08-18 22:32:03 +00:00
Member
Copy link

Built and landed on main as 7f764c8. Angie (ENG), seat claude. Removing autonomy/async-consult.

The measurement you asked for, before shipping rather than after

It costs no REST call. discordgo's State caches thread channels, so State.Channel answers from memory:

  • GUILD_CREATE carries guild.Threads and GuildAdd writes every one into channelMap (state.go:103).
  • THREAD_CREATE and THREAD_UPDATE route to ChannelAdd under TrackThreads, which defaults on (state.go:1083).
  • Both events ride the GUILDS intent, which this service already requests, so nothing new is subscribed.
  • Channel.OwnerID is on the cached object, populated on both paths.

So the ownership check reads memory on the path that matters, including every thread Echo opens herself, since THREAD_CREATE lands as she creates it.

The state miss is where I made a call you did not specify. A channel the state has never seen reports unowned rather than falling back to a lookup. The summon decision is the one gate where a REST call per message would be unbounded, and the two gates that can already force a call are admission-bounded for exactly that reason. Mention and reply-to-Echo still decide for such a thread, so an unseen thread is quieter rather than deaf. TestThreadOwnershipReadsCachedGatewayState pins the measurement so it cannot quietly stop being true.

Built as specified

summonedLocally summons when Channel.OwnerID is the bot user. No per-thread-starter scoping, so any member's message in an Echo thread summons. No expiry, so the thread stays summonable for its life, and there is no timer to find and delete later.

agent.go:717 reply-to-Echo is untouched, and so is the access-policy check ahead of the summon decision.

Acceptance

All four, as tests:

  • An unmentioned message in an Echo-created thread summons - TestMessageInServiceOwnedThreadSummons, including one member answering another.
  • The same message in a member-created thread does not - TestMessageInMemberOwnedThreadDoesNotSummon.
  • Mention and reply-to-Echo unchanged - regression cases in both new tests plus TestReplyToServiceMessageSummons and TestDirectMessagesSummonWithoutAMention, unmodified.
  • The access-policy refusal still fires first - untouched in admitMessage, which evaluates the policy before calling summonedLocally.

just gate green.

Documented

The accepted consequence is written down as a decision rather than left to be rediscovered: in mentions the summon list is now five things rather than four, and threads says plainly that two members talking in an Echo thread each summon a turn, throttled rather than bounded, with no quiet period.

The docs folder is at its 40-page cap, so this went into the existing pages rather than a new one.

Not in this commit

Kai also asked for a reply whose whole answer is an emoji reaction. That is not this issue, so it is filed and landed separately as #991.

**Built and landed on `main` as `7f764c8`. Angie (ENG), seat `claude`. Removing `autonomy/async-consult`.** ## The measurement you asked for, before shipping rather than after **It costs no REST call.** discordgo's `State` caches thread channels, so `State.Channel` answers from memory: * `GUILD_CREATE` carries `guild.Threads` and `GuildAdd` writes every one into `channelMap` (`state.go:103`). * `THREAD_CREATE` and `THREAD_UPDATE` route to `ChannelAdd` under `TrackThreads`, which defaults on (`state.go:1083`). * Both events ride the `GUILDS` intent, which this service already requests, so nothing new is subscribed. * `Channel.OwnerID` is on the cached object, populated on both paths. So the ownership check reads memory on the path that matters, including every thread Echo opens herself, since `THREAD_CREATE` lands as she creates it. **The state miss is where I made a call you did not specify.** A channel the state has never seen reports *unowned* rather than falling back to a lookup. The summon decision is the one gate where a REST call per message would be unbounded, and the two gates that can already force a call are admission-bounded for exactly that reason. Mention and reply-to-Echo still decide for such a thread, so an unseen thread is quieter rather than deaf. `TestThreadOwnershipReadsCachedGatewayState` pins the measurement so it cannot quietly stop being true. ## Built as specified `summonedLocally` summons when `Channel.OwnerID` is the bot user. No per-thread-starter scoping, so any member's message in an Echo thread summons. No expiry, so the thread stays summonable for its life, and there is no timer to find and delete later. `agent.go:717` reply-to-Echo is untouched, and so is the access-policy check ahead of the summon decision. ## Acceptance All four, as tests: * An unmentioned message in an Echo-created thread summons - `TestMessageInServiceOwnedThreadSummons`, including one member answering another. * The same message in a member-created thread does not - `TestMessageInMemberOwnedThreadDoesNotSummon`. * Mention and reply-to-Echo unchanged - regression cases in both new tests plus `TestReplyToServiceMessageSummons` and `TestDirectMessagesSummonWithoutAMention`, unmodified. * The access-policy refusal still fires first - untouched in `admitMessage`, which evaluates the policy before calling `summonedLocally`. `just gate` green. ## Documented The accepted consequence is written down as a decision rather than left to be rediscovered: in [mentions](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/src/branch/main/docs/sirens-echo-mentions.md) the summon list is now five things rather than four, and [threads](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/src/branch/main/docs/sirens-echo-threads.md) says plainly that two members talking in an Echo thread each summon a turn, throttled rather than bounded, with no quiet period. The docs folder is at its 40-page cap, so this went into the existing pages rather than a new one. ## Not in this commit Kai also asked for a reply whose whole answer is an emoji reaction. That is not this issue, so it is filed and landed separately as #991.
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#750
No description provided.