coilyco-gaming/sirens-echo

Watch

capability.md tells both Deep lanes they have six tool rounds while deploy gives them twelve #953

New issue

Closed

opened 2026-08-18 15:10:25 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-18 15:10:25 +00:00

Member

Found while writing the Dowel provenance prose (PR #952). Measurement only, nothing changed.

The divergence

capability.md is the file that tells the model what it can do, and its own preamble says "Treat a capability absent from this file as one the service does not have."

It states:

At most six tool rounds. After the sixth, the answer uses what they returned.

That matches the harness default, overridable(&maxToolRounds, "SIRENS_ECHO_TOOL_ROUNDS", 6) at internal/community/config.go:378.

It does not match what two of the three lanes actually run. From coilyco-bridge/deploy at services/sirens-echo/deploy/:

sirens-echo-definition.yml - no model_budget.tool_rounds, so it takes the default 6. capability.md is correct here.
sirens-deep-definition.yml - tool_rounds: 12.
sirens-dowel-definition.yml - tool_rounds: 12.

ModelBudget.ToolRounds only falls back to maxToolRounds when unset (config.go:690), so both Deep lanes run twelve while their prompt tells them six. Both load coilyco-general, which carries the claim.

Why it matters now

sirens-dowel is the August 19 demo lane, and this understates its own budget by half on a lane whose identity understanding is a contracted deliverable of that session (sirens-echo#929).

The direction of the error is the awkward one. A model told it has six rounds when it has twelve will decline or truncate work it could have finished, which is the same member-visible shape as #935 (unconstrained requests flailing) approached from the opposite side. It also makes any statement the agent volunteers about its own limits false, on a permanent public recording.

TestCapabilityDocReachesEveryAgent checks that every lane reaches a capability doc. Nothing checks that the numbers in it match the lane's resolved config, which is why this sat unnoticed.

Not fixed here deliberately

Two reasons to leave it.

The honest fix makes the number derive from resolved config rather than being restated in prose, which is the "every number has one home" discipline and overlaps PR #947's sweep.
Editing a live bound on the demo lane inside the freeze window is a change the operator should sequence, not a side effect of a prose PR.

What would settle the fix

Whether the correct move is to render the round count into capability.md at prompt-build time from ModelBudget.ToolRounds, or to drop the specific number from the prose and state the bound qualitatively. The first keeps the promise precise and costs a generation step, the second cannot go stale.

Refs #952, #935, #929

Found while writing the Dowel provenance prose (PR #952). Measurement only, nothing changed. ## The divergence `capability.md` is the file that tells the model what it can do, and its own preamble says "Treat a capability absent from this file as one the service does not have." It states: > At most six tool rounds. After the sixth, the answer uses what they returned. That matches the harness default, `overridable(&maxToolRounds, "SIRENS_ECHO_TOOL_ROUNDS", 6)` at `internal/community/config.go:378`. It does not match what two of the three lanes actually run. From `coilyco-bridge/deploy` at `services/sirens-echo/deploy/`: * `sirens-echo-definition.yml` - no `model_budget.tool_rounds`, so it takes the default 6. **capability.md is correct here.** * `sirens-deep-definition.yml` - `tool_rounds: 12`. * `sirens-dowel-definition.yml` - `tool_rounds: 12`. `ModelBudget.ToolRounds` only falls back to `maxToolRounds` when unset (`config.go:690`), so both Deep lanes run twelve while their prompt tells them six. Both load `coilyco-general`, which carries the claim. ## Why it matters now `sirens-dowel` is the August 19 demo lane, and this understates its own budget by half on a lane whose identity understanding is a contracted deliverable of that session (sirens-echo#929). The direction of the error is the awkward one. A model told it has six rounds when it has twelve will decline or truncate work it could have finished, which is the same member-visible shape as #935 (unconstrained requests flailing) approached from the opposite side. It also makes any statement the agent volunteers about its own limits false, on a permanent public recording. `TestCapabilityDocReachesEveryAgent` checks that every lane *reaches* a capability doc. Nothing checks that the numbers in it match the lane's resolved config, which is why this sat unnoticed. ## Not fixed here deliberately Two reasons to leave it. 1. The honest fix makes the number derive from resolved config rather than being restated in prose, which is the "every number has one home" discipline and overlaps PR #947's sweep. 2. Editing a live bound on the demo lane inside the freeze window is a change the operator should sequence, not a side effect of a prose PR. ## What would settle the fix Whether the correct move is to render the round count into `capability.md` at prompt-build time from `ModelBudget.ToolRounds`, or to drop the specific number from the prose and state the bound qualitatively. The first keeps the promise precise and costs a generation step, the second cannot go stale. Refs #952, #935, #929

coilyco-ops referenced this issue

2026-08-18 15:16:58 +00:00

feat(dowel): give the Dowel lane its own provenance, placement, and demo prose #952

coilyco-ops referenced this issue

2026-08-19 02:14:36 +00:00

fix(skills): stop the inline Moxn briefing calling the surface read-only #1022

coilyco-ops referenced this issue

2026-08-19 02:15:14 +00:00

Epic: August 19 Temporal Vibe Check demo readiness, the work that is on camera #981

coilyco-ops added the

labels

2026-08-19 03:38:47 +00:00

coilyco-ops commented

2026-08-19 16:19:26 +00:00

Author

Member

Resolved by the same commit as #978. Closing.

Came here to write the fix and found it landed 21 hours ago. 1f6e246 on 2026-08-18T21:24 removed both integers from coilyco-general's capability.md, which is the file this issue names and the one both Deep lanes load.

This issue asked which of two moves was correct:

Whether the correct move is to render the round count into capability.md at prompt-build time from ModelBudget.ToolRounds, or to drop the specific number from the prose and state the bound qualitatively.

The second was taken. Current main:

Both are set per deployment, so neither number belongs in this file and neither should be quoted from memory. Say that a limit exists and that a task would need a longer chain, rather than naming a figure.

Verified against all three deployed definitions in coilyco-bridge/deploy: sirens-deep and sirens-dowel both carry tool_rounds: 12 and both load coilyco-general, so both now read prose that no longer contradicts them. sirens-echo sets no model_budget and does not load coilyco-general at all.

Your first stated reason for not fixing it in #952 held up, incidentally. The number now has one home, which is the definition.

The part of this issue that is not closed

TestCapabilityDocReachesEveryAgent checks that every lane reaches a capability doc. Nothing checks that the numbers in it match the lane's resolved config, which is why this sat unnoticed.

That observation is untouched by 1f6e246 and is the durable half. Shape 3 removed the number that could drift rather than making drift detectable, so the class is narrowed, not closed. #1011 owns it, filed after four instances of the same defect in 24 hours, and it is open and correctly scoped.

Closing this as the specific divergence it reported, with the test gap carried by #1011 rather than dropped.

## Resolved by the same commit as #978. Closing. Came here to write the fix and found it landed 21 hours ago. `1f6e246` on 2026-08-18T21:24 removed both integers from `coilyco-general`'s `capability.md`, which is the file this issue names and the one both Deep lanes load. This issue asked which of two moves was correct: > Whether the correct move is to render the round count into `capability.md` at prompt-build time from `ModelBudget.ToolRounds`, or to drop the specific number from the prose and state the bound qualitatively. **The second was taken.** Current `main`: > **Both are set per deployment, so neither number belongs in this file and neither should be quoted from memory.** Say that a limit exists and that a task would need a longer chain, rather than naming a figure. Verified against all three deployed definitions in `coilyco-bridge/deploy`: `sirens-deep` and `sirens-dowel` both carry `tool_rounds: 12` and both load `coilyco-general`, so both now read prose that no longer contradicts them. `sirens-echo` sets no `model_budget` and does not load `coilyco-general` at all. Your first stated reason for not fixing it in #952 held up, incidentally. The number now has one home, which is the definition. ## The part of this issue that is not closed > `TestCapabilityDocReachesEveryAgent` checks that every lane *reaches* a capability doc. Nothing checks that the numbers in it match the lane's resolved config, which is why this sat unnoticed. That observation is untouched by `1f6e246` and is the durable half. Shape 3 removed the number that could drift rather than making drift detectable, so the class is narrowed, not closed. #1011 owns it, filed after four instances of the same defect in 24 hours, and it is open and correctly scoped. Closing this as the specific divergence it reported, with the test gap carried by #1011 rather than dropped.

coilyco-ops closed this issue

2026-08-19 16:19:32 +00:00

coilyco-ops referenced this issue

2026-08-19 16:19:54 +00:00

Reconcile every harness doc and skill against the deployed state, and make capability drift a check rather than a discovery #1011