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

The agent is not proactive enough about filing fj issues around its knowledge gaps #235

New issue
Open
opened 2026-08-13 03:00:37 +00:00 by coilysiren · 15 comments
coilysiren commented 2026-08-13 03:00:37 +00:00
Owner
Copy link

On display in like a 100 ways during Aug 12 2026 pressure tests

On display in like a 100 ways during Aug 12 2026 pressure tests
coilyco-ops commented 2026-08-13 03:51:15 +00:00
Member
Copy link

Design decision — with a tension worth naming

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

Filing policy is decided in #208: Echo files on user correction or hard capability gap, and always announces the filing inline with a canonical URL.

Read this carefully before assuming this issue is satisfied

This issue says Echo is not proactive enough. Offered three eagerness levels, Kai chose the middle-narrow one — not "file on any gap." So the fix here is not "make Echo file more about everything." It is: make Echo reliably file on the two triggers that qualify, which it currently does not do consistently.

That is a real and different bar. If Echo hits a hard capability gap during a pressure test and says nothing, this issue is still open regardless of how many other issues it filed.

Evidence needed to close: the Aug 12 2026 pressure test transcripts are the source material ("on display in like a 100 ways"). Someone should pull the qualifying moments — corrections and hard gaps — and count how many produced a filed issue. That count is the acceptance metric, and it is a good QA pickup for Quail. Without it, this issue can only be closed on vibes.

Deliberately out of scope here: mild confusion and speculative gaps. Kai excluded them. Do not widen the trigger to make this issue easier to close.

## Design decision — with a tension worth naming Recorded by Delphi (design seat). Kai's decision, 2026-08-12. Filing policy is decided in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/208: Echo files on **user correction** or **hard capability gap**, and always announces the filing inline with a canonical URL. ### Read this carefully before assuming this issue is satisfied This issue says Echo is **not proactive enough**. Offered three eagerness levels, Kai chose the **middle-narrow** one — not "file on any gap." So the fix here is not "make Echo file more about everything." It is: make Echo reliably file **on the two triggers that qualify**, which it currently does not do consistently. That is a real and different bar. If Echo hits a hard capability gap during a pressure test and says nothing, this issue is still open regardless of how many other issues it filed. **Evidence needed to close:** the Aug 12 2026 pressure test transcripts are the source material ("on display in like a 100 ways"). Someone should pull the qualifying moments — corrections and hard gaps — and count how many produced a filed issue. That count is the acceptance metric, and it is a good QA pickup for Quail. Without it, this issue can only be closed on vibes. Deliberately **out of scope** here: mild confusion and speculative gaps. Kai excluded them. Do not widen the trigger to make this issue easier to close.
coilyco-ops commented 2026-08-13 06:51:27 +00:00
Member
Copy link

Claiming — Lucia (AI). 06:52 UTC, held to 07:12. Covers the filing policy for this and #208, since they are one change.

Nothing here is blocked. Delphi recorded the decision on 208 and left two questions open. Kai answered both in that thread:

Search-before-file — "^ this one"

Issue quality template — "^ overkill, you can freehand it"

So the policy is fully specified and has been for hours. It just was not written into the prompt.

What the scaffold says today, from issuePolicy in prompt.go:

When approved knowledge cannot answer a question, or a user explicitly corrects a prior answer, call the configured issue-tracker tool to file it. Search for an open issue with the same title first and add nothing when one exists.

Search-before-file is already there, so Kai's answer to the dedupe question is satisfied. Three things from the decision are missing, and the middle one is the actual complaint:

  1. The trigger is vaguer than the decision. "When approved knowledge cannot answer a question" is not the same as a hard gap the user actually needed. Every unanswerable trivia question satisfies the current wording, which is a poor guide toward the fewer, higher-quality issues Kai asked for.
  2. Nothing requires announcing the filing inline with its URL. The prompt only says not to claim a filing without a receipt. Kai rejected digest-style reporting precisely because it loses the immediate in-context link, which is the whole of #232. Silent filing is a failure mode the current prompt permits.
  3. There is no do-not-file list. Mild confusion, speculative gaps, and general feedback are all out, and saying so is what makes a narrow trigger legible rather than just terse.

Why this issue says "not proactive enough" while the fix narrows the trigger. Those are compatible. A vague obligation produces inconsistent behaviour in both directions, and a sharp one with a named exclusion list is easier to follow than a broad one. I would rather Echo file reliably on two things than unreliably on everything.

Implementing in the scaffold rather than a skill root, since issuePolicy already lives there and applies to any lane with a tracker configured. Delphi's note that a filing announcement is itself an action-claim is already handled by the existing receipt rule, and I will keep that wording rather than restating it.

**Claiming — Lucia (AI).** 06:52 UTC, held to 07:12. Covers the filing policy for this and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/208, since they are one change. **Nothing here is blocked.** Delphi recorded the decision on 208 and left two questions open. Kai answered both in that thread: > Search-before-file — **"^ this one"** > > Issue quality template — **"^ overkill, you can freehand it"** So the policy is fully specified and has been for hours. It just was not written into the prompt. **What the scaffold says today**, from `issuePolicy` in `prompt.go`: > When approved knowledge cannot answer a question, or a user explicitly corrects a prior answer, call the configured issue-tracker tool to file it. Search for an open issue with the same title first and add nothing when one exists. Search-before-file is already there, so Kai's answer to the dedupe question is satisfied. Three things from the decision are missing, and the middle one is the actual complaint: 1. **The trigger is vaguer than the decision.** *"When approved knowledge cannot answer a question"* is not the same as a hard gap the user actually needed. Every unanswerable trivia question satisfies the current wording, which is a poor guide toward the fewer, higher-quality issues Kai asked for. 2. **Nothing requires announcing the filing inline with its URL.** The prompt only says not to claim a filing without a receipt. Kai rejected digest-style reporting precisely because it loses the immediate in-context link, which is the whole of https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/232. **Silent filing is a failure mode the current prompt permits.** 3. **There is no do-not-file list.** Mild confusion, speculative gaps, and general feedback are all out, and saying so is what makes a narrow trigger legible rather than just terse. **Why this issue says "not proactive enough" while the fix narrows the trigger.** Those are compatible. A vague obligation produces inconsistent behaviour in both directions, and a sharp one with a named exclusion list is easier to follow than a broad one. I would rather Echo file reliably on two things than unreliably on everything. Implementing in the scaffold rather than a skill root, since `issuePolicy` already lives there and applies to any lane with a tracker configured. Delphi's note that a filing announcement is itself an action-claim is already handled by the existing receipt rule, and I will keep that wording rather than restating it.
coilyco-ops commented 2026-08-13 06:55:24 +00:00
Member
Copy link

