[DealAppSeo]

Durable coding lanes for T12: claim, make, independently check, integrate, refill. They run on trinity_tasks with no new table. Off by default and not scheduled. The most a lane can publish is a draft PR, and a human merges.

What this adds

• Lanes (src/orchestration/t12-lane-*.ts, scripts/t12/lanes.ts): leases with a fencing token, exact-file path locks, hash-chained decision receipts, automatic refill, duplicate-wake refusal, and the emergency halt.
• Independent check: a different lane re-runs the test in a fresh checkout. The test must also fail when the code change is reverted and when each break the task names is applied.
• Free-only routing: per-provider cooldowns in the database, at most two hosts per claim, and WAITING_FOR_CAPACITY when every route is cooling. Together is removed. A 429 still stops that wave; the next claim routes elsewhere.
• Restricted worker: the CLI refuses to start with privileged environment variables or a database role that can bypass row security.
• Task-bound belts: a lane needs a live belt for this task and this claim before it can submit. Postgres enforces this through the worker role's row policy. The worker has no privilege on the grants or the denial log, and a denied belt never reaches a model.

Needs the owner before it can run against production

migrations/2026-11-08_t12_lane_worker_role_DRAFT.sql is a draft and has not been applied. Set the role's login password separately.

Review it as a change to more than the lanes. It closes PUBLIC EXECUTE on existing SECURITY DEFINER functions in public that are still open to PUBLIC, because PUBLIC cannot exclude one role. Every other existing role is granted EXECUTE by name first, so none of them gains or loses access. A role created later would not inherit access to those functions through PUBLIC.

Limits

• A belt does not gate model calls. The worker holds its free provider keys. It refuses the OpenRouter key, whose account holds paid credit, so a restricted worker cannot use that route.
• Maker and checker share one database role, so a compromised worker could forge a verdict on work already submitted. The human merge is the gate for that.
• A denied direct write is refused, but only Postgres's own log records it. Checkout denials are recorded where the worker cannot edit them.
• A belt is a server-issued grant. It is not a signature or a ZK proof.
• The verdict is labelled same_controller_rerun. Controls are only as strong as the breaks a task names.

Evidence

• Full suite at 1d952b86: 12,958 passed, 150 failed. By test name against main at 1869bd40, the only new failures are two 5-second timeouts in tests/hal-crag-corroboration. That suite already fails on main and varied between 1, 2 and 4 failures across runs today. This branch changes no HAL file.
• Enforcement mutations: 27 of 27 belt rules caught by a named test, plus all 37 fixes made after Strix's review, each red without the fix. An earlier pass found a real defect, since fixed: a same-named role that already existed kept its privileges.
• Lane, handoff and halt suites at 8855a180: 437 passed. The full-suite figure above predates the review fixes.
• Real run: three OS processes under the restricted role took three different tasks at once on TrustShell with free models. Two commits were approved by a different lane than the maker, with negative controls red. A third was rejected on a real compiler error.
• Crash recovery and duplicate-wake refusal use real processes and SIGKILL, with a loopback model.

The Postgres test blocks need a throwaway database and report as skipped without one. The variable is named at the top of each block.

🤖 Generated with Claude Code

[strix-security]

Strix Security Review

✅ No open security findings. All previously reported findings have been resolved.

PR summary: Adds durable T12 coding lanes (claim, make, independently check, integrate, refill) on the existing `trinity_tasks` table, with leases and fencing tokens, exact-file path locks, hash-chained decision receipts, free-only model routing with per-provider cooldowns, and a draft migration that creates a restricted `t12_lane_worker` Postgres role whose row policy requires a task-bound belt before a submission can be written. Everything is off by default and unscheduled, and the most a lane can publish is a draft PR.

Review summary

I reviewed the full PR — the lane store, git adapters, runner, router, worker profile, the draft worker-role migration, and the free-provider change — and traced the worker-controlled values into every SQL, git and filesystem sink. The one prior finding, the migration failing open because its sanitising guard aborted only its own DO block, is fixed: the file is now a single BEGIN/COMMIT transaction, so a refusal stops the whole apply, and the new test runs it statement-by-statement as psql -f would. No new security issues were confirmed. The remaining observations are hardening gaps rather than vulnerabilities: check() trusts spec.verify.controls[].file without re-validating it, but the only actor who can author that spec is the lane worker role, which already has the same filesystem write on the same host and already executes arbitrary code there under T12_LANES_ALLOW_EXEC; and the free-only guarantee for the paid OpenRouter route is enforced by the CLI's credential refusal rather than by the routing table itself.

13 resolved findings

