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

Job record: make a unit of work first-class, durable, and idempotent #143

New issue
Closed
opened 2026-08-12 11:10:38 +00:00 by coilyco-ops · 4 comments
coilyco-ops commented 2026-08-12 11:10:38 +00:00
Member
Copy link

Outcome

A job is a first-class object in the harness: it has an id, an owner, a state, and a lifecycle that outlives the turn that created it.

This is the foundation unit. Every other unit in this batch depends on it, and most of them collapse into small changes once it exists.

Why this is the first one

Today the harness has turns and it has side effects, and nothing in between. A Discord message starts a turn, the turn may call a tool, the turn ends. If the pod restarts mid-turn the work is simply gone, and nothing can be asked about afterwards.

That gap is what separates a chat agent from a platform. Almost every "platform" feature people want - progress, cancellation, resumption, per-run telemetry, addressable history - is a property of a durable work object, not a property of a conversation.

Scope

Item 1 - durable work items.

  • A job record with, at minimum: id, created-at, requesting principal, transport and origin (Discord channel or message, or /v1/turn), current state, terminal outcome, and error.
  • States named explicitly and transitions enumerated. A state machine, not a status string.
  • Persistence that survives pod restart. The deployment surface for this is tracked separately in coilyco-bridge/deploy (linked below), so this unit should treat the store as an interface rather than picking a backend inline.
  • Jobs are queryable by id and listable by requesting principal.

Item 3 - resumability and idempotency.

  • An idempotency key on job submission, so a retried summon does not create a second job.
  • Restart behavior defined per state. A job interrupted mid-execution must not silently double-apply an effect it already performed.
  • At-least-once delivery assumed from the transport, so the harness owns dedup.

Explicitly out of scope

  • Async submit/poll and cancellation - separate unit.
  • Any execution surface - separate unit.
  • Per-requester authority and attribution. Not approved in this batch. The job record should carry the requesting principal as a field regardless, because retrofitting an owner onto existing records is worse than carrying one from the start. Storing it grants nothing.

Acceptance

  • A job survives a pod restart and is retrievable by id afterward with its state intact.
  • Submitting the same request twice with the same idempotency key yields one job.
  • Every job carries the principal that requested it.
  • The state machine is documented, and an invalid transition is an error rather than a silent overwrite.

Related

  • Deployment surface: the persistent job store, tracked in coilyco-bridge/deploy.
  • Depends on nothing. Blocks every other unit in this batch.

Next owner

Engineer.

## Outcome A job is a first-class object in the harness: it has an id, an owner, a state, and a lifecycle that outlives the turn that created it. This is the foundation unit. Every other unit in this batch depends on it, and most of them collapse into small changes once it exists. ## Why this is the first one Today the harness has turns and it has side effects, and nothing in between. A Discord message starts a turn, the turn may call a tool, the turn ends. If the pod restarts mid-turn the work is simply gone, and nothing can be asked about afterwards. That gap is what separates a chat agent from a platform. Almost every "platform" feature people want - progress, cancellation, resumption, per-run telemetry, addressable history - is a property of a durable work object, not a property of a conversation. ## Scope **Item 1 - durable work items.** * A job record with, at minimum: id, created-at, requesting principal, transport and origin (Discord channel or message, or `/v1/turn`), current state, terminal outcome, and error. * States named explicitly and transitions enumerated. A state machine, not a status string. * Persistence that survives pod restart. The deployment surface for this is tracked separately in `coilyco-bridge/deploy` (linked below), so this unit should treat the store as an interface rather than picking a backend inline. * Jobs are queryable by id and listable by requesting principal. **Item 3 - resumability and idempotency.** * An idempotency key on job submission, so a retried summon does not create a second job. * Restart behavior defined per state. A job interrupted mid-execution must not silently double-apply an effect it already performed. * At-least-once delivery assumed from the transport, so the harness owns dedup. ## Explicitly out of scope * Async submit/poll and cancellation - separate unit. * Any execution surface - separate unit. * Per-requester authority and attribution. **Not approved in this batch.** The job record should carry the requesting principal as a field regardless, because retrofitting an owner onto existing records is worse than carrying one from the start. Storing it grants nothing. ## Acceptance * A job survives a pod restart and is retrievable by id afterward with its state intact. * Submitting the same request twice with the same idempotency key yields one job. * Every job carries the principal that requested it. * The state machine is documented, and an invalid transition is an error rather than a silent overwrite. ## Related * Deployment surface: the persistent job store, tracked in `coilyco-bridge/deploy`. * Depends on nothing. Blocks every other unit in this batch. ## Next owner Engineer.
coilyco-ops commented 2026-08-12 11:12:55 +00:00
Author
Member
Copy link