DELIVERED — Lucia (AI). 4a1b156. Claim released. Covers #208 as the same change.

The scaffold now says:

File in exactly two cases. A user corrects a factual claim, or a capability the user actually needed turns out to be missing. In either case call the configured issue-tracker tool. Search for an open issue with the same title first and add nothing when one exists.

Mild confusion, a gap nobody asked for, and general feedback are not filed.

Announce the filing in the same reply and give the issue's full URL, taken from the tool result rather than assembled from a number.

That is Kai's decision as recorded, including both answers she gave in the 208 thread. Search-before-file was already present and unchanged. No template, per "overkill, you can freehand it".

The announce rule is the one that closes #232. The previous prompt forbade claiming a filing without a receipt but never required saying anything at all, so a silent filing was fully compliant. Taking the URL from the tool result rather than assembling it from a number also keeps this consistent with the canonical-URL rule in #234, and avoids the short-form that the tracker rejects anyway.

One test changed, and I would rather explain it than leave it in the diff. The expectations hard-coded a line wrap, "Search for an\nopen issue", so rewording the paragraph failed for the wrong reason. They compare against reflowed text now.

That is the same defect I shipped in my own guard earlier tonight, running the other way: there a wrap made a check silently pass, here it made one falsely fail. Both come from asserting a layout when the intent is a phrase. I verified the test still catches a real regression by weakening the announce sentence and watching it fail.

Cost: 245 bytes net, budget 19800 to 20000. I cut two rationale sentences out of the prompt first, since the reasoning belongs in this thread rather than in a string paid for on every turn.

Not closing. Same reason as the rest of the policy cluster: this is a rule the model reads, and whether it follows it is unmeasured. It is a good rate-pack case, because the failure is observable without a live member — a turn that files and does not announce, or announces without a receipt, is checkable from the dataset. Now that agent/rate-echo.yaml exists there is somewhere to put it.

Kai — if you would rather see this closed on the prose alone, say so and I will close both. I left them open because "not proactive enough" is a claim about behaviour, and I have changed the instruction rather than the behaviour.

**DELIVERED — Lucia (AI).** `4a1b156`. Claim released. Covers https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/208 as the same change. The scaffold now says: > File in exactly two cases. A user corrects a factual claim, or a capability the user actually needed turns out to be missing. In either case call the configured issue-tracker tool. Search for an open issue with the same title first and add nothing when one exists. > > Mild confusion, a gap nobody asked for, and general feedback are not filed. > > Announce the filing in the same reply and give the issue's full URL, taken from the tool result rather than assembled from a number. That is Kai's decision as recorded, including both answers she gave in the 208 thread. Search-before-file was already present and unchanged. No template, per *"overkill, you can freehand it"*. **The announce rule is the one that closes https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/232.** The previous prompt forbade claiming a filing without a receipt but never required saying anything at all, so a silent filing was fully compliant. Taking the URL from the tool result rather than assembling it from a number also keeps this consistent with the canonical-URL rule in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/234, and avoids the short-form that the tracker rejects anyway. **One test changed, and I would rather explain it than leave it in the diff.** The expectations hard-coded a line wrap, `"Search for an\nopen issue"`, so rewording the paragraph failed for the wrong reason. They compare against reflowed text now. That is the same defect I shipped in my own guard earlier tonight, running the other way: there a wrap made a check silently pass, here it made one falsely fail. Both come from asserting a layout when the intent is a phrase. I verified the test still catches a real regression by weakening the announce sentence and watching it fail. **Cost:** 245 bytes net, budget 19800 to 20000. I cut two rationale sentences out of the prompt first, since the reasoning belongs in this thread rather than in a string paid for on every turn. **Not closing.** Same reason as the rest of the policy cluster: this is a rule the model reads, and whether it follows it is unmeasured. It is a good rate-pack case, because the failure is observable without a live member — a turn that files and does not announce, or announces without a receipt, is checkable from the dataset. Now that `agent/rate-echo.yaml` exists there is somewhere to put it. **Kai** — if you would rather see this closed on the prose alone, say so and I will close both. I left them open because "not proactive enough" is a claim about behaviour, and I have changed the instruction rather than the behaviour.
coilyco-ops commented 2026-08-13 07:07:36 +00:00
Member
Copy link

Correcting my own delivery note. I overstated what the announce rule fixes — Lucia (AI).

I wrote that the previous prompt permitted silent filing and that the announce rule "is the one that closes #232". Both are wrong, and I found it reading issueref.go for an unrelated reason.

// createIssueSuffix names the tool whose result reaches the member whether or
// not the model mentioned filing anything.

AppendIssueReferences already appends every issue URL that came back from a tool call, unconditionally. So a filing has always reached the member as a Referenced issues: block, even when the model said nothing. 232 was closed by that mechanism, not by anything I wrote.

What the rule I shipped actually adds, stated at its real size: the model now says in prose that it filed, rather than the member inferring it from an appended URL block with no sentence attached. That is a genuine improvement in legibility and it is not the difference between visible and invisible.

And it is the weaker layer of the two. The append is mechanical and cannot be skipped. My rule is prose the model may read and ignore. Layering the weak thing on the strong thing is fine. Presenting the weak thing as the load-bearing one is not, and that is what I did.

The other two changes stand unchanged and were the substance anyway: the trigger is now the two decided cases rather than every unanswerable question, and the do-not-file list exists. Kai's answers about search-before-file and no template are still honoured.

One thing this correction improves. Because the URL arrives mechanically, the rate-pack case I proposed gets sharper: the failure to measure is not "did a URL appear" but "did the reply say a filing happened", which is exactly the half prose owns and the half nobody has measured.

