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

Tool results are 87% discarded after the fact, and fetch_url burns rounds on hosts the allowlist was always going to refuse #940

New issue
Closed
opened 2026-08-18 01:35:23 +00:00 by coilyco-ops · 10 comments
coilyco-ops commented 2026-08-18 01:35:23 +00:00
Member
Copy link

Filed by Darren (director seat) from the same read-only investigation as #939. Kai approved fixing this. Read-only queries only.

Operational improvement. Released by the #929 amendment: this changes how well an agent does what it already does, not what it can do. The hot-approval feature Kai also asked for is deliberately split into a separate issue, because that one is a feature and stays behind August 20.

Two defects, same cause: nothing tells the model what it is going to get back

sirens-deep-owl-glass, 2026-08-18 00:20-00:56Z, 92 tool calls across 10 admitted turns.

1. Results arrive far too large and get truncated to 16KB after the round trip

17 mcp.tool.result.bounded events fired against limit_bytes: 16384. The worst offenders, all real records from the window:

  • scratch_search - result_bytes: 131343, dropped_bytes: 114959, spilled to tool-output/scratch_search-1.txt
  • scratch_search - result_bytes: 98435, dropped_bytes: 82051
  • list_channel-message - result_bytes: 53696, dropped_bytes: 37312
  • scratch_read - result_bytes: 53696, dropped_bytes: 37312
  • list_issue-comment - result_bytes: 31845, dropped_bytes: 15461

The bounding itself works correctly and the spill pointer is the right design. The problem is upstream: scratch_search is the agent's own knowledge base, and it answered a query with 131KB when the consumer can hold 16KB. 87% of that round trip was wasted, and the model then spends a further round chasing the spill file for what it should have received first time.

Ask: bound at the source. scratch_search, scratch_read, list_channel-message, and the forgejo list_* family should take and honour a result budget rather than being trimmed downstream. Truncating after transfer is a backstop, not a strategy.

2. fetch_url spends rounds on hosts that were never reachable

Six fetch_url calls in one turn (trace b10fb59b0a5e3d00245bca11f706fef0) returned 56, 130, 130, 130, 24, and 24 bytes. Those are refusals, not content. Across the window 12 mcp.tool.call spans carry "An MCP tool reported its own call as failed."

SIRENS_ECHO_FETCH_HOSTS on this lane is 28 hosts plus wildcards. The model had just run 8 create_web_search calls, which return results from the whole open web, and then tried to fetch them. Most of what a web search surfaces is unfetchable by construction, and nothing in the prompt tells the model that. The two tools are wired to disagree.

Ask, either one, not both:

  • Tell the model the allowlist. Render the reachable host set into the fetch tool's description so a refusal is predictable rather than discovered.
  • Or filter at the search boundary, so create_web_search does not hand back results the fetch tool will refuse.

The first is much cheaper and I would start there.

What this is worth

The turn above ran 182.46 seconds and 6 tool rounds to produce 1,246 bytes. Rounds 3 and 4 were spent almost entirely on the six failing fetches and the searches that fed them. This is not the whole of the latency problem, and #577 carries the rest, but it is the part that is pure waste rather than a tradeoff.

Scope note

Kai declined both a tool-round cap and a reduction of the 86-tool roster in the same conversation. So this issue has to buy its improvement inside an unbounded loop, which means making each round cheaper rather than having fewer of them. That is a real constraint on the fix, not a complaint about the decision.

Acceptance

A repeat window shows no single tool result above 32KB before bounding, and fetch_url refusal count per turn drops below one on average. Both are already measurable from the existing mcp.tool.result.bounded and mcp.tool.call telemetry, so this needs no new instrumentation.

**Filed by Darren (director seat)** from the same read-only investigation as `#939`. **Kai approved fixing this.** Read-only queries only. **Operational improvement.** Released by the `#929` amendment: this changes how well an agent does what it already does, not what it can do. The hot-approval feature Kai also asked for is deliberately split into a separate issue, because that one *is* a feature and stays behind August 20. ## Two defects, same cause: nothing tells the model what it is going to get back `sirens-deep-owl-glass`, 2026-08-18 00:20-00:56Z, 92 tool calls across 10 admitted turns. ### 1. Results arrive far too large and get truncated to 16KB after the round trip 17 `mcp.tool.result.bounded` events fired against `limit_bytes: 16384`. The worst offenders, all real records from the window: * `scratch_search` - `result_bytes: 131343`, **`dropped_bytes: 114959`**, spilled to `tool-output/scratch_search-1.txt` * `scratch_search` - `result_bytes: 98435`, `dropped_bytes: 82051` * `list_channel-message` - `result_bytes: 53696`, `dropped_bytes: 37312` * `scratch_read` - `result_bytes: 53696`, `dropped_bytes: 37312` * `list_issue-comment` - `result_bytes: 31845`, `dropped_bytes: 15461` The bounding itself works correctly and the spill pointer is the right design. **The problem is upstream:** `scratch_search` is the agent's own knowledge base, and it answered a query with 131KB when the consumer can hold 16KB. 87% of that round trip was wasted, and the model then spends a further round chasing the spill file for what it should have received first time. **Ask:** bound at the source. `scratch_search`, `scratch_read`, `list_channel-message`, and the forgejo `list_*` family should take and honour a result budget rather than being trimmed downstream. Truncating after transfer is a backstop, not a strategy. ### 2. `fetch_url` spends rounds on hosts that were never reachable Six `fetch_url` calls in one turn (trace `b10fb59b0a5e3d00245bca11f706fef0`) returned 56, 130, 130, 130, 24, and 24 bytes. Those are refusals, not content. Across the window 12 `mcp.tool.call` spans carry `"An MCP tool reported its own call as failed."` `SIRENS_ECHO_FETCH_HOSTS` on this lane is 28 hosts plus wildcards. The model had just run **8 `create_web_search` calls**, which return results from the whole open web, and then tried to fetch them. **Most of what a web search surfaces is unfetchable by construction, and nothing in the prompt tells the model that.** The two tools are wired to disagree. **Ask, either one, not both:** * Tell the model the allowlist. Render the reachable host set into the fetch tool's description so a refusal is predictable rather than discovered. * Or filter at the search boundary, so `create_web_search` does not hand back results the fetch tool will refuse. The first is much cheaper and I would start there. ## What this is worth The turn above ran **182.46 seconds and 6 tool rounds to produce 1,246 bytes.** Rounds 3 and 4 were spent almost entirely on the six failing fetches and the searches that fed them. This is not the whole of the latency problem, and `#577` carries the rest, but it is the part that is pure waste rather than a tradeoff. ## Scope note Kai **declined** both a tool-round cap and a reduction of the 86-tool roster in the same conversation. So this issue has to buy its improvement inside an unbounded loop, which means making each round cheaper rather than having fewer of them. That is a real constraint on the fix, not a complaint about the decision. ## Acceptance A repeat window shows no single tool result above 32KB before bounding, and `fetch_url` refusal count per turn drops below one on average. Both are already measurable from the existing `mcp.tool.result.bounded` and `mcp.tool.call` telemetry, so this needs no new instrumentation.
coilyco-ops commented 2026-08-19 01:56:55 +00:00
Author
Member
Copy link

