Repository navigation
feat(bets): live bets per goal is an operator setting, not a constant (v0.460.0) - #867
Merged
Merged
Conversation
… (v0.460.0) The 4-live-bet cap exists so a loop cannot run more experiments than a human can attribute. It cuts both ways: on 2026-10-12 expresstech's goal was regressing in a page family its agent had no slot left to bet on, so four running bets were holding the loop back rather than protecting it. - `settings.betsLiveCap` (key `bets_live_cap`) is the operator override; resolution (default 4, clamp 1..8) lives with the store in `resolveLiveBetCap`, the same split as the concurrency cap. `BetStore` takes a thunk and resolves per `create`, so a change takes effect with no restart, and the refusal names the cap in force. - `GET`/`PUT /api/settings/bets` (owner/admin, audited `settings.betsCap.updated`). Past the ceiling is a 400 naming it, never a silent clamp. - The goal room's Bets header shows "N/M live" and, for an owner/admin, a picker. - `bet_list` returns `cap` + `live` so an agent knows its slots instead of learning them from a refused propose. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The 4-live-bet cap exists so a loop cannot run more experiments than a human can attribute. It cuts both ways, and today showed the other edge: expresstech's goal has been regressing for two weeks in a page family its agent had no slot left to bet on — four running bets (n8n, Fly.io, Google Forms, Indonesian) all judging in November. The agent correctly reported "slots are full, so no new bet", which means the cap was holding the loop back rather than protecting it.
What
settings.betsLiveCap(keybets_live_cap) is the operator override. Resolution — default 4, clamp 1..MAX_LIVE_BETS_CEILING(8) — lives with the store inresolveLiveBetCap, the same split as the concurrency cap: settings holds the raw override, the resolver owns the default.BetStoretakes a thunk, not a number, and resolves percreate, so a cap change takes effect with no restart. The refusal names the cap actually in force.GET/PUT /api/settings/bets— owner/admin, auditedsettings.betsCap.updated. A value past the ceiling is a 400 naming the ceiling, never a silent clamp: an operator who asks for 20 should be told the limit, not handed 8 and left believing they got 20.N/M live(amber when full) and, for an owner/admin, a picker — the cap is only interesting while looking at a full board, so it lives there rather than in Settings.bet_listreturnscap+live. The agent's actual decision is "have I got a slot", and it used to learn the answer only by being refused atbet_propose.Testing
scripts/bets-test.cjs→ 53 passed, 0 failed (10 new in case 11b): the store enforces a raised cap with no restart, the 5th and 6th propose now succeed, the refusal names 6, past-the-ceiling is a 400 that leaves the cap untouched, no cookie cannot change it, both read sides carry the cap, and clearing returns to 4. Fullnpm run test:governancegreen;npm run typecheck+ both bundles build.🤖 Generated with Claude Code