This is the foundation of a seven-issue batch. Recording the full map here so this issue can act as the entry point.

Origin

An itemized comparison of what Sirens Deep is today — a conversational agent whose entrypoint is Discord — against a dev platform whose entrypoint happens to be Discord. Sixteen gaps were identified; ten were approved for scoping.

Approved: durable work items, async execution, resumability/idempotency, cancellation, sandboxed execution, workspace, job-scoped telemetry, progress reporting, structured commands, thread-as-work-context.

Not approved, deliberately deferred: per-requester authority, attribution, authorization beyond admission, approval gates, per-task secret brokering, queue and backpressure.

The batch

Harness — coilyco-gaming/sirens-echo

Unit Covers
this issue job record, idempotency
#144 async submit/poll/notify, cancellation
#145 Ward-backed execution, per-job workspace
#146 job-scoped telemetry, progress reporting
#147 structured commands, thread-to-job binding

Deployment — coilyco-bridge/deploy

Unit Enables
coilyco-bridge/deploy#391 persistent job store — this issue
coilyco-bridge/deploy#392 execution workspace, Ward reach — issue 145

Dependency shape

Everything depends on this issue and nothing else depends on anything else. 144, 145, 146, and 147 are independent of each other and can proceed in parallel once the job record exists.

That is not an accident of how the batch was cut. Nine of the sixteen original gaps turned out to be the same missing thing — there is no object between "a message" and "an effect." Progress, cancellation, resumption, per-run telemetry, and addressable history are all properties of a durable work object. Build the object and most of them become small.

Sequencing note

#145 and coilyco-bridge/deploy#392 add an execution surface while per-requester authority and attribution stay deferred. Every job will act as one identity with no audit distinction between requesters.

That is sound while admission is a direct-message allowlist of one account. coilyco-bridge/deploy#365 proposes opening Sirens Deep to a Discord guild on 2026-08-19. Those two changes should not land in the same window; if the guild opens first, per-requester authority should precede execution. Both execution issues carry this note.

Batched by ops (Olaf).

This is the foundation of a seven-issue batch. Recording the full map here so this issue can act as the entry point. ## Origin An itemized comparison of what Sirens Deep is today — a conversational agent whose entrypoint is Discord — against a dev platform whose entrypoint happens to be Discord. Sixteen gaps were identified; ten were approved for scoping. Approved: durable work items, async execution, resumability/idempotency, cancellation, sandboxed execution, workspace, job-scoped telemetry, progress reporting, structured commands, thread-as-work-context. **Not approved, deliberately deferred:** per-requester authority, attribution, authorization beyond admission, approval gates, per-task secret brokering, queue and backpressure. ## The batch **Harness — `coilyco-gaming/sirens-echo`** | Unit | Covers | | --- | --- | | **this issue** | job record, idempotency | | https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/144 | async submit/poll/notify, cancellation | | https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/145 | Ward-backed execution, per-job workspace | | https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/146 | job-scoped telemetry, progress reporting | | https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/147 | structured commands, thread-to-job binding | **Deployment — `coilyco-bridge/deploy`** | Unit | Enables | | --- | --- | | https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/391 | persistent job store — this issue | | https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/392 | execution workspace, Ward reach — issue 145 | ## Dependency shape Everything depends on this issue and nothing else depends on anything else. 144, 145, 146, and 147 are independent of each other and can proceed in parallel once the job record exists. That is not an accident of how the batch was cut. Nine of the sixteen original gaps turned out to be the same missing thing — there is no object between "a message" and "an effect." Progress, cancellation, resumption, per-run telemetry, and addressable history are all properties of a durable work object. Build the object and most of them become small. ## Sequencing note https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/145 and https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/392 add an execution surface while per-requester authority and attribution stay deferred. Every job will act as one identity with no audit distinction between requesters. That is sound while admission is a direct-message allowlist of one account. https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/365 proposes opening Sirens Deep to a Discord guild on 2026-08-19. Those two changes should not land in the same window; if the guild opens first, per-requester authority should precede execution. Both execution issues carry this note. Batched by ops (Olaf).
coilyco-ops commented 2026-08-12 11:56:14 +00:00
Author
Member
Copy link

Direction: the store is decided, and so is the timing

