Repository navigation
chore: temporarily disable claw server downloading - #1420
Conversation
Greptile SummaryThis PR temporarily disables Claw Server resource downloads. The main changes are:
Confidence Score: 4/5The changed resource flow can still package old Claw files from an incremental workspace.
packages/browseros/build/config/download_resources.yaml Important Files Changed
Prompt To Fix All With AIFix the following 2 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 2
packages/browseros/build/config/download_resources.yaml:74-80
**Claw Expectations Still Run**
The real download-config test still expects a Claw resource entry for each supported platform. With these operations commented out, the config loads successfully but the filtered operations no longer include any `browseros-claw-server-resources-*` item, so the test workflow fails until the test contract is updated for the temporary disablement.
### Issue 2 of 2
packages/browseros/build/config/download_resources.yaml:74-80
**Stale Claw Resources Remain**
The matching copy operations still read from `resources/binaries/browseros_claw_server/<platform>/resources`, but the downloader only clears a destination when its download entry runs. On an incremental workspace with a previous Claw download, this change skips both the fresh download and the clear, so stale Claw server resources can still be copied into the build.
Reviews (1): Last reviewed commit: "chore: temporarily disable claw server d..." | Re-trigger Greptile |
| # - name: "BrowserOS Claw Server Resources - macOS ARM64" | ||
| # r2_key: "claw-server/prod-resources/latest/browseros-claw-server-resources-darwin-arm64.zip" | ||
| # destination: "resources/binaries/browseros_claw_server/darwin-arm64" | ||
| # download_type: "artifact_zip" | ||
| # os: ["macos"] | ||
| # arch: ["arm64"] | ||
| # |
There was a problem hiding this comment.
The real download-config test still expects a Claw resource entry for each supported platform. With these operations commented out, the config loads successfully but the filtered operations no longer include any browseros-claw-server-resources-* item, so the test workflow fails until the test contract is updated for the temporary disablement.
Rule Used: Remove unused/dead code rather than leaving it in ... (source)
Learned From
browseros-ai/BrowserOS-agent#126
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/browseros/build/config/download_resources.yaml
Line: 74-80
Comment:
**Claw Expectations Still Run**
The real download-config test still expects a Claw resource entry for each supported platform. With these operations commented out, the config loads successfully but the filtered operations no longer include any `browseros-claw-server-resources-*` item, so the test workflow fails until the test contract is updated for the temporary disablement.
**Rule Used:** Remove unused/dead code rather than leaving it in ... ([source](https://app.greptile.com/browseros-org-2/-/custom-context?memory=9b045db4-2630-428c-95b7-ccf048d34547))
**Learned From**
[browseros-ai/BrowserOS-agent#126](https://github.com/browseros-ai/BrowserOS-agent/pull/126)
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| # - name: "BrowserOS Claw Server Resources - macOS ARM64" | ||
| # r2_key: "claw-server/prod-resources/latest/browseros-claw-server-resources-darwin-arm64.zip" | ||
| # destination: "resources/binaries/browseros_claw_server/darwin-arm64" | ||
| # download_type: "artifact_zip" | ||
| # os: ["macos"] | ||
| # arch: ["arm64"] | ||
| # |
There was a problem hiding this comment.
The matching copy operations still read from resources/binaries/browseros_claw_server/<platform>/resources, but the downloader only clears a destination when its download entry runs. On an incremental workspace with a previous Claw download, this change skips both the fresh download and the clear, so stale Claw server resources can still be copied into the build.
Rule Used: Remove unused/dead code rather than leaving it in ... (source)
Learned From
browseros-ai/BrowserOS-agent#126
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/browseros/build/config/download_resources.yaml
Line: 74-80
Comment:
**Stale Claw Resources Remain**
The matching copy operations still read from `resources/binaries/browseros_claw_server/<platform>/resources`, but the downloader only clears a destination when its download entry runs. On an incremental workspace with a previous Claw download, this change skips both the fresh download and the clear, so stale Claw server resources can still be copied into the build.
**Rule Used:** Remove unused/dead code rather than leaving it in ... ([source](https://app.greptile.com/browseros-org-2/-/custom-context?memory=9b045db4-2630-428c-95b7-ccf048d34547))
**Learned From**
[browseros-ai/BrowserOS-agent#126](https://github.com/browseros-ai/BrowserOS-agent/pull/126)
How can I resolve this? If you propose a fix, please make it concise.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>
… (#179) The six dispatches parked at the retry ceiling on 2026-09-04 all had an unmet count that was exactly their omitted count: criteria that were never judged at all, recorded indistinguishably from criteria that were judged and failed. Three reached maximumRealAttempts and escalated to a person without the work ever being assessed; the oldest waited 91 hours. - unjudgedCriteria names the promised criteria no verdict line answered, matching through quote drift (punctuation, case, the parser's 300-character slice) with a containment guard so one word cannot judge the whole contract. - The round records judged and unjudged per dispatch (FR-001) and the send-back names the two lists under distinct headings (FR-002), so a worker can tell 'you did not do this' from 'you did not say whether you did this'. - Once a bee has judged any criteria, the unjudged ones are added to the question as unmet, so the policy decides sendBack-versus-escalate on the complete picture rather than waiting for lines that will never come. A block missing entirely is still a wait: that is the torn- transcript signature (browseros-ai#1335), not a wall of omissions. - An attempt whose unmet criteria are ALL unjudged does not increment send_backs (FR-003): the retry budget is spent on work that was attempted and found wanting, never on silence. reviewFinishedDispatches is exported for the suite, as runRound is. The new suite drives the real policy binary and pins both acceptance scenarios: 2-of-5 judged leaves the counter alone; 5 covered with 2 failings advances it. Co-authored-by: Trinity Bee <bee@trinity.local>
No description provided.