jayminwest/warren

The defect When warren runs in public mode (WARREN_AUTH=public), it refuses every project whose URL is not a github.com URL. This happens even when the configured forge owns the URL. A forge is the git hosting provider that warren talks to: GitHub, Azure DevOps (WARREN_FORGE=ado), or GitLab (WARREN_FORGE=gitlab, added in #1300). Public mode keeps a list of allowed repos in WARREN_PUBLIC_ALLOWLIST. The module that checks this list, src/projects/public-allowlist.ts, gets the owner and repo name from a URL with parseGitHubUrl, which accepts github.com URLs only: src/projects/public-allowlist.ts:251: assertGitUrlAllowlisted is the registration check. addProject calls it at src/projects/manage.ts:114. For a GitLab or Azure DevOps URL, parseGitHubUrl throws unrecognized GitHub URL, so POST /projects returns HTTP 400 before the allowlist is consulted. src/projects/public-allowlist.ts:229: isGitUrlAllowlisted is used by the boot check assertRegisteredProjectsAllowlisted. It catches the parse

The defect The web UI (src/ui/src/, React + Tailwind v4) uses about 1,150 arbitrary-value Tailwind classes such as text-[11px] or gap-[6px], across 55 of 81 .tsx files (counted 2026-10-06; heaviest: src/ui/src/pages/telemetry/judge-tab.tsx 67, src/ui/src/pages/instance.tsx 51, src/ui/src/pages/operations/active-workloads.tsx 49). Nothing stops new ones: biome.jsonc enables no Tailwind rule, the installed Biome is 2.4.14 (package.json:105 pins ^2.4.10), and Biome's noTailwindArbitraryValue rule has no baseline mode anyway, so it cannot be switched on while 1,150 hits exist. No ratchet script exists under scripts/. Fix direction Add scripts/check-tailwind-arbitrary.ts plus a budget file scripts/tailwind-arbitrary-budgets.json: Scan src/ui/src/**/*.tsx for tokens matching /\b[a-z-]+-\[[^\]]+\]/. Do not count the CSS-variable form text-(--color-info) (it uses parentheses, see src/ui/src/pages/runs/runs-table.tsx:27) or data-[...] variants. Compare per-file counts with the budget. Fail whe

The defect Acceptance (nightly) has never been green. It has run 39 times since its first run on 2026-07-31, and 38 of those failed. The one that did not fail was cancelled. No run has ever reported a passing suite. The last cron run (34096324912, 2026-09-07) reports 2 passed, 21 failed, 1 skipped. Only scenarios 01 and 11 pass, which are the two that never call POST /projects. Twenty of the 21 failures are the same 503: POST /projects: expected status 201, got 503: {"error":{"code":"sandbox_git_preflight","message":"sandbox git preflight failed: /usr/bin/git does not execute inside the sandbox: bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted", ...}} src/sandbox/bwrap.ts:71 always emits --unshare-all, so every sandboxed command asks bwrap for a fresh network namespace, and bwrap brings up lo inside it. That last part needs CAP_NET_ADMIN over the new namespace, and on this runner it is denied. The header comment on the workflow explains the runner choice as: "The runner al

The gap Between a turn starting and a turn ending, warren is blind. It cannot tell a model that is thinking from one that has stalled, and it cannot tell useful output from a reasoning stream that has degenerated into whitespace until the provider's length cap ends the turn. Two production incidents in one week: A pi run on OpenRouter sat idle for 45 minutes inside one turn and burned $2.38 before the heartbeat watchdog fired. A glm-5.3-flash model produced whitespace-only reasoning deltas until the length cap, on five runs in a row, each paid for in full. Why warren cannot see either: The event bridge receives every streamed delta but drops the per-delta types before persisting them. src/runs/stream/bridge.ts:206-209 continues on isPerDeltaNoiseEvent, and :454 lists message_update, tool_execution_update, and message_start as that set. The rationale at :418-424 is sound (persisting them flooded the event table), but no inspection happens before the drop. The watchdog anchors on the

The gap When a run's work is rescued to a warren/rescue/<runId> branch after the agent failed to land it, nothing tells the operator the rescue exists and nothing lets them dispatch a follow-up run from it. Today the recovery is a hand sequence: find the run id, guess the branch name, fetch it, check it out, dispatch a new run, and paste the original prompt. What exists: src/runtime/salvage.ts:41-44 defines RESCUE_BRANCH_PREFIX = "warren/rescue/" and rescueBranchFor(runId). The reap path stamps salvageRef and salvagePath onto the run row (src/runs/reap/run.ts:298-311, and the pod-posted arm at :262-268). The wire type carries both fields to the UI (src/ui/src/api/types.ts:178-180). What does not: No page under src/ui/src/pages/ and no command under src/cli/commands/ renders salvageRef or salvagePath (the only hits are null values in test fixtures). POST /runs (src/server/handlers/runs/dispatch.ts:98-130) accepts continueFromRunId, cloneFromRunId, and existingBranch, but has no field