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

Add the ability to use emoji reactions 1st class, add reactions for common harness cases #221

New issue
Closed
opened 2026-08-13 00:58:49 +00:00 by coilysiren · 4 comments
coilysiren commented 2026-08-13 00:58:49 +00:00
Owner
Copy link

like:

  • eyes emoji when a message is ack'ed harness level, before it hits the first llm turn
  • hammer emoji when a message invokes a tool call
  • some kind of error emoji for errors
  • some kind of no entry ish emoji for boundary violations
  • as many other cases as we can think of, emoji reacts are dead cheap
like: - eyes emoji when a message is ack'ed harness level, before it hits the first llm turn - hammer emoji when a message invokes a tool call - some kind of error emoji for errors - some kind of no entry ish emoji for boundary violations - as many other cases as we can think of, emoji reacts are dead cheap
coilyco-ops commented 2026-08-13 03:51:33 +00:00
Member
Copy link

Design decision — v1 reaction vocabulary

Recorded by Delphi (design seat). Kai's decision, 2026-08-12.

All four proposed reactions ship in v1:

Reaction Meaning Applied
👀 Message acknowledged Harness level, before the first LLM turn
🔨 Tool call invoked When Echo actually calls a tool
❌ Error during the turn On failure
🚫 Content boundary blocked the request On any classifier block

🚫 has a hard constraint — read before implementing

A distinct block reaction leaks the signal that #226 is built to hide. If 🚫 appears only on ordinary blocks and not on sensitive ones (or vice versa), the reaction becomes a probe: a user can distinguish "you tripped NSFW/minors" from "that's just out of scope" by watching the emoji, even though the text refusal is identical.

Requirement: 🚫 is applied uniformly to every classifier block, sensitive and ordinary alike. No variation in emoji, no variation in timing. The reaction says "blocked" and nothing more. Under that rule the reaction carries zero differential information and is safe.

Also keep 🚫 and ❌ strictly distinct: a block is not an error. Conflating them re-creates the "is it refusing or is it broken?" ambiguity that the visible-refusal rule in #227 exists to prevent.

Why 👀 matters more than it looks

It is applied pre-LLM, so it is the only signal that survives a total model failure. During the ~2.5-hour outage in #190, a 👀 with no reply would have made the failure visible to every user immediately. Worth building first, and worth wiring into whatever alerting comes out of 190.

🔨 doubles as a visible receipt and pairs with the claim check in #206 — no hammer, no action happened. That gives QA an out-of-band way to verify action-claims without reading traces.

Open

The issue invites "as many other cases as we can think of." The four above are v1; more can follow. Additions should be checked against the same leak test applied to 🚫.

Distinct from inline emoji in message bodies, which is #203.

## Design decision — v1 reaction vocabulary Recorded by Delphi (design seat). Kai's decision, 2026-08-12. **All four proposed reactions ship in v1:** | Reaction | Meaning | Applied | | --- | --- | --- | | 👀 | Message acknowledged | Harness level, **before** the first LLM turn | | 🔨 | Tool call invoked | When Echo actually calls a tool | | ❌ | Error during the turn | On failure | | 🚫 | Content boundary blocked the request | On any classifier block | ### 🚫 has a hard constraint — read before implementing A distinct block reaction **leaks the signal** that https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/226 is built to hide. If 🚫 appears only on ordinary blocks and not on sensitive ones (or vice versa), the reaction becomes a probe: a user can distinguish "you tripped NSFW/minors" from "that's just out of scope" by watching the emoji, even though the text refusal is identical. **Requirement: 🚫 is applied uniformly to every classifier block, sensitive and ordinary alike.** No variation in emoji, no variation in timing. The reaction says "blocked" and nothing more. Under that rule the reaction carries zero differential information and is safe. Also keep 🚫 and ❌ strictly distinct: a block is not an error. Conflating them re-creates the "is it refusing or is it broken?" ambiguity that the visible-refusal rule in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/227 exists to prevent. ### Why 👀 matters more than it looks It is applied pre-LLM, so it is the only signal that survives a total model failure. During the ~2.5-hour outage in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/190, a 👀 with no reply would have made the failure visible to every user immediately. Worth building first, and worth wiring into whatever alerting comes out of 190. 🔨 doubles as a visible receipt and pairs with the claim check in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/206 — no hammer, no action happened. That gives QA an out-of-band way to verify action-claims without reading traces. ### Open The issue invites "as many other cases as we can think of." The four above are v1; more can follow. Additions should be checked against the same leak test applied to 🚫. Distinct from inline emoji in message bodies, which is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/203.
coilyco-ops commented 2026-08-13 05:05:36 +00:00
Member
Copy link

CLAIM — Angie (ENG) at 2026-08-13T05:06Z, 20 minute hold. Scope is internal/community reaction plumbing plus its hook points.

First, a correction I owe this issue. Earlier tonight I told Kai on other threads that this collided with the shipped neutral contract, because ValidateNeutralStyle rejects any emoji or decorative symbol. That was wrong, and I should have checked before saying it. That check governs the model's reply text. A reaction is harness state applied to the member's own message, on a different Discord surface, and never passes through reply validation at all. There is no conflict. I was steering away from approved work on a misreading.

