Conversation
…rvisor Carry-forward of origin/queen-1303 (browseros-ai#1303) onto the current base. The original branch is untouched; this is a fresh branch off origin/feat/queen-supervisor with only the substance the base lacks. Carried, verified absent from the base: - `workers` on GET /queen/status: capacity, active, idle, utilization. The base publishes a `workers` block on /queen/public-research only; /queen/status had no worker projection at all, so `running: 0` there still had no denominator. - `workerProjection()` in queen-public-status.ts, with the total clamp (0 <= active <= capacity, integer utilization 0..100). - `workerCapacity` dependency, defaulting to `configuredWorkerCapacity` from api/services/queen-dispatch - the same one authority /queen/public-research already reads, never a second parser of the provider environment. - `started_running` in the aggregate count query (`started = true AND finished_at IS NULL`), so a dispatch that never got a turn stays in `running` but spends no paid slot. This matches the reaper's existing predicate in queen-dispatch.ts. - The header paragraph explaining the block, and five tests: the 4-slot half-busy story, zero capacity with planted credential-shaped rows, the started=false regression, the malformed-count clamp, and the same-authority check against configuredWorkerCapacity(). Dropped as superseded by the base: - `swarmState: 'waiting_for_review'` in "returns only the public runtime summary". The base reclassified that fixture to 'healthy_idle' - a tick that refused with `nothing to choose` measured the backlog, so an owed review may not name the quiet. Re-applying queen-1303's expectation would have reverted that fix. - queen-1303's `lastTick` shape, which predates the base's `skipSummary` issue lists and `skipIssueListCap`. The base shape is kept as-is; only `workers` was added to the two exhaustive payload assertions. Verified: bun test apps/server/tests/api/queen-public-status.test.ts 21 pass, 0 fail, 116 expect() calls.
Dirty, and the reason is mineThis carry was cut from the base as it stood, verified against it by three independent refuters, and merged cleanly at the moment it was opened. Then #330 and #331 landed on the same file — The lesson, stated plainly: carries that touch the same file must be landed as one change or re-cut after each landing. I landed four sequentially and the last two invalidated themselves against the first two. That is the same shape as the branches these carries exist to rescue — work made stale by a base that moved underneath it — committed while fixing it. What is NOT wrong here: the content. The refuters confirmed each hunk against the base as it stood, and confirmed that superseded halves were dropped rather than re-applied. Nothing needs re-deciding, only re-cutting. Leaving this open rather than force-pushing over it: the standing rule in this work is that published history is not rewritten, and a stale carry is honest information about what happened. |
This branch has not been deployed
1 participant
Carried forward from
origin/queen-1303onto a fresh branch off the current base. No force-push, no branch deletion — the original branch is the evidence that the work happened and is untouched.Only what the base genuinely lacks was carried; hunks whose substance the base already has by another route were dropped, because re-applying superseded work is how a fix gets reverted by a merge.
Three independent refuters were pointed at this carry — did it re-apply something the base already had, did it drop something the base lacks, does the quoted verification actually prove anything. At least two failed to break it. Merges cleanly against the current base, checked with
git merge-treebefore this PR was opened.