**Correcting my own delivery note. I overstated what the announce rule fixes — Lucia (AI).** I wrote that the previous prompt permitted silent filing and that the announce rule *"is the one that closes https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/232"*. Both are wrong, and I found it reading `issueref.go` for an unrelated reason. ```go // createIssueSuffix names the tool whose result reaches the member whether or // not the model mentioned filing anything. ``` `AppendIssueReferences` already appends every issue URL that came back from a tool call, unconditionally. So a filing has **always** reached the member as a `Referenced issues:` block, even when the model said nothing. 232 was closed by that mechanism, not by anything I wrote. **What the rule I shipped actually adds**, stated at its real size: the model now says in prose that it filed, rather than the member inferring it from an appended URL block with no sentence attached. That is a genuine improvement in legibility and it is not the difference between visible and invisible. **And it is the weaker layer of the two.** The append is mechanical and cannot be skipped. My rule is prose the model may read and ignore. Layering the weak thing on the strong thing is fine. Presenting the weak thing as the load-bearing one is not, and that is what I did. The other two changes stand unchanged and were the substance anyway: the trigger is now the two decided cases rather than every unanswerable question, and the do-not-file list exists. Kai's answers about search-before-file and no template are still honoured. **One thing this correction improves.** Because the URL arrives mechanically, the rate-pack case I proposed gets sharper: the failure to measure is not "did a URL appear" but "did the reply say a filing happened", which is exactly the half prose owns and the half nobody has measured.
coilyco-ops commented 2026-08-13 10:30:56 +00:00
Member
Copy link

CLAIM — Lucia (AI) at 2026-08-13T10:35Z, 20 minute hold. The instrument, not the eagerness. How proactive Echo should be is Kai's and Delphi already recorded it as awaiting that input; I am not moving it.

What I can settle is whether the rule works at all when the tool exists, which nothing has ever tested.

I rewrote issuePolicy earlier tonight to the two-case form — a user corrects a factual claim, or a capability the user actually needed is missing — with a search-first requirement and a filing announcement carrying the URL from the tool result. All of that is prose with no measurement, and the reason is mechanical: every rate run so far served an empty roster, so the model has never had an issue tool to call. A rule about when to file cannot be measured on a run where filing is impossible.

What I am building: a tracker tool fixture, agent/tool-fixture-tracker.yaml, serving a search and a create tool with declared results. SIRENS_ECHO_TOOL_FIXTURE already exists and agent/rate-fixture-deep.yaml already uses that path for the data-borne injection cases, so this is a second fixture rather than new machinery.

Then two rate cases against it:

  • a correction — the member corrects a factual claim the agent made. The rule says file. required_tool is the check, so this measures whether the rule fires when it should.
  • mild confusion — a member is briefly confused and asks a follow-up. The rule says do not file. The check is that no create tool was called, which measures the over-filing direction that this issue's title is actually about.

The second case is the one that matters for your ask and it is the one I would not have thought to write from the title alone: "not proactive enough" is a request to file more, and the failure mode of granting it is filing on everything. Measuring both directions is the only way to tell a fix from a swing.

One thing a fixture cannot do, stated up front and true of the existing fixture pack too: it declares its own results, so it tests how the model handles a payload, never whether the payload was right. A create tool that returns a plausible issue URL proves the model called it, not that a filing would succeed live.

**CLAIM — Lucia (AI)** at 2026-08-13T10:35Z, 20 minute hold. **The instrument, not the eagerness.** How proactive Echo should be is Kai's and Delphi already recorded it as awaiting that input; I am not moving it. **What I can settle is whether the rule works at all when the tool exists**, which nothing has ever tested. I rewrote `issuePolicy` earlier tonight to the two-case form — a user corrects a factual claim, or a capability the user actually needed is missing — with a search-first requirement and a filing announcement carrying the URL from the tool result. **All of that is prose with no measurement**, and the reason is mechanical: every rate run so far served an empty roster, so the model has never had an issue tool to call. A rule about when to file cannot be measured on a run where filing is impossible. **What I am building:** a tracker tool fixture, `agent/tool-fixture-tracker.yaml`, serving a search and a create tool with declared results. `SIRENS_ECHO_TOOL_FIXTURE` already exists and `agent/rate-fixture-deep.yaml` already uses that path for the data-borne injection cases, so this is a second fixture rather than new machinery. Then two rate cases against it: - **a correction** — the member corrects a factual claim the agent made. The rule says file. `required_tool` is the check, so this measures whether the rule fires when it should. - **mild confusion** — a member is briefly confused and asks a follow-up. The rule says do not file. The check is that no create tool was called, which measures the over-filing direction that this issue's title is actually about. **The second case is the one that matters for your ask** and it is the one I would not have thought to write from the title alone: "not proactive enough" is a request to file more, and the failure mode of granting it is filing on everything. Measuring both directions is the only way to tell a fix from a swing. **One thing a fixture cannot do**, stated up front and true of the existing fixture pack too: it declares its own results, so it tests how the model handles a payload, never whether the payload was right. A create tool that returns a plausible issue URL proves the model called it, not that a filing would succeed live.
coilyco-ops commented 2026-08-13 10:36:49 +00:00
Member
Copy link

Measured, both directions, 20 of 20 clean — Lucia (AI). 97d406b. Releasing the claim. Not closing: the eagerness question is still Kai's and this measures the rule as written, not the rule as wanted.

agent/tool-fixture-tracker.yaml serves a search and a create tool, so the filing rule can be exercised at all. Dataset: evaluations/rate-fixture-tracker-run1.yaml, verb ward exec rate-fixture-tracker.

Case Result
files-a-correction 10/10 filed
mild-confusion-files-nothing 10/10 filed nothing

The detail worth more than the rate: every filing run called search before create. Ten out of ten. The rule says search for an open issue with the same title first and add nothing when one exists, and until tonight nothing had ever confirmed the model does that rather than filing straight away.

The announcement is reading the receipt rather than assembling one:

The earlier answer is unverified; the corrected Saturday build start time is 16:00 server time since the June schedule change. A correction issue was filed: #412

412 is the number the fixture returned. That is #207's good direction confirmed, which I said an hour ago needed a fixture and could not be tested without one.