Direction from Kai, 2026-08-12 session. This is the batch entry point, so the batch-wide decisions are recorded here and referenced from the other four.

Timing

The demo track owns the week to August 19. This batch starts August 20 and is the priority from then on.

"The batch is the real work" describes where the value is; August 19 is a hard date with a permanent public recording behind it. Both are true and they do not compete for the same seven days.

Ownership: one seat (claude) carries the whole portfolio, demo track and batch alike.

The persistent store: Postgres

The issue says to treat the store as an interface rather than picking a backend inline, with the choice tracked in coilyco-bridge/deploy#391.

That choice is made: Postgres, and it is already running. Build against it directly. No interface indirection is needed for the purpose of deferring a backend decision, because there is no longer a decision to defer.

This unblocks the acceptance criterion that a job survives a pod restart and is retrievable by id afterward with its state intact — it is testable from day one rather than pending another repository's ticket.

Items 5 and 6 are un-deferred

The batch comment lists per-requester authority and attribution under not approved, deliberately deferred. Kai has approved both as scope.

They are not yet issues. The engineer files them as two separate issues in this repository, written to this batch's format — Outcome, Why, Scope, Acceptance, Depends on — and positioned as blockers on #145, per the sequencing decision recorded there.

This changes the batch's dependency shape. It is no longer "everything depends on #143 and nothing else depends on anything else": #145 now depends on #143 and on both new issues.

Unchanged in this issue

Everything else stands. In particular the point that the job record carries the requesting principal as a field regardless — that was correct when authority was deferred and it is still correct now that it is not. Storing it grants nothing; retrofitting an owner onto existing records is worse than carrying one from the start.

The state machine, the idempotency key, and per-state restart behavior are all unchanged.

## Direction: the store is decided, and so is the timing Direction from Kai, 2026-08-12 session. This is the batch entry point, so the batch-wide decisions are recorded here and referenced from the other four. ## Timing **The demo track owns the week to August 19. This batch starts August 20 and is the priority from then on.** "The batch is the real work" describes where the value is; August 19 is a hard date with a permanent public recording behind it. Both are true and they do not compete for the same seven days. Ownership: one seat (claude) carries the whole portfolio, demo track and batch alike. ## The persistent store: Postgres The issue says to treat the store as an interface rather than picking a backend inline, with the choice tracked in `coilyco-bridge/deploy#391`. **That choice is made: Postgres, and it is already running.** Build against it directly. No interface indirection is needed for the purpose of deferring a backend decision, because there is no longer a decision to defer. This unblocks the acceptance criterion that a job survives a pod restart and is retrievable by id afterward with its state intact — it is testable from day one rather than pending another repository's ticket. ## Items 5 and 6 are un-deferred The batch comment lists per-requester authority and attribution under **not approved, deliberately deferred**. **Kai has approved both as scope.** They are not yet issues. The engineer files them as **two separate issues** in this repository, written to this batch's format — Outcome, Why, Scope, Acceptance, Depends on — and positioned as **blockers on #145**, per the sequencing decision recorded there. This changes the batch's dependency shape. It is no longer "everything depends on #143 and nothing else depends on anything else": #145 now depends on #143 *and* on both new issues. ## Unchanged in this issue Everything else stands. In particular the point that the job record carries the requesting principal as a field regardless — that was correct when authority was deferred and it is still correct now that it is not. Storing it grants nothing; retrofitting an owner onto existing records is worse than carrying one from the start. The state machine, the idempotency key, and per-state restart behavior are all unchanged.
coilyco-ops commented 2026-08-12 11:58:51 +00:00
Author
Member
Copy link

Items 5 and 6 are filed — updated batch map

Following the decision above, the two un-deferred items now exist as issues. Updating the batch map on this entry point so it stays the single place to read the shape.

Harness — coilyco-gaming/sirens-echo

Unit Covers
#143 (this issue) job record, idempotency
#144 async submit/poll/notify, cancellation
#145 Ward-backed execution, per-job workspace
#146 job-scoped telemetry, progress reporting
#147 structured commands, thread-to-job binding
#150 per-requester authority — item 5, newly approved
#151 attribution — item 6, newly approved

Deployment — coilyco-bridge/deploy

Unit Enables
deploy#391 persistent job store — superseded in effect: Postgres is chosen and already running
deploy#392 execution workspace, Ward reach — #145

Revised dependency shape

