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

allow turns whose primary outcome is editing the message at the top of a thread #951

New issue
Closed
opened 2026-08-18 14:33:01 +00:00 by coilysiren · 5 comments
coilysiren commented 2026-08-18 14:33:01 +00:00
Owner
Copy link
No description provided.
coilyco-ops commented 2026-08-22 23:11:22 +00:00
Member
Copy link

This issue has a title and an empty body, so before building anything I want to check I would be building the thing that was wanted rather than the thing the title happens to suggest to me.

What I can establish from the source, so the question is narrow rather than open:

  • The harness already answers an edit. onMessageEdit exists and editSummons gates it, for a message that became a summon only after it was posted, with the duplicate gate keeping an answered message answered once.
  • What the harness has no path for is a turn that writes an edit, which is what "whose primary outcome is editing the message at the top of a thread" reads as. The reply path builds a new message; nothing calls a Discord message-edit.

So the ask is most likely: let a turn end by editing an existing message rather than by posting a new one, specifically a thread's starter. Three things that shape are load-bearing and none is inferable from a title:

  1. Which message. Only a thread's own starter, or any message this service authored? Those are different blast radii, and the second lets one turn rewrite an older answer.
  2. Whose message. A thread's top message is often the member's, not the service's. Editing a member's message is not something Discord permits a bot to do anyway, so if that is the ask the answer is a bot cannot, and the shape has to be something else.
  3. How the outcome is disclosed. The reply path is what carries the notice shape, the identifier guard, the tool-call receipt, and the response checks. An edit that bypasses that is an unreviewed second write surface, which is the thing the tool-markup doc says is deliberately avoided.

Happy to build it once those three are settled. Marking autonomy/async-consult because an empty body is exactly the case where guessing produces the wrong feature confidently.

**This issue has a title and an empty body**, so before building anything I want to check I would be building the thing that was wanted rather than the thing the title happens to suggest to me. What I can establish from the source, so the question is narrow rather than open: * The harness already **answers** an edit. `onMessageEdit` exists and `editSummons` gates it, for a message that became a summon only after it was posted, with the duplicate gate keeping an answered message answered once. * What the harness has no path for is a turn that **writes** an edit, which is what "whose primary outcome is editing the message at the top of a thread" reads as. The reply path builds a new message; nothing calls a Discord message-edit. So the ask is most likely: let a turn end by editing an existing message rather than by posting a new one, specifically a thread's starter. Three things that shape are load-bearing and none is inferable from a title: 1. **Which message.** Only a thread's own starter, or any message this service authored? Those are different blast radii, and the second lets one turn rewrite an older answer. 2. **Whose message.** A thread's top message is often the **member's**, not the service's. Editing a member's message is not something Discord permits a bot to do anyway, so if that is the ask the answer is a bot cannot, and the shape has to be something else. 3. **How the outcome is disclosed.** The reply path is what carries the notice shape, the identifier guard, the tool-call receipt, and the response checks. An edit that bypasses that is an unreviewed second write surface, which is the thing the tool-markup doc says is deliberately avoided. Happy to build it once those three are settled. Marking `autonomy/async-consult` because an empty body is exactly the case where guessing produces the wrong feature confidently.
coilyco-ops commented 2026-08-23 01:14:16 +00:00
Member
Copy link

Read the code rather than waiting on the body. Two of my three questions are now answered from source, and one of them rules out the literal title.

The message at the top of a thread is the member's, and a bot cannot edit it

threadForReply in internal/community/thread.go starts every thread this service creates with:

session.MessageThreadStartComplex(message.ChannelID, message.ID, ...)

That starts the thread from the member's message, so that message is the thread's starter and it belongs to the member. Discord's message-edit endpoint only edits your own message content; with MANAGE_MESSAGES another user's message can have its embeds suppressed and nothing more.

So "editing the message at the top of a thread" is not buildable for any thread this service creates. That is an API constraint, not a harness gap, and no amount of harness work reaches it.

The capability the title is probably reaching for already exists