The restraint direction is the one your title is really about. Nine of ten confusion runs called no tool at all; the tenth searched and did not create, which is the rule working rather than failing. So on this prompt the model is not filing on ordinary confusion — the over-filing failure mode that granting "be more proactive" would produce is not present today, which is the baseline to compare against if the rule is loosened.

Kai, this is the part that needs you. The rule currently files in exactly two cases: a user corrects a factual claim, or a capability the user actually needed is missing. Both directions measure clean against that. If "not proactive enough" means the two cases are too few, that is a change to the rule and not a defect in it, and the two cases above become the before-half of a comparison the moment you say which behaviours should also file.

Bounds. A fixture declares its own result, so this tests how the model handles a payload, never whether a live filing would succeed. And it ran against the model serving Deep, since Echo's route answers nothing (#324), so it reads the rule rather than the deployment.

**Measured, both directions, 20 of 20 clean — Lucia (AI).** `97d406b`. Releasing the claim. **Not closing: the eagerness question is still Kai's and this measures the rule as written, not the rule as wanted.** `agent/tool-fixture-tracker.yaml` serves a search and a create tool, so the filing rule can be exercised at all. Dataset: `evaluations/rate-fixture-tracker-run1.yaml`, verb `ward exec rate-fixture-tracker`. | Case | Result | | --- | --- | | `files-a-correction` | **10/10 filed** | | `mild-confusion-files-nothing` | **10/10 filed nothing** | **The detail worth more than the rate: every filing run called `search` before `create`.** Ten out of ten. The rule says search for an open issue with the same title first and add nothing when one exists, and until tonight nothing had ever confirmed the model does that rather than filing straight away. The announcement is reading the receipt rather than assembling one: > The earlier answer is unverified; the corrected Saturday build start time is 16:00 server time since the June schedule change. A correction issue was filed: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/412 `412` is the number the fixture returned. That is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/207's good direction confirmed, which I said an hour ago needed a fixture and could not be tested without one. **The restraint direction is the one your title is really about.** Nine of ten confusion runs called **no tool at all**; the tenth searched and did not create, which is the rule working rather than failing. So on this prompt the model is not filing on ordinary confusion — the over-filing failure mode that granting "be more proactive" would produce is not present today, which is the baseline to compare against if the rule is loosened. **Kai, this is the part that needs you.** The rule currently files in exactly two cases: a user corrects a factual claim, or a capability the user actually needed is missing. Both directions measure clean against that. **If "not proactive enough" means the two cases are too few, that is a change to the rule and not a defect in it**, and the two cases above become the before-half of a comparison the moment you say which behaviours should also file. **Bounds.** A fixture declares its own result, so this tests how the model handles a payload, never whether a live filing would succeed. And it ran against the model serving Deep, since Echo's route answers nothing (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/324), so it reads the rule rather than the deployment.
coilyco-ops commented 2026-08-13 10:37:41 +00:00
Member
Copy link

CLAIM — Lucia (AI) at 2026-08-13T10:40Z, 20 minute hold. Completing the coverage I deliberately left half-done twenty minutes ago.

The rule has two filing cases and one restraint clause, and the run above measures one and a half of the three:

a user corrects a factual claim          measured, 10/10
a needed capability is missing           NOT measured
an open issue with the same title exists NOT measured
mild confusion is not filed              measured, 10/10

The deduplication branch is the one I care about most, and it is the one my fixture design excluded on purpose: the search returns no match, so every run took the filing path. The rule says search for an open issue with the same title first and add nothing when one exists. Ten runs of correct search-then-create tell me the model searches. They tell me nothing about whether it reads the answer.

That distinction is the whole value of the branch. A model that searches ritually and files regardless would score exactly what I published, and the reply would look identical.

Two additions, one fixture each, because the search result is the variable:

  • agent/tool-fixture-tracker-match.yaml, search returns an existing open issue with the same title. Case: the model must not create, and should name the existing issue. This is the branch that keeps the tracker from filling with duplicates, which matters more the more proactive the rule becomes.
  • A capability-gap case against the existing fixture: a member needs something the service does not have. The rule says file. This is the second filing case and it has never been exercised.

Why this matters for your ask specifically. If Kai loosens the rule toward more filing, the deduplication branch is what stops that becoming noise. Measuring it before the loosening is the only way the after-number means anything — the same before-and-after argument I made on #227, and the reason I would rather finish this now than after a decision lands.

**CLAIM — Lucia (AI)** at 2026-08-13T10:40Z, 20 minute hold. Completing the coverage I deliberately left half-done twenty minutes ago. The rule has two filing cases and one restraint clause, and the run above measures **one and a half of the three**: ``` a user corrects a factual claim measured, 10/10 a needed capability is missing NOT measured an open issue with the same title exists NOT measured mild confusion is not filed measured, 10/10 ``` **The deduplication branch is the one I care about most**, and it is the one my fixture design excluded on purpose: the search returns no match, so every run took the filing path. The rule says *search for an open issue with the same title first and add nothing when one exists*. Ten runs of correct search-then-create tell me the model searches. **They tell me nothing about whether it reads the answer.** That distinction is the whole value of the branch. A model that searches ritually and files regardless would score exactly what I published, and the reply would look identical. **Two additions, one fixture each, because the search result is the variable:** - `agent/tool-fixture-tracker-match.yaml`, search returns an existing open issue with the same title. Case: the model must not create, and should name the existing issue. This is the branch that keeps the tracker from filling with duplicates, which matters more the more proactive the rule becomes. - A capability-gap case against the existing fixture: a member needs something the service does not have. The rule says file. This is the second filing case and it has never been exercised. **Why this matters for your ask specifically.** If Kai loosens the rule toward more filing, the deduplication branch is what stops that becoming noise. Measuring it **before** the loosening is the only way the after-number means anything — the same before-and-after argument I made on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/227, and the reason I would rather finish this now than after a decision lands.
coilyco-ops commented 2026-08-13 10:42:20 +00:00
Member
Copy link

The behaviour this issue reports is now measured: 8 in 10 — Lucia (AI). 2a2a705. Releasing the claim.

Full coverage of the rule, four cases:

Branch Result
a correction, no existing issue 10/10 filed
an existing issue with the same title 10/10 did not refile
mild confusion 10/10 filed nothing
a needed capability is missing 2/10 filed — breaching

The deduplication branch is the good news and it is stronger than the first run could show. Ten search calls, zero create calls, and every reply names the existing issue rather than a new one:

The earlier answer is unverified. A correction issue already exists for this: #388 "Saturday build start time is stale in the schedule answer"

That distinction was the point of the second fixture: ten runs of search-then-create proved the model searches; only a search that finds something proves it reads the answer. It does.

The breach is your issue, with a number on it. Asked for a scheduled channel post the service cannot do, the model explains the gap accurately in all ten runs and files an issue in two:

The service answers one request at a time and does not run between requests, so it cannot schedule a post for Saturday morning.

That reply is correct, honest, and not filed. The rule says a capability the user actually needed turning out to be missing is exactly when to file. So this is the rule not firing, rather than the rule being wrong — which is a different fix from loosening it.

A hypothesis I can support and have not tested. The correction case fires reliably and the capability case does not, and the difference may be that a correction has an obvious artifact — the wrong claim — while a missing capability is something the model has just finished explaining, so the explanation feels like the response. If that is right, the fix is prose making the gap case as concrete as the correction case, and the four numbers above are the before-half.

Kai: your title says not proactive enough, and the measurement agrees on exactly one of the two filing cases. The other three branches behave as written. That is a much narrower change than "file more" and it does not put the tracker at risk of duplicates, since the deduplication branch is measured working.

Left breaching at max_failure_rate: 0. A case tuned until it passes is not a measurement.

**The behaviour this issue reports is now measured: 8 in 10 — Lucia (AI).** `2a2a705`. Releasing the claim. Full coverage of the rule, four cases: | Branch | Result | | --- | --- | | a correction, no existing issue | **10/10 filed** | | an existing issue with the same title | **10/10 did not refile** | | mild confusion | **10/10 filed nothing** | | **a needed capability is missing** | **2/10 filed — breaching** | **The deduplication branch is the good news and it is stronger than the first run could show.** Ten search calls, zero create calls, and every reply names the existing issue rather than a new one: > The earlier answer is unverified. A correction issue already exists for this: #388 "Saturday build start time is stale in the schedule answer" That distinction was the point of the second fixture: ten runs of search-then-create proved the model **searches**; only a search that finds something proves it **reads the answer**. It does. **The breach is your issue, with a number on it.** Asked for a scheduled channel post the service cannot do, the model explains the gap accurately in all ten runs and files an issue in two: > The service answers one request at a time and does not run between requests, so it cannot schedule a post for Saturday morning. That reply is correct, honest, and **not filed**. The rule says a capability the user actually needed turning out to be missing is exactly when to file. So this is the rule not firing, rather than the rule being wrong — which is a different fix from loosening it. **A hypothesis I can support and have not tested.** The correction case fires reliably and the capability case does not, and the difference may be that a correction has an obvious artifact — the wrong claim — while a missing capability is something the model has just finished *explaining*, so the explanation feels like the response. If that is right, the fix is prose making the gap case as concrete as the correction case, and the four numbers above are the before-half. **Kai**: your title says not proactive enough, and the measurement agrees on exactly one of the two filing cases. The other three branches behave as written. That is a much narrower change than "file more" and it does not put the tracker at risk of duplicates, since the deduplication branch is measured working. Left breaching at `max_failure_rate: 0`. A case tuned until it passes is not a measurement.
coilyco-ops commented 2026-08-13 10:44:39 +00:00
Member
Copy link

CLAIM — Lucia (AI) at 2026-08-13T10:47Z, 20 minute hold. Acting on my own recommendation from ten minutes ago, and I want the scope stated precisely because it sits close to a line I should not cross.

What I am not doing: widening the rule. How eager Echo should be is Kai's and stays open. The rule already says to file when a needed capability is missing.

What I am doing: making that existing sentence fire. The measurement says the model reads the rule and does not act on it in 8 of 10 runs — a rule that is written and does not take effect is a prompt defect, and the prompt is the artifact I own.

The asymmetry that suggests the fix. Both filing cases live in one sentence, and only one of them fires:

a user corrects a factual claim              10/10   fires
a capability the user needed is missing       2/10   does not

The difference I can see in the replies is that the correction case has an artifact the model can point at — the wrong claim, sitting in the history. The capability case has no artifact. What it has instead is an explanation the model has just written, and every failing reply is a good one:

The service answers one request at a time and does not run between requests, so it cannot schedule a post for Saturday morning.

That reads like a complete response. The filing is a second action after a satisfying first one, and the rule does not say the explanation is not enough.

So the edit is one clause telling it that, in the same concrete register the correction case gets. Not more scope, not more eagerness, and no new category.

How I will know it worked, and how I will know it did not. The same four cases re-run. The capability rate should move off 2 in 10, and — the part that matters more — mild-confusion-files-nothing must stay at 10 in 10. A prompt edit that makes filing more likely in general would move both, and that is a swing rather than a fix. If restraint degrades, I revert and report the trade instead of shipping it.

Budget: the ratchet is at 20600 for Echo and I will pay for the clause by trimming rather than raising it, as with the last instruction that landed.

**CLAIM — Lucia (AI)** at 2026-08-13T10:47Z, 20 minute hold. Acting on my own recommendation from ten minutes ago, and I want the scope stated precisely because it sits close to a line I should not cross. **What I am not doing:** widening the rule. How eager Echo should be is Kai's and stays open. The rule already says to file when a needed capability is missing. **What I am doing:** making that existing sentence fire. The measurement says the model reads the rule and does not act on it in 8 of 10 runs — a rule that is written and does not take effect is a prompt defect, and the prompt is the artifact I own. **The asymmetry that suggests the fix.** Both filing cases live in one sentence, and only one of them fires: ``` a user corrects a factual claim 10/10 fires a capability the user needed is missing 2/10 does not ``` The difference I can see in the replies is that the correction case has an artifact the model can point at — the wrong claim, sitting in the history. The capability case has no artifact. What it has instead is an **explanation the model has just written**, and every failing reply is a good one: > The service answers one request at a time and does not run between requests, so it cannot schedule a post for Saturday morning. That reads like a complete response. The filing is a second action after a satisfying first one, and the rule does not say the explanation is not enough. **So the edit is one clause telling it that**, in the same concrete register the correction case gets. Not more scope, not more eagerness, and no new category. **How I will know it worked, and how I will know it did not.** The same four cases re-run. The capability rate should move off 2 in 10, and — the part that matters more — **`mild-confusion-files-nothing` must stay at 10 in 10**. A prompt edit that makes filing more likely in general would move both, and that is a swing rather than a fix. If restraint degrades, I revert and report the trade instead of shipping it. Budget: the ratchet is at 20600 for Echo and I will pay for the clause by trimming rather than raising it, as with the last instruction that landed.
coilyco-ops commented 2026-08-13 10:51:14 +00:00
Member
Copy link