• Lane-worker migration fails open: the sanitising guard aborts only its own DO block, so a pre-existing over-privileged role keeps every grant while the rest of the file still applies — resolved in 5f9f5b3
• Migration leaves the worker's default privileges in place, so tables created later in public are readable by the lane worker — resolved in 79c61f9
• Lane-worker role keeps the REPLICATION attribute, so a pre-existing worker reads the whole database past row security and the belt — resolved in 79c61f9
• Lane publisher pushes a worker-controlled refspec, letting a compromised lane push arbitrary commits to main and bypass the human-merge gate — resolved in 8855a18
• Lane-worker profile exempts OPENROUTER_API_KEY, a paid-credit key, from the credential refusal — resolved in 8855a18
• Lane verdict path satisfies the handoff gate's independent-voice requirement with a voice the lane registry documents as not independent — resolved in 8855a18
• Lane-worker boot refusal does not treat table ownership as a row-security bypass, so an owner-role DATABASE_URL passes both checks and escapes every lane policy — resolved in 5fb9ea8
• Lane worker can lock arbitrary trinity_tasks rows and flood the denial log through t12_belt_checkout — resolved in 3d8997d
• Lane-worker role keeps PUBLIC EXECUTE on pre-existing SECURITY DEFINER functions, escaping the lane pool — resolved in 3d8997d
• Lane-worker role migration leaves pre-existing role memberships and object grants intact, so SET ROLE reaches superuser — resolved in 3d8997d
• Lane worker row policy leaves status/result/verdict columns writable, letting a compromised worker forge a RepID-scored task with no belt, no submission and no check — resolved in 3d8997d
• Publish and exec flags can be combined, letting model-written test code read the push token and bypass the human-merge gate — resolved in 3d8997d
• Lane worker boot refusal misses the engine's actual signing and secret key names — resolved in 3d8997d

Ruled out (5)

• Can the lane worker role read or write data outside the lane pool through the migration's grants, RLS policies or SECURITY DEFINER functions?
  The sanitising block revokes memberships, table/sequence/column ACLs, function grants, schema grants and default ACLs and aborts the whole transaction on ownership, the belt functions pin search_path and schema-qualify every reference, and the worker holds no grant at all on principal_grants or tri…
• Can a worker-controlled value reach a git command or filesystem path outside the task's lease?
  submission branch, commit and base are constrained to this task's branch and full object ids by both the row policy and submissionRefProblem before git sees them, and spec.paths/context pass validateSpec plus an exact-match check before any write.
• Can a lane reach the paid-credit OpenRouter route or start with a privileged credential or database role?
  The CLI refuses OPENROUTER_API_KEY and every credential-shaped name before any work begins, and with T12_FREE_WAVE unset the wave order is empty so no host is attempted regardless of the order override.
• Can a planted spec.verify.controls[].file make the checker write outside the fresh checkout?
  The mechanism is real but the only actor who can author that spec is the t12_lane_worker role, which already has the same filesystem write on the same host and already executes arbitrary code there under T12_LANES_ALLOW_EXEC, so no privilege boundary is crossed.
• Does the new T12 route table let an attacker-controlled URL reach the providerFetch passthrough?
  T12_ROUTES holds only hardcoded PROVIDER_URLS literals and the local base is validated to a loopback host, so no attacker-controlled destination reaches the passthrough from the changed code.

Review history (7)

• Review 7 · 5f9f5b3 · Nov 8 18:59 UTC · Fixed 1
• Review 6 · 79c61f9 · Nov 8 18:47 UTC · Found 1 new Medium Vulnerability · Fixed 2
• Review 5 · 8855a18 · Nov 8 18:30 UTC · Found 1 new Medium Vulnerability and 1 new Low Vulnerability · Fixed 3
• Review 4 · 5fb9ea8 · Nov 8 17:57 UTC · Found 1 new High Vulnerability and 2 new Low Vulnerabilities · Fixed 1
• Review 3 · 3d8997d · Nov 8 17:46 UTC · Found 1 new Medium Vulnerability · Fixed 6
• Review 2 · 4aed5c1 · Nov 8 17:23 UTC · Found 1 new High Vulnerability and 2 new Medium Vulnerabilities
• Review 1 · 1d952b8 · Nov 8 17:13 UTC · Found 1 High Vulnerability and 2 Medium Vulnerabilities and 1 Low Vulnerability

_{Review 7 on this PR · 5f9f5b3 · requested Nov 8 18:50 UTC on a new commit}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[strix-security]

Strix flagged 4 new security findings below. See the pinned summary comment for the full PR status.

[strix-security]

Strix flagged 3 new security findings below. See the pinned summary comment for the full PR status.

[strix-security]

Strix flagged a new security finding below. See the pinned summary comment for the full PR status.

[strix-security]

Strix flagged 3 new security findings below. See the pinned summary comment for the full PR status.

[strix-security]

Strix flagged 2 new security findings below. See the pinned summary comment for the full PR status.

[strix-security]

Strix flagged a new security finding below. See the pinned summary comment for the full PR status.

[strix-security]

I reviewed the full PR — the lane store, git adapters, runner, router, worker profile, the draft worker-role migration, and the free-provider change — and traced the worker-controlled values into every SQL, git and filesystem sink. The one prior finding, the migration failing open because its sanitising guard aborted only its own DO block, is fixed: the file is now a single BEGIN/COMMIT transaction, so a refusal stops the whole apply, and the new test runs it statement-by-statement as psql -f would. No new security issues were confirmed. The remaining observations are hardening gaps rather than vulnerabilities: check() trusts spec.verify.controls[].file without re-validating it, but the only actor who can author that spec is the lane worker role, which already has the same filesystem write on the same host and already executes arbitrary code there under T12_LANES_ALLOW_EXEC; and the free-only guarantee for the paid OpenRouter route is enforced by the CLI's credential refusal rather than by the routing table itself.

---

Reviewed by Strix
_{Configure security review settings}