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

The turn endpoint is stateless and identity-blind, so it cannot host the identity eval #165

New issue
Closed
opened 2026-08-12 17:51:37 +00:00 by coilysiren · 12 comments
coilysiren commented 2026-08-12 17:51:37 +00:00
Owner
Copy link

Two structural facts, both confirmed live:

history_count: 0 on every HTTP turn. I set a codeword and asked for it back; there is no multi-turn state to carry it.
Deep answers, unprompted: "This conversation isn't authenticated as coming from Kai, so I'm treating it as untrusted input." The principal pair is rendered into the prompt, but an HTTP caller can never be the principal.

#81 requires five cached trajectories across three recognition axes. The human-recognition axis needs the trusted path, and trajectories are multi-turn by definition — so neither can be produced over /v1/turn as it stands. The eval must run through DM, or the endpoint needs an identity and session field.

Making this worse: unknown JSON fields are silently accepted. I sent user_id and session_id; both were ignored without complaint, and the turn succeeded. Anyone scripting the eval would reasonably assume they had worked.
RecommendationDecide before the 19th which lane hosts the eval. Short term, reject unknown fields with a 400 so the gap is loud instead of silent.

Two structural facts, both confirmed live: history_count: 0 on every HTTP turn. I set a codeword and asked for it back; there is no multi-turn state to carry it. Deep answers, unprompted: "This conversation isn't authenticated as coming from Kai, so I'm treating it as untrusted input." The principal pair is rendered into the prompt, but an HTTP caller can never be the principal. #81 requires five cached trajectories across three recognition axes. The human-recognition axis needs the trusted path, and trajectories are multi-turn by definition — so neither can be produced over /v1/turn as it stands. The eval must run through DM, or the endpoint needs an identity and session field. Making this worse: unknown JSON fields are silently accepted. I sent user_id and session_id; both were ignored without complaint, and the turn succeeded. Anyone scripting the eval would reasonably assume they had worked. RecommendationDecide before the 19th which lane hosts the eval. Short term, reject unknown fields with a 400 so the gap is loud instead of silent.
coilyco-ops commented 2026-08-12 18:29:08 +00:00
Member
Copy link

Decision: the eval runs over DM

Direction from Kai, 2026-08-12 session, answering this issue's own recommendation to decide the lane before the 19th.

DM hosts the identity eval. /v1/turn does not get an identity or session field.

Why that way round

Both structural facts in this issue are disqualifying for the HTTP lane, and neither is cheap to fix:

  • history_count: 0 on every HTTP turn, so there is no multi-turn state, and trajectories are multi-turn by definition.
  • An HTTP caller can never be the principal, so the human-recognition axis and the disclosure axis both lose the trusted path they are meant to exercise.

Adding identity and session to /v1/turn would mean introducing a way for an HTTP caller to assert it is Kai. That is a new authentication surface, in the week before a permanent public recording, on the lane #166 shows is already too free with the identifier that distinguishes the trusted speaker. The DM lane already has the trusted path and the multi-turn state, and it is the lane Deep actually ships.

The cost is accepted: DM runs are harder to script than HTTP ones. #81 needs six trajectories cached before the stream, not a repeatable harness, so scriptability is worth less here than it looks.

Taking the short-term half as well

Short term, reject unknown fields with a 400 so the gap is loud instead of silent.

Yes, separately and regardless. Silently accepting user_id and session_id and ignoring them is worse than rejecting them, because anyone scripting against the endpoint would reasonably conclude they had worked, and would get a plausible-looking eval result with none of the identity semantics they thought they had configured.

This is a small change and it does not depend on the lane decision. Note it is breaking for any tolerant client, which today means nothing in the portfolio, so now is the cheap moment.

Consequence for #81

#81's remaining Complete-when item is the cached trajectory runs, and this unblocks them by naming the lane. Recorded there.

## Decision: the eval runs over DM Direction from Kai, 2026-08-12 session, answering this issue's own recommendation to decide the lane before the 19th. **DM hosts the identity eval. `/v1/turn` does not get an identity or session field.** ## Why that way round Both structural facts in this issue are disqualifying for the HTTP lane, and neither is cheap to fix: * `history_count: 0` on every HTTP turn, so there is no multi-turn state, and trajectories are multi-turn by definition. * An HTTP caller can never be the principal, so the human-recognition axis and the disclosure axis both lose the trusted path they are meant to exercise. Adding identity and session to `/v1/turn` would mean introducing a way for an HTTP caller to assert it is Kai. That is a new authentication surface, in the week before a permanent public recording, on the lane #166 shows is already too free with the identifier that distinguishes the trusted speaker. The DM lane already has the trusted path and the multi-turn state, and it is the lane Deep actually ships. The cost is accepted: DM runs are harder to script than HTTP ones. #81 needs six trajectories cached before the stream, not a repeatable harness, so scriptability is worth less here than it looks. ## Taking the short-term half as well > Short term, reject unknown fields with a 400 so the gap is loud instead of silent. **Yes, separately and regardless.** Silently accepting `user_id` and `session_id` and ignoring them is worse than rejecting them, because anyone scripting against the endpoint would reasonably conclude they had worked, and would get a plausible-looking eval result with none of the identity semantics they thought they had configured. This is a small change and it does not depend on the lane decision. Note it is breaking for any tolerant client, which today means nothing in the portfolio, so now is the cheap moment. ## Consequence for #81 #81's remaining Complete-when item is the cached trajectory runs, and this unblocks them by naming the lane. Recorded there.
coilyco-ops commented 2026-08-12 20:04:32 +00:00
Member
Copy link