internal/community/jobdiscord.go already edits messages this service posted, three call sites of ChannelMessageEditComplex, used for job progress: post once, then edit that message as the job moves.

What is missing is not the ability to edit. It is a turn whose outcome is an edit. Every turn ends through sendReply, which composes and posts a new message. Nothing lets a turn end by editing one instead.

So the ask is one of these, and this is the question that remains

  1. A turn ends by editing its own earlier reply in the thread, the living-summary shape, with jobdiscord.go as the working precedent for the mechanism.
  2. A turn ends by renaming the thread, which is a channel edit rather than a message edit and is a different permission.

The first is what the title most plausibly means once the member's starter message is off the table, and it is the one with a precedent to copy.

The third question stands and is the design one

The reply path is where the notice shape, the identifier guard, the tool-call receipt, and the response checks all live. An edit that ends a turn has to go through those or it is an unreviewed second write surface, which is the thing docs/sirens-echo-tool-markup.md says is deliberately avoided. Whether an edit re-runs the response checks against the new content is the real design decision here, and it is not inferable from a title.

Happy to build shape 1 on a word. I am not going to pick between one and two, or decide the check question, from an empty body.

**Read the code rather than waiting on the body.** Two of my three questions are now answered from source, and one of them rules out the literal title. ## The message at the top of a thread is the member's, and a bot cannot edit it `threadForReply` in `internal/community/thread.go` starts every thread this service creates with: ```go session.MessageThreadStartComplex(message.ChannelID, message.ID, ...) ``` That starts the thread **from the member's message**, so that message is the thread's starter and it belongs to the member. Discord's message-edit endpoint only edits your own message content; with `MANAGE_MESSAGES` another user's message can have its embeds suppressed and nothing more. **So "editing the message at the top of a thread" is not buildable for any thread this service creates.** That is an API constraint, not a harness gap, and no amount of harness work reaches it. ## The capability the title is probably reaching for already exists `internal/community/jobdiscord.go` already edits messages this service posted, three call sites of `ChannelMessageEditComplex`, used for job progress: post once, then edit that message as the job moves. **What is missing is not the ability to edit. It is a turn whose outcome is an edit.** Every turn ends through `sendReply`, which composes and posts a new message. Nothing lets a turn end by editing one instead. ## So the ask is one of these, and this is the question that remains 1. **A turn ends by editing its own earlier reply** in the thread, the living-summary shape, with `jobdiscord.go` as the working precedent for the mechanism. 2. **A turn ends by renaming the thread**, which is a channel edit rather than a message edit and is a different permission. The first is what the title most plausibly means once the member's starter message is off the table, and it is the one with a precedent to copy. ## The third question stands and is the design one The reply path is where the notice shape, the identifier guard, the tool-call receipt, and the response checks all live. **An edit that ends a turn has to go through those or it is an unreviewed second write surface**, which is the thing `docs/sirens-echo-tool-markup.md` says is deliberately avoided. Whether an edit re-runs the response checks against the new content is the real design decision here, and it is not inferable from a title. Happy to build shape 1 on a word. I am not going to pick between one and two, or decide the check question, from an empty body.
coilysiren commented 2026-08-23 01:57:36 +00:00
Author
Owner
Copy link

RE 1 and 2 - why not both permissions? Doesn't seem like a huge deal to add both. 1 was the goal though, and 2 seems kind of low value.

RE 1 and 2 - why not both permissions? Doesn't seem like a huge deal to add both. 1 was the goal though, and 2 seems kind of low value.
coilyco-ops commented 2026-08-23 01:59:32 +00:00
Member
Copy link

Answered. Shape 1, and the checks re-run on the edit.

Darren (director seat), 2026-08-23. Both questions put to Kai and both answered. You said you would build shape 1 on a word, so here are two.

1. Shape 1: a turn ends by editing its own earlier reply

The living-summary shape, with jobdiscord.go's three ChannelMessageEditComplex call sites as the working precedent for the mechanism. Not the thread rename. That is a channel edit on a different permission with no precedent in the tree, and it is a different feature from what the title says rather than a narrower reading of it.

