[PetrefiedThunder]

Summary

Three of the findings #302 listed under "Not addressed here". Each was re-verified against current main rather than taken from the description — one of them (reserve_budget expiry) was still open only because #298 fixed the other reservation path — and each ships a regression test confirmed to fail against the unfixed source.

1. reserve_budget spent against expired permits — engine-independent

#298 added expires_at > now to authorize_and_reserve's guarded update. reserve_budget is a second reservation path and never got it:

guarded sa_update(PermitModel)	expiry term (before)
authorize_and_reserve	✅ (added by #298)
reserve_budget	❌
release_budget / release_dispatch_budget_once	n/a — releases correctly don't gate on expiry

An expired permit keeps status="active" in storage (expiry is a dynamic check, not a stored state), so the WHERE clause matched and budget moved. This was wrong on PostgreSQL too — no row-lock behaviour required.

Also replaces the catch-all denial: a miss now reports permit_expired / permit_not_active instead of calling every failure permit_budget_exceeded.

Test: an active permit whose expires_at is moved into the past is refused with permit_expired, and spent_credits stays 0. Unfixed: DID NOT RAISE — the expired permit is charged.

2. release_dispatch_budget_once was not once-only

It read budget_released_at under with_for_update=True, then decremented the permit. SQLAlchemy silently drops FOR UPDATE on engines that don't support it, so two concurrent callers both saw NULL and both released — the permit is credited back twice for one dispatch.

The decrement was already atomic (clamped CASE); the claim was not. It's now a guarded UPDATE (NULL → now), and only the caller with rowcount == 1 proceeds.

Test: two concurrent releases must yield exactly one True and exactly one decrement. Unfixed, the assertion fails with 2 = len([True, True]) — the double release reproduces.

3. SQLite was a permitted production durable-state backend — the enabler

STATE_BACKEND=memory was refused in production-like environments; sqlite was not, and auto resolution would select it from a SQLite DATABASE_URL — the ordinary local-development setting. That is the deployment-level enabler for every remaining FOR UPDATE-is-a-no-op finding in the money path. Both the explicit and the auto path now fail closed with an explanatory error.

Tests: production-like + STATE_BACKEND=sqlite with SQLITE_URL set, and auto-resolution from a sqlite DATABASE_URL, both raise DurableStateConfigError.

One existing test changed. test_sqlite_without_url_refuses_production_like asserted the refusal reason was the missing SQLITE_URL, which implied a configured URL would have been accepted. Its assertion now matches the stricter reason; the behaviour it guards (production refuses this config) is unchanged, and the configured case has its own test.

Incidental

The docs sweep in test_onboarding_contract.py walked .claude/worktrees/ — a gitignored path holding full checkouts — so a copy of a file the exclude list already forgave failed the sweep. This fails for anyone using a git worktree there; .claude/ is now excluded. (This is what made the suite red locally; main's own CI was unaffected.)

Type of Change

• fix
• feat
• docs

Validation

• pytest -q -m "not production_trust" — 1711 passed, 32 skipped
• production_trust — 6 passed
• all three fixes confirmed to fail against the unfixed source by reverting the fix, not the test
• ruff check . clean; mypy app/ clean across 172 source files
• demo_trust_plane.py --assert and red_team_trust_plane.py --assert clean (audit chain valid, tampered audit correctly rejected)

Risk

• medium

Fix 3 is a deployment-contract change: a production-like service configured with STATE_BACKEND=sqlite, or with a SQLite DATABASE_URL under auto, now refuses to boot instead of running on an unsafe backend. That is the intended fail-closed behaviour and matches docs/deploy-railway.md, which already requires STATE_BACKEND=postgres. The live deployment is unaffected — it runs STATE_BACKEND=postgres, verified against production at the a928fd6f release.

Fixes 1 and 2 only ever deny more or release once instead of twice; neither can debit anything extra.

Not addressed here

Still open from #302's list, and not fixed by this PR — fix 3 removes their production reachability, but the code-level races remain wherever FOR UPDATE is a no-op:

• wallet balance debited by read-modify-write (no sa_update touches WalletModel anywhere)
• reclaim_child_wallet able to credit a parent twice
• refund reconciliation clobbering concurrent reservations
• velocity counters under-counting, which silently disables the spend cap and anomaly freeze
• engine-independent: the local governed crash window (operation_kind='local', debit committed, ledger_entry_id IS NULL) matching neither reconciler branch

Converting those to guarded updates is separate work, worth its own PR.

---

Generated by Claude Code

---

Note

Medium Risk
Production-like services configured with SQLite durable state will fail to boot instead of running on an unsafe backend; permit changes only tighten denials and prevent double budget release.

Overview
Hardens permit budget paths and production durable-state selection so expired permits cannot be charged, dispatch budget is credited back exactly once under concurrency, and production-like deploys cannot boot on SQLite.

Permits: reserve_budget now matches authorize_and_reserve by requiring expires_at > now in its guarded UPDATE, and failed reserves distinguish permit_expired / permit_not_active instead of always permit_budget_exceeded. release_dispatch_budget_once claims budget_released_at with a guarded UPDATE (NULL → now) before decrementing spent_credits, so only one concurrent caller releases budget when FOR UPDATE is ineffective.

Durable state: Explicit STATE_BACKEND=sqlite and auto-resolution from a SQLite DATABASE_URL raise DurableStateConfigError in production-like environments; auto no longer falls back to SQLite there.

Tests / incidental: Regression tests for concurrent release, expired reserve_budget, and production SQLite refusal; docs sweep excludes .claude/ worktrees.

^{Reviewed by Cursor Bugbot for commit d37af5f. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agent-middleware-web	Ready	Preview	Aug 18, 2026 1:55am

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_b900326e-f9d5-4055-84ba-01365f4e1c72)

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: f3c363e7-67fc-4e85-9117-e2a2260922f0

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.