CURRENT PRIORITY — P0: task intake, acceptance, and Bee liveness

This is the immediate blocker and takes precedence over throughput tuning and broad T27O migration work until diagnosed. The reported symptom is that queued tasks are not being accepted/claimed and Bees remain idle. Treat this as a production-liveness incident to investigate, not as proof of a specific root cause.

First response — establish where the task stops

1. Trace one real task end-to-end: issue/card created → accepted/validated → queued → dispatched/leased → worker/bee starts → branch/PR → CI/verdict.
2. Identify the exact transition and reason for each non-progressing task: validation/shape refusal, missing required fields, dependency/priority gate, duplicate/idempotency key, repo/file lock, unavailable provider, concurrency cap, stale lease, CI/runner saturation, or supervisor error.
3. Count queued, refused, leased, running, expired/stale, review-blocked, and terminal tasks; distinguish worker capacity from runner/CI capacity. Do not infer today's state from historical metrics.
4. Inspect the deployed supervisor in gHashTag/BrowserOS at trios/agent-server/apps/server/src/api/services/queen-tick.ts, queen-dispatch.ts, queen-lease.ts, and queen-ci-verdict.ts; compare deployed revision with source and the canonical specs/queen/dispatch.t27.
5. Reproduce with one minimal valid task, add a regression test for the exact failing transition, fix the narrow cause, and verify that the task reaches a terminal verdict and releases its worker slot.
6. Report evidence: task IDs (non-sensitive), state transitions, refusal/error reason, timestamps, current counts, root cause, fix/rollback, and a before/after acceptance test.

Definition of done for the P0 gate

• A newly submitted valid task is accepted or rejected with a clear machine-readable reason.
• An accepted task is claimed by an available Bee, or the system explains which dependency/capacity gate blocks it.
• No task remains indefinitely in a nonterminal state without a deadline and recovery path.
• Lease/worker slots are released exactly once on success, failure, timeout, cancellation, or reaping.
• A regression test proves the reported failure cannot silently recur.
• Only after this gate is green should idle capacity be used to fan out the T27O MVP work.

Research note — why this order is justified

Repository-level translation research finds that file-by-file translation breaks on cross-file dependencies; dependency-aware batches plus compile/test feedback perform better (DepWareTrans, arXiv:2608.14128, Aug 2026). Empirical work on LLM code translation also reports substantial correctness failures and the need for tests/context (Pan et al., ICSE 2024). Therefore, first repair task intake and reliable dispatch, then split T27O work into dependency-aware, independently testable slices. Do not launch more agents into a queue that cannot reliably accept, lease, or finish their work.

Related: T27O MVP tracking in gHashTag/t27#9847 (currently closed by the issue-shape gate; do not treat it as an active epic until its closure reason is resolved); compiler/toolchain audit in #1644; T27O audit and compiler work in gHashTag/t27#8998 and #1644. Keep one queue and one supervisor; do not introduce a parallel scheduler.

Goal

Make Queen and the bee network measurably responsive and efficient by fixing the existing runtime in dependency order: observe the real bottlenecks, eliminate stuck dispatches and wasted work, improve safe reuse/caching, then port only proven hot paths to T27/T27B/Zig. Grow the existing system node by node; do not replace working components or create a parallel architecture without evidence.

This epic complements (does not duplicate) #1644, which audits T27C/T27B/T27O. This issue is specifically about the live Queen/bee orchestration and runtime performance.

Known evidence (must be re-verified against current production)

• apps/website/public/t27/files/specs/queen/dispatch.t27 documents the real task lifecycle and names the deployed supervisor implementation in gHashTag/BrowserOS at trios/agent-server/apps/server/src/api/services/queen-tick.ts, plus queen-dispatch.ts, queen-lease.ts, queen-ci-verdict.ts, and PostgreSQL queries/migrations. The same spec explicitly distinguishes this supervisor from Trinity's local Zig policy loop.
• apps/website/public/t27/files/specs/queen/review_valve.t27 records a historical snapshot dated 2026-10-05: 219 cards in review, 144 escalated, 193 stuck cards, 125 empty branches, 25/70 workers active, and 98 CI runs queued. These are historical observations, not current metrics; re-measure before using them as a baseline.
• apps/website/public/t27/files/specs/verified/reuse.t27 already specifies safe reuse/sealing rules based on spec bytes, use dependency closure, toolchain, configuration, and prior PASS verdict. Extend and integrate existing machinery rather than inventing a second cache.
• docs/QUEEN_CENTRAL_SPEC_CATALOG_2026-09-07.md documents a previously fixed stale-result bug for changed source bytes under the same path. Regression coverage exists for same-source reuse and changed-source analysis in the shipped compiler WASM; this does not establish that every Queen/bee cache is effective.
• Main live dispatch implementation is TypeScript under Bun; T27 has specifications and generated/ported decision logic, but this does not mean the whole supervisor or every bee is already running as T27.