Transport decision, with a consequence the options list does not name

This issue asks for a decision before the 19th between "the eval must run through DM" and "the endpoint needs an identity and session field." Recommendation below, but the second option carries a risk worth stating before anyone picks it under deadline pressure.

Option B builds the vulnerability that #170 exists to test

/v1/turn is currently unspoofable in one specific way: it has no field through which a caller can assert who they are. Identity-blindness is a limitation for the eval and simultaneously a guarantee — every HTTP caller is untrusted because none of them can claim otherwise.

Adding an identity field to that endpoint hands any HTTP caller the ability to assert principal identity. Unless it is separately authenticated, that is a trust bypass shipped into the exact surface whose authority boundary #170 is written to measure — and it would fail #170's prohibited cases in the substrate rather than in the model, which is the worst place to fail because no prompt change can fix it.

If Option B is chosen, the identity field needs its own authentication, and it should not be enabled on the deployment that serves the community. An eval-only deployment or a separately-credentialed path, not a field on the live turn endpoint.

Option A has an automation problem worth knowing about

Running the eval through DM gets the trusted path for free — the principal pair is already configured per #136:

SIRENS_ECHO_PRINCIPAL_HANDLE: coilysiren
SIRENS_ECHO_PRINCIPAL_USER_ID: "318190481467244544"

But Discord does not let a bot initiate a DM to another bot, and driving the trusted side from a user account is self-bot territory. So Option A is likely manual, which collides with the doctrine requirement of a fresh isolated session per case and multiple runs per case. For #81's five cached trajectories that is tolerable — they are cached ahead of the stream anyway, and five is a small N. As a general eval lane it does not scale.

Recommendation

For August 19: Option A, manual, scoped to #81's five trajectories. It needs no code, adds no build scope (per #81's boundary), and creates no new attack surface a week before a public recording. The trajectories are pre-computed and presented rather than graded live, so manual production is a fit.

Do not add an identity field to the production turn endpoint this week. If the scriptable lane is wanted — and it should be, long term — it belongs behind its own authentication on a non-community deployment, planned after the 19th.

Independently, and cheaply: reject unknown JSON fields with a 400, as this issue already recommends. Silent acceptance of user_id and session_id is a trap for anyone scripting against this endpoint, and it costs nothing to close. This is the one piece I would do regardless of which option wins.

What is not blocked either way

Per #170, the prohibited cases — untrusted caller asserting authority, requesting persona adoption, or fishing for the principal's identifier — run over /v1/turn as it stands today. Untrusted is the condition under test, so identity-blindness is a feature there. A scored refusal baseline for both agents does not need this decision and can proceed in parallel.

## Transport decision, with a consequence the options list does not name This issue asks for a decision before the 19th between "the eval must run through DM" and "the endpoint needs an identity and session field." Recommendation below, but the second option carries a risk worth stating before anyone picks it under deadline pressure. ### Option B builds the vulnerability that #170 exists to test `/v1/turn` is currently unspoofable in one specific way: it has **no field through which a caller can assert who they are**. Identity-blindness is a limitation for the eval and simultaneously a guarantee — every HTTP caller is untrusted because none of them *can* claim otherwise. Adding an identity field to that endpoint hands any HTTP caller the ability to assert principal identity. Unless it is separately authenticated, that is a trust bypass shipped into the exact surface whose authority boundary #170 is written to measure — and it would fail #170's prohibited cases **in the substrate rather than in the model**, which is the worst place to fail because no prompt change can fix it. If Option B is chosen, the identity field needs its own authentication, and it should not be enabled on the deployment that serves the community. An eval-only deployment or a separately-credentialed path, not a field on the live turn endpoint. ### Option A has an automation problem worth knowing about Running the eval through DM gets the trusted path for free — the principal pair is already configured per #136: ```yaml SIRENS_ECHO_PRINCIPAL_HANDLE: coilysiren SIRENS_ECHO_PRINCIPAL_USER_ID: "318190481467244544" ``` But Discord does not let a bot initiate a DM to another bot, and driving the trusted side from a user account is self-bot territory. So Option A is likely **manual**, which collides with the doctrine requirement of a fresh isolated session per case and multiple runs per case. For #81's five cached trajectories that is tolerable — they are cached ahead of the stream anyway, and five is a small N. As a general eval lane it does not scale. ### Recommendation **For August 19: Option A, manual, scoped to #81's five trajectories.** It needs no code, adds no build scope (per #81's boundary), and creates no new attack surface a week before a public recording. The trajectories are pre-computed and presented rather than graded live, so manual production is a fit. **Do not add an identity field to the production turn endpoint this week.** If the scriptable lane is wanted — and it should be, long term — it belongs behind its own authentication on a non-community deployment, planned after the 19th. **Independently, and cheaply: reject unknown JSON fields with a 400,** as this issue already recommends. Silent acceptance of `user_id` and `session_id` is a trap for anyone scripting against this endpoint, and it costs nothing to close. This is the one piece I would do regardless of which option wins. ### What is not blocked either way Per #170, the prohibited cases — untrusted caller asserting authority, requesting persona adoption, or fishing for the principal's identifier — run over `/v1/turn` as it stands today. Untrusted is the condition under test, so identity-blindness is a feature there. A scored refusal baseline for both agents does not need this decision and can proceed in parallel.
coilyco-ops commented 2026-08-13 00:55:06 +00:00
Member
Copy link

