Repository navigation
Conversation
Contributor
Author
Review notesNot blocking, not verified. Each is one reviewer's claim.
Written by an agent. |
…reason and nothing pins the human view
The unit layer could not see it at all: deleting formatStatus from the daemon status branch left every unit test green. This kills that mutation where a mutation sweep runs it cheapest.
CI's comment lint judged the repro's doc blocks; the checks they explain are already named in their test titles, so each comment keeps only what the code does not show.
why: the guard scanned line by line, so a call whose table spans lines (`it.fails.each([...])\n(...)`) passed it, and the file read as covered while the rule did not reach it (testing rule 4). The scan now matches a whole comment-stripped file, allows a modifier on either side of `fails` (`it.only.fails` and `it.fails.each` are both real chains in vitest), and pins the shapes it must catch and the ones it must leave alone as two tables.
…tten on why: stripComments dropped a block comment without its newlines, so the meta-test's report pointed a reader at the header above the call rather than at the call itself. The strip now leaves a block comment's newlines in place, and the meta-test pins the reported line for a call written below a multi-line header.
V3RON
marked this pull request as ready for review
October 16, 2026 19:41
3 tasks done
V3RON
added a commit
that referenced
this pull request
Oct 17, 2026
…te (#402) (#650) Closes #402 ### Status Implement: done (592/592 leasing green) Review: round 1 passed (spec, code, claims: F0) Hardware: n/a Gate: running Next: gate result - [x] A waiter whose queue timeout falls due while its lease is being written gets the grant, not a timeout — `#decide` marks the ready grant `processing` before the write, so the queue's mid-attempt rule spares it; the triage test lands in this PR and passes - [x] A ready grant whose registry commit throws defers the waiter with one `warn` (`step=grant`) and grants it on the next wake — the `catch` mirrors `#grantPhysical`; the pin fails on its log assertion without it - [x] A ready grant the queue will not put in flight writes no lease — the `markProcessing` refusal is checked before `#grant`; the pin fails on its device/lease assertions without it The only caller-visible additions: a failed ready grant now logs one `warn` line and the waiter stays open for the next wake instead of wedging, and `waitingDemand` reports the waiter in flight during the write — the triage report lists both as intended. ## Assumptions - Assumption: a refused `markProcessing` on the ready path ends the drive silently (`return undefined`) rather than deferring — the queue refused because the waiter is at its deadline and already rejected; deferring would re-queue a dead waiter. Same handling as the plan path at the other `markProcessing` call. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 0 notes. Rounds: 1. Tokens: n/a. Kind `full`, so all three reviews ran; the code reviewer with `lens: both` in its own worktree of `3a1d0cee`. Inputs came from `.agents/scripts/review-inputs.sh 650` (rules, ADRs and briefs from `main`). How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644 and #646. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*
6 tasks done
V3RON
added a commit
that referenced
this pull request
Oct 17, 2026
…worker is starting (#651) Closes #406 The overview read a starting worker's absent `leases`/`devices` as zero, so the fleet's tiles, chart, capacity bars and worker rows named counts that treated the unknown as none. Absent now stays unknown. ## Done when - [x] Tiles show `—`, not a count — `ui/src/model/overview.ts:154-166`; the carried test asserts `Utilisation —` and `Leases —`. - [x] The chart returns no minutes — `overview.ts:193-194`; same test: `minutes` `[]`, `chartSummary` `""`. The panel says "Not reported.". - [x] A worker row omits its lease count and says "Not reported" — `overview.ts:114-127`; same test: no `leases` property, that label. - [x] Capacity bars say unknown — `overview.ts:84-88`, and the screen prints a dash and draws no share bar for it (a bar only shades a printed figure). - [x] A reporting worker beside an unread one leaves the total unknown, and keeps its own figures — same test, second case. - [x] Console lane green — the PR's Console job; the fleet fixture already waits out the `starting` window (`e2e/console/fixtures.ts:209`). Deleting the `isUnread` guard reddens the test on its `—` assertion; deleting the row's label or the bar guard reddens each named assertion. ### Status Implement: done (2/2 green) Review: round 1 (2 src fixed), round 2 F0, fix-check F0 Hardware: n/a Gate: running Next: gate ## Assumptions - Assumption: whether a platform's share bar shows while its figures are unknown — the bar is left out. It only shades a number printed beside it (`docs/internal/DESIGN.md`), and an empty one reads as "nothing leased", the claim this bug is about. ## Review Spec review: 0 blocking, 2 fixed, 0 notes. Code review: 0 blocking, 1 fixed, 1 note. Claims review: 0 blocking, 0 fixed, 1 note. Rounds: 2. Tokens: n/a. Kind `full`, so all three reviews ran round 1, the code reviewer with `lens: both`. Three round-1 notes claimed wrong state or a rule breach, so each was verified: two were confirmed and fixed (the unknown tiles named a unit no test could pin, so the unit is omitted while unknown; an unread platform still drew an empty share bar), and one was a `docs/CONSOLE.md` line saying the dash appears "while it is starting" when a worker that disconnects while starting keeps its leases absent too (`src/gateway/worker-registry.ts:422-441`). Two `src` fixes took round 2 (code + claims), both F0; the comment-lint fix to the test's own comments took the fix check, also F0. Rejected: - spec: ui/src/model/overview.test.ts:64 the new comments break the comment lint — CI's `lint:comments` is what rules on it; the lint then rejected six comments and that fix went through the fix check. How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643 and #644. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only its `review-inputs.sh` directory and its own worktree of the reviewed commit, blind to this body, the commit messages and each other. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*
2 tasks done
V3RON
added a commit
that referenced
this pull request
Oct 17, 2026
…658) Closes #647 ### Status Implement: done (596/596 leasing, 2348/2348 changed) Review: round 1 + fix check passed (spec, code, claims: F0) Hardware: n/a Gate: running Next: gate result - [x] A waiter whose grant of the booted or provisioned device fails to store is deferred with one `warn` (`step=grant`) and granted on the next wake — the triage tests from `bug/647-repro` land in this PR and pass; deleting the `catch` turns both red on the grant-step `warn` assertion, and a `catch` without the `#defer` turns both red on `queueDepth` - [x] A failed handoff grant still releases the device claim and the capacity reservation — the releases stay in the `finally`; deleting them turns 40 leasing tests red, including the two triage tests ## Assumptions - Assumption: the `warn` message names the plan kind ("granting a provisioned device failed" / "granting a booted device failed") — matches the wording of the sibling grant-failure lines; no test or doc pins message text. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 0 notes. Rounds: 1. Tokens: n/a. How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646 and #650. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only the inputs directory from `.agents/scripts/review-inputs.sh` and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output; each read `.agents/briefs/calibration.md` first. Round 1 reviewed `90d98d35`; a format-hook rewrap of one test line forced a history rewrite, so a fix check (code and claims, `lens: both`) reviewed `90780cc9` and confirmed the delta formatting-only (F0 both). Nothing was reviewed by the agent that wrote the code. *Written by an agent.*
3 tasks done
V3RON
added a commit
that referenced
this pull request
Oct 17, 2026
… refused (#661) Closes #389 ### Status Implement: done (green; probe red on both claims) Review: round 1, 1 text fixed unreviewed Hardware: n/a Gate: running Next: gate result ## Done when - [x] The warm pool leaves a device of a platform whose driver was refused out of its shutdown and boot choice — the triage repro (carried unchanged from `bug/389-repro`) is the regression test - [x] The next least recently used device is shut down instead and the pool comes back under budget — same repro, its named assertions - [x] The refused platform's device stays counted in capacity, so the pool sees no free slot and does not over-subscribe — the view's capacity totals stay unfiltered; a probe filtering them reddens the repro and the table test ## Assumptions - Assumption: whether a refused platform's device stays warm-listed to the reaper through `targeted()` — left as today (still listed): the reaper's own abort on such a device is #659, and changing the list here would decide that reaper behaviour without its spec. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 1 blocking, 1 fixed, 0 notes. Rounds: 1. Tokens: n/a. Fixed unreviewed: - claims: src/core/create-core.test.ts:604 the repro's `why:` said the pause is one tick plus a millisecond; 31_000 ms is one tick plus a second (comment only, assertions unchanged) Kind `full`, so all three reviews ran; the code reviewer with `lens: both` in its own worktree of `49658360`. Inputs came from `.agents/scripts/review-inputs.sh 661` (rules, ADRs and briefs from `main`). How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649 and #650. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*
3 tasks done
V3RON
added a commit
that referenced
this pull request
Oct 17, 2026
…664) Closes #659 ### Status Implement: done (14/14 reaper file, 1222/1222 `src/core`, 4379/4379 `pnpm test:changed`; probes 2/2) Review: round 1, 0 blocking, 0 fixed unreviewed, 0 notes Hardware: n/a Gate: running Next: merged or parked with the line it printed ## Done when - [x] One action that throws inside the reaper's loop is contained, logged, and the run continues, so every proposal after a device whose platform has no driver is still executed, for both the idle-shutdown and the idle-destroy verb — the carried repro (`src/core/reaper.test.ts`, both verbs in one run) - [x] A run-level failure (a rule or the registry view that throws) still rejects the run — "A cleanup run that throws logs at error." and "a cleanup run that throws is logged once, however many triggers joined it" - [x] The fix adds no third `hasDriver` filter and duplicates no skip predicate — the catch is at `execute`; nothing was added to `#view()` Probes run on the final head, each reverted after: - Revert (the bare `await` restored): the repro reds on its own named assertion — `promise rejected "NoDriverError: No driver registered for platform: android" … at CleanupReaper.#runOnce`, and the log test reds on its resolve assertion. - Over-catch (the catch widened around the whole pass): both run-level tests above red on their log assertions, so they are live and the catch sits at `execute`, not around the pass. New path and its test (strict area): the `catch` adds one path, the `cleanup action failed` line, proven by "logs a cleanup action that throws at error, naming the action, rule and target, and still resolves the run". The repro covers the continue side for both verbs. ## Assumptions - Assumption: exit status of `simlock cleanup` with a failed action — it now exits 0 with the failure only in an error log; this follows from the fault isolation the triage chose and no doc says otherwise. `docs/CLI.md`'s `cleanup` section and its exit-code table name no failure for a command whose run completes, `NO_DRIVER` (12) stays true of the commands that still surface it, and no e2e or client test pins a throwing `cleanup.run`. For #660: `NukeService.#runNuke` has the same loop with the same missing catch; the shape here (catch at `execute`, log, continue) factors to it, but its spec decides its own fix and this PR does not touch it. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 0 notes. Rounds: 1. Tokens: n/a. Nothing was rejected, so nothing is listed. Round 1 confirmed no *src* finding, so round 2 and the fix check did not run (rule 14). Kind `full`, so all three reviews ran; the code reviewer with `lens: both` in its own worktree of `cffd92ee`. Inputs came from `.agents/scripts/review-inputs.sh 664` (rules, ADRs and briefs from `main`). How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649, #650 and #661. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output; each read `.agents/briefs/calibration.md` first. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*
This was referenced Oct 17, 2026
fix(console): the workers-list lane helpers drop a re-read refused by a stopping gateway (#642)
#667
Merged
V3RON
added a commit
that referenced
this pull request
Oct 17, 2026
…668) Closes #660 ### Status Implement: done (8/8 in `nuke-service.test.ts`; `pnpm test:changed` 4387 passed) Review: round 1, 0 open Hardware: n/a Gate: running Next: gate result ## What is this? `simlock nuke` stopped at the first device whose platform has no driver: `NoDriverError` escaped the reset loop, every device after it stayed booted, and the command reported failure. One device that cannot be reset is now logged and the reset goes on. ## How does it work? `NukeService.#runNuke` catches around the per-device `#resetDevice` call only — the inline shape #664 landed in the cleanup reaper, no shared helper. A maintenance or release-all failure still rejects the run, and the `finally` still reopens admission. `NukeService` had no logger; it takes an optional one now, wired where `create-core.ts` builds it, and the device it could not reset is logged at error with its id, platform and error. ## Done when - [x] The reset does not abort on a device whose platform has no driver and still resets every device after it — the triage reproduction, carried unchanged from `bug/660-repro`, is green: both driverless records are passed over and the healthy device after each ends `deleted`, across both verbs. Reverting the catch reddens it on `NoDriverError`. - [x] The new branch has its own path test, as a strict area needs — "logs a device it cannot reset at error, naming the device, platform and error". Deleting the log line reddens that test alone. - [x] A maintenance or release-all throw still rejects the run — "reopens admission even when reset work fails" is untouched and live: widening the catch over the whole loop reddens it. `src/core/AGENTS.md`'s Nuke item states the isolation and stays within its 150-line budget. No end-user doc claimed `nuke` fails when one device cannot be reached, so none changed; no event changed. ## Assumptions - Assumption: exit status of `simlock nuke` with a device it could not reach — it now exits 0 with the failure only in an error log; this follows from the fault isolation the triage chose and no doc says otherwise. `docs/CLI.md`'s nuke section and exit-code table checked: neither states that nuke fails when one device cannot be reached. ## Review Spec review: 0 blocking, 0 fixed, 1 note. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 0 notes. Rounds: 1. Tokens: n/a. Kind `full`, so all three reviews ran; the code reviewer with `lens: both` in its own worktree of `d54b86b5`. Inputs came from `.agents/scripts/review-inputs.sh 668` (rules, ADRs and briefs from `main`), and the reviewers saw no PR body, no commit messages and none another reviewer's output. How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649, #650 and #661. The `reviewer` agent ran instead as a fresh detached `claude -p` session on `bug/660` — its definition from `.claude/agents/reviewer.md`, its model from that file's frontmatter — which spawned the three reviewers itself as its own fresh sub-agents, each reading only the inputs directory and its own worktree of the reviewed commit. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*
V3RON
added a commit
that referenced
this pull request
Oct 17, 2026
… a stopping gateway (#642) (#667) Closes #642 ### Status Implement: done (repro red 8e565b6 -> green cf17fb2; fix commit 759ebe2) Review: round 2 passed (spec/code/claims F0) Hardware: n/a Gate: not run Next: gate ## Done when - [x] The lane's /v1/workers response helpers survive the gateway's listener stopping between interception and fetch — the carried repro (`workers-gateway-stops-mid-fetch.spec.ts`, adapted to call the real extracted helpers) is red at 8e565b6 with the lane's `route.fetch: connect ECONNREFUSED` signature and green from cf17fb2; the helpers drop that re-read with `route.abort()` - [x] A non-connect error from the re-read still fails the test (the narrow catch) — pinned: a rejection the regex does not match propagates out of the handler with no abort; probes: broadening the catch reddens the non-connect case, dropping it reddens the connect and repro cases; narrowing the regex to `ECONNREFUSED` reddens the ECONNRESET / socket-hang-up cases - [x] `workers.spec.ts` keeps passing with the helpers extracted, unchanged behavior — the two helpers moved to `workers-answers.ts` verbatim but for the `fetchOrDrop` guard; lane run green ## Assumptions - Assumption: the connect-level classes are `ECONNREFUSED`, `ECONNRESET` and `socket hang up` — the three the triage census observed (refused connect and destroyed mid-request); any other error still rethrows. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 2 blocking, 2 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 1 note. Rounds: 2. Tokens: n/a. Kind `tests-only`, so all three reviews ran; the code reviewer with `lens: tests`. Inputs from `.agents/scripts/review-inputs.sh 667` (rules, ADRs and briefs from `main`). Round 1 reviewed `cf17fb26`; round 2 reviewed the fix `759ebe28` (code + claims, F0 both). How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649, #650 and #661. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output; each read `.agents/briefs/calibration.md` first. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*
3 tasks done
V3RON
added a commit
that referenced
this pull request
Oct 17, 2026
…#665) (#669) Closes #665 ### Status Implement: done (600/600 leasing, 2354/2354 changed; both probes red) Review: round 1 passed (spec, code, claims: F0) Hardware: n/a Gate: running Next: gate result - [x] `#decide` plans no device work for a waiter `markProcessing` has just rejected — the guard at `src/leasing/lease-acquisition-coordinator.ts:904` mirrors the ready-grant branch the report points at; the new eviction test drives a real `timeoutMs` deadline falling due inside the eviction and fails on `createdModels` gaining `"iPhone 16"` without the guard - [x] A refused plan gives back what it holds — `releasePlanResources`; deleting only that release turns the eviction test red on `reservedRunning: 1` and all three table cases red on `NoCapacityError` for the next request - [x] The refusal leaves nothing queued behind a plan nobody performs — each table case asserts `outcome: "pending"` with `queueDepth: 0` Only the refused plan's own work disappears. The caller's answer is unchanged: the queue's own expiry had already settled it with `QueueTimeoutError`. ## Assumptions - Assumption: a refused `markProcessing` on the operation branch ends the drive silently, as the ready-grant branch already does — the queue refused because the waiter is at its deadline and already rejected; deferring would re-queue a dead waiter. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 1 note. Rounds: 1. Tokens: n/a. Fixed unreviewed (text, commit `a3d448ae`: comments only, no assertion changed): - claims: src/leasing/lease-acquisition-coordinator.test.ts:1549 the `why:` named a capacity reservation for the two `evict-*` cases, which hold a claim only; the guard's own comment said the same and was fixed with it Kind `full`, so all three reviews ran; the code reviewer with `lens: both` in its own worktree of `3cb8cada`. Inputs came from `.agents/scripts/review-inputs.sh 669` (rules, ADRs and briefs from `main`). How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649 and #650. Each reviewer ran as a fresh detached session reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output, and read `.agents/briefs/calibration.md` first. Two deviations, both disclosed: the `claude` CLI reported its monthly spend limit exhausted until 2026-10-18 15:00, so the children ran as detached `opencode run` sessions rather than detached `claude -p` ones; the pinned reviewer models (`opus`, `sonnet`) are not reachable there, so each ran on the one model that was. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*
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
1 participant
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.
Closes #422
The
it.failspassed whether or not the human view existed, so nothingpinned
daemon status's human view (#429 fold-in).Done when
it.failsbecomes a normal passing test on the real output —e2e/daemon-lifecycle.test.tsasserts the first line isDaemon: running (worker).formatStatusexists;
src/cli/index.ts:1296).daemon statusleaves the whole suite green #429 fold-in) — provenbelow at both the e2e and unit levels.
src/expected-failures.test.tsscans every tracked test file.How each was checked
Mutating
src/cli/index.ts:1296towriteResultonly (human view deleted):Restored: unit suite 7023 passed, e2e 4 passed, meta-test 19 passed.
Reintroducing the old
it.failsmakes the meta-test name it, as does thechained
it.skipIf(false).failsform and a call whose table spans lines —the scan matches a whole file now, not one line at a time (testing rule 4).
A reported offender carries the line its call is written on.
Status
Implement: done Review: round 1 + fix-check, 0 blocking Hardware: n/a Gate: running
Next: gate
Assumptions
src/cli/index.test.ts:1325, whose title claims only that the daemon is never auto-launched; adding the stdout assertion there would break testing rule 1, so the pin is a new test in that samedescribe, next to the ones it belongs with.Review
Spec review: 0 blocking, 0 fixed, 2 notes. Code review: 0 blocking, 0 fixed, 1 note. Claims review: 0 blocking, 0 fixed, 0 notes.
Rounds: 1. Tokens: n/a.
Kind
tests-only: all three reviews ran, the code review withlens: tests.Two verified notes were fixed without a round: the assumption bullet is now
one line, so the review inputs hold it whole; a stripped block comment no
longer shifts a reported offender's line. The fix commit (
23836566) got thefix-checkcode and claims reviews; both returned F0.How the reviews were spawned: this session sits at subagent depth and the
harness refused nested spawns, as on #643. Each reviewer ran as a fresh
detached
claude -psession — the body of.claude/agents/<reviewer>.mdasits system prompt, its model from that file's frontmatter — reading only the
review-inputs.shdirectory and its own worktree of the reviewed commit,with no PR body, commit messages or other reviewer's output. Nothing was
reviewed by the agent that wrote the code.
Written by an agent.