Repository navigation
chore: temporarily disable claw extension - #1421
Merged
Merged
Conversation
Contributor
Greptile SummaryThis PR temporarily removes the BrowserOS Claw extension from bundled extension packaging.
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (1): Last reviewed commit: "chore: temporarily disable claw extensio..." | Re-trigger Greptile |
Dmitrii Vasilev (gHashTag)
added a commit
to gHashTag/BrowserOS
that referenced
this pull request
Sep 4, 2026
Filing N tasks does not give you N workers, and last round proved it on my own work: of four issues filed, browseros-ai#1420 and browseros-ai#1421 both named queen-tick.ts in their Boundary. Two bees may not write one file, so the scheduler correctly refused one with fileConflict and the fourth worker slot stayed empty while the backlog looked healthy. The conflict is a property of the WORK, so it is settled where the work is created. That is what Dependabot's grouping, Nx's file-keyed task graph and Kubernetes anti-affinity all do: tell the scheduler only about things that can coexist. author.mjs took candidates in the order they were measured and never asked. It now takes a disjoint batch, widest boundary first, excluding anything that collides with paths live dispatches already hold, and it PRINTS every candidate it set aside with the reason - a selector that drops work silently is indistinguishable from a broken one. disjoint.mjs compares paths component-wise, never as strings. rings/SR-0 is a string prefix of rings/SR-00/Queen.swift and is not a directory containing it; comparing raw prefixes is a recorded defect of this project. Run against the live board it immediately found a real double claim: rings/SR-02/ChatViewModel.swift is held by BOTH browseros-ai#1133 and browseros-ai#1240. A THIRD DETECTOR, because two were not enough variety to feed four workers. The backlog starved with the swarm at zero bees: author.mjs found fourteen real deficits and could file against NONE, every one already having an issue - one of the ones parked at the retry ceiling. L3 is repository law and is broken in 86 server files by 2690 characters, almost all box drawing in comment rules. That is the right kind of fuel: measurable by one grep, one file per task so N tasks really do give N workers, and renewable. Files with non-ASCII in live code are skipped, because rewriting a user-facing string is a change of behaviour. AND A FALSE REFUSAL OF MY OWN, caught by filing them. brief-gate demanded a promised identifier as the ONLY mechanically checkable criterion, so it refused three real cleanups - a cleanup defines nothing new. A command over a path the Boundary reserves, with an exact expected output, is a property of the TREE rather than of the report, and is harder to fake than an identifier. Accepted now, with the demand kept strict: exact output, and the path must be one the Boundary actually holds. Three negatives pin it. fp-check no longer counts NEVER ACTED as a false accusation. That state is a true statement about the world and the single most valuable line coverage.mjs prints - it is how the reaper's untested branch was found. Counting it here made every newly written tool look like a false accusation until its first act, which would have taught me to ignore the checker. The selftest fixture now mints its identifier per run. It used a fixed name, and once the file was committed that name existed in the tree five times - so brief-gate did exactly its job and refused the draft. The fixture had falsified its own premise by being saved. selftest 57/57. fp-check 19 known-good inputs, 0 accused. Three issues filed with pairwise disjoint boundaries: browseros-ai#1424, browseros-ai#1425, browseros-ai#1426. 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
…#122) * fix(queen): the brief numbers the verdict slots the report must fill (browseros-ai#1421) Five dispatches on 2026-09-04 were returned or escalated with the reviewer reporting "Finished work omitted N verdict lines", N being exactly the count of criteria called unmet. The workers did not refuse to answer: the brief already numbered the criteria but never required the report to be numbered the same way, so prose about the work satisfied the letter of the instruction and none of its purpose, and nothing checked before the turn ended. - briefFor now emits a VERDICT template with one numbered slot per criterion and states in words that an omitted slot is read as unmet, with a self-check the bee runs before it stops. The template appears only when the task states criteria: a task with none keeps the standing generic request byte for byte, because its bee states its own criteria first and slots nobody has written are not numbered. - missingVerdictSlots(text, total) names the criterion numbers a report leaves uncovered, reading the same block parseVerdictBlock reads so a covered slot and a judged line are the same thing. It is deliberately not wired past this file: the mid-turn teller would live in queen-dispatch.ts, outside this change's boundary, and this is the one definition of "missing" it will call. * fix(queen): the only machine-read part of the report was written last Three hours of dispatches: 17% accepted, 33% sent back, 28% answered wait - which means the review could not judge them at all. The transcripts settle why, and the fault is in the instruction rather than in any worker. browseros-ai#1429 discussed all four of its criteria in prose - "Criterion 4 ... Met." - and then wrote a VERDICT block containing TWO lines browseros-ai#1427 the same browseros-ai#1430 three of four the accepted ones exactly one line per criterion The brief said "End your LAST message with exactly this block". So the only machine-read part of a 25-35 kB report sat in the position where a turn that runs short loses it first, and a worker treating it as a closing summary rather than as the deliverable trims it exactly there. It now says BEGIN, and says why: everything after the block is prose for a person, the block is the only part read by machine, and a report that runs long loses whatever is last. Nothing the worker knows changes - it has done the work and taken its measurements before it composes the message. What changes is what survives when something is cut. The parser no longer cares. It took lastIndexOf, which was right while the block had to be last; it now tries every occurrence and keeps the fullest parse. That is stable under either convention, so a worker running an older brief is not punished, and a report that quotes the heading while explaining this rule cannot blank the result. Carries the browseros-ai#1421 work it belongs with - the numbered slot per criterion, one line each, and the statement that an omitted slot is read as unmet. That was finished on queen-1421 and never merged, because its own review could not parse the block it was written to fix. Nine new cases pin both halves: block at the top, block at the end, the heading appearing twice, two real blocks of different lengths, no block, and a heading with nothing under it. 190 pass across the queen suite, 0 fail, and this file contributes 0 typecheck errors - both gates run this time, not one. --------- Co-authored-by: Trinity Bee <bee@trinity.local> 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
…, 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>
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.