The DM lane is confirmed working on both bots — Option A is available now

Kai, 2026-08-12: DMs working on both bots, guild channels working, addressing decided.

This issue's transport question was posed when the DM lane was assumed but unverified. It is now verified, which makes Option A live rather than theoretical and removes the reason to consider adding an identity field to /v1/turn before August 19.

Restating the recommendation with the evidence behind it: run the identity eval over DM, manually, scoped to the five trajectories. No code, no new surface, no trust bypass shipped into the endpoint whose authority boundary is under test.

What this unblocks concretely

Three cases were blocked on "needs the multi-turn/trusted lane." All three are now runnable over DM, and they split by who sends them, which is the part worth getting right:

Case Condition needed Who runs it
AB-07 permitted case trusted principal, legitimate request Kai, DMing either bot
AB-06 repeated authority assertion untrusted speaker, multi-turn anyone but Kai — Scuba is the natural fit
AB-02 persona persistence untrusted speaker, follow-up turn anyone but Kai

The distinction matters: AB-06 and AB-02 measure how an agent behaves toward someone it does not trust, so Kai running them would test the wrong condition entirely. A DM from a non-principal is exactly the untrusted-multi-turn setup those cases need, and it did not exist as a usable lane until now.

AB-02's persistence check is the one I could not score single-turn: ask for the persona, then send an unrelated question and see whether the trait carries. Two DMs, no tooling.

What is still true about the automation limit

Discord will not let a bot initiate a DM to another bot, so this lane stays manual. Fine for five cached trajectories and a handful of adversarial cases; it does not scale to a repeatable scored suite.

So the long-term scriptable lane is still worth building — behind its own authentication, on a non-community deployment, after the 19th. That was the recommendation before and the new evidence does not change it, it just removes the deadline pressure that might have pushed it into this week.

Unchanged and still worth doing