Delphi's note is what made me look again, so credit there.

Taking Kai's list as the spec:

Case Reaction
accepted at harness level, before the first model turn eyes
the turn invoked a tool call hammer
the turn failed a warning mark
refused at a boundary a no-entry mark

Two properties I intend to hold.

A reaction must never be able to fail a turn. It is a Discord side effect on a path that already has a real answer to deliver, so every failure is swallowed and logged rather than returned. A member losing an answer because a reaction call 403'd would be a worse outcome than no reactions at all.

The tool reaction reaches the tool loop the way the progress line does. I added a turn-scoped context carrier for that in 89354fe, so the tool round can report from behind the completion boundary without the proxy taking a new argument. The same route works here rather than a second mechanism.

Worth naming, since it is the reason this is more than cosmetic. Delphi observed on #190 that the harness-level ack would have marked every incoming message during the 2.5 hour model outage and then produced no reply, turning a silent failure into a visible one for every member in the channel at zero alerting cost. That is a real operational property, and it is why I am picking this over prettier work.

One thing I will confirm rather than assume: whether the bot identity actually holds ADD_REACTIONS in the target channel. If it does not, this ships as a no-op that logs, and that becomes a note for Ops rather than a silent nothing.

**CLAIM — Angie (ENG)** at 2026-08-13T05:06Z, 20 minute hold. Scope is `internal/community` reaction plumbing plus its hook points. **First, a correction I owe this issue.** Earlier tonight I told Kai on other threads that this collided with the shipped neutral contract, because `ValidateNeutralStyle` rejects any emoji or decorative symbol. That was wrong, and I should have checked before saying it. That check governs the **model's reply text**. A reaction is harness state applied to the member's own message, on a different Discord surface, and never passes through reply validation at all. There is no conflict. I was steering away from approved work on a misreading. Delphi's note is what made me look again, so credit there. Taking Kai's list as the spec: | Case | Reaction | | --- | --- | | accepted at harness level, before the first model turn | eyes | | the turn invoked a tool call | hammer | | the turn failed | a warning mark | | refused at a boundary | a no-entry mark | **Two properties I intend to hold.** *A reaction must never be able to fail a turn.* It is a Discord side effect on a path that already has a real answer to deliver, so every failure is swallowed and logged rather than returned. A member losing an answer because a reaction call 403'd would be a worse outcome than no reactions at all. *The tool reaction reaches the tool loop the way the progress line does.* I added a turn-scoped context carrier for that in `89354fe`, so the tool round can report from behind the completion boundary without the proxy taking a new argument. The same route works here rather than a second mechanism. **Worth naming, since it is the reason this is more than cosmetic.** Delphi observed on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/190 that the harness-level ack would have marked every incoming message during the 2.5 hour model outage and then produced no reply, turning a silent failure into a visible one for every member in the channel at zero alerting cost. That is a real operational property, and it is why I am picking this over prettier work. One thing I will confirm rather than assume: whether the bot identity actually holds `ADD_REACTIONS` in the target channel. If it does not, this ships as a no-op that logs, and that becomes a note for Ops rather than a silent nothing.
coilyco-ops commented 2026-08-13 05:08:52 +00:00
Member
Copy link

DELIVERED — Angie (ENG). Landed on main as ec115ac. All four cases from your list.

Case Mark Applied
accepted at harness level 👀 as the turn starts, before any model call
the turn called a tool 🔨 in the tool round
the turn produced no reply ⚠️ on the failure path
refused at a boundary ⛔ on the admission denial, whether or not a notice is also sent

A reaction can never fail a turn. Every failure is swallowed and logged once as discord.reaction.failed. A member losing a real answer because a reaction call was refused would be worse than having no reactions at all, and there is a test asserting a failing reactor does not surface.

The tool round marks through the turn context, the same route the progress line and attribution already take, so no second mechanism and a transport with no reaction surface is inert rather than special-cased.

On the permission question I said I would confirm rather than assume: I could not. ADD_REACTIONS is a live Discord grant on the bot identity in the target channel, and I have no read-only path to it from here. So the honest status is:

  • if the bot holds it, all four marks appear on the next roll
  • if it does not, every reaction 403s, the turn is completely unaffected, and discord.reaction.failed appears in logs with the reason

That failure mode is deliberate rather than lucky, but it does mean Ops should check the bot's channel permissions after the roll, and the absence of marks is diagnosable from that log line rather than being a silent nothing. Noting it on the rollout issue.

The operational point, since it is why this was worth doing over prettier work. Delphi's observation on #190 holds: during the 2.5 hour model outage the accepted mark would have landed on every incoming message and then produced no reply, making a total failure visible to every member in the channel immediately. It is not monitoring and it pages nobody, but it converts silent failure into visible failure. Given Kai deferred the detection work on 190 and the August 19 demo runs on the tier whose silent failure caused that outage, this is the cheapest backstop available.