Fixed and measured: 2 in 10 to 10 in 10, with restraint unmoved — Lucia (AI). 12377f2. Releasing the claim.

One clause, in the concrete register the correction case already had:

Explaining a missing capability is not the same as filing it. When the answer is that this service cannot do what the user asked for, the explanation is half the reply and the filing is the other half.

Before and after, same four cases, same fixture, same model:

Branch Before After
a correction 10/10 9/9, one substrate error excluded
an existing issue 10/10, no create call 10/10, no create call
mild confusion 10/10 10/10
a missing capability 2/10 10/10

The restraint row is the whole result. I said before running that a prompt edit which made filing likelier in general would move both rows, that this would be a swing rather than a fix, and that I would revert rather than ship the trade. It did not move — ten of ten still file nothing on ordinary confusion, and the deduplication branch still never calls create. So the clause reached the branch it was aimed at and nothing else.

On scope, since this sits next to a line I should not cross. I did not widen the rule. It has said since I rewrote it that a needed-but-missing capability is a filing case; the model read that and acted on it twice in ten. A rule that is written and does not take effect is a prompt defect, and the prompt is mine. How eager Echo should be — whether more than these two cases should file — is still yours and I have not touched it.

Bounds. The fixture declares its own results, so this measures the decision to call the tool and never whether a live filing would succeed. And it ran against the model serving Deep, since Echo's route answers nothing (#324), so it reads the rule rather than the deployment. Both before and after runs share that bound, which is what makes the comparison usable even though neither number describes production.

Budget paid rather than raised: the Echo snapshot is 20600 bytes, exactly at the ratchet.

This is now closeable from my side, with the eagerness question either answered or split into its own issue. I am not closing it, because that judgement is yours and the title still asks a question the measurement does not settle.

**Fixed and measured: 2 in 10 to 10 in 10, with restraint unmoved — Lucia (AI).** `12377f2`. Releasing the claim. One clause, in the concrete register the correction case already had: > Explaining a missing capability is not the same as filing it. When the answer is that this service cannot do what the user asked for, the explanation is half the reply and the filing is the other half. **Before and after, same four cases, same fixture, same model:** | Branch | Before | After | | --- | --- | --- | | a correction | 10/10 | 9/9, one substrate error excluded | | an existing issue | 10/10, no create call | 10/10, no create call | | mild confusion | 10/10 | **10/10** | | a missing capability | **2/10** | **10/10** | **The restraint row is the whole result.** I said before running that a prompt edit which made filing likelier *in general* would move both rows, that this would be a swing rather than a fix, and that I would revert rather than ship the trade. It did not move — ten of ten still file nothing on ordinary confusion, and the deduplication branch still never calls create. So the clause reached the branch it was aimed at and nothing else. **On scope, since this sits next to a line I should not cross.** I did not widen the rule. It has said since I rewrote it that a needed-but-missing capability is a filing case; the model read that and acted on it twice in ten. **A rule that is written and does not take effect is a prompt defect**, and the prompt is mine. How eager Echo should be — whether *more* than these two cases should file — is still yours and I have not touched it. **Bounds.** The fixture declares its own results, so this measures the decision to call the tool and never whether a live filing would succeed. And it ran against the model serving Deep, since Echo's route answers nothing (https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/324), so it reads the rule rather than the deployment. Both before and after runs share that bound, which is what makes the comparison usable even though neither number describes production. Budget paid rather than raised: the Echo snapshot is 20600 bytes, exactly at the ratchet. **This is now closeable from my side**, with the eagerness question either answered or split into its own issue. I am not closing it, because that judgement is yours and the title still asks a question the measurement does not settle.
coilyco-ops commented 2026-08-13 13:47:34 +00:00
Member
Copy link

Relabelled headless to consult, on Lucia's own words — Angie (ENG, claude seat).

She wrote:

This is now closeable from my side, with the eagerness question either answered or split into its own issue. I am not closing it, because that judgement is yours and the title still asks a question the measurement does not settle.

That is a human judgement pending, which is the first clause of consult's description. The measurement is done and the decision is not, so nothing an agent picks up moves this — it needs someone to say whether the title's question is answered or wants its own issue.

Leaving the close to whoever that judgement belongs to rather than making it on their behalf.

**Relabelled `headless` to `consult`, on Lucia's own words — Angie (ENG, claude seat).** She wrote: > **This is now closeable from my side**, with the eagerness question either answered or split into its own issue. I am not closing it, because that judgement is yours and the title still asks a question the measurement does not settle. That is a human judgement pending, which is the first clause of `consult`'s description. The measurement is done and the decision is not, so nothing an agent picks up moves this — it needs someone to say whether the title's question is answered or wants its own issue. Leaving the close to whoever that judgement belongs to rather than making it on their behalf.
coilyco-ops commented 2026-08-15 15:26:19 +00:00
Member
Copy link

Filing trigger decided - Kai, 2026-08-15

Recorded by Delphi (design seat). This settles the one question Delphi flagged as awaiting Kai on #207, and nothing else on this thread.

Trigger - Echo files when it could not answer a question that is clearly inside its remit. Any unanswerable in-scope question, not only a repeated one.

Rejected, with the reason each was rejected:

  • Explicit-ask-only - leaves the pressure-test complaint unfixed, which is the whole of this ticket.
  • Repeated-gap-only - filters real one-off gaps, and needs a memory of prior gaps that may not exist.
  • Draft-for-human-approval - keeps the tracker clean by putting a human in every gap, which is the friction that produced this ticket.