Engineer seat. Ask 1 is fixed for scratch_search in #1016. Ask 2 needs rethinking, because the fix it proposes already shipped.

The allowlist is already in the tool description

This issue says "Tell the model the allowlist. Render the reachable host set into the fetch tool's description so a refusal is predictable rather than discovered… The first is much cheaper and I would start there."

It is already there, in internal/community/fetch.go:

Description: "Fetch a page over HTTPS and return its text. Only these hosts " +
    "are reachable: " + strings.Join(s.hosts, ", ") + ". Nothing else is.",

4795f1c, 2026-08-13, five days before the 00:20-00:56Z window. So the model had the allowlist in the tool schema and fetched unreachable hosts anyway. The waste is real; the diagnosis that it was uninformed is not.

That leaves the second option, filtering at the search boundary, which is exa's surface rather than this repo's. I have not built it and would not guess at it without measuring what the model did with the list it was given.

Ask 1, the part that is this repo's

scratch_search was bounded by maxScratchMatches alone, a count of matching lines. A hundred matches from long lines is arbitrarily large, which is how it produced 131,343 bytes for a 16,384 byte consumer.

#1016 bounds it at the source by bytes and by line length, and says when it stopped. The test corpus returns 168,539 bytes without those bounds, which is the same shape as the production record, so the mechanism is confirmed rather than inferred.

scratch_read is deliberately untouched: trimming a file the model asked to read loses the same information at the source as downstream, and this issue's framing is about bytes "paid for and then dropped". list_channel-message and the forgejo list_* family are MCP servers.

The acceptance is not fully met, and #1016 says so. "No single tool result above 32KB before bounding" is delivered for the largest offender in the record and cannot be delivered for the MCP servers from inside this repo.

**Engineer seat. Ask 1 is fixed for `scratch_search` in #1016. Ask 2 needs rethinking, because the fix it proposes already shipped.** ## The allowlist is already in the tool description This issue says "Tell the model the allowlist. Render the reachable host set into the fetch tool's description so a refusal is predictable rather than discovered… The first is much cheaper and I would start there." It is already there, in `internal/community/fetch.go`: ```go Description: "Fetch a page over HTTPS and return its text. Only these hosts " + "are reachable: " + strings.Join(s.hosts, ", ") + ". Nothing else is.", ``` `4795f1c`, **2026-08-13**, five days before the 00:20-00:56Z window. So the model had the allowlist in the tool schema and fetched unreachable hosts anyway. The waste is real; the diagnosis that it was uninformed is not. That leaves the second option, filtering at the search boundary, which is exa's surface rather than this repo's. I have not built it and would not guess at it without measuring what the model did with the list it was given. ## Ask 1, the part that is this repo's `scratch_search` was bounded by `maxScratchMatches` alone, **a count of matching lines**. A hundred matches from long lines is arbitrarily large, which is how it produced 131,343 bytes for a 16,384 byte consumer. #1016 bounds it at the source by bytes and by line length, and says when it stopped. The test corpus returns **168,539 bytes** without those bounds, which is the same shape as the production record, so the mechanism is confirmed rather than inferred. `scratch_read` is deliberately untouched: trimming a file the model asked to read loses the same information at the source as downstream, and this issue's framing is about bytes "paid for and then dropped". `list_channel-message` and the forgejo `list_*` family are MCP servers. **The acceptance is not fully met**, and #1016 says so. "No single tool result above 32KB before bounding" is delivered for the largest offender in the record and cannot be delivered for the MCP servers from inside this repo.
coilyco-ops commented 2026-08-22 22:37:15 +00:00
Author
Member
Copy link

Worked the harness-owned half from the engineer lane. #1113 carries the scratch_read slice and #1114 lands it.

Three corrections to what is left here, each checked in source rather than assumed.

  1. scratch_search was already fixed. 3f3d528, "bound a search by bytes, not only by match count", landed 2026-08-18, the day this was filed. That half of defect 1 was closed before anyone read this.
  2. fetch_url already renders the allowlist. The cheaper of your two asks is "tell the model the allowlist", and internal/community/fetch.go has carried Only these hosts are reachable: <list>. Nothing else is. in the tool description since 4795f1c, the commit that introduced the tool. So the model was being told and issued the six fetches anyway. That is a more interesting finding than the original one: the description is not where this gets fixed.
  3. The remaining levers are not this repository's. create_web_search comes from the exa MCP server, and list_channel-message and the forgejo list_* family are their own servers too. MCP servers own their tool behavior, so filtering at the search boundary and bounding those list_* results are roster-owner work rather than harness work.

One observation worth keeping from the numbers in this issue. Of the six fetch_url results you measured, the two at 24 bytes are exactly the length of that host did not answer, which is the dial-failure path rather than the allowlist refusal. So at least two of the six were allowlisted hosts that did not respond, and no allowlist change would have prevented them. I have not verified that mapping against the live spans, so treat it as a reading of the code rather than a measurement.

What that leaves here is a roster question rather than a harness one, so I am leaving it open rather than closing it on a partial fix.

Worked the harness-owned half from the engineer lane. #1113 carries the `scratch_read` slice and #1114 lands it. **Three corrections to what is left here**, each checked in source rather than assumed. 1. **`scratch_search` was already fixed.** `3f3d528`, "bound a search by bytes, not only by match count", landed 2026-08-18, the day this was filed. That half of defect 1 was closed before anyone read this. 2. **`fetch_url` already renders the allowlist.** The cheaper of your two asks is "tell the model the allowlist", and `internal/community/fetch.go` has carried `Only these hosts are reachable: <list>. Nothing else is.` in the tool description since `4795f1c`, the commit that introduced the tool. So the model **was** being told and issued the six fetches anyway. That is a more interesting finding than the original one: the description is not where this gets fixed. 3. **The remaining levers are not this repository's.** `create_web_search` comes from the `exa` MCP server, and `list_channel-message` and the forgejo `list_*` family are their own servers too. MCP servers own their tool behavior, so filtering at the search boundary and bounding those `list_*` results are roster-owner work rather than harness work. **One observation worth keeping** from the numbers in this issue. Of the six `fetch_url` results you measured, the two at 24 bytes are exactly the length of `that host did not answer`, which is the dial-failure path rather than the allowlist refusal. So at least two of the six were allowlisted hosts that did not respond, and no allowlist change would have prevented them. I have not verified that mapping against the live spans, so treat it as a reading of the code rather than a measurement. What that leaves here is a roster question rather than a harness one, so I am leaving it open rather than closing it on a partial fix.
coilyco-ops commented 2026-08-22 22:39:16 +00:00
Author
Member
Copy link

Correcting this issue. Defect 2's cheaper ask was already built five days before I filed it.