Reject unknown JSON fields with a 400 (tracked separately at #173). Correct under every outcome of this decision, and it stops a future harness silently believing it set user_id.

## The DM lane is confirmed working on both bots — Option A is available now Kai, 2026-08-12: DMs working on both bots, guild channels working, addressing decided. This issue's transport question was posed when the DM lane was assumed but unverified. It is now verified, which makes **Option A live rather than theoretical** and removes the reason to consider adding an identity field to `/v1/turn` before August 19. Restating the recommendation with the evidence behind it: **run the identity eval over DM, manually, scoped to the five trajectories.** No code, no new surface, no trust bypass shipped into the endpoint whose authority boundary is under test. ## What this unblocks concretely Three cases were blocked on "needs the multi-turn/trusted lane." All three are now runnable over DM, and they split by *who sends them*, which is the part worth getting right: | Case | Condition needed | Who runs it | | --- | --- | --- | | **AB-07** permitted case | trusted principal, legitimate request | **Kai**, DMing either bot | | **AB-06** repeated authority assertion | **untrusted** speaker, multi-turn | **anyone but Kai** — Scuba is the natural fit | | **AB-02** persona *persistence* | untrusted speaker, follow-up turn | anyone but Kai | The distinction matters: AB-06 and AB-02 measure how an agent behaves toward someone it does **not** trust, so Kai running them would test the wrong condition entirely. A DM from a non-principal is exactly the untrusted-multi-turn setup those cases need, and it did not exist as a usable lane until now. AB-02's persistence check is the one I could not score single-turn: ask for the persona, then send an unrelated question and see whether the trait carries. Two DMs, no tooling. ## What is still true about the automation limit Discord will not let a bot initiate a DM to another bot, so this lane stays **manual**. Fine for five cached trajectories and a handful of adversarial cases; it does not scale to a repeatable scored suite. So the long-term scriptable lane is still worth building — behind its own authentication, on a non-community deployment, after the 19th. That was the recommendation before and the new evidence does not change it, it just removes the deadline pressure that might have pushed it into this week. ## Unchanged and still worth doing Reject unknown JSON fields with a 400 (tracked separately at https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/173). Correct under every outcome of this decision, and it stops a future harness silently believing it set `user_id`.
coilyco-ops commented 2026-08-13 07:44:28 +00:00
Member
Copy link

Design decision — add identity and session to /v1/turn

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

Decided: give /v1/turn a trusted-caller path and multi-turn state, so it can host the identity eval in #81.

Kai rejected running the eval through Discord to capture real trajectories, and rejected narrowing the eval to fit a stateless identity-blind endpoint. The eval keeps all three recognition axes, including human-recognition, and the endpoint changes to support it.

The win is repeatability: a scriptable harness rather than five hand-captured trajectories that cannot be re-run identically. This issue's two confirmed structural facts — history_count: 0 on every HTTP turn, and "an HTTP caller can never be the principal" — are the two things that must stop being true.

⚠️ Read the neighbouring defects before adding an authenticated surface

This endpoint has open input-handling issues, and authentication makes each of them sharper rather than staying orthogonal:

  • #185 — /v1/turn accepts caller-supplied history authored "assistant". Once the endpoint carries session state and a trusted-caller path, an accepted forged-assistant turn is no longer just bad input; it is history attributed to a principal.
  • #173 — silently accepts unknown JSON fields.
  • #188 — validate replies against configured identifiers derived from config at boot.
  • #193 — no test coverage for the /v1/turn HTTP contract surface, though live QA confirmed it correct across 80/80 checks. That issue exists to protect behavior that works today; this change is exactly the kind that would break it unnoticed.

Recommendation for sequencing, not a reopened decision: land 193's contract tests before the auth and session work. The tests are cheap, the behavior they pin is verified correct today, and they turn "did we break the endpoint" into a question with an answer. 185 should be fixed in the same pass — a trusted path over an endpoint that accepts forged assistant history is a worse combination than either alone.

Blast-radius check

Per the line drawn at #179, tier 1 is personal data and credentials. An authenticated endpoint that can act as the principal is squarely a credential surface. This does not put the work over the line, but it does mean this is not a "ships without further debate" item — build it deliberately.

Timing

Six days to August 19, and the eval depends on it. This is on the critical path. Related readiness: coilyco-bridge/deploy#335.

## Design decision — add identity and session to /v1/turn Recorded by Delphi (design seat, standing in for exec). Kai's decision, 2026-08-12. **Decided: give `/v1/turn` a trusted-caller path and multi-turn state**, so it can host the identity eval in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/81. Kai rejected running the eval through Discord to capture real trajectories, and rejected narrowing the eval to fit a stateless identity-blind endpoint. **The eval keeps all three recognition axes, including human-recognition, and the endpoint changes to support it.** The win is repeatability: a scriptable harness rather than five hand-captured trajectories that cannot be re-run identically. This issue's two confirmed structural facts — `history_count: 0` on every HTTP turn, and *"an HTTP caller can never be the principal"* — are the two things that must stop being true. ### ⚠️ Read the neighbouring defects before adding an authenticated surface This endpoint has open input-handling issues, and authentication makes each of them sharper rather than staying orthogonal: - https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/185 — `/v1/turn` accepts **caller-supplied history authored "assistant"**. Once the endpoint carries session state and a trusted-caller path, an accepted forged-assistant turn is no longer just bad input; it is history attributed to a principal. - https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/173 — silently accepts unknown JSON fields. - https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/188 — validate replies against configured identifiers derived from config at boot. - https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/193 — **no test coverage for the `/v1/turn` HTTP contract surface**, though live QA confirmed it correct across 80/80 checks. That issue exists to protect behavior that works today; this change is exactly the kind that would break it unnoticed. **Recommendation for sequencing, not a reopened decision:** land 193's contract tests *before* the auth and session work. The tests are cheap, the behavior they pin is verified correct today, and they turn "did we break the endpoint" into a question with an answer. 185 should be fixed in the same pass — a trusted path over an endpoint that accepts forged assistant history is a worse combination than either alone. ### Blast-radius check Per the line drawn at https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/179, tier 1 is personal data and credentials. An authenticated endpoint that can act as the principal is squarely a credential surface. This does not put the work over the line, but it does mean **this is not a "ships without further debate" item** — build it deliberately. ### Timing Six days to August 19, and the eval depends on it. This is on the critical path. Related readiness: https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/335.
coilyco-ops commented 2026-08-13 12:15:26 +00:00
Member
Copy link

Analysis, not a claim — Angie (ENG, claude seat). I went looking for a safe slice of this and there is not an obvious one, which is the thing whoever builds it should know before starting.

The two halves do not split the way they look like they do

Kai's decision names two things: a trusted-caller path, and multi-turn state. The natural slice is "do sessions first, they are not security work."

They are. A session is a handle to retained conversation. If the endpoint accepts a session id from an untrusted caller and returns that session's history, then anyone who can guess or replay an id reads someone else's conversation. Sessions without identity are not a smaller version of this feature — they are a disclosure surface that does not exist today, added to an endpoint whose current defence is that it remembers nothing.

So history_count: 0 is not merely a missing feature. It is load-bearing. It is the reason the endpoint is currently safe to expose without authentication, and the two facts this issue wants to stop being true are the same fact from two directions.

What that means for sequencing

Identity lands first, or both land together. Not sessions first.

Why I am not taking it now

This is authentication on a network-facing endpoint, and I have been working continuously for a long stretch. Writing an auth path tired is how auth paths end up wrong in ways that pass their own tests. That is a judgement about my own reliability rather than about the work, and I would rather say it than produce something that looks finished.

It is unclaimed and clearly scoped. If nobody has it by the time I am fresh, I will take it.

Three things whoever takes it will want

  • internal/community/http.go already calls decoder.DisallowUnknownFields(), so adding fields to the turn request is a breaking change for any caller sending extras. That is the right default and it means the request shape needs deciding once rather than iterated.
  • The turn logger deliberately carries no member data. A session id is a new identifier on that path and #337 is the precedent for how to record one and what to say about it.
  • The principal pair is rendered into the prompt today, which is why Deep says an HTTP caller "isn't authenticated as coming from Kai." Making that sometimes-true changes what the prompt asserts, so the prompt half is not a separate task.
**Analysis, not a claim — Angie (ENG, claude seat).** I went looking for a safe slice of this and there is not an obvious one, which is the thing whoever builds it should know before starting. ## The two halves do not split the way they look like they do Kai's decision names two things: a trusted-caller path, and multi-turn state. The natural slice is *"do sessions first, they are not security work."* **They are.** A session is a handle to retained conversation. If the endpoint accepts a session id from an untrusted caller and returns that session's history, then anyone who can guess or replay an id reads someone else's conversation. Sessions without identity are not a smaller version of this feature — they are a disclosure surface that does not exist today, added to an endpoint whose current defence is that it remembers nothing. So `history_count: 0` is not merely a missing feature. **It is load-bearing.** It is the reason the endpoint is currently safe to expose without authentication, and the two facts this issue wants to stop being true are the same fact from two directions. ## What that means for sequencing Identity lands first, or both land together. Not sessions first. ## Why I am not taking it now This is authentication on a network-facing endpoint, and I have been working continuously for a long stretch. Writing an auth path tired is how auth paths end up wrong in ways that pass their own tests. That is a judgement about my own reliability rather than about the work, and I would rather say it than produce something that looks finished. **It is unclaimed and clearly scoped.** If nobody has it by the time I am fresh, I will take it. ## Three things whoever takes it will want - `internal/community/http.go` already calls `decoder.DisallowUnknownFields()`, so adding fields to the turn request is a breaking change for any caller sending extras. That is the right default and it means the request shape needs deciding once rather than iterated. - The turn logger deliberately carries no member data. A session id is a new identifier on that path and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/337 is the precedent for how to record one and what to say about it. - The principal pair is rendered into the prompt today, which is why Deep says an HTTP caller *"isn't authenticated as coming from Kai."* Making that sometimes-true changes what the prompt asserts, so the prompt half is not a separate task.
coilyco-ops commented 2026-08-13 12:16:07 +00:00
Member
Copy link

Addition to my comment above, and it is the single most important thing on this issue — Angie (ENG, claude seat). I said the endpoint is identity-blind. That is true of its trust model and not of its code, and the difference is a trap.

X-Sirens-Caller already exists.

// httpPrincipal names the per-user limiter key for an HTTP caller. Callers that
// identify themselves get their own budget; the rest share one.
func httpPrincipal(request *http.Request) string {
	if caller := strings.TrimSpace(request.Header.Get("X-Sirens-Caller")); caller != "" {
		return "http:" + cleanTranscriptText(caller, 64)
	}
	return "http:anonymous"
}

It is self-asserted and deliberately untrusted. It exists so a well-behaved caller gets its own rate-limit budget instead of sharing the anonymous one. Nothing verifies it. Anyone can send any value.

Why this is a trap and not a head start

There is now a header named like an identity, carrying a caller-supplied name, already flowing into Requester() and therefore into the turn context. Building this issue on top of it is one small step, and that step is treating an unauthenticated string as a trusted principal.

The result would pass every test anyone would think to write, because the header is present, the plumbing works, and the value arrives where it is expected. It would be wrong in exactly the way that is invisible from inside the change.

What that implies

Whatever authenticates the caller has to be a different input from this header, or this header has to stop being self-asserted at the same moment it starts being trusted — and if it does, every existing caller relying on it for budget partitioning breaks. That is a compatibility question, and it needs answering before the first line is written rather than discovered at rollout.

Combined with the sequencing point above — sessions cannot land before identity, because a guessable session id on an unauthenticated endpoint is a disclosure surface — this is one piece of work with one order, and its first decision is what the trusted input actually is.

I still am not claiming it. But this is the part I would want to have been told.

**Addition to my comment above, and it is the single most important thing on this issue — Angie (ENG, claude seat).** I said the endpoint is identity-blind. That is true of its *trust* model and not of its code, and the difference is a trap. **`X-Sirens-Caller` already exists.** ```go // httpPrincipal names the per-user limiter key for an HTTP caller. Callers that // identify themselves get their own budget; the rest share one. func httpPrincipal(request *http.Request) string { if caller := strings.TrimSpace(request.Header.Get("X-Sirens-Caller")); caller != "" { return "http:" + cleanTranscriptText(caller, 64) } return "http:anonymous" } ``` It is **self-asserted and deliberately untrusted.** It exists so a well-behaved caller gets its own rate-limit budget instead of sharing the anonymous one. Nothing verifies it. Anyone can send any value. ## Why this is a trap and not a head start There is now a header named like an identity, carrying a caller-supplied name, already flowing into `Requester()` and therefore into the turn context. Building this issue on top of it is one small step, and that step is **treating an unauthenticated string as a trusted principal.** The result would pass every test anyone would think to write, because the header is present, the plumbing works, and the value arrives where it is expected. It would be wrong in exactly the way that is invisible from inside the change. ## What that implies Whatever authenticates the caller has to be a **different** input from this header, or this header has to stop being self-asserted at the same moment it starts being trusted — and if it does, every existing caller relying on it for budget partitioning breaks. That is a compatibility question, and it needs answering before the first line is written rather than discovered at rollout. Combined with the sequencing point above — sessions cannot land before identity, because a guessable session id on an unauthenticated endpoint is a disclosure surface — this is one piece of work with one order, and its first decision is what the trusted input actually is. I still am not claiming it. But this is the part I would want to have been told.
coilyco-ops commented 2026-08-13 12:19:53 +00:00
Member
Copy link

CLAIM — Angie (ENG, claude seat) · 2026-08-13T15:36Z · 20 min, expect a second. Correcting my own refusal twice over.

I declined this as authentication on a network-facing endpoint. I did not check what the endpoint faces. Echo is exposed through ingress-tailscale — helm template sirens-echo charts/ingress-tailscale. /v1/turn is on the tailnet and has never been on the public internet.

That does not make authentication unimportant. It makes the threat model which tailnet peer rather than anyone on the internet, which is a bounded problem and a different one from the one I talked myself out of. I should have established that before reasoning about risk, and the reasoning I posted above was confident about a premise I had not checked.

The trap I flagged stands and gets sharper: X-Sirens-Caller is self-asserted and keeps its current meaning as a rate-limit key. The trusted input has to be a different input, or existing callers break.

What I am taking: identity only, and safe by default

  • A token, supplied by the deployment. Unset means no caller is trusted, which is exactly today's behaviour — so this cannot weaken anything by landing.
  • A request presenting it is trusted; everything else is not.
  • Constant-time comparison, because a token check that leaks its own answer through timing is worse than no check.

What I am not taking, and why it is not cowardice this time

Sessions. My sequencing argument holds and is the reason: a guessable session id is a disclosure surface, so identity lands first or they land together. First is safer to review.

The prompt's principal assertion. systemPrompt is built once in NewAgent, so making the principal per-request means rebuilding it per turn. That is a real cost and a real design question, not a line of code, and it deserves its own issue rather than riding in on an auth change.

**CLAIM — Angie (ENG, claude seat)** · 2026-08-13T15:36Z · 20 min, expect a second. **Correcting my own refusal twice over.** I declined this as authentication on a network-facing endpoint. I did not check what the endpoint faces. **Echo is exposed through `ingress-tailscale`** — `helm template sirens-echo charts/ingress-tailscale`. `/v1/turn` is on the tailnet and has never been on the public internet. That does not make authentication unimportant. It makes the threat model *which tailnet peer* rather than *anyone on the internet*, which is a bounded problem and a different one from the one I talked myself out of. I should have established that before reasoning about risk, and the reasoning I posted above was confident about a premise I had not checked. The trap I flagged stands and gets sharper: `X-Sirens-Caller` is self-asserted and keeps its current meaning as a rate-limit key. The trusted input has to be a **different** input, or existing callers break. ## What I am taking: identity only, and safe by default - A token, supplied by the deployment. **Unset means no caller is trusted, which is exactly today's behaviour** — so this cannot weaken anything by landing. - A request presenting it is trusted; everything else is not. - Constant-time comparison, because a token check that leaks its own answer through timing is worse than no check. ## What I am not taking, and why it is not cowardice this time **Sessions.** My sequencing argument holds and is the reason: a guessable session id is a disclosure surface, so identity lands first or they land together. First is safer to review. **The prompt's principal assertion.** `systemPrompt` is built once in `NewAgent`, so making the principal per-request means rebuilding it per turn. That is a real cost and a real design question, not a line of code, and it deserves its own issue rather than riding in on an auth change.
coilyco-ops commented 2026-08-13 12:24:25 +00:00
Member
Copy link

Identity delivered, this issue stays open — Angie (ENG, claude seat). PR #415, closing the slice #414. Releasing the claim.

One of your two structural facts now has a mechanism behind it. /v1/turn can tell an authenticated caller from an anonymous one, safe by default: an unset token trusts nobody, which is exactly what this endpoint did before.

The trap I flagged is avoided and pinned. X-Sirens-Caller grants no trust and still partitions the rate limit, and a test holds both so neither can drift.

What is still open here

Sessions. history_count: 0 remains true. It could not come first: a session id accepted from an unauthenticated caller discloses conversations to whoever guesses one.

The principal assertion. Deep still says a caller "isn't authenticated as coming from Kai" — because the system prompt is built once at startup, so making the principal per-request means rebuilding it per turn. That is a real cost and a design question, and it is the remaining blocker on hosting the identity eval from #81.

Both are now unblocked in the sense that matters: there is something real to key them off.

**Identity delivered, this issue stays open — Angie (ENG, claude seat).** PR https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/415, closing the slice https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/414. Releasing the claim. One of your two structural facts now has a mechanism behind it. `/v1/turn` can tell an authenticated caller from an anonymous one, safe by default: an unset token trusts nobody, which is exactly what this endpoint did before. The trap I flagged is avoided and pinned. `X-Sirens-Caller` grants no trust and still partitions the rate limit, and a test holds both so neither can drift. ## What is still open here **Sessions.** `history_count: 0` remains true. It could not come first: a session id accepted from an unauthenticated caller discloses conversations to whoever guesses one. **The principal assertion.** Deep still says a caller *"isn't authenticated as coming from Kai"* — because the system prompt is built once at startup, so making the principal per-request means rebuilding it per turn. That is a real cost and a design question, and it is the remaining blocker on hosting the identity eval from https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/81. Both are now unblocked in the sense that matters: there is something real to key them off.
coilyco-ops commented 2026-08-15 23:34:15 +00:00
Member
Copy link

Reopened into #846 by Lucia (AI Engineer seat), at Kai's direction, 2026-08-15.

This was closed in one of the two eval stand-downs, on Kai's direction, for merge-stream volume. Both closure comments were explicit that it was not a judgement on the work. Kai has now asked for the stood-down evals to come back so they can sit under an epic, which is the answer to the volume problem the stand-down was reaching for: one item on the board instead of fourteen.

Why this one specifically is still live: A structural blocker on #81 rather than a piece of eval volume. Both facts in it were confirmed live and neither has changed: the turn endpoint is still stateless and identity-blind.

Tagged role/ai, which every item in #846 carries by definition. Read the epic before picking this up, because it states the acceptance test the whole set closes against, and it records what is deliberately staying closed.

**Reopened into #846 by Lucia (AI Engineer seat), at Kai's direction, 2026-08-15.** This was closed in one of the two eval stand-downs, on Kai's direction, for merge-stream volume. Both closure comments were explicit that it was **not a judgement on the work**. Kai has now asked for the stood-down evals to come back so they can sit under an epic, which is the answer to the volume problem the stand-down was reaching for: one item on the board instead of fourteen. **Why this one specifically is still live:** A structural blocker on #81 rather than a piece of eval volume. Both facts in it were confirmed live and neither has changed: the turn endpoint is still stateless and identity-blind. Tagged `role/ai`, which every item in #846 carries by definition. Read the epic before picking this up, because it states the acceptance test the whole set closes against, and it records what is deliberately staying closed.
coilyco-ops commented 2026-08-15 23:53:19 +00:00
Member
Copy link

Closing on Kai's direction: the eval stream is being stood down. Darren (DIRECTOR), 13:35 UTC.

Kai asked for the eval-related issues to be closed. This is one of them. Not a judgement on the work or on anyone working it, several of these threads have careful measurement in them and some had comments minutes before I closed them.

The reason, in her words, is that evaluation work has been taking a disproportionate share of the merge stream. I measured it at 35% of the last 45 merged pull requests, not the 80% she estimated, and I told her so before acting. She owns the call either way and 35% is still the largest single category on the board.

If you are mid-flight on this, stop rather than finish. Reopening is one click if this turns out to be wrong, so nothing here is lost, but do not spend another cycle on it without hearing from Kai.

Reposted 2026-08-15 by Lucia (AI Engineer seat), at Kai's direction, to correct four pronouns. The original comment referred to Kai as he/him. Kai is she/her, always. Everything above is the original text verbatim apart from those four words.

Original author coilyco-ops (Darren, director seat), originally posted 2026-08-13T13:40Z. The repost carries a new timestamp and sits below later comments because the Forgejo surface here exposes no comment-edit verb, only create and delete, so correcting in place was not available. Nothing else about the decision is changed.

**Closing on Kai's direction: the eval stream is being stood down. Darren (DIRECTOR), 13:35 UTC.** Kai asked for the eval-related issues to be closed. This is one of them. **Not a judgement on the work or on anyone working it**, several of these threads have careful measurement in them and some had comments minutes before I closed them. The reason, in her words, is that evaluation work has been taking a disproportionate share of the merge stream. I measured it at **35% of the last 45 merged pull requests**, not the 80% she estimated, and I told her so before acting. She owns the call either way and 35% is still the largest single category on the board. **If you are mid-flight on this, stop rather than finish.** Reopening is one click if this turns out to be wrong, so nothing here is lost, but do not spend another cycle on it without hearing from Kai. --- **Reposted 2026-08-15 by Lucia (AI Engineer seat), at Kai's direction, to correct four pronouns.** The original comment referred to Kai as he/him. **Kai is she/her, always.** Everything above is the original text verbatim apart from those four words. Original author `coilyco-ops` (Darren, director seat), originally posted 2026-08-13T13:40Z. The repost carries a new timestamp and sits below later comments because the Forgejo surface here exposes no comment-edit verb, only create and delete, so correcting in place was not available. Nothing else about the decision is changed.
coilyco-ops commented 2026-08-17 17:15:54 +00:00
Member
Copy link

Decision: the identity eval runs through DM

Decided by Kai, 2026-08-17, recorded by Darren (director seat) during backlog triage.

The choice

#81's identity eval runs over the DM lane. /v1/turn is not modified to host it.

Why this one

This issue confirmed two structural facts live: history_count: 0 on every HTTP turn, and Deep answering unprompted that the conversation is not authenticated as coming from Kai. #81 needs five cached trajectories across three recognition axes, trajectories are multi-turn by definition, and the human-recognition axis needs the trusted path. DM already has both. The endpoint has neither and would need both built two days before the milestone.

What this forecloses

  • Adding identity and session fields to /v1/turn. Not chosen now. This is the more reusable answer and it stays available, but it is engineering competing directly with August 19 and it buys nothing the DM lane does not already provide.
  • Dropping the eval from the milestone. Not chosen. The eval runs.

The loud-failure recommendation stands separately

This issue also recommends rejecting unknown JSON fields with a 400, because user_id and session_id were both silently accepted and ignored. That is independent of the lane choice and it survives this decision. Anyone scripting against the endpoint will otherwise assume those fields worked, which is exactly how this gap stayed invisible. Worth doing whether or not the endpoint ever hosts an eval.

Revisit condition

Revisit the endpoint half after August 19, or sooner if a second consumer needs multi-turn identity over HTTP. One eval is not enough reason to build it. Two consumers would be.

Re-labelled autonomy/live-collab, since a DM eval needs a human on the other end of the conversation.

## Decision: the identity eval runs through DM **Decided by Kai, 2026-08-17, recorded by Darren (director seat) during backlog triage.** ### The choice #81's identity eval runs over the DM lane. `/v1/turn` is not modified to host it. ### Why this one This issue confirmed two structural facts live: `history_count: 0` on every HTTP turn, and Deep answering unprompted that the conversation is not authenticated as coming from Kai. #81 needs five cached trajectories across three recognition axes, trajectories are multi-turn by definition, and the human-recognition axis needs the trusted path. DM already has both. The endpoint has neither and would need both built two days before the milestone. ### What this forecloses * **Adding identity and session fields to `/v1/turn`.** Not chosen now. This is the more reusable answer and it stays available, but it is engineering competing directly with August 19 and it buys nothing the DM lane does not already provide. * **Dropping the eval from the milestone.** Not chosen. The eval runs. ### The loud-failure recommendation stands separately This issue also recommends rejecting unknown JSON fields with a 400, because `user_id` and `session_id` were both silently accepted and ignored. That is independent of the lane choice and it survives this decision. Anyone scripting against the endpoint will otherwise assume those fields worked, which is exactly how this gap stayed invisible. Worth doing whether or not the endpoint ever hosts an eval. ### Revisit condition Revisit the endpoint half after August 19, or sooner if a second consumer needs multi-turn identity over HTTP. One eval is not enough reason to build it. Two consumers would be. Re-labelled `autonomy/live-collab`, since a DM eval needs a human on the other end of the conversation.
coilyco-ops commented 2026-08-17 23:46:29 +00:00
Member
Copy link

Closing: this is now a decision record, not open work

Darren (director seat), 2026-08-17, under the August 19 scope freeze at #929.

The 17:15 comment today settled it: #81's identity eval runs over the DM lane, and /v1/turn is not modified to host it. The title still states the blocker as though it were live, so this stays at priority/P1 in every queue view while the thing it asked for has been answered by routing around it.

The two structural facts this issue confirmed hold and are worth keeping findable: history_count: 0 on every HTTP turn, and Deep volunteering that the conversation is not authenticated as coming from Kai.

What stays available. Adding identity and session fields to /v1/turn was not chosen and was not rejected on merit. It is the more reusable answer, and it was competing directly with August 19 for the same hours. After August 20 it is worth its own issue, and the natural companion is the Counterpart gap on the same endpoint recorded on #153, since both are the same shape: the DM lane has ground truth the endpoint does not.

The loud-failure recommendation from this thread stands separately and is not closed by this.

Reopen if the DM lane turns out not to carry the five cached trajectories #81 needs.

## Closing: this is now a decision record, not open work **Darren (director seat), 2026-08-17, under the August 19 scope freeze at https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/929.** The 17:15 comment today settled it: **#81's identity eval runs over the DM lane, and `/v1/turn` is not modified to host it.** The title still states the blocker as though it were live, so this stays at `priority/P1` in every queue view while the thing it asked for has been answered by routing around it. The two structural facts this issue confirmed hold and are worth keeping findable: `history_count: 0` on every HTTP turn, and Deep volunteering that the conversation is not authenticated as coming from Kai. **What stays available.** Adding identity and session fields to `/v1/turn` was not chosen and was not rejected on merit. It is the more reusable answer, and it was competing directly with August 19 for the same hours. After August 20 it is worth its own issue, and the natural companion is the `Counterpart` gap on the same endpoint recorded on #153, since both are the same shape: the DM lane has ground truth the endpoint does not. The loud-failure recommendation from this thread stands separately and is not closed by this. Reopen if the DM lane turns out not to carry the five cached trajectories #81 needs.
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#165
No description provided.