Principles

1. Measure before optimizing. No claims of speedup without repeatable baseline and end-to-end measurements.
2. T27 remains the canonical source for decision rules where a T27 spec already exists. Keep adapters consistent with it; avoid duplicate state machines.
3. Fix correctness and liveness before raw throughput: no indefinitely stuck dispatch, stale lease, lost worker slot, or review dead-end.
4. Cache only when all correctness-relevant inputs match. Missing hashes/versions/configuration fail closed and trigger recomputation.
5. Reuse verified artifacts and unchanged context; deduplicate in-flight identical work (single-flight) where safe.
6. Do not optimize away necessary independent verification. Reuse evidence only while its source, dependencies, toolchain, and verdict remain valid.
7. Port only measured hot paths. Preserve current behavior using differential tests against the existing implementation and golden fixtures.
8. No mainnet/token-economic changes are part of this epic.

Work packages (dependency order)

P0 — Establish production truth and baseline

• Pin deployed supervisor revision and confirm it matches source/branch.
• Capture current dispatch counts by state/age, worker slots (busy/idle/stale), queue wait, task runtime, review/CI wait, retry count, empty-diff rate, and issue/file-conflict reasons.
• Add trace/correlation IDs from task -> bee run -> branch/PR -> CI -> verdict.
• Record per-stage P50/P95/P99, model tokens/cost, cache hit/miss and duplicate-work rate.
• Deliver a reproducible baseline report; do not use the 2026-10-05 snapshot as current truth.

P1 — Liveness and recovery

• Audit state transitions and all leases/reapers/timeouts in queen-tick.ts, queen-dispatch.ts, queen-runner-work.ts, queen-lease.ts, queen-ci-verdict.ts, and associated DB queries/migrations.
• Prove with tests that every nonterminal state has a deadline or explicit external dependency and a recovery path.
• Fix repeat-judging of the same immutable head; key review decisions to head SHA + criteria hash + reviewer/tool version.
• Ensure every terminal/reaped/released dispatch releases worker slots and file boundaries exactly once.
• Add tests for crash/restart, duplicate events, lease expiry, stale worker heartbeat, CI queue timeout, empty diff, exhausted retries, changed criteria, and idempotent cleanup.

P2 — Safe reuse and cache efficiency

• Inventory each cache independently: compiler/spec artifacts, repo/API reads, model prompt/context, bee outputs, test/CI results.
• For each cache document key, invalidation, TTL, ownership, memory/DB cost, hit rate, and correctness test.
• Reuse only on exact source + dependency closure + toolchain + config + PASS seal, in accordance with verified/reuse.t27.
• Add single-flight/deduplication for identical in-flight work and bounded concurrency for expensive remote calls.
• Test source changes at same path, dependency changes, toolchain changes, failed verdicts, cancellation and concurrent requests.

P3 — Scheduling and concurrency

• Explain idle worker slots and file-conflict/blocking states from actual telemetry.
• Separate worker capacity from runner/CI capacity and provider availability.
• Add fair scheduling/backpressure, bounded queues, per-repository/file locks with expiry, and explicit cancellation.
• Track useful accepted work per worker-hour, not merely launched bee count.

P4 — Hot-path optimization and T27/T27B adoption

• Profile CPU and allocation hotspots after P0-P3.
• Benchmark TypeScript/Bun against the existing T27-generated/native implementation for pure decision functions only.
• Port a function only if it is deterministic, covered by oracle/differential tests, and shown to matter end-to-end.
• Keep I/O orchestration in the existing service unless profiling proves it is the bottleneck; don't move network/database waits into a language rewrite.
• Report before/after throughput, P95 end-to-end latency, cost per accepted change, and regression results.

Acceptance criteria

• Current deployment revision and runtime ownership are verified.
• Every task state has documented transitions, timeout/reaper behavior, and tested recovery.
• No reproducible stale-cache result when source/dependencies/toolchain/config changes.
• Duplicate in-flight work and repeated review of an unchanged head are measurably reduced.
• Cache hit rate, duplicate-work rate, worker utilization, stuck-task age, cost per accepted change, and P50/P95/P99 latency are reported before and after.
• All existing relevant tests pass; new failure-injection and differential tests pass.
• Each code change is a small, independently reviewable PR; no broad rewrite without evidence.
• Final report distinguishes measured results from hypotheses and names remaining bottlenecks.

Out of scope

• Rewriting all of Queen or all bees in one pass.
• Replacing T27C/T27B/T27O or creating a parallel cache/reference architecture.
• Tokenomics, rewards, UBI, or mainnet changes.
• Claiming speedups from language choice without end-to-end measurements.