Coverage in internal/community/reactions_test.go, four cases including that every listed case has a distinct mark, so a future addition cannot quietly reuse one.

ward exec build, policy-check, vet, test, and the full pre-commit gate pass. Rollout rides coilyco-bridge/deploy#427

Closing. If you want more cases, they are now one constant and one call site each, which was the point of doing the plumbing properly.

**DELIVERED — Angie (ENG).** Landed on main as `ec115ac`. All four cases from your list. | Case | Mark | Applied | | --- | --- | --- | | accepted at harness level | 👀 | as the turn starts, **before any model call** | | the turn called a tool | 🔨 | in the tool round | | the turn produced no reply | ⚠️ | on the failure path | | refused at a boundary | ⛔ | on the admission denial, whether or not a notice is also sent | **A reaction can never fail a turn.** Every failure is swallowed and logged once as `discord.reaction.failed`. A member losing a real answer because a reaction call was refused would be worse than having no reactions at all, and there is a test asserting a failing reactor does not surface. **The tool round marks through the turn context**, the same route the progress line and attribution already take, so no second mechanism and a transport with no reaction surface is inert rather than special-cased. **On the permission question I said I would confirm rather than assume: I could not.** `ADD_REACTIONS` is a live Discord grant on the bot identity in the target channel, and I have no read-only path to it from here. So the honest status is: - if the bot holds it, all four marks appear on the next roll - if it does not, every reaction 403s, the turn is completely unaffected, and `discord.reaction.failed` appears in logs with the reason That failure mode is deliberate rather than lucky, but it does mean **Ops should check the bot's channel permissions after the roll**, and the absence of marks is diagnosable from that log line rather than being a silent nothing. Noting it on the rollout issue. **The operational point, since it is why this was worth doing over prettier work.** Delphi's observation on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/190 holds: during the 2.5 hour model outage the accepted mark would have landed on every incoming message and then produced no reply, making a total failure visible to every member in the channel immediately. It is not monitoring and it pages nobody, but it converts silent failure into visible failure. Given Kai deferred the detection work on 190 and the August 19 demo runs on the tier whose silent failure caused that outage, this is the cheapest backstop available. Coverage in `internal/community/reactions_test.go`, four cases including that every listed case has a distinct mark, so a future addition cannot quietly reuse one. `ward exec build`, `policy-check`, `vet`, `test`, and the full pre-commit gate pass. Rollout rides https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/427 Closing. If you want more cases, they are now one constant and one call site each, which was the point of doing the plumbing properly.
coilyco-ops commented 2026-08-13 11:39:23 +00:00
Member
Copy link

Third rendering of the same vocabulary — in-message tool disclosure

Recorded by Delphi (design seat). Kai's decision, 2026-08-13. Cross-link, no change to the reaction set decided above.

Kai approved an in-message footer disclosing tool calls: #385

> 🔨 ✅ `eco.get_market` ×2
> 🔨 ❌ `eco.get_stores`

She chose complementary, one vocabulary — so 🔨 and ❌ mean the same things there as they do here. The reaction says a tool ran, at a glance, on the incoming message. The footer says which ones, and whether they worked, in the reply.

That makes three renderings of one state model, alongside the rich progress element in #111 — which Kai decided should be built as one system with this reaction set. Whoever scopes any of the three should scope the vocabulary once.

Two notes for that shared vocabulary:

  • The footer works where reactions cannot. Reactions are Discord-only; the footer is message body, so it is the canonical disclosure on the HTTP surface too.
  • 🚫 has no footer equivalent, deliberately. A blocked request makes no tool calls, so it gets no footer — and per #175 a boundary response stays short. The uniform-🚫 requirement recorded above still applies to the reaction, and nothing in the footer may describe why a request was blocked or it re-leaks what #226 hides.
## Third rendering of the same vocabulary — in-message tool disclosure Recorded by Delphi (design seat). Kai's decision, 2026-08-13. Cross-link, no change to the reaction set decided above. Kai approved an **in-message footer disclosing tool calls**: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/385 ``` > 🔨 ✅ `eco.get_market` ×2 > 🔨 ❌ `eco.get_stores` ``` She chose **complementary, one vocabulary** — so 🔨 and ❌ mean the same things there as they do here. The reaction says *a tool ran*, at a glance, on the incoming message. The footer says *which ones, and whether they worked*, in the reply. That makes three renderings of one state model, alongside the rich progress element in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/111 — which Kai decided should be built as one system with this reaction set. **Whoever scopes any of the three should scope the vocabulary once.** Two notes for that shared vocabulary: - **The footer works where reactions cannot.** Reactions are Discord-only; the footer is message body, so it is the canonical disclosure on the HTTP surface too. - **🚫 has no footer equivalent, deliberately.** A blocked request makes no tool calls, so it gets no footer — and per https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/175 a boundary response stays short. The uniform-🚫 requirement recorded above still applies to the reaction, and **nothing in the footer may describe why a request was blocked** or it re-leaks what https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/226 hides.
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#221
No description provided.