Skip to content

chore: bump version - #1538

Merged
Nikhil (shadowfax92) merged 1 commit into
mainfrom
fix/0702-1647-zebra
Jul 2, 2026
Merged

Nikhil (shadowfax92) merged 1 commit into
mainfrom
fix/0702-1647-zebra

Conversation

@shadowfax92

Copy link
Copy Markdown
Contributor

No description provided.

@shadowfax92
Nikhil (shadowfax92) merged commit 2baefbc into main Jul 2, 2026
6 of 7 checks passed
@github-actions github-actions Bot added the chore label Jul 2, 2026
@greptile-apps

greptile-apps Bot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

Bumps the BrowserOS version from 0.47.0.2 to 0.47.2.0 and increments the build offset from 172 to 173. No code logic changes are included.

  • BROWSEROS_VERSION: BROWSEROS_BUILD incremented from 0 to 2, BROWSEROS_PATCH reset to 0.
  • BROWSEROS_BUILD_OFFSET: incremented from 172 to 173 to track cumulative build count.

Confidence Score: 5/5

Safe to merge — only version metadata files are touched, with no code logic changes.

Both changed files are plain version metadata. The version advances from 0.47.0.2 to 0.47.2.0 and the build offset increments by one — purely mechanical, low-risk changes with no functional impact.

No files require special attention.

Important Files Changed

Filename Overview
packages/browseros/resources/BROWSEROS_VERSION Bumps version from 0.47.0.2 to 0.47.2.0 by incrementing BROWSEROS_BUILD from 0 to 2 and resetting BROWSEROS_PATCH from 2 to 0
packages/browseros/bos_build/config/BROWSEROS_BUILD_OFFSET Increments build offset from 172 to 173, tracking the cumulative build count

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[BROWSEROS_VERSION] --> B["0.47.0.2 (MAJOR=0, MINOR=47, BUILD=0, PATCH=2)"]
    A --> C["0.47.2.0 (MAJOR=0, MINOR=47, BUILD=2, PATCH=0)"]
    B -->|PR #1538| C
    D[BROWSEROS_BUILD_OFFSET] --> E["172"]
    D --> F["173"]
    E -->|PR #1538| F
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[BROWSEROS_VERSION] --> B["0.47.0.2 (MAJOR=0, MINOR=47, BUILD=0, PATCH=2)"]
    A --> C["0.47.2.0 (MAJOR=0, MINOR=47, BUILD=2, PATCH=0)"]
    B -->|PR #1538| C
    D[BROWSEROS_BUILD_OFFSET] --> E["172"]
    D --> F["173"]
    E -->|PR #1538| F
Loading

Reviews (1): Last reviewed commit: "chore: bump version" | Re-trigger Greptile

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant