Repository navigation
chore: bump version - #1308
Merged
Merged
chore: bump version#1308
Conversation
Contributor
✅ Tests passed — 1316/1320
|
Contributor
Dmitrii Vasilev (gHashTag)
added a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 4, 2026
… onto the supervisor base (#331) Carry-forward of origin/queen-1308 onto origin/feat/queen-supervisor. The bee branch was cut before the tree-loader hardening landed, so the two edits met inside queen-public-research.ts. Applied by hand, hunk by hunk, so the base's newer work is not reverted by a merge. CARRIED, because the base has none of it: - queen-dispatch.ts: `WorkerCapacityBreakdown` and `workerCapacityBreakdown()`, the one authority that answers WHICH capacity a total is made of - connected credentials, lanes per credential, effective capacity - three integers and nothing that can be inverted into a secret. `configuredWorkerCapacity()` now delegates to it, so the number dispatch allocates against and the number the public endpoint explains cannot diverge. - queen-dispatch.ts: `keysFor` trims before it judges. ' key' and 'key' in two boxes were counted as two credentials on one rate limit; a whitespace-only value was counted as configured. The trimmed value is also the stored one, so the count and the selection read the same list. - queen-public-research.ts: the route reads the breakdown instead of the bare count and spreads the anonymous factors into `workers`. - Both test files, including the closure assertions that no planted value, no provider variable name and no key_index-shaped field leaves the endpoint. ADAPTED to the base, which the bee branch could not have seen: - tests/api/queen-tree-load.test.ts pins the route with `workerCapacity: () => 0`. That file does not exist on queen-1308. Renaming the dep without it would have left that route reading the REAL environment. Repointed at the breakdown. - The carried factorisation table configures OPENAI_API_KEY_2, a suffixed name absent from both cleanup lists. Bun runs the api tests in one process, so it survived into queen-public-research.test.ts and made "nothing is connected" read one connected credential. Added to both KEYS lists. DROPPED as superseded: nothing. Every hunk's substance was absent from the base. Not reverted: the branch predates `isTreeLoadFailure` / `TreeLoadFailure`, which the base added to turn a wrong-shape tech-tree.json into a 503 instead of a 500 on a wildcard-CORS public endpoint. That handling is untouched here. Closes browseros-ai#1308 Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Dmitrii Vasilev (gHashTag)
added a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 4, 2026
…, and close-done kept its own copy of the rule (#360) `tri why` warned ahead: all nine remaining accepted branches conflict, so nothing can land, close-done will close nothing, and the pipeline stops as soon as those boundaries are all that is left. Four of the nine were finished work. THE ROUTE NO COMPARISON OF BYTES CAN TAKE. `isLanded` had four routes - ancestry, an identical merged tree, a patch-id match, and a hand-applied change. Every one of them compares CONTENT. They are all blind to the thing this loop does constantly: when a bee's branch goes stale, I re-cut its change against the current base and squash-merge THAT. The carry is a new commit with a new tree and a new patch-id, so nothing content-shaped connects it back, and the bee's original branch becomes permanent debt - re-offered every round, conflicting every round, holding its boundary fenced for ever. So read the message. L1 of this repository is "no code merged without `Closes #N`", which makes the message a load-bearing record and not a courtesy: browseros-ai#1310 landed as PR #330 browseros-ai#1308 landed as PR #331 browseros-ai#1362 `Closes browseros-ai#1362` in a base commit browseros-ai#1421 carried by a commit that says "Carries the browseros-ai#1421 work it belongs with" Nine conflicting branches became six. The matching is done in JavaScript rather than in git's regex, because two rounds ago a BRE read as a JavaScript regex convicted a bee - the dialect belongs somewhere it is known. AND THE TIGHTENING BROKE THE CASE IT WAS WRITTEN FOR. I required `(#N)` to end the line, to reject "unlike (browseros-ai#1421), this does X". One minute later browseros-ai#1310 stopped being recognised: a squash subject here reads `feat(queen): explain idle paid slots (browseros-ai#1310) (#330)` - the issue first, then the pull request. A trailing CHAIN of references is a subject; a parenthesis in the middle of a sentence is not. CLOSE-DONE KEPT ITS OWN COPY OF THE RULE. It had the tree test and nothing else, for weeks, while `land.mjs` grew four more routes it never learned. A rule transcribed twice is two rules that agree until somebody edits one - which is L2 of this repository, and it had happened here in the file that decides whether an issue may be closed. It asks `land.mjs` now. What remains is real debt and is reported as such: browseros-ai#1387, browseros-ai#1302 and browseros-ai#1303 carry 880 insertions of finished work outside the base, all three with their issues already CLOSED - the inverse of the false statement close-done exists to prevent. A conflict is still reported for a person and never resolved by guessing. selftest 144 pass 0 fail. Co-authored-by: Dmitrii Vasilev <trackgmedernj@hotmail.com>
Dmitrii Vasilev (gHashTag)
added a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 4, 2026
… rebase" was advice toward deleting finished code (#361) `land` reported nine conflicts and one remedy: rebase, or close as superseded. Taking that advice on browseros-ai#1302 would have destroyed landed work. browseros-ai#1302 is "expose Queen billing mode and quota authority in public research status", 205 insertions, accepted, its issue already closed. Replaying it onto today's base would have: - deleted `WorkerCapacityBreakdown`, which is browseros-ai#1308's work, carried and merged as PR #331 after this branch was cut - deleted the tree-load-failure handling the base gained since - REINTRODUCED a non-ASCII ellipsis into a path redaction the base already performs in ASCII - breaking L3 in the same stroke That branch is not waiting for a rebase. It is superseded in part, and what survives is a small delta belonging on today's base as new work. A conflict says two sides touched the same lines; it says nothing about which side is behind, and the advice depends entirely on that. So the report measures it: how far has the base travelled on the conflicting files since the fork point? CONFL queen-1302 2 conflicting file(s): ...queen-public-research.ts, ...test.ts | the base moved on these since the fork: N commit(s), M insertions - a rebase would replay OLD code over new; re-file what survives against today's base It is a measurement, not a verdict. The person still decides, with the number that decides it. AND THE COUNT WAS INFLATED. `git merge-tree --name-only` interleaves prose with paths - "Auto-merging X" and "CONFLICT (add/add): Merge conflict in X" are commentary about the file named on the line above. Counting them reported "6 conflicting path(s)" for two files. An inflated number is how a report stops being read, and this one had been doubling every conflict it printed. The reason line is no longer truncated to 96 characters either, which had been cutting off exactly the half that says what to do. selftest 145 pass 0 fail. Co-authored-by: Dmitrii Vasilev <trackgmedernj@hotmail.com>
Dmitrii Vasilev (gHashTag)
added a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 5, 2026
…fication rather than a patch (#366) Five branches had jammed the landing pipeline for four rounds. `land` could say they conflict and how far the base had travelled; the next question was the one a person has to answer, and I kept deferring it: rebase, or re-do the work? Rebasing browseros-ai#1302 would have deleted browseros-ai#1308's landed code and reintroduced a non-ASCII ellipsis into a redaction the base already performs in ASCII, breaking L3 in the same stroke. AND A CLEAN REBASE WOULD NOT HAVE SHOWN IT. A semantic conflict carries no markers: git resolves the text correctly while the combined code is logically broken - upstream renames a function your commit still calls, the changes sit on different lines, nothing conflicts, everything is wrong. So "it applied cleanly" is not evidence, and `salvage.mjs` does not offer it. It applies nothing. It never rebases. The selftest fails if the words `git rebase`, `cherry-pick` or `git apply` ever appear in it. WHAT IT PRODUCES is the standard answer for a branch whose module was restructured underneath it: use the old diff as a statement of what was WANTED, not as patches. Concretely - the names the branch introduces that the repository still does not have: queen-1302 8 of 200 candidates absent: quotaAuthority, provider_quota, estimated_usd_gate, statusMode, readTelemetry, QuotaAuthority, billingProjection, ResearchDeps queen-1303 4 of 243: started_running, plantedSecret, startedUnfinished, startedRunning queen-1387 19 of 273: specQualityHeadingParity, extractorHeadings, checkNames, maskNonAscii, RING_COPY, scanMatchingClose, ... Three branches of 881 added lines reduce to 31 missing names, because most of what they carried had already landed by another route. IT IS NOT A PARSE, deliberately. Six false accusations in this project came from a checker that tried to recognise a declaration by its shape across Swift, TypeScript and markdown, and the list of ways to spell "define" has no end. Every identifier-shaped token is a candidate and the BASE TREE decides which are new - absence is checkable without knowing any language. A hex blob is dropped, because queen-1303's diff offered `fedcba9876` from a fake sha in a fixture, and proposing that as a capability the repository lacks is the `node_modules` accusation in a new costume. The cap on candidates is printed alongside the total, since a silent truncation would read as "this is everything". `--brief` writes the measurement as an issue a bee can pass, and every criterion is FAIL-TO-PASS BY CONSTRUCTION: the name was measured absent from the base a moment earlier, so it cannot be satisfied by an empty patch and `verdict-audit` will check it against both the fork point and the branch without being asked. Filed as Trinity-S-AI-DNA/trios#1537, browseros-ai#1538 and browseros-ai#1539, all three passing the delegation gate with their boundaries parsed. They carry no `queen-authored` label on purpose: that label is `author.mjs`'s own WIP accounting, and salvage work is not the backlog it is metering. selftest 155 pass 0 fail. `tri salvage <N> [--brief]`. Co-authored-by: Dmitrii Vasilev <trackgmedernj@hotmail.com>
Dmitrii Vasilev (gHashTag)
added a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 5, 2026
…and stop advising a rebase that would destroy work (#369) For four rounds `why` warned that all remaining accepted branches conflict, that nothing can land and that the swarm will starve behind them. Mechanically true and useless: those branches will never land. Their base has moved past them, replaying one would delete work that landed since, and there was nothing in the loop that could say so. `salvage` has now measured what each still owes and filed it as a brief against today's base - Trinity-S-AI-DNA/trios#1537, browseros-ai#1538, browseros-ai#1539, browseros-ai#1540. So the branches are recorded as REPLACED, with the issue that replaces each: queen-1302 -> browseros-ai#1537 billing mode and quota authority queen-1303 -> browseros-ai#1538 the started_running state queen-1387 -> browseros-ai#1539 the heading-parity checker queen-1422 -> browseros-ai#1540 the noise filter that deleted its answer Five conflicting branches become one, and the one that remains - queen-1484 - is not debt either: it is an OPEN issue whose own criterion fails against the base today, which the swarm can pick up as ordinary work. RECORDED, NEVER INFERRED. Nothing here guesses that a branch is superseded. Someone says so and says by what, in a file, with a timestamp. The branches themselves are untouched: no deletion, no force, nothing irreversible. The selftest fails if `--force`, `branch -D` or `push --delete` ever appear in this file. AND THE ADVICE CHANGED, because it was wrong. For four rounds this tool told a reader that a conflicting branch "needs a rebase, or an honest closure as superseded". Rebasing browseros-ai#1302 would have deleted browseros-ai#1308's landed code and reintroduced a non-ASCII ellipsis into a redaction the base already performs in ASCII. It now says what was learned: A rebase is usually the WRONG remedy once the base has moved: replaying an old branch can delete work that landed since, and applying cleanly proves nothing, because a semantic conflict carries no markers. tri salvage <N> measures what the branch would still add, asks the issue its own criterion against the base, and writes the remainder as a brief A tool that recommends the destructive option in one line, every round, for four rounds, is worse than one that says nothing. selftest 160 pass 0 fail. Co-authored-by: Dmitrii Vasilev <trackgmedernj@hotmail.com>
Dmitrii Vasilev (gHashTag)
added a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 5, 2026
…) (#372) The public research page shows the same paid worker slots /queen/status explains, but never said which quota gate they answer to, so an idle subscription swarm read as broken capacity. Add a billing block built from the exact resolver the status page publishes: billingMode plus quotaAuthority, one of two closed words - provider_quota under a Coding Plan, estimated_usd_gate under metered API work. An explanation, not a decision: queend still owns whether a Bee starts, and neither word can be read as an activity claim. Written against today's base: the capacity contract moved to the worker breakdown authority (browseros-ai#1308) and the tree loader learned failure states since the specification branch, so the capability is re-expressed for the deps that exist now, with TRIOS_SWARM_BILLING_MODE joining the cleared environment keys the default-resolver cases require. Co-authored-by: Trinity Bee <bee@trinity.local>
Dmitrii Vasilev (gHashTag)
pushed a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 17, 2026
…URL was the whole pool Measured on 2026-09-17 in production: ten working Z.ai keys carried sixteen bees while three working NVIDIA keys sat unused beside them. A key handed to a bee is only as good as the URL the bee sends it to, and the deployment has exactly one: TRIOS_QUEEN_WORKER_BASE_URL, one model, every generic key sent there. Putting an NVIDIA key into TRIOS_QUEEN_WORKER_API_KEY_n would not widen the swarm, it would hand a bee a 401 that arrives blamed on the work. So there are now numbered endpoint pools. The FIRST pool is the variables that already exist, unchanged in name and meaning. Further pools start at 2: TRIOS_QUEEN_WORKER_POOL_<n>_BASE_URL the endpoint (required) TRIOS_QUEEN_WORKER_POOL_<n>_MODEL the model that endpoint serves (required) TRIOS_QUEEN_WORKER_POOL_<n>_PROVIDER openai-compatible (default) or zai TRIOS_QUEEN_WORKER_POOL_<n>_CONTEXT that model's context window TRIOS_QUEEN_WORKER_POOL_<n>_API_KEY, _API_KEY_2 ... _API_KEY_16 What travels to /chat - provider, base URL, model, context window - comes from the same pool as the key. One allocator runs over the concatenated list, so a wave of bees takes one credential of every pool before any key carries a second lane: the rule availableKeyIndex already applied inside one pool. queen_dispatch.key_index is one integer, read back every tick to learn which credentials are busy. First-pool keys keep the index they have always had, so rows in flight across the deploy still mean the same key. A key of pool n is (n - 1) * POOL_KEY_STRIDE + position (pool 2 starts at 1000). The pool NUMBER is used rather than its rank among today's valid pools, so disconnecting pool 2 does not rename every busy key of pool 3. Deliberately not changed: - A single endpoint takes the old code path byte for byte; every existing test passes untouched (66 before, 78 after). - The closed breakdown (browseros-ai#1308) stays three integers. Lanes per credential stay one number for the deployment, which keeps it an exact statement: credentials x lanes, bounded by the policy ceiling. No pool name, URL or variable name enters it. - An explicit endpoint stays authoritative, including its refusal: a valid second pool does not take over from a first pool with no key. - A local Ollama stays one measured inference slot and reads no pools. - The model is required per pool and never inherited: the first pool's model name sent to another provider is a 404. - One secret named by two pools is one credential (browseros-ai#1293). A pool someone began to configure and dispatch ignored reads as configured in a variable editor and supplies nothing. endpointPoolProblems() names the missing variable (names only, never a value), and the "every key is busy" refusal carries it, because that is the moment an operator asks why the swarm is narrower than the variables suggest. The dispatch detail printed `key ${keyIndex + 1}`; with a durable index of 1002 that would read "key 1003/3". It now prints the pool and the position in it. Applies cleanly to fix/queen-worker-provider-and-prompt-size (the branch production deploys from) as well as to feat/queen-supervisor. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Dmitrii Vasilev (gHashTag)
pushed a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 19, 2026
…ee fits, so ask before every start The worker ceiling is a number and the credential list is a number, and the one thing that actually decides how many bees run at once - the container - was never asked. Measured on 2026-09-17 from the Railway metrics: the container is limited to 24 GB and held 14.7 GB with sixteen bees running, about 0.85 GB a bee over 1 GB idle; the volume is 50 GB with 29 to 31 in use and 35.8 at the day's peak. The same day the ceiling stopped being a constant and the credential list reached 36 lanes. A full swarm would ask for about 31 GB of 24, and the kernel answers that by killing the container with every running bee in it, each holding the only copy of its unfinished turn. queen-resources.ts is whether one more bee fits. Before every start it reads what the container holds that the kernel cannot give back - memory.current minus the file cache, both lists, minus reclaimable slab - against memory.max, and the free space on the workspace volume. cgroup v2, then v1, then /proc/meminfo. Nothing is cached, so the line moves with the container and with the operator's variables and no restart is needed. Memory refuses when used + (young + 1) x perBee > limit - min(10%, 8 GB); disk when free < perBeeDisk + min(10%, 10 GB). Memory first, one cause reported. Unknown is a refusal; a machine that is not Linux has no container to protect. Young bees: the tick starts bees back to back and a bee takes minutes to allocate what it will hold, so every start inside the warm-up reserves a bee's memory the reading cannot show yet. The reservation is keyed by the turn and ends in closeDispatch, because /chat answers 200 and streams a provider refusal afterwards: kept as timestamps, a provider outage reserved ten GB for bees that were already dead. The gate sits in dispatchBee after the key refusals and before the worktree is cut. Disk gets one reap before it refuses, bounded at the guard's own line rather than the collector's 55%. A container refusal is not booked against the issue: it says nothing about the issue and is how a memory-bound round ends. The reaper no longer takes the tree of a running bee. reapWorktrees takes a protect set and prepareWorktree's own reap gets it too - that one fires at 80% used, earlier than the guard refuses, and on a scratch repository it removed two trees registered as running. The gate's reap also protects the branch being dispatched: a re-dispatch could reap its own tree and then cut it afresh with -B, dropping the last attempt's unpushed commit. An unreadable registry reaps nothing instead of protecting nobody. The round report says why. /queen/needs-you serves the headline to a browser and promises no path, so the headline gets a label from a closed vocabulary (no room in the container: memory | disk) and the body gets the guard's summary, carried as a field and never cut out of prose that names a path. Checked from inside a Railway container rather than assumed: memory.max reads 24000000000, memory.current and memory.stat are readable, there is no cgroup v1, and /proc/meminfo describes the host (338 GB). So a stated TRIOS_QUEEN_MEMORY_LIMIT_MB can only lower the line - the kernel's limit wins - and the host is never held against a stated container limit. Numbers are printed in decimal GB, the unit the platform sells and the cgroup file uses. Admission control only: a bee admitted and then grown far past its reserve can still take the container down. It caps nothing by count; the Swift copies, the closed capacity breakdown (browseros-ai#1308) and /queen/status are untouched. Two review rounds found and these tests now pin: the unprotected reap, the re-dispatch reaping its own tree, dead starts holding reservations, a stated limit above the kernel's, active cache counted as used, a missing checkout read as a full disk. Each new behavioural test was checked by breaking the line it guards. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.