Conversation
…s answer to
Carry-forward of origin/queen-1302 onto origin/feat/queen-supervisor. The bee
branch was cut before the base gained the tree-load-failure guard, the ASCII
evidence sanitiser and the per-credential lane counting, so a rebase or a
cherry-pick would have reverted all three. Only the substance the base
genuinely lacks is applied here, by hand, hunk by hunk.
Carried:
- the `billing` block on GET /queen/public-research: `billingMode` derived
from the same `configuredBillingMode` resolver /queen/status publishes, so
the two public pages cannot tell different stories about one swarm, plus
`quotaAuthority` naming which gate actually refuses a new Bee
(provider_quota under a Coding Plan, estimated_usd_gate when metered).
Without it an idle subscription swarm reads as broken capacity.
- the injectable `billingMode` dep and the `BillingMode` / `QuotaAuthority`
types, the latter derived from the resolver rather than re-declared.
- the five appended tests: closed two-key shape, env resolution, the
conservative metered default for missing/empty/unknown values, agreement
with the /queen/status contract across every raw configuration, and the
proof that neither billing word can be read as an activity claim.
Dropped as superseded - already in the base by another route:
- `import { loadTree as loadCanonicalTree, type Tree }` and
`loadTree?: () => Promise<Tree | null>`. The base now imports
`isTreeLoadFailure` and `TreeLoadFailure` and answers 503 for a
wrong-shape file; the bee's older import would have reopened the
unhandled 500.
- the `'/Users/.../'` / `'/home/.../'` replacements in sanitizeEvidence. The
base already replaced those with ASCII `'/Users/.../'` per L3 PURITY.
- the set-based `workerProjection`. The base counts rows rather than unique
key_index values, so two logical lanes on one credential show as two
active Bees; the bee's `busy` set would have shown one.
- the two base tests that encode those behaviours - the corrected slot
ordering and 'counts two logical lanes on one credential as two active
Bees' - kept as the base has them.
The original branch queen-1302 is untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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-1302onto 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.