The original comment's "everything depends on #143 and nothing else depends on anything else" no longer holds. Current shape:

  • #143 depends on nothing. Blocks everything.
  • #144, #146, #150, #151, and the thread-binding half of #147 all depend on #143 alone and can proceed in parallel once it lands.
  • #145 depends on #143, #150, and #151. It is last, deliberately.
  • The structured-command half of #147 additionally waits on the applications.commands scope decision deferred at #127.

#151 before #150 is the recommended order within the pair; see the sequencing note there.

Still not approved

Items 7 and 8 — authorization beyond admission, approval gates — plus per-task secret brokering and queue/backpressure. Unchanged from the original batch. Kai un-deferred items 5 and 6 only, and both new issues state that boundary so neither expands into it.

## Items 5 and 6 are filed — updated batch map Following the decision above, the two un-deferred items now exist as issues. Updating the batch map on this entry point so it stays the single place to read the shape. **Harness — `coilyco-gaming/sirens-echo`** | Unit | Covers | | --- | --- | | **#143** (this issue) | job record, idempotency | | #144 | async submit/poll/notify, cancellation | | #145 | Ward-backed execution, per-job workspace | | #146 | job-scoped telemetry, progress reporting | | #147 | structured commands, thread-to-job binding | | **#150** | per-requester authority — item 5, newly approved | | **#151** | attribution — item 6, newly approved | **Deployment — `coilyco-bridge/deploy`** | Unit | Enables | | --- | --- | | deploy#391 | persistent job store — **superseded in effect**: Postgres is chosen and already running | | deploy#392 | execution workspace, Ward reach — #145 | ## Revised dependency shape The original comment's "everything depends on #143 and nothing else depends on anything else" no longer holds. Current shape: * **#143** depends on nothing. Blocks everything. * **#144**, **#146**, **#150**, **#151**, and the thread-binding half of **#147** all depend on #143 alone and can proceed in parallel once it lands. * **#145** depends on #143, **#150**, and **#151**. It is last, deliberately. * The structured-command half of **#147** additionally waits on the `applications.commands` scope decision deferred at #127. `#151` before `#150` is the recommended order within the pair; see the sequencing note there. ## Still not approved Items 7 and 8 — authorization beyond admission, approval gates — plus per-task secret brokering and queue/backpressure. Unchanged from the original batch. Kai un-deferred items 5 and 6 only, and both new issues state that boundary so neither expands into it.
coilyco-ops commented 2026-08-12 12:14:07 +00:00
Author
Member
Copy link

Correction: the store is provisioned, and it brings requirements with it

My earlier comment said deploy#391 was "superseded in effect." That is wrong and I am correcting it before anyone builds on it. 391 was not superseded — it was implemented, in coilyco-bridge/deploy#393, merged 2026-08-12T11:40:45Z. I was reading a checkout from 08:15 that predated the work.

The correction matters because 391 and 393 settled several things this issue now inherits rather than gets to decide.

What exists

Per lane — sirens-deep and sirens-echo, both — four objects copied from services/eco-gnome/deploy/main.yml:

  • postgres:17, one replica, strategy: Recreate
  • 2Gi local-path RWO PVC, pinned to kai-server
  • ClusterIP Service on 5432
  • ExternalSecret templating one SSM SecureString into two keys: POSTGRES_PASSWORD for the database, and DSN for the harness

Rollout ordering puts the store ahead of the app on both lanes, so the harness resolves its store at startup rather than on first write.

Not verified live. PR 393 lists what an operator still has to confirm: ExternalSecret sync, PVC binding, Postgres initialising on a volume root it does not own, and pg_isready readiness.

Four things this issue now owns

1. Name the DSN environment variable. Deliberately left to this issue. The Secret already carries the DSN key; neither values file wires it yet, so adding it is one extraEnv entry once the name exists. Ops proposed SIRENS_ECHO_JOB_STORE_DSN. Pick it or pick better, but pick — nothing connects until it is named.

The DSN is spelled as a URL rather than a keyword string, because the harness is Go. Passwords are alphanumeric by construction so no percent-encoding is involved.

2. Migrations are harness-owned and applied on boot. No migration Job exists in the deploy repo or anywhere else, by design. Copy eco-gnome's shape: apply on boot with a retry loop while Postgres warms. This is a real requirement on this issue that its body does not currently mention.

3. Echo gets a store too, so decide what Echo does with it. deploy#391 scope item 3 named the trap directly:

The two lanes share an image. If the harness gains a job store, Echo either gets one or is explicitly configured without one. A half-configured lane that starts and then fails on first write is the bad outcome.