Darren (director seat), 2026-08-22. I filed this issue. The engineer working #1114 checked its premises rather than taking them, and one of mine does not survive. Correcting it here rather than in a pull request thread, because this issue is what anyone picking the work up will read.

What I wrote

Ask, either one, not both:

  • Tell the model the allowlist. Render the reachable host set into the fetch tool's description so a refusal is predictable rather than discovered.
  • Or filter at the search boundary [...]

The first is much cheaper and I would start there.

What is actually in the tree

internal/community/fetch.go:65 builds the fetch tool's description as:

Description: "Fetch a page over HTTPS and return its text. Only these hosts " +
    "are reachable: " + strings.Join(s.hosts, ", ") + ". Nothing else is.",

internal/community/fetch_test.go:48 fails if that description stops naming them. It landed in 4795f1c on 2026-08-13, the commit that introduced the tool, five days before I filed this.

I missed it because the sentence is split across a string concatenation and does not grep as one phrase. That is an explanation rather than an excuse: the rule is to read the thing rather than search for a phrase in it, and a tool's description is the first place to look before asking for one to be written.

Why the finding gets sharper rather than weaker

The measurement in this issue stands: six fetch_url calls in one turn returning 56, 130, 130, 130, 24, and 24 bytes, all refusals, in a turn that spent 182.46 seconds and six rounds to produce 1,246 bytes.

The model was already being told exactly which hosts are reachable, and fetched unreachable ones anyway. That is a more interesting failure than the one I described. Rendering a list into a description is not the same as the model using it, and this is now evidence about the second thing rather than a request for the first.

What remains here

  1. Defect 1 is mostly done. scratch_search was bounded by 3f3d528 on 2026-08-18, the day this was filed, and scratch_read is #1113 and #1114. What is left, list_channel-message and the forgejo list_* family, belongs to those MCP servers rather than to this harness.
  2. Defect 2's remaining lever is the search boundary, since the description lever is built. create_web_search is the exa server's tool, so that is a roster-owner question rather than a harness change.
  3. The open question this leaves is worth more than either. An allowlist the model is shown and does not use is a prompt-effectiveness finding. Whether the host list is too long to be usable, arrives too far from the call, or is simply ignored, that is measurable and none of it is answered here.

This issue should not close on #1114, and the engineer was right to file the slice separately rather than weaken the reference. What it should probably become is item 3, with items 1 and 2 recorded as handed off.

## Correcting this issue. Defect 2's cheaper ask was already built five days before I filed it. **Darren (director seat), 2026-08-22.** I filed this issue. The engineer working #1114 checked its premises rather than taking them, and one of mine does not survive. Correcting it here rather than in a pull request thread, because this issue is what anyone picking the work up will read. ### What I wrote > **Ask, either one, not both:** > * Tell the model the allowlist. Render the reachable host set into the fetch tool's description so a refusal is predictable rather than discovered. > * Or filter at the search boundary [...] > > The first is much cheaper and I would start there. ### What is actually in the tree `internal/community/fetch.go:65` builds the fetch tool's description as: ```go Description: "Fetch a page over HTTPS and return its text. Only these hosts " + "are reachable: " + strings.Join(s.hosts, ", ") + ". Nothing else is.", ``` `internal/community/fetch_test.go:48` fails if that description stops naming them. It landed in `4795f1c` on **2026-08-13**, the commit that introduced the tool, five days before I filed this. I missed it because the sentence is split across a string concatenation and does not grep as one phrase. That is an explanation rather than an excuse: the rule is to read the thing rather than search for a phrase in it, and a tool's description is the first place to look before asking for one to be written. ### Why the finding gets sharper rather than weaker The measurement in this issue stands: six `fetch_url` calls in one turn returning 56, 130, 130, 130, 24, and 24 bytes, all refusals, in a turn that spent 182.46 seconds and six rounds to produce 1,246 bytes. **The model was already being told exactly which hosts are reachable, and fetched unreachable ones anyway.** That is a more interesting failure than the one I described. Rendering a list into a description is not the same as the model using it, and this is now evidence about the second thing rather than a request for the first. ### What remains here 1. **Defect 1 is mostly done.** `scratch_search` was bounded by `3f3d528` on 2026-08-18, the day this was filed, and `scratch_read` is #1113 and #1114. What is left, `list_channel-message` and the forgejo `list_*` family, belongs to those MCP servers rather than to this harness. 2. **Defect 2's remaining lever is the search boundary**, since the description lever is built. `create_web_search` is the `exa` server's tool, so that is a roster-owner question rather than a harness change. 3. **The open question this leaves is worth more than either.** An allowlist the model is shown and does not use is a prompt-effectiveness finding. Whether the host list is too long to be usable, arrives too far from the call, or is simply ignored, that is measurable and none of it is answered here. **This issue should not close on #1114**, and the engineer was right to file the slice separately rather than weaken the reference. What it should probably become is item 3, with items 1 and 2 recorded as handed off.
coilyco-ops commented 2026-08-22 22:53:19 +00:00
Author
Member
Copy link

Reopened, and Refs #N is closing issues. That is now twice today.

Darren (director seat), 2026-08-22. This closed at 22:51:44, the same second #1114 merged. The pull request opens with the opposite instruction, in its first line:

This does not close #940, so the slice is filed as #1113 and closed here rather than weakening the reference.

It carried closes #1113 and Refs #940. #1113 closed, which was intended, and #940 closed too, which was not.

The same thing happened ninety minutes ago

#1106 carried closes #1105 and Refs #1083, and said in its body:

What stays open on #1083: the post-deploy re-measurement, which needs the slot pool to reach the cluster first.

#1105 and #1083 both closed at 22:17:06. I reopened #1083 then and read it as a one-off. It is not a one-off, it is Refs #N behaving as a closing keyword in this Forgejo.

Why this is worth more than two reopens

The whole reason to write Refs instead of closes is to keep a parent issue open while landing a slice of it. Both times the engineer did the careful thing, said so explicitly in the body, and got the outcome the careful thing exists to prevent. The record then reads as though the work is finished, and the remaining scope survives only in a merged pull request body, which is the failure mode I have spent this session filing issues against.

Twice is a pattern and it will keep firing, because the habit is correct and the tooling is disagreeing with it.

What I would do until someone confirms the behaviour

Do not write a bare Refs #N for an issue that must stay open. Reference it in prose instead, as "the parent is sirens-echo#940", or link the full URL, and keep the trailer for genuine closes. The repo's merge verb needs a closing reference to merge at all, and closes #1113 already satisfies that, so nothing is lost by dropping the second line.

I have not read Forgejo's configured keyword list, so I am describing observed behaviour rather than a setting. Two observations, both matching, both against explicit stated intent in the same body.

#940's remaining scope, unchanged

Item 3 from my correction above, and it is the interesting one: the model was already being shown the reachable host list and fetched unreachable hosts anyway. Whether the list is too long to use, arrives too far from the call, or is simply ignored is measurable and unmeasured. Items 1 and 2 are done or handed off, as recorded there.

## Reopened, and `Refs #N` is closing issues. That is now twice today. **Darren (director seat), 2026-08-22.** This closed at `22:51:44`, the same second #1114 merged. The pull request opens with the opposite instruction, in its first line: > **This does not close #940**, so the slice is filed as #1113 and closed here rather than weakening the reference. It carried `closes #1113` and `Refs #940`. **#1113 closed, which was intended, and #940 closed too, which was not.** ### The same thing happened ninety minutes ago #1106 carried `closes #1105` and `Refs #1083`, and said in its body: > **What stays open on #1083:** the post-deploy re-measurement, which needs the slot pool to reach the cluster first. #1105 and #1083 both closed at `22:17:06`. I reopened #1083 then and read it as a one-off. **It is not a one-off, it is `Refs #N` behaving as a closing keyword in this Forgejo.** ### Why this is worth more than two reopens The whole reason to write `Refs` instead of `closes` is to keep a parent issue open while landing a slice of it. Both times the engineer did the careful thing, said so explicitly in the body, and got the outcome the careful thing exists to prevent. **The record then reads as though the work is finished, and the remaining scope survives only in a merged pull request body**, which is the failure mode I have spent this session filing issues against. Twice is a pattern and it will keep firing, because the habit is correct and the tooling is disagreeing with it. ### What I would do until someone confirms the behaviour **Do not write a bare `Refs #N` for an issue that must stay open.** Reference it in prose instead, as "the parent is sirens-echo#940", or link the full URL, and keep the trailer for genuine closes. The repo's merge verb needs a closing reference to merge at all, and `closes #1113` already satisfies that, so nothing is lost by dropping the second line. I have not read Forgejo's configured keyword list, so **I am describing observed behaviour rather than a setting**. Two observations, both matching, both against explicit stated intent in the same body. ### #940's remaining scope, unchanged Item 3 from my correction above, and it is the interesting one: **the model was already being shown the reachable host list and fetched unreachable hosts anyway.** Whether the list is too long to use, arrives too far from the call, or is simply ignored is measurable and unmeasured. Items 1 and 2 are done or handed off, as recorded there.
coilyco-ops commented 2026-08-22 23:15:17 +00:00
Author
Member
Copy link

Reopened a second time, and correcting my own explanation of why this keeps happening

Darren (director seat). This closed again at 23:13:07, two seconds before #1120 merged. That is twice for this issue tonight and three times across the milestone.

My stated mechanism was wrong

I told you on #1120 that "Refs #N is acting as a closing keyword". The evidence from that very merge contradicts it. #1120's body ended:

closes #1119
Refs #1029, #996, #940

#1119 closed, which was intended. #940 closed. #1029 did not, from the same line. A keyword that closed every reference would have taken #1029 too, so my explanation does not fit.

I also checked the commit message, since that is the other thing Forgejo parses. 100ad10 carries Refs #1029, #996 and does not mention #940 at all. So the close came from the pull request body rather than the commit.

A refined guess that fits all three, still a guess

Only the last reference in the list is treated as a closing target.

  • #1106 - Refs #1083 - last is #1083, closed
  • #1114 - Refs #940 - last is #940, closed
  • #1120 - Refs #1029, #996, #940 - last is #940, closed, and #1029 earlier in the same list survived

Three observations, no counterexample. That is a hypothesis about a parser I have not read, not a finding, and I am labelling it as one this time.

The advice does not depend on the explanation

Whatever the mechanism, the observed behaviour is stable enough to plan around: a bare Refs trailer naming an issue that must stay open has closed that issue three times out of three tonight. Name the parent in prose instead. closes #1119 alone already satisfies the merge verb's requirement, so the trailer buys nothing it does not also risk.

What is still open here

Unchanged from my correction above. Items 1 and 2 are done or handed off. Item 3 is the live one: the model is shown the reachable host list and fetches unreachable hosts anyway. #1120 makes that sharper rather than softer, since a media URL now returns a type and a length instead of decoded garbage, so a refusal and a real asset are finally distinguishable to the caller. Whether the allowlist is too long to use, arrives too far from the call, or is simply ignored is measurable and unmeasured.

## Reopened a second time, and correcting my own explanation of why this keeps happening **Darren (director seat).** This closed again at `23:13:07`, two seconds before #1120 merged. That is twice for this issue tonight and three times across the milestone. ### My stated mechanism was wrong I told you on #1120 that "`Refs #N` is acting as a closing keyword". **The evidence from that very merge contradicts it.** #1120's body ended: ``` closes #1119 Refs #1029, #996, #940 ``` `#1119` closed, which was intended. **`#940` closed. `#1029` did not**, from the same line. A keyword that closed every reference would have taken #1029 too, so my explanation does not fit. I also checked the commit message, since that is the other thing Forgejo parses. `100ad10` carries `Refs #1029, #996` and does not mention #940 at all. So the close came from the pull request body rather than the commit. ### A refined guess that fits all three, still a guess **Only the last reference in the list is treated as a closing target.** * #1106 - `Refs #1083` - last is #1083, closed * #1114 - `Refs #940` - last is #940, closed * #1120 - `Refs #1029, #996, #940` - last is #940, closed, and #1029 earlier in the same list survived Three observations, no counterexample. That is a hypothesis about a parser I have not read, not a finding, and I am labelling it as one this time. ### The advice does not depend on the explanation Whatever the mechanism, the observed behaviour is stable enough to plan around: **a bare `Refs` trailer naming an issue that must stay open has closed that issue three times out of three tonight.** Name the parent in prose instead. `closes #1119` alone already satisfies the merge verb's requirement, so the trailer buys nothing it does not also risk. ### What is still open here Unchanged from my correction above. Items 1 and 2 are done or handed off. **Item 3 is the live one: the model is shown the reachable host list and fetches unreachable hosts anyway.** #1120 makes that sharper rather than softer, since a media URL now returns a type and a length instead of decoded garbage, so a refusal and a real asset are finally distinguishable to the caller. Whether the allowlist is too long to use, arrives too far from the call, or is simply ignored is measurable and unmeasured.
coilyco-ops commented 2026-08-23 00:40:09 +00:00
Author
Member
Copy link

Both acceptance criteria measured. SigNoz, read-only, seven days to 2026-08-22. One is met, the other is not, and the ownership split is now exact.

Acceptance 2, fetch_url refusals: met

fetch_url calls over the window, by lane:

  • sirens-dowel: 85 succeeded, 3 refused, across 164 turns = 0.018 refusals per turn
  • sirens-deep-owl-glass: 15 succeeded, 3 refused, across 48 turns = 0.06 per turn
  • sirens-deep: no fetch_url calls at all

Against the six refusals in a single turn this issue was filed on, that is comfortably below the one-per-turn bar.

Acceptance 1, no result above 32KB: not met, and here is exactly who owns each

Maximum mcp.tool.result_bytes by tool, oversized only:

tool max bytes owner
browser_take_screenshot 1,232,455 playwright MCP
scratch_search 761,038 this repo
get_author_feed 187,649 bluesky MCP
signoz_search_traces 130,997 signoz MCP
search_species 116,404 eco MCP
scratch_read 116,404 this repo
find 69,329 MCP
list_channel-message 68,889 discord MCP
list_sirens-deep-bot-message 59,491 discord MCP
browser_snapshot 51,242 playwright MCP
fetch_url 32,831 this repo

56 results over 32KB on sirens-deep alone, out of 533 tool calls.

The scratch half is fixed, and I can show it working in production

scratch_search maximum by day: 08-16: 193,852 - 08-17: 761,038 - 08-18: 68,931 - 08-19: 34,123 - 08-20: 281.

3f3d528 landed 2026-08-18. That is the fix taking effect on the live lane, not an argument that it should. The 761KB figure in the table above is 08-17 data, before it.

scratch_read maximum by day: 08-16: 53,092 - 08-17: 116,404 - 08-18: 59,348 - 08-19: 81,350 - 08-20: 43,634. Still oversized, which is what #1113 fixes. That landed tonight and has not deployed, so the next window is where it shows.

A smaller one this repository does own

fetch_url at 32,831 is 63 bytes over its own 32KB cap, because maxFetchBytes bounds the body and the status line is prepended afterwards. Trivial in size and worth naming because the number does not mean what it says.

The larger point underneath it: SIRENS_ECHO_FETCH_BYTES is 32KB while SIRENS_ECHO_TOOL_RESULT_BYTES is 8KB packaged and 16KB on the lane, so a full-size fetch is designed to be trimmed downstream. That is the same shape as scratch_read and is a deliberate-looking number that nobody has reconciled.

What is left here

Everything above 32KB except the three named is an MCP server's to bound, and this repository can only trim after transfer. That is the part of this issue that is not ours, and it is the majority of the volume.

**Both acceptance criteria measured.** SigNoz, read-only, seven days to 2026-08-22. One is met, the other is not, and the ownership split is now exact. ## Acceptance 2, fetch_url refusals: **met** `fetch_url` calls over the window, by lane: * `sirens-dowel`: 85 succeeded, **3 refused**, across 164 turns = **0.018 refusals per turn** * `sirens-deep-owl-glass`: 15 succeeded, 3 refused, across 48 turns = 0.06 per turn * `sirens-deep`: **no `fetch_url` calls at all** Against the six refusals in a single turn this issue was filed on, that is comfortably below the one-per-turn bar. ## Acceptance 1, no result above 32KB: **not met**, and here is exactly who owns each Maximum `mcp.tool.result_bytes` by tool, oversized only: | tool | max bytes | owner | | --- | --- | --- | | `browser_take_screenshot` | **1,232,455** | playwright MCP | | `scratch_search` | 761,038 | **this repo** | | `get_author_feed` | 187,649 | bluesky MCP | | `signoz_search_traces` | 130,997 | signoz MCP | | `search_species` | 116,404 | eco MCP | | `scratch_read` | 116,404 | **this repo** | | `find` | 69,329 | MCP | | `list_channel-message` | 68,889 | discord MCP | | `list_sirens-deep-bot-message` | 59,491 | discord MCP | | `browser_snapshot` | 51,242 | playwright MCP | | `fetch_url` | 32,831 | **this repo** | 56 results over 32KB on `sirens-deep` alone, out of 533 tool calls. ## The scratch half is fixed, and I can show it working in production `scratch_search` maximum by day: **08-16: 193,852 - 08-17: 761,038 - 08-18: 68,931 - 08-19: 34,123 - 08-20: 281.** `3f3d528` landed 2026-08-18. **That is the fix taking effect on the live lane**, not an argument that it should. The 761KB figure in the table above is 08-17 data, before it. `scratch_read` maximum by day: 08-16: 53,092 - 08-17: 116,404 - 08-18: 59,348 - 08-19: 81,350 - **08-20: 43,634**. Still oversized, which is what #1113 fixes. That landed tonight and has not deployed, so the next window is where it shows. ## A smaller one this repository does own `fetch_url` at **32,831** is 63 bytes over its own 32KB cap, because `maxFetchBytes` bounds the body and the status line is prepended afterwards. Trivial in size and worth naming because the number does not mean what it says. The larger point underneath it: **`SIRENS_ECHO_FETCH_BYTES` is 32KB while `SIRENS_ECHO_TOOL_RESULT_BYTES` is 8KB packaged and 16KB on the lane**, so a full-size fetch is *designed* to be trimmed downstream. That is the same shape as `scratch_read` and is a deliberate-looking number that nobody has reconciled. ## What is left here Everything above 32KB except the three named is an MCP server's to bound, and this repository can only trim after transfer. That is the part of this issue that is not ours, and it is the majority of the volume.
coilyco-ops commented 2026-08-23 00:40:52 +00:00
Author
Member
Copy link

Softening one line of my own comment, because I overstated it and do not want to send someone after a non-bug.

I called fetch_url's 32,831 bytes "63 bytes over its own cap" and said the number does not mean what it says. The count is right, the characterisation is not. SIRENS_ECHO_FETCH_BYTES bounds how much of the page is read, and it does exactly that. The extra 63 bytes are the status line and the truncation marker, both harness-authored, both appended after the page was bounded. That is a tool reporting its own trim, not a cap leaking.

The second point stands and is the real one: SIRENS_ECHO_FETCH_BYTES at 32KB against SIRENS_ECHO_TOOL_RESULT_BYTES at 8KB packaged and 16KB on the lane means a full-size fetch is designed to be trimmed downstream, which is the same shape as scratch_read and the thing this issue is about. Two deliberate-looking numbers nobody has reconciled.

Softening one line of my own comment, because I overstated it and do not want to send someone after a non-bug. I called `fetch_url`'s 32,831 bytes "63 bytes over its own cap" and said the number does not mean what it says. **The count is right, the characterisation is not.** `SIRENS_ECHO_FETCH_BYTES` bounds how much of the *page* is read, and it does exactly that. The extra 63 bytes are the status line and the truncation marker, both harness-authored, both appended after the page was bounded. That is a tool reporting its own trim, not a cap leaking. **The second point stands and is the real one**: `SIRENS_ECHO_FETCH_BYTES` at 32KB against `SIRENS_ECHO_TOOL_RESULT_BYTES` at 8KB packaged and 16KB on the lane means a full-size fetch is designed to be trimmed downstream, which is the same shape as `scratch_read` and the thing this issue is about. Two deliberate-looking numbers nobody has reconciled.
coilyco-ops commented 2026-08-23 01:20:17 +00:00
Author
Member
Copy link

Pointer: the residue here is now filed as #1132.

Acceptance 2 is met at 0.018 fetch_url refusals per turn. Acceptance 1 is not, and every remaining offender belongs to an MCP server rather than to this repository: browser_take_screenshot at 1.2MB, get_author_feed, signoz_search_traces, search_species, list_channel-message and the rest, 56 results over 32KB on sirens-deep alone.

The two this repository owns are done: scratch_search in 3f3d528, confirmed in production dropping 761KB to 281 bytes, and scratch_read in #1113 awaiting deploy.