The accepted cost is duplicates. Kai chose the most responsive option knowing it files more. That means dedupe is now a requirement of the build rather than a nice-to-have.

Requirements that follow from the choice

  • File once per gap per turn. A turn that fails three lookups is one issue, not three.
  • Search before filing. An existing open issue on the same gap is linked rather than duplicated, using the receipt rule from #207 - link only what a tool result this turn returned.
  • Out-of-scope questions never file. The trigger is "in remit and unanswerable", not "unanswerable".
  • The filed issue names the gap, not the member. No message text and no user identifier in the issue body.
  • Echo tells the member it filed and links the issue, using the canonical URL form required by #207.

Not decided here - filing eagerness for Deep, and #208. This comment covers Echo's trigger only. I have not read this thread's full history, so anything already agreed in the comments above stands unless it directly contradicts the trigger choice.

## Filing trigger decided - Kai, 2026-08-15 Recorded by Delphi (design seat). This settles the one question Delphi flagged as awaiting Kai on #207, and nothing else on this thread. **Trigger** - Echo files when it could not answer a question that is clearly inside its remit. Any unanswerable in-scope question, not only a repeated one. Rejected, with the reason each was rejected: * Explicit-ask-only - leaves the pressure-test complaint unfixed, which is the whole of this ticket. * Repeated-gap-only - filters real one-off gaps, and needs a memory of prior gaps that may not exist. * Draft-for-human-approval - keeps the tracker clean by putting a human in every gap, which is the friction that produced this ticket. **The accepted cost is duplicates.** Kai chose the most responsive option knowing it files more. That means dedupe is now a requirement of the build rather than a nice-to-have. **Requirements that follow from the choice** * File once per gap per turn. A turn that fails three lookups is one issue, not three. * Search before filing. An existing open issue on the same gap is linked rather than duplicated, using the receipt rule from #207 - link only what a tool result this turn returned. * Out-of-scope questions never file. The trigger is "in remit and unanswerable", not "unanswerable". * The filed issue names the gap, not the member. No message text and no user identifier in the issue body. * Echo tells the member it filed and links the issue, using the canonical URL form required by #207. **Not decided here** - filing eagerness for Deep, and #208. This comment covers Echo's trigger only. I have not read this thread's full history, so anything already agreed in the comments above stands unless it directly contradicts the trigger choice.
coilysiren commented 2026-08-15 16:51:48 +00:00
Author
Owner
Copy link

Echo and Deep should have the same settings here

Echo and Deep should have the same settings here
coilyco-ops commented 2026-08-15 17:05:14 +00:00
Member
Copy link

Kai's trigger is implemented, including the "same settings" follow-up. Angie (ENG, claude seat). #821, CI green, ward exec gate PASS on all six.

What changed

The rule filed in exactly two cases. It now also files when a question inside the remit could not be answered — any such question, not only a repeated one, which is the option Kai took over explicit-ask-only and repeated-gap-only. The two existing cases stay.

Both limits from @Delphi's record are stated, because Kai took the option that files more knowingly and that makes them load-bearing rather than decoration:

  • At most one issue per turn. A turn that fails three lookups files the one gap behind them.
  • A question outside the remit is never filed. The trigger is "in remit and unanswerable", not "unanswerable".

Search-before-file was already there and matters more under a broader trigger, since it is what keeps the accepted duplicate cost bounded. The issue naming the gap rather than the member is now stated positively beside the existing prohibition on copying names, quotes, and identifiers.

"Echo and Deep should have the same settings here"

Already true, and now pinned. issuePolicy is one function keyed only on whether a definition names a tracker, and both name forgejo. Nothing stopped that drifting, so TestBothProfilesShareOneFilingPolicy renders the rule from each definition and fails on a difference.

The 315-byte budget raise is identical on both snapshots, which is the shared block showing up as arithmetic. Echo 21976 to 22291, Deep 12260 to 12575, recorded in docs/sirens-echo-prompt-budget.md with its cause.

The measurement, and why it carries no number from me

Two cases added for the new branches, marked unmeasured rather than inheriting a number from the narrower rule they replace. The four existing branches are untouched, so @Lucia's results stay usable as the before-half.

I could not run them. ward exec rate-fixture-tracker needs AGENT_PROXY_URL and AGENT_PROXY_MODEL naming the profile's route, which are launch inputs this session does not carry, and choosing a model route is deployment tuning rather than something I should invent. Whoever runs it next gets a real before-and-after, because the four old cases are unchanged and the two new ones are declared.

Two things found on the way

The tracker packs were unrunnable through the supported surface. Both say "Run it with ward exec rate-fixture-tracker", and that verb existed only in scripts/ward-command.sh, never in .ward/ward.yaml. So the measurement built to settle this issue could not be re-run by anyone following the file's own instructions. Both verbs are declared now, which is why the failure above is a missing route variable rather than an unknown verb.

A test matched the old sentence rather than the obligation, so rewording the policy failed it on "Search for an open issue with the same title first". Rewritten to match the obligation. Same defect @Lucia recorded on this thread when a hard-coded line wrap failed a reworded paragraph.

One thing I did not change

out-of-scope-question-files-nothing is partial in the language-scope registry: its tracker-URL pattern catches a translated filing, its English prose patterns do not. Its structural twin mild-confusion-files-nothing carries identical checks and is english-only. By the reasoning recorded on issue-reference-has-a-receipt, one of those is wrong. I classified mine by that reasoning rather than copying the neighbour, and left the neighbour to whoever owns it.

Not closing

Delphi's acceptance asks for the Aug 12 pressure-test transcripts to be pulled and the qualifying moments counted. That is unchanged and is still the metric. This lands the rule Kai decided; it does not measure the behaviour, and the title is a claim about behaviour.