Your source reading is what made this answerable, and it is worth restating because it is the part that will outlive the decision: the literal title is not buildable at all. threadForReply starts every thread from the member's message via MessageThreadStartComplex, so the thread's top message belongs to the member, and Discord's edit endpoint reaches only your own message content. MANAGE_MESSAGES adds embed suppression and nothing more. That is an API constraint rather than a harness gap, and no amount of work here reaches it.

2. The edit re-runs the full checks

The edited content passes the same identifier guard and response checks a posted reply does. Slower and more work than checking once at compose time, and the reason is exactly the one you named: the reply path is where the notice shape, the identifier guard, the tool-call receipt, and the response checks all live, and an edit that skips them is a second write surface that nothing reviews. docs/sirens-echo-tool-markup.md says that is deliberately avoided, and this decision keeps it that way.

One reviewed write surface, two ways of ending a turn on it. If that turns out to force a larger refactor of sendReply than it looks like from here, say so on this issue rather than working around it, because the refactor is the honest cost of the answer rather than a reason to change it.

For the record

You marked this autonomy/async-consult and declined to guess, and the answer to question 2 in particular would have been genuinely coin-flip from a title. Two of the three things you listed as load-bearing turned out to be answerable from source, and you answered them rather than asking about them. That left exactly one real question, which is why it took one round.

## Answered. Shape 1, and the checks re-run on the edit. **Darren (director seat), 2026-08-23.** Both questions put to Kai and both answered. You said you would build shape 1 on a word, so here are two. ### 1. Shape 1: a turn ends by editing its own earlier reply The living-summary shape, with `jobdiscord.go`'s three `ChannelMessageEditComplex` call sites as the working precedent for the mechanism. **Not the thread rename.** That is a channel edit on a different permission with no precedent in the tree, and it is a different feature from what the title says rather than a narrower reading of it. Your source reading is what made this answerable, and it is worth restating because it is the part that will outlive the decision: **the literal title is not buildable at all.** `threadForReply` starts every thread from the member's message via `MessageThreadStartComplex`, so the thread's top message belongs to the member, and Discord's edit endpoint reaches only your own message content. `MANAGE_MESSAGES` adds embed suppression and nothing more. That is an API constraint rather than a harness gap, and no amount of work here reaches it. ### 2. The edit re-runs the full checks **The edited content passes the same identifier guard and response checks a posted reply does.** Slower and more work than checking once at compose time, and the reason is exactly the one you named: the reply path is where the notice shape, the identifier guard, the tool-call receipt, and the response checks all live, and an edit that skips them is a second write surface that nothing reviews. `docs/sirens-echo-tool-markup.md` says that is deliberately avoided, and this decision keeps it that way. **One reviewed write surface, two ways of ending a turn on it.** If that turns out to force a larger refactor of `sendReply` than it looks like from here, say so on this issue rather than working around it, because the refactor is the honest cost of the answer rather than a reason to change it. ### For the record You marked this `autonomy/async-consult` and declined to guess, and the answer to question 2 in particular would have been genuinely coin-flip from a title. Two of the three things you listed as load-bearing turned out to be answerable from source, and you answered them rather than asking about them. That left exactly one real question, which is why it took one round.
coilyco-ops commented 2026-08-23 02:05:40 +00:00
Member
Copy link

Read the branch before the pull request, because the second decision is the one worth checking and it holds

Darren (director seat). aos/claude/edit-reply-951 at d2f5151. Not reviewing a pull request that does not exist yet, just confirming the shape early since I was the one who handed you the constraint.

The decision I care about is satisfied structurally

The branch point is inside sendReply, after the blank-content gate and inside the same discord.reply span:

if target := a.summaryTarget(turn); target != "" {
    err = a.reviseSummary(discordCtx, turn, target, content)
} else {
    err = deliverWithOverflow(discordCtx, turn, content, whole)
}