Both stores are now provisioned. This issue has to make Echo's behaviour deliberate rather than incidental.

4. There are no backups. Recorded as a decision, not an oversight. The PVC is the only copy; a lost disk or PVC loses job history including in-flight records. Persistent is not durable here, and the state machine should not assume otherwise.

Unchanged

Postgres is still the answer and it is still already running, so this issue is not blocked. Everything above is detail arriving with it rather than a reversal.

## Correction: the store is provisioned, and it brings requirements with it My earlier comment said `deploy#391` was "superseded in effect." **That is wrong and I am correcting it before anyone builds on it.** 391 was not superseded — it was implemented, in `coilyco-bridge/deploy#393`, merged 2026-08-12T11:40:45Z. I was reading a checkout from 08:15 that predated the work. The correction matters because 391 and 393 settled several things this issue now inherits rather than gets to decide. ## What exists Per lane — `sirens-deep` **and** `sirens-echo`, both — four objects copied from `services/eco-gnome/deploy/main.yml`: * `postgres:17`, one replica, `strategy: Recreate` * 2Gi `local-path` RWO PVC, pinned to kai-server * ClusterIP Service on 5432 * ExternalSecret templating one SSM SecureString into two keys: `POSTGRES_PASSWORD` for the database, and **`DSN`** for the harness Rollout ordering puts the store ahead of the app on both lanes, so the harness resolves its store at startup rather than on first write. **Not verified live.** PR 393 lists what an operator still has to confirm: ExternalSecret sync, PVC binding, Postgres initialising on a volume root it does not own, and `pg_isready` readiness. ## Four things this issue now owns **1. Name the DSN environment variable.** Deliberately left to this issue. The Secret already carries the `DSN` key; neither values file wires it yet, so adding it is one `extraEnv` entry once the name exists. Ops proposed **`SIRENS_ECHO_JOB_STORE_DSN`**. Pick it or pick better, but pick — nothing connects until it is named. The DSN is spelled as a URL rather than a keyword string, because the harness is Go. Passwords are alphanumeric by construction so no percent-encoding is involved. **2. Migrations are harness-owned and applied on boot.** No migration Job exists in the deploy repo or anywhere else, by design. Copy eco-gnome's shape: apply on boot with a **retry loop while Postgres warms**. This is a real requirement on this issue that its body does not currently mention. **3. Echo gets a store too, so decide what Echo does with it.** `deploy#391` scope item 3 named the trap directly: > The two lanes share an image. If the harness gains a job store, Echo either gets one or is explicitly configured without one. A half-configured lane that starts and then fails on first write is the bad outcome. Both stores are now provisioned. This issue has to make Echo's behaviour deliberate rather than incidental. **4. There are no backups.** Recorded as a decision, not an oversight. The PVC is the only copy; a lost disk or PVC loses job history including in-flight records. Persistent is not durable here, and the state machine should not assume otherwise. ## Unchanged Postgres is still the answer and it is still already running, so this issue is not blocked. Everything above is detail arriving with it rather than a reversal.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
aos/claude/sj87-entity-attribute
aos/claude/sj87-challenge
aos/claude/turn-duration-buckets
aos/claude/turn-stages-over-cap
aos/claude/turn-stages-hold-doc
aos/claude/turn-iteration-cap
book-leads-the-glyphs
science-and-web-culture-packs
record-lane-role-voice-pairings
catalogue-stage-phrase
progress-rows-one-knob
skill-read-worklog-detail
librarian-lookup-first
librarian-person-package
feat/dowel-no-boundaries
aos/claude/gh1035-no-blank-posts
aos/claude/gh1036-harness-thread-name
fix/thread-names
feat/trajectory-completes
fix/prompt-budgets
aos/claude/docs-cut-2
aos/claude/ka54-thread-ownership
aos/claude/admission-bound
aos/claude/gh1025-roster-reexport
aos/claude/docs-strip-archaeology
feat/temporal-mcp
aos/claude/dowel-board-moxn-write-boundaries
aos/claude/ue65-moxn-write-framing
aos/claude/progress-backoff
aos/claude/bound-scratch-search-2
aos/claude/unblock-main
aos/claude/tool-breaker
fix/roster-core-eager
aos/claude/finish-dowel-rename
fix/971-skill-contract
aos/claude/model-answered-not-unavailable
aos/claude/mcp-singular-command
task/moxn-and-temporal-skills
aos/claude/ue65-temporal-brand
task/dowel-site-work-tier
aos/claude/ue65-roster-drift
fix/dropped-turn-always-speaks
aos/claude/folded-ask-coverage
aos/claude/dowel-board
aos/claude/dowel-pronouns
feat/trajectory-keyed-on-the-message
aos/claude/coalesce-discord-lane
task/derive-shipped-profiles
fix/ship-the-dowel-skill-root
aos/claude/eval-context
fix/bundle-references-reachable
aos/claude/eval-docs-one-page
aos/claude/dowel-engineer-suite
fix/catalogue-clone-cache
feat/engineer-role-graph
task/free-the-config-numbers
aos/claude/dowel-site-work
aos/claude/dowel-prose
aos/claude/mx76-derive-knobs
issue-859-on-demand-skill-reads
issue-651-ship-well-formed-replies
issue-852-filing-validity
issue-916-calculator-tool
issue-854-feature-flag-table
issue-866-role-mention-summons
issue-858-grounding-bound-per-server
issue-899-progress-keeps-updating
issue-900-rollup-mirrors-worklog
issue-901-raise-progress-cadence
issue-904-thread-title-length
issue-905-http-reachability
issue-855-turn-clock
issue-895-silent-turn
issue-873-mcp-tool-span-error
issue-878-settle-dropped-jobs
aos/claude/aw85-se-bands
aos/claude/hs68-model-rejected
aos/claude/hs68-effect-telemetry
aos/claude/hs68-temporal-mirror
aos/claude/hs68-prompt-commands
aos/claude/hs68-model-idle-timeout
aos/claude/hs68-prompt-command-intent
aos/claude/hs68-consult-label-name
aos/claude/hs68-grant-denial-403
aos/claude/hs68-queued-jobs-dropped
aos/claude/hs68-knob-guard
aos/claude/bk79-agent-folders
aos/claude/bk79-own-instructions
aos/claude/ym96-docs-band
aos/claude/bk79-server-instructions
aos/claude/aw85-mcp-beaver-doc
aos/claude/bk79-session-workspace
aos/claude/yt58-org-relationship
aos/claude/bk79-numeric-config
aos/claude/xu59-just-boundaries
aos/claude/xu59-eval-board
aos/claude/bk79-phrase-telemetry
aos/claude/bk79-object-emoji
aos/claude/xh55-otlp-logs
aos/claude/aw85-thread-prefill
aos/claude/wy58-thread-prefill-always
aos/claude/wy58-thread-prefill
aos/claude/xh55-move-to-repo
aos/claude/wy58-thread-title-length
aos/claude/xh55-filing-trigger
aos/claude/yt58-worklog-embed
aos/claude/aw85-relative-brevity
aos/claude/xh55-reasoning-roundtrip
aos/claude/yt58-clock-rotation
aos/claude/yt58-unbreak-main
aos/claude/bk79-test-build-break
aos/claude/yt58-partial-refusal
aos/claude/aw85-turn-failure-classify
aos/claude/aw85-outbound-spill
aos/claude/xh55-budget-spent-cause
aos/claude/wy58-bundles-not-content
aos/claude/wy58-refusal-reason
aos/claude/yt58-role-snapshot-gate
aos/claude/xh55-docker-probe
aos/claude/bk79-grounding-tools
aos/claude/az59-gate-span
aos/claude/az59-pg-jobstore
eng/roster-request-headers
eng/roster-headers
eng/list-the-mcps
aos/claude/mg96-fm
eng/name-echos-seat
eng/unpin-the-card-wording
olaf/remove-irl-physical
aos/claude/mg96
eng/echo-composes-ops
quail/two-rows-not-four
fix/two-failures-two-verdicts
feat/an-emitted-message-is-not-emitted-twice
quail/partial-coverage-outcome
feat/ten-minutes-or-ten-messages
feat/a-waiting-turn-says-how-long
feat/a-job-may-emit-content
quail/round-fanout-unbounded
quail/adversarial-reply-ceiling
docs/list-the-open-pull-requests
quail/principal-id-stays-out-of-the-prompt
fix/every-label-in-a-wildcard-prefix-is-a-label
docs/the-battery-assumes-two-checks-it-does-not-run
fix/a-rest-failure-keeps-its-status
quail/retag-label-rows
quail/adjacency-guard-row
test/pin-names-the-issue-that-owns-it
test/pin-points-at-a-live-issue
quail/job-outcome-discarded
fix/repair-exhaustion-is-not-an-outage
quail/reasoning-omitempty-pin
docs/label-id-silently-drops
quail/gating-pack-markup-gap
fix/instance-name-reads-identity
docs/indistinguishable-542-resolution
fix/instance-name-not-a-live-service
quail/unwired-capability-guard
fix/repair-path-reasoning-content
quail/indistinguishable-values-recurrence
quail/identity-short-form-rows
quail/repair-path-reasoning-content
docs/verify-a-write-landed-claude
quail/host-label-shape-corpus
docs/a-deploy-owned-file-has-two-shapes-claude
fix/a-roster-path-must-name-servers-claude
fix/every-label-before-the-suffix-claude
fix/a-first-label-must-exist-claude
feat/tune-the-timeouts-from-deployment-claude
qa/protocol-limits-are-not-dials
feat/a-wildcard-is-not-a-suffix-claude
feat/retry-what-fails-fast-claude
fix/name-the-deliberate-hold-claude
test/the-access-check-exit-codes-claude
build/ship-the-access-check-claude
qa/callers-not-reachability
qa/pin-the-unwired-thread-binding
feat/an-offline-access-policy-gate-claude
test/the-notice-detaches-twice-claude
docs/say-what-the-job-thread-does-claude
fix/a-notice-does-not-thread-claude
fix/one-invocation-is-a-phrase-claude
fix/a-moment-ago-is-this-turn
fix/main-is-red-on-the-adverb-row
fix/an-adverb-does-not-break-the-auxiliary
qa/score-the-575-fix
feat/a-reply-names-its-subject
eng/a-turn-is-not-the-past
fix/since-you-asked-is-this-turn
docs/a-default-that-reads-as-an-answer
fix/a-nameless-tool-is-not-the-server
qa/pin-the-outage-state
fix/a-session-lifetime-is-not-a-latency
fix/an-undated-passive-is-still-a-claim
fix/main-is-red-on-the-corpus
fix/an-undated-passive-is-a-claim
eng/a-session-is-not-a-request
fix/a-self-claim-in-the-simple-past
qa/extend-grounding-corpus
fix/a-tool-never-offered-is-not-a-tool-declined
eng/one-doc-for-the-tracker-surface
eng/say-what-is-switched-on
fix/evaluation-is-not-the-production-service
qa/pin-the-listing-attribute
eng/split-five-docs-off-the-cap
eng/concurrent-means-goroutines
eng/split-the-tracker-surface
test/the-first-label-of-a-hostname
fix/a-cache-hit-is-not-a-round-trip
qa/pin-the-budget-ladder
fix/the-first-label-of-a-hostname
eng/the-scratchpad-assumes-one-replica
fix/a-person-is-named-in-prose
docs/jobs-are-single-process
qa/enumerate-the-mention-positions
eng/split-the-response-inventory
fix/green-main-doc-cap-and-stale-characterizations
eng/main-is-green-again
eng/split-the-mention-scope
fix/mentions-doc-over-cap
qa/unredden-the-code-span-pin
qa/pin-the-code-span-collision
eng/code-spans-are-not-prose
feat/a-thread-title-says-what-it-is-for
fix/discord-markup-is-not-prose-either
eng/mark-the-turn-once
fix/a-name-in-a-url-is-not-a-person
qa/pin-every-reaction-is-emitted
eng/mentions-skip-link-spans
fix/one-step-owns-every-service-suffix
qa/pin-the-mention-url-collision
docs/the-roster-is-member-influenced
docs/what-a-mention-can-reach
qa/pin-the-documented-glyphs
feat/naming-someone-reaches-them
qa/pin-the-sandbox-label-wiring
qa/pin-the-truncated-receipt
feat/the-harness-labels-what-it-files
qa/compare-a-case-by-marshalling
fix/one-spelling-for-the-status-vocabulary
qa/declare-pack-divergence
fix/the-reactions-match-the-approved-vocabulary
fix/a-file-path-is-just-a-file-path
qa/pin-the-mapped-tailnet-form
fix/a-truncated-page-says-so
fix/the-extraction-case-detects-a-dump
docs/the-consult-label-tracks-the-thread
feat/the-eval-can-forge-a-turn
fix/refuse-the-tailnet-range
qa/pin-the-fail-heading-count
feat/a-bounded-fetch-tool
fix/preserve-the-longform-probe-pack
qa/pin-the-lane-gate
qa/preserve-the-longform-pack
fix/the-prompt-is-not-a-secret
fix/a-reference-never-loses-to-the-footer
qa/preserve-the-probe-packs
feat/a-trusted-caller-on-the-tailnet
fix/capability-tells-the-truth-about-the-scratchpad
qa/echo-battery-negative-control
fix/one-fail-block-not-two
feat/tool-call-footer
fix/guard-the-extraction-case
feat/canonical-phrases-by-key
fix/the-progress-line-is-a-reply-too
qa/pin-the-agent-recognition-case
qa/pin-the-tool-name-markup-guards
feat/five-second-buffer
fix/a-failing-case-shows-the-reply
fix/extraction-case-stops-penalising-compliance
fix/a-security-case-that-penalises-compliance
feat/deny-actually-denies
feat/job-refusals-reach-telemetry
fix/land-the-harness-refresh-on-main
feat/a-long-reply-gets-a-thread
feat/the-thinking-line-shows-it-is-working
feat/roster-hour-ttl-and-refresh
refactor/every-number-in-one-file
feat/agent-can-refresh-its-roster
fix/size-refusal-is-not-a-parse-error
fix/budget-base-above-the-reasoning-floor
fix/one-number-for-the-progress-cadence
fix/gate-sees-a-new-file
fix/one-meaning-for-channel-id
fix/look-up-verbs-cannot-match
feat/recognise-a-trace-lookup-request
feat/discord-identifiers-on-the-turn-span
fix/budget-failure-names-the-reasoning-spend
feat/notice-carries-the-trace-id
qa/cut-run-stops-calling
docs/merge-lane-closing-reference
eng/gate-knows-the-lane
eng/feature-inventory-catchup
fix/rate-dataset-survives-a-cut-run
test/consolidate-pack-coverage
pr-lane-318
fix/flip-unknown-field-rows
test/turn-unknown-fields
fix/rate-doc-over-cap
test/language-scope-characterization
fix/pronoun-case-cannot-fire
fix/main-red-again
fix/main-is-red-doc-cap
fix/gate-negated-accuracy-claim
fix/stale-skip-allowlist-note
test/definition-must-reject
test/gate-covers-every-pack
test/bucket-table-bound
test/compose-deny-offline
fix/symlink-test-skips-itself
test/build-revision
fix/eviction-corpus-green
test/eviction-corpus
test/duration-config
test/rune-boundary
test/send-bounds
test/reserved-path-spellings
test/data-borne-injection
test/scratch-partition-collision
test/capability-docs-all
test/injection-cases
docs/http-contract-retry-after
test/capability-reach
test/rate-cases-from-192
test/score-order
test/capability-doc-matches-code
test/grounding-action-claim-corpus
test/http-turn-contract
feat/require-rate-limit-on-open-guilds
fix/pr-image-build
fix/compose-stage-inputs
feat/sirens-deep-compose-wiring
fix/deep-forgejo-mcp
refactor/evaluation-pack-yaml
coilysiren-patch-1
feat/deep-steam-mcp
feat/drop-issue-envelope
fix/dm-needs-no-mention
fix/pronoun-defaults
chore/aos-precommit-v0.18-lint-backlog
fix/harness-attribution-and-forgejo-detail
fix/tool-inflated-completion-budget
feat/sirens-deep-compose
feat/banner-hires
feat/banner
feat/sirens-deep-mark
feat/sirens-deep-transparent
feat/prompt-snapshots
fix/policy-check-image-context
sirens-deep-admission-hardening
docs/drop-private-image-claim
feat/thread-scoped-replies
issue-67
feat/sirens-community-harness
No results found.
Labels
Clear labels   
move-to-repo
coilyco-bridge-deploy
 issue belongs in the coilyco-bridge/deploy repo

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

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

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

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

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

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

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

  
autonomy
headless
 The agent can perform the work on its own

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

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

  
priority
P0
 priority tier

  
priority
P1
 priority tier

  
priority
P2
 priority tier

  
priority
P3
 priority tier

  
priority
P4
 priority tier

  
role/ai
requires work from the AI Engineer role

  
role/creator
requires work from Content Creator role

  
role/design
requires work from the design role

  
role/director
requires work from the director role

  
role/engineer
requires work from the engineer role

  
role/exec
requires work from the exec role

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

  
role/ops
requires work from the ops role

  
role/qa
requires work from the QA role

No labels
move-to-repo
coilyco-bridge-deploy
move-to-repo
coilyco-flight-deck-agent-compose
move-to-repo
coilyco-gaming-eco-app
move-to-repo
coilysiren-inbox
move-to-repo
unknown
🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
c#
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo#143
No description provided.