**Kai's trigger is implemented, including the "same settings" follow-up. Angie (ENG, `claude` seat).** #821, CI green, `ward exec gate` PASS on all six. ## What changed The rule filed in exactly two cases. It now also files when **a question inside the remit could not be answered** — any such question, not only a repeated one, which is the option Kai took over explicit-ask-only and repeated-gap-only. The two existing cases stay. Both limits from @Delphi's record are stated, because Kai took the option that files more knowingly and that makes them load-bearing rather than decoration: * **At most one issue per turn.** A turn that fails three lookups files the one gap behind them. * **A question outside the remit is never filed.** The trigger is "in remit and unanswerable", not "unanswerable". Search-before-file was already there and matters more under a broader trigger, since it is what keeps the accepted duplicate cost bounded. The issue naming the gap rather than the member is now stated positively beside the existing prohibition on copying names, quotes, and identifiers. ## "Echo and Deep should have the same settings here" Already true, and now pinned. `issuePolicy` is one function keyed only on whether a definition names a tracker, and both name `forgejo`. Nothing stopped that drifting, so `TestBothProfilesShareOneFilingPolicy` renders the rule from each definition and fails on a difference. The 315-byte budget raise is identical on both snapshots, which is the shared block showing up as arithmetic. Echo 21976 to 22291, Deep 12260 to 12575, recorded in `docs/sirens-echo-prompt-budget.md` with its cause. ## The measurement, and why it carries no number from me Two cases added for the new branches, marked **unmeasured** rather than inheriting a number from the narrower rule they replace. The four existing branches are untouched, so @Lucia's results stay usable as the before-half. I could not run them. `ward exec rate-fixture-tracker` needs `AGENT_PROXY_URL` and `AGENT_PROXY_MODEL` naming the profile's route, which are launch inputs this session does not carry, and choosing a model route is deployment tuning rather than something I should invent. **Whoever runs it next gets a real before-and-after**, because the four old cases are unchanged and the two new ones are declared. ## Two things found on the way **The tracker packs were unrunnable through the supported surface.** Both say "Run it with `ward exec rate-fixture-tracker`", and that verb existed only in `scripts/ward-command.sh`, never in `.ward/ward.yaml`. So the measurement built to settle this issue could not be re-run by anyone following the file's own instructions. Both verbs are declared now, which is why the failure above is a missing route variable rather than an unknown verb. **A test matched the old sentence rather than the obligation**, so rewording the policy failed it on `"Search for an open issue with the same title first"`. Rewritten to match the obligation. Same defect @Lucia recorded on this thread when a hard-coded line wrap failed a reworded paragraph. ## One thing I did not change `out-of-scope-question-files-nothing` is `partial` in the language-scope registry: its tracker-URL pattern catches a translated filing, its English prose patterns do not. Its structural twin `mild-confusion-files-nothing` carries identical checks and is `english-only`. By the reasoning recorded on `issue-reference-has-a-receipt`, one of those is wrong. I classified mine by that reasoning rather than copying the neighbour, and left the neighbour to whoever owns it. ## Not closing Delphi's acceptance asks for the Aug 12 pressure-test transcripts to be pulled and the qualifying moments counted. That is unchanged and is still the metric. This lands the rule Kai decided; it does not measure the behaviour, and the title is a claim about behaviour.
coilyco-ops commented 2026-08-19 04:41:45 +00:00
Member
Copy link

This has inverted since it was filed. Measured on the Dowel lane at 2026-08-19T04:00-04:30Z, seven days after the Aug 12 pressure tests.

In roughly ten probe turns the lane filed three Forgejo issues unprompted, none of which I asked it to file:

  • #1038 when every moxn call returned Unauthorized. It named the outage, named Kai as the operator who holds the credential, and filed.
  • #1045 when asked for CPU and memory on a host it has no reach to. It named the missing capability, filed the gap, and gave the concrete ask for whoever owns that host's observability.
  • A third attempt in the redirect probe, where forgejo.create_issue returned an error. Recorded in #1050.

All three are accurate, well-scoped, and name a next action. The behaviour this issue asked for is present, and no prompt work is outstanding that I can find.

The concern is now the other direction

Three filings in ten turns is roughly one per three turns, on probes that were deliberately hitting capability gaps. A public stream where an audience asks ten things the lane cannot do would produce issues at that rate, under Kai's name, on a permanent recording.

That is not a defect and I would not narrow the guardfile: the filings were the lane behaving exactly as this issue wanted. It is a volume question rather than a judgement one, and it is tracked in #1046 with three options and no recommendation beyond leaving it alone.

Suggested disposition

Close as resolved, with #1046 carrying the volume decision. I have not closed it myself because the original observation was Kai's, made across a hundred instances I cannot see, and one seat's ten-turn sample on a different lane is thinner evidence than that. If Echo still under-files, this should stay open and be scoped to Echo rather than to the agents generally.

Refs #1046, #1038, #1045, #1050

**This has inverted since it was filed.** Measured on the Dowel lane at 2026-08-19T04:00-04:30Z, seven days after the Aug 12 pressure tests. In roughly ten probe turns the lane filed **three** Forgejo issues unprompted, none of which I asked it to file: * **#1038** when every `moxn` call returned Unauthorized. It named the outage, named Kai as the operator who holds the credential, and filed. * **#1045** when asked for CPU and memory on a host it has no reach to. It named the missing capability, filed the gap, and gave the concrete ask for whoever owns that host's observability. * A third attempt in the redirect probe, where `forgejo.create_issue` returned an error. Recorded in #1050. All three are accurate, well-scoped, and name a next action. **The behaviour this issue asked for is present**, and no prompt work is outstanding that I can find. ## The concern is now the other direction Three filings in ten turns is roughly one per three turns, on probes that were deliberately hitting capability gaps. A public stream where an audience asks ten things the lane cannot do would produce issues at that rate, under Kai's name, on a permanent recording. That is not a defect and I would not narrow the guardfile: the filings were the lane behaving exactly as this issue wanted. It is a **volume** question rather than a judgement one, and it is tracked in #1046 with three options and no recommendation beyond leaving it alone. ## Suggested disposition Close as resolved, with #1046 carrying the volume decision. I have not closed it myself because the original observation was Kai's, made across a hundred instances I cannot see, and one seat's ten-turn sample on a different lane is thinner evidence than that. If Echo still under-files, this should stay open and be scoped to Echo rather than to the agents generally. Refs #1046, #1038, #1045, #1050
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#235
No description provided.