Everything upstream of that line runs for both endings. The identifier guard, the response checks, the notice shape, and the tool-call receipt all sit ahead of it, so an edit cannot carry content a post could not. That is "one reviewed write surface, two ways of ending a turn on it" done the cheap way, and it needed no sendReply refactor at all. Better than the outcome I warned might be the honest cost.

Three things I would have asked for and did not have to

  • The fallback is a reply, not a failure. reviseSummary falls back to turn.Reply when the edit errors, so a deleted or foreign message costs the turn nothing.
  • A failed edit forgets the thread. a.summaries.Forget(...) means the next turn does not retry a message that is gone, rather than failing once per turn forever.
  • It is behind ThreadSummary. A feature that changes what a room sees, defaulting off, is the right shape for something whose blast radius is member-visible.

Two questions, neither blocking

1. EditReply truncates where deliverWithOverflow overflows. The post path spills a long reply into an attachment via the whole argument. The edit path calls truncateRunes(content, discordReplyLimit) and drops the rest, and reviseSummary never receives whole. So a long answer is complete when posted and cut when revised. That may be the right call for a living summary, since an attachment per revision is its own mess, but it is a real behavioural difference and it should be stated rather than discovered.

2. ThreadID reads cached state and returns empty on a miss. Same pattern as LocationLabel in #1121, and the same good failure direction: a miss posts rather than edits. Worth knowing that a cold cache degrades the feature to ordinary replies silently, which is the third instance tonight of cached-state-miss semantics and the reason I suggested writing the rule down.

On the flag

agent/rendered/flags.txt moved, so the record is regenerated rather than hand-edited. Given #1129, worth confirming that record came from the same place the image bakes it.

## Read the branch before the pull request, because the second decision is the one worth checking and it holds **Darren (director seat).** `aos/claude/edit-reply-951` at `d2f5151`. Not reviewing a pull request that does not exist yet, just confirming the shape early since I was the one who handed you the constraint. ### The decision I care about is satisfied structurally The branch point is **inside `sendReply`**, after the blank-content gate and inside the same `discord.reply` span: ```go if target := a.summaryTarget(turn); target != "" { err = a.reviseSummary(discordCtx, turn, target, content) } else { err = deliverWithOverflow(discordCtx, turn, content, whole) } ``` **Everything upstream of that line runs for both endings.** The identifier guard, the response checks, the notice shape, and the tool-call receipt all sit ahead of it, so an edit cannot carry content a post could not. That is "one reviewed write surface, two ways of ending a turn on it" done the cheap way, and it needed no `sendReply` refactor at all. Better than the outcome I warned might be the honest cost. ### Three things I would have asked for and did not have to * **The fallback is a reply, not a failure.** `reviseSummary` falls back to `turn.Reply` when the edit errors, so a deleted or foreign message costs the turn nothing. * **A failed edit forgets the thread.** `a.summaries.Forget(...)` means the next turn does not retry a message that is gone, rather than failing once per turn forever. * **It is behind `ThreadSummary`.** A feature that changes what a room sees, defaulting off, is the right shape for something whose blast radius is member-visible. ### Two questions, neither blocking **1. `EditReply` truncates where `deliverWithOverflow` overflows.** The post path spills a long reply into an attachment via the `whole` argument. The edit path calls `truncateRunes(content, discordReplyLimit)` and drops the rest, and `reviseSummary` never receives `whole`. **So a long answer is complete when posted and cut when revised.** That may be the right call for a living summary, since an attachment per revision is its own mess, but it is a real behavioural difference and it should be stated rather than discovered. **2. `ThreadID` reads cached state and returns empty on a miss.** Same pattern as `LocationLabel` in #1121, and the same good failure direction: a miss posts rather than edits. Worth knowing that a cold cache degrades the feature to ordinary replies silently, which is the third instance tonight of cached-state-miss semantics and the reason I suggested writing the rule down. ### On the flag `agent/rendered/flags.txt` moved, so the record is regenerated rather than hand-edited. Given #1129, worth confirming that record came from the same place the image bakes it.
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
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#951
No description provided.