Repository navigation
chore: bump version - #1538
Merged
Merged
chore: bump version#1538
Conversation
Contributor
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
…minator (browseros-ai#1538) (#371) running: 0 could never say whether the swarm was empty or merely had no capacity to spend. workers answers that: capacity from the same configuredWorkerCapacity authority /queen/public-research reads, active from a new started_running count (started = true AND finished_at IS NULL, because a dispatch that never got a turn holds no paid slot), plus idle and an integer utilization, every malformed input folded into the closed range 0 <= active <= capacity. The queue classification now reads the same started-unfinished count, so the how-many and the why of idle slots are two readings of one number and can never tell two stories. swarmState keeps its base on running: an unfinished dispatch is still a dispatch the table owes an ending, started or not. Carried from the closed queen-1303 branch as a statement of intent and rewritten against the base as it stands; nothing is copied, and both files stay ASCII. The four names the success criteria require are defined and exercised: started_running, startedUnfinished, plantedSecret, startedRunning. bun test on the file: 27 pass, 0 fail. The lefthook pre-commit could not run in this container (npx absent, bash-only test under dash); its biome command was run manually via bunx and passed with no fixes. Co-authored-by: Trinity Bee <bee@trinity.local>
Dmitrii Vasilev (gHashTag)
added a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 5, 2026
…pped connection, and I had seen it before (#373) THE SALVAGE LOOP CLOSED, and looking at it found the defect. Last round `salvage` measured what four stale branches still owed and wrote each as a brief. This round the swarm executed three of them. The audit: browseros-ai#1537 8 promised identifiers absent at the fork point, present on the branch, 6 in a declaration browseros-ai#1538 4 of 4, 3 in a declaration browseros-ai#1539 10 of 10, 9 in a declaration browseros-ai#1484 its own criterion failed at the fork point and passes on the branch Four for four, every one proven fail-to-pass. Measurement -> brief -> work -> audit -> land works end to end, and #370, #371 and #372 carry it into the base. BUT THEY HAD BEEN FINISHED FOR A ROUND AND NOBODY COULD SEE THEM. The Queen's own board said "completed" for browseros-ai#1538, browseros-ai#1539 and browseros-ai#1484 - dispatched, run for 9 to 15 minutes, 23 to 35 thousand output tokens each, reviewed and ACCEPTED - while no branch existed on the remote and no comment existed on the issue. `push-work` is the only way a bee's work leaves the container. It had died on `Operation timed out (os error 60)` from `railway ssh`, which is a network hop failing the way network hops fail. A retry thirty seconds later pushed thirteen branches. AND I HAD SEEN IT BEFORE. Two rounds ago the chain printed `push-work=FAILED`, I re-ran it by hand, it worked, and I wrote it off as transient without changing anything. "It worked when I tried again" is not a diagnosis. It is the observation that a retry belongs in the code, and skipping that step cost a round of invisible work. So the channel retries with backoff, and only for channel-shaped failures - "Operation timed out", "Connection reset", "SendRequest", ETIMEDOUT, 502. A git answer is an answer: `! [rejected] ... (non-fast-forward)` is not retried, because a partly-rejected push is a normal outcome the reporting already knows how to describe. The selftest pins both directions. AND A CHANNEL FAILURE MUST NOT LOOK LIKE "NOTHING TO PUSH". Both end without pushing anything and only one of them is fine. The chain reads this step's words, so the words differ: COULD NOT REACH THE CONTAINER after retrying. could not reach the container after 3 attempts: ... Nothing was pushed and nothing was inspected. This is NOT "nothing to push": this step is the only way a bee's work leaves the container, and it did not run. Exit 3, and never a stack trace. selftest 162 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
…ad been failing two thirds of the time (#374) I came to watch four salvage briefs through the swarm. They passed - and looking at them found something much larger. THE SALVAGE LOOP CLOSED. browseros-ai#1537, browseros-ai#1538 and browseros-ai#1539 were executed by bees and every promised identifier is absent at the fork point and present on the branch: 8 of 8, 4 of 4, 10 of 10, six to nine of them in a declaration. browseros-ai#1484's own criterion failed at the fork point and passes on the branch. Landed as #370, #371, #372. Measurement -> brief -> work -> audit -> land, proven end to end. BUT THEY HAD BEEN FINISHED FOR A ROUND AND INVISIBLE. The Queen's board said "completed" for three of them - dispatched, run 9 to 15 minutes, 23 to 35 thousand output tokens each, reviewed and ACCEPTED - with no branch on the remote and no comment on the issue. `push-work` had died on `Operation timed out (os error 60)`. A retry pushed thirteen branches. I HAD SEEN IT BEFORE AND FIXED NOTHING. Two rounds ago the chain printed `push-work=FAILED`, I re-ran it by hand, it worked, and I called it transient. "It worked when I tried again" is not a diagnosis; it is the observation that a retry belongs in the code. SO I ASKED THE LEDGER, for the first time in the whole run. Over 23 hours: reap 45 of 63 runs failed 71% lease 43 of 63 68% push-work 46 of 70 66% close-done 32 of 70 46% Those are exactly the four steps that FREE the swarm. All four reach the container through `railway ssh` and each carried its own six-line copy of the call. None of them retried. They had been failing about two thirds of the time for as long as the ledger goes back, and it was invisible because every run only ever reported itself - a single failure looks like bad luck, and only the record shows it is the system. `channel.mjs` is that call, once. It retries a CHANNEL failure - "Operation timed out", "Connection reset", "SendRequest", ETIMEDOUT, 502 - and never retries an ANSWER: `git push` exits non-zero when a ref is rejected, and a partly-rejected push is a normal outcome its caller already describes. Retrying an answer would be as wrong as crashing on a dropped connection, and the selftest pins both directions. Copying the push-work fix into three more files would have been L2 again: a rule transcribed four times is four rules that agree until someone edits one. It also marks the failure, so a caller can tell "I looked and found nothing" from "I never looked" - the same silence, completely different facts. AND THE LEDGER RECORDED NO REASON FOR ANY OF THEM. `line` is set only when a SUMMARY pattern matches, and no pattern matches a failure, so every one of the 46 FAILED entries carries an empty summary. The console had the reason. The record did not, and those failures can never now be diagnosed. Both chains keep the last six lines of a failing step from here on. `tri failures` reads the ledger backwards; `tri channel` says whether the one way in is up. Four `tri` commands were also passing their own name through as an argument, which is why `tri failures --since 1` looked for a step called "failures". selftest 166 pass 0 fail. Co-authored-by: Dmitrii Vasilev <trackgmedernj@hotmail.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.