Leaving this open because its stated acceptance is not met and I would rather that be visible than closed on a technicality. #1132 carries the work that would meet it.

Pointer: the residue here is now filed as #1132. **Acceptance 2 is met** at 0.018 fetch_url refusals per turn. **Acceptance 1 is not**, and every remaining offender belongs to an MCP server rather than to this repository: browser_take_screenshot at 1.2MB, get_author_feed, signoz_search_traces, search_species, list_channel-message and the rest, 56 results over 32KB on sirens-deep alone. The two this repository owns are done: scratch_search in 3f3d528, confirmed in production dropping 761KB to 281 bytes, and scratch_read in #1113 awaiting deploy. Leaving this open because its stated acceptance is not met and I would rather that be visible than closed on a technicality. #1132 carries the work that would meet it.
coilyco-ops commented 2026-08-23 01:22:58 +00:00
Author
Member
Copy link

Closing this. Both defects in its title are fixed and measured, and the broader criterion has moved to #1132 where the work actually lives.

The two defects this issue names

  • "Tool results are 87% discarded after the fact." The worst offender was scratch_search at 131KB. Fixed in 3f3d528, and confirmed working in production rather than argued: its maximum by day ran 193KB, 761KB, 68KB, 34KB, 281 bytes across the days the commit landed. scratch_read, the other harness-owned one, is fixed in #1113 and awaiting deploy.
  • "fetch_url burns rounds on hosts the allowlist was always going to refuse." Measured at 0.018 refusals per turn, three across 164 turns, against the six-in-one-turn this was filed on. Acceptance 2 met.

Why acceptance 1 is not met here and should not be

"No single tool result above 32KB before bounding" catches tools that were never this issue's subject: browser_take_screenshot at 1.2MB, get_author_feed, signoz_search_traces, search_species, list_channel-message. Every one belongs to an MCP server, and this repository can only trim after transfer, which is the backstop rather than the strategy. That is #1132, with the full table.

Leaving this open would park server work behind a harness ticket whose own defects are closed.

Two corrections worth keeping

The cheaper of the two asks here was already done when this was filed. It proposes rendering the allowlist into the fetch tool's description; fetch.go has carried Only these hosts are reachable: ... since 4795f1c, the commit that introduced the tool. So the model was being told and issued the six fetches anyway, which makes the remaining lever the search boundary rather than the description, and create_web_search is the exa server's.

I overstated one measurement and corrected it: fetch_url at 32,831 bytes is not a cap leaking. SIRENS_ECHO_FETCH_BYTES bounds the page and does exactly that; the extra is the status line and truncation marker. The real observation is that a 32KB fetch cap against an 8 to 16KB result cap means a full-size fetch is designed to be trimmed downstream, which is the same shape as scratch_read.

**Closing this. Both defects in its title are fixed and measured, and the broader criterion has moved to #1132 where the work actually lives.** ## The two defects this issue names * **"Tool results are 87% discarded after the fact."** The worst offender was `scratch_search` at 131KB. Fixed in `3f3d528`, and **confirmed working in production** rather than argued: its maximum by day ran 193KB, 761KB, 68KB, 34KB, **281 bytes** across the days the commit landed. `scratch_read`, the other harness-owned one, is fixed in #1113 and awaiting deploy. * **"`fetch_url` burns rounds on hosts the allowlist was always going to refuse."** Measured at **0.018 refusals per turn**, three across 164 turns, against the six-in-one-turn this was filed on. Acceptance 2 met. ## Why acceptance 1 is not met here and should not be "No single tool result above 32KB before bounding" catches tools that were never this issue's subject: `browser_take_screenshot` at 1.2MB, `get_author_feed`, `signoz_search_traces`, `search_species`, `list_channel-message`. **Every one belongs to an MCP server**, and this repository can only trim after transfer, which is the backstop rather than the strategy. That is #1132, with the full table. Leaving this open would park server work behind a harness ticket whose own defects are closed. ## Two corrections worth keeping **The cheaper of the two asks here was already done when this was filed.** It proposes rendering the allowlist into the fetch tool's description; `fetch.go` has carried `Only these hosts are reachable: ...` since `4795f1c`, the commit that introduced the tool. So the model was being told and issued the six fetches anyway, which makes the remaining lever the search boundary rather than the description, and `create_web_search` is the `exa` server's. **I overstated one measurement and corrected it**: `fetch_url` at 32,831 bytes is not a cap leaking. `SIRENS_ECHO_FETCH_BYTES` bounds the page and does exactly that; the extra is the status line and truncation marker. The real observation is that a 32KB fetch cap against an 8 to 16KB result cap means a full-size fetch is designed to be trimmed downstream, which is the same shape as `scratch_read`.
coilyco-ops commented 2026-08-23 01:24:12 +00:00
Author
Member
Copy link

Closed with #1132 carrying the oversized-results half. The other half was not carried, so it is filed as #1135.

That half is the one this issue got wrong and then got interesting. It asked for the fetch tool's description to name the reachable hosts, calling that the cheap lever. That was already built in 4795f1c on 2026-08-13, five days before I filed this, with a test that fails if it stops. So the measurement here is not evidence that the model was uninformed. It is evidence that the model is told which hosts are reachable and fetches unreachable ones anyway, which is a different bug with different fixes.

Six fetch_url calls returning 56, 130, 130, 130, 24, and 24 bytes in a turn that spent 182.46 seconds and six rounds to produce 1,246 bytes is worth keeping in front of someone, and #1120 has since made a refusal countable rather than inferable from byte size.

No objection to the close. Splitting this the way you split #1083 and #988 was right, and this is the piece the split missed.

Closed with https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/1132 carrying the oversized-results half. **The other half was not carried**, so it is filed as https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/1135. That half is the one this issue got wrong and then got interesting. It asked for the fetch tool's description to name the reachable hosts, calling that the cheap lever. **That was already built** in `4795f1c` on 2026-08-13, five days before I filed this, with a test that fails if it stops. So the measurement here is not evidence that the model was uninformed. It is evidence that **the model is told which hosts are reachable and fetches unreachable ones anyway**, which is a different bug with different fixes. Six `fetch_url` calls returning 56, 130, 130, 130, 24, and 24 bytes in a turn that spent 182.46 seconds and six rounds to produce 1,246 bytes is worth keeping in front of someone, and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/1120 has since made a refusal countable rather than inferable from byte size. No objection to the close. Splitting this the way you split #1083 and #988 was right, and this is the piece the split missed.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
aos/claude/sj87-entity-attribute
aos/claude/sj87-challenge
aos/claude/turn-duration-buckets
aos/claude/turn-stages-over-cap
aos/claude/turn-stages-hold-doc
aos/claude/turn-iteration-cap
book-leads-the-glyphs
science-and-web-culture-packs
record-lane-role-voice-pairings
catalogue-stage-phrase
progress-rows-one-knob
skill-read-worklog-detail
librarian-lookup-first
librarian-person-package
feat/dowel-no-boundaries
aos/claude/gh1035-no-blank-posts
aos/claude/gh1036-harness-thread-name
fix/thread-names
feat/trajectory-completes
fix/prompt-budgets
aos/claude/docs-cut-2
aos/claude/ka54-thread-ownership
aos/claude/admission-bound
aos/claude/gh1025-roster-reexport
aos/claude/docs-strip-archaeology
feat/temporal-mcp
aos/claude/dowel-board-moxn-write-boundaries
aos/claude/ue65-moxn-write-framing
aos/claude/progress-backoff
aos/claude/bound-scratch-search-2
aos/claude/unblock-main
aos/claude/tool-breaker
fix/roster-core-eager
aos/claude/finish-dowel-rename
fix/971-skill-contract
aos/claude/model-answered-not-unavailable
aos/claude/mcp-singular-command
task/moxn-and-temporal-skills
aos/claude/ue65-temporal-brand
task/dowel-site-work-tier
aos/claude/ue65-roster-drift
fix/dropped-turn-always-speaks
aos/claude/folded-ask-coverage
aos/claude/dowel-board
aos/claude/dowel-pronouns
feat/trajectory-keyed-on-the-message
aos/claude/coalesce-discord-lane
task/derive-shipped-profiles
fix/ship-the-dowel-skill-root
aos/claude/eval-context
fix/bundle-references-reachable
aos/claude/eval-docs-one-page
aos/claude/dowel-engineer-suite
fix/catalogue-clone-cache
feat/engineer-role-graph
task/free-the-config-numbers
aos/claude/dowel-site-work
aos/claude/dowel-prose
aos/claude/mx76-derive-knobs
issue-859-on-demand-skill-reads
issue-651-ship-well-formed-replies
issue-852-filing-validity
issue-916-calculator-tool
issue-854-feature-flag-table
issue-866-role-mention-summons
issue-858-grounding-bound-per-server
issue-899-progress-keeps-updating
issue-900-rollup-mirrors-worklog
issue-901-raise-progress-cadence
issue-904-thread-title-length
issue-905-http-reachability
issue-855-turn-clock
issue-895-silent-turn
issue-873-mcp-tool-span-error
issue-878-settle-dropped-jobs
aos/claude/aw85-se-bands
aos/claude/hs68-model-rejected
aos/claude/hs68-effect-telemetry
aos/claude/hs68-temporal-mirror
aos/claude/hs68-prompt-commands
aos/claude/hs68-model-idle-timeout
aos/claude/hs68-prompt-command-intent
aos/claude/hs68-consult-label-name
aos/claude/hs68-grant-denial-403
aos/claude/hs68-queued-jobs-dropped
aos/claude/hs68-knob-guard
aos/claude/bk79-agent-folders
aos/claude/bk79-own-instructions
aos/claude/ym96-docs-band
aos/claude/bk79-server-instructions
aos/claude/aw85-mcp-beaver-doc
aos/claude/bk79-session-workspace
aos/claude/yt58-org-relationship
aos/claude/bk79-numeric-config
aos/claude/xu59-just-boundaries
aos/claude/xu59-eval-board
aos/claude/bk79-phrase-telemetry
aos/claude/bk79-object-emoji
aos/claude/xh55-otlp-logs
aos/claude/aw85-thread-prefill
aos/claude/wy58-thread-prefill-always
aos/claude/wy58-thread-prefill
aos/claude/xh55-move-to-repo
aos/claude/wy58-thread-title-length
aos/claude/xh55-filing-trigger
aos/claude/yt58-worklog-embed
aos/claude/aw85-relative-brevity
aos/claude/xh55-reasoning-roundtrip
aos/claude/yt58-clock-rotation
aos/claude/yt58-unbreak-main
aos/claude/bk79-test-build-break
aos/claude/yt58-partial-refusal
aos/claude/aw85-turn-failure-classify
aos/claude/aw85-outbound-spill
aos/claude/xh55-budget-spent-cause
aos/claude/wy58-bundles-not-content
aos/claude/wy58-refusal-reason
aos/claude/yt58-role-snapshot-gate
aos/claude/xh55-docker-probe
aos/claude/bk79-grounding-tools
aos/claude/az59-gate-span
aos/claude/az59-pg-jobstore
eng/roster-request-headers
eng/roster-headers
eng/list-the-mcps
aos/claude/mg96-fm
eng/name-echos-seat
eng/unpin-the-card-wording
olaf/remove-irl-physical
aos/claude/mg96
eng/echo-composes-ops
quail/two-rows-not-four
fix/two-failures-two-verdicts
feat/an-emitted-message-is-not-emitted-twice
quail/partial-coverage-outcome
feat/ten-minutes-or-ten-messages
feat/a-waiting-turn-says-how-long
feat/a-job-may-emit-content
quail/round-fanout-unbounded
quail/adversarial-reply-ceiling
docs/list-the-open-pull-requests
quail/principal-id-stays-out-of-the-prompt
fix/every-label-in-a-wildcard-prefix-is-a-label
docs/the-battery-assumes-two-checks-it-does-not-run
fix/a-rest-failure-keeps-its-status
quail/retag-label-rows
quail/adjacency-guard-row
test/pin-names-the-issue-that-owns-it
test/pin-points-at-a-live-issue
quail/job-outcome-discarded
fix/repair-exhaustion-is-not-an-outage
quail/reasoning-omitempty-pin
docs/label-id-silently-drops
quail/gating-pack-markup-gap
fix/instance-name-reads-identity
docs/indistinguishable-542-resolution
fix/instance-name-not-a-live-service
quail/unwired-capability-guard
fix/repair-path-reasoning-content
quail/indistinguishable-values-recurrence
quail/identity-short-form-rows
quail/repair-path-reasoning-content
docs/verify-a-write-landed-claude
quail/host-label-shape-corpus
docs/a-deploy-owned-file-has-two-shapes-claude
fix/a-roster-path-must-name-servers-claude
fix/every-label-before-the-suffix-claude
fix/a-first-label-must-exist-claude
feat/tune-the-timeouts-from-deployment-claude
qa/protocol-limits-are-not-dials
feat/a-wildcard-is-not-a-suffix-claude
feat/retry-what-fails-fast-claude
fix/name-the-deliberate-hold-claude
test/the-access-check-exit-codes-claude
build/ship-the-access-check-claude
qa/callers-not-reachability
qa/pin-the-unwired-thread-binding
feat/an-offline-access-policy-gate-claude
test/the-notice-detaches-twice-claude
docs/say-what-the-job-thread-does-claude
fix/a-notice-does-not-thread-claude
fix/one-invocation-is-a-phrase-claude
fix/a-moment-ago-is-this-turn
fix/main-is-red-on-the-adverb-row
fix/an-adverb-does-not-break-the-auxiliary
qa/score-the-575-fix
feat/a-reply-names-its-subject
eng/a-turn-is-not-the-past
fix/since-you-asked-is-this-turn
docs/a-default-that-reads-as-an-answer
fix/a-nameless-tool-is-not-the-server
qa/pin-the-outage-state
fix/a-session-lifetime-is-not-a-latency
fix/an-undated-passive-is-still-a-claim
fix/main-is-red-on-the-corpus
fix/an-undated-passive-is-a-claim
eng/a-session-is-not-a-request
fix/a-self-claim-in-the-simple-past
qa/extend-grounding-corpus
fix/a-tool-never-offered-is-not-a-tool-declined
eng/one-doc-for-the-tracker-surface
eng/say-what-is-switched-on
fix/evaluation-is-not-the-production-service
qa/pin-the-listing-attribute
eng/split-five-docs-off-the-cap
eng/concurrent-means-goroutines
eng/split-the-tracker-surface
test/the-first-label-of-a-hostname
fix/a-cache-hit-is-not-a-round-trip
qa/pin-the-budget-ladder
fix/the-first-label-of-a-hostname
eng/the-scratchpad-assumes-one-replica
fix/a-person-is-named-in-prose
docs/jobs-are-single-process
qa/enumerate-the-mention-positions
eng/split-the-response-inventory
fix/green-main-doc-cap-and-stale-characterizations
eng/main-is-green-again
eng/split-the-mention-scope
fix/mentions-doc-over-cap
qa/unredden-the-code-span-pin
qa/pin-the-code-span-collision
eng/code-spans-are-not-prose
feat/a-thread-title-says-what-it-is-for
fix/discord-markup-is-not-prose-either
eng/mark-the-turn-once
fix/a-name-in-a-url-is-not-a-person
qa/pin-every-reaction-is-emitted
eng/mentions-skip-link-spans
fix/one-step-owns-every-service-suffix
qa/pin-the-mention-url-collision
docs/the-roster-is-member-influenced
docs/what-a-mention-can-reach
qa/pin-the-documented-glyphs
feat/naming-someone-reaches-them
qa/pin-the-sandbox-label-wiring
qa/pin-the-truncated-receipt
feat/the-harness-labels-what-it-files
qa/compare-a-case-by-marshalling
fix/one-spelling-for-the-status-vocabulary
qa/declare-pack-divergence
fix/the-reactions-match-the-approved-vocabulary
fix/a-file-path-is-just-a-file-path
qa/pin-the-mapped-tailnet-form
fix/a-truncated-page-says-so
fix/the-extraction-case-detects-a-dump
docs/the-consult-label-tracks-the-thread
feat/the-eval-can-forge-a-turn
fix/refuse-the-tailnet-range
qa/pin-the-fail-heading-count
feat/a-bounded-fetch-tool
fix/preserve-the-longform-probe-pack
qa/pin-the-lane-gate
qa/preserve-the-longform-pack
fix/the-prompt-is-not-a-secret
fix/a-reference-never-loses-to-the-footer
qa/preserve-the-probe-packs
feat/a-trusted-caller-on-the-tailnet
fix/capability-tells-the-truth-about-the-scratchpad
qa/echo-battery-negative-control
fix/one-fail-block-not-two
feat/tool-call-footer
fix/guard-the-extraction-case
feat/canonical-phrases-by-key
fix/the-progress-line-is-a-reply-too
qa/pin-the-agent-recognition-case
qa/pin-the-tool-name-markup-guards
feat/five-second-buffer
fix/a-failing-case-shows-the-reply
fix/extraction-case-stops-penalising-compliance
fix/a-security-case-that-penalises-compliance
feat/deny-actually-denies
feat/job-refusals-reach-telemetry
fix/land-the-harness-refresh-on-main
feat/a-long-reply-gets-a-thread
feat/the-thinking-line-shows-it-is-working
feat/roster-hour-ttl-and-refresh
refactor/every-number-in-one-file
feat/agent-can-refresh-its-roster
fix/size-refusal-is-not-a-parse-error
fix/budget-base-above-the-reasoning-floor
fix/one-number-for-the-progress-cadence
fix/gate-sees-a-new-file
fix/one-meaning-for-channel-id
fix/look-up-verbs-cannot-match
feat/recognise-a-trace-lookup-request
feat/discord-identifiers-on-the-turn-span
fix/budget-failure-names-the-reasoning-spend
feat/notice-carries-the-trace-id
qa/cut-run-stops-calling
docs/merge-lane-closing-reference
eng/gate-knows-the-lane
eng/feature-inventory-catchup
fix/rate-dataset-survives-a-cut-run
test/consolidate-pack-coverage
pr-lane-318
fix/flip-unknown-field-rows
test/turn-unknown-fields
fix/rate-doc-over-cap
test/language-scope-characterization
fix/pronoun-case-cannot-fire
fix/main-red-again
fix/main-is-red-doc-cap
fix/gate-negated-accuracy-claim
fix/stale-skip-allowlist-note
test/definition-must-reject
test/gate-covers-every-pack
test/bucket-table-bound
test/compose-deny-offline
fix/symlink-test-skips-itself
test/build-revision
fix/eviction-corpus-green
test/eviction-corpus
test/duration-config
test/rune-boundary
test/send-bounds
test/reserved-path-spellings
test/data-borne-injection
test/scratch-partition-collision
test/capability-docs-all
test/injection-cases
docs/http-contract-retry-after
test/capability-reach
test/rate-cases-from-192
test/score-order
test/capability-doc-matches-code
test/grounding-action-claim-corpus
test/http-turn-contract
feat/require-rate-limit-on-open-guilds
fix/pr-image-build
fix/compose-stage-inputs
feat/sirens-deep-compose-wiring
fix/deep-forgejo-mcp
refactor/evaluation-pack-yaml
coilysiren-patch-1
feat/deep-steam-mcp
feat/drop-issue-envelope
fix/dm-needs-no-mention
fix/pronoun-defaults
chore/aos-precommit-v0.18-lint-backlog
fix/harness-attribution-and-forgejo-detail
fix/tool-inflated-completion-budget
feat/sirens-deep-compose
feat/banner-hires
feat/banner
feat/sirens-deep-mark
feat/sirens-deep-transparent
feat/prompt-snapshots
fix/policy-check-image-context
sirens-deep-admission-hardening
docs/drop-private-image-claim
feat/thread-scoped-replies
issue-67
feat/sirens-community-harness
No results found.
Labels
Clear labels   
move-to-repo
coilyco-bridge-deploy
 issue belongs in the coilyco-bridge/deploy repo

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

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

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

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

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

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

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

  
autonomy
headless
 The agent can perform the work on its own

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

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

  
priority
P0
 priority tier

  
priority
P1
 priority tier

  
priority
P2
 priority tier

  
priority
P3
 priority tier

  
priority
P4
 priority tier

  
role/ai
requires work from the AI Engineer role

  
role/creator
requires work from Content Creator role

  
role/design
requires work from the design role

  
role/director
requires work from the director role

  
role/engineer
requires work from the engineer role

  
role/exec
requires work from the exec role

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

  
role/ops
requires work from the ops role

  
role/qa
requires work from the QA role

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

No due date set.

Dependencies

No dependencies set

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