fleet/fleetd
3
0
Fork 0
Code Issues 73 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

fleetd #201/#227 unit 5: wire errorPattern, cool-off spawn gate, and fleet views #246

Closed
agent wants to merge 0 commits from worker/cb201-unit5-wiring-6c12e6-8 into main
pull from: worker/cb201-unit5-wiring-6c12e6-8
merge into: fleet:main
Conversation 0 Commits - Files Changed -
agent commented 2026-09-03 06:46:16 +02:00
Member
Copy Link
Copy Source

fleetd #201/#227 Unit 5 — production wiring, spawn gate, and fleet views

Wires the already-merged Units 1-4 and the #234 fix into production, per the
lead's brief and docs/CB-201-227-Refinement.md § "Unit 5".

What changed (16 files, 1295 insertions / 67 deletions)

  • Fleetd.java — per-profile errorPattern compiled once at startup
    (mirrors exhaustedPattern exactly); one production BackendErrorSink
    wired with the exact order the lead specified: (1) SessionManager.onBackendError,
    (2) resolve effectiveCredentialId() fail-loud (never Optional.ifPresent,
    logs ERROR + ReplyPushLoop.onBackendTargetUnmapped on an unresolvable
    target), (3) BackendOutagePolicy.record(credentialId, target, reason),
    (4) ReplyPushLoop.onBackendIncident(...) on a new incident only. Also
    closed a previously-flagged gap: the new FleetMcp(...) construction now
    passes a real FleetMcp.OutageSource reading the live outagePolicy
    instance, instead of silently defaulting to OutageSource.none().
  • config/FleetConfig.java, config/ConfigRef.java — errorPattern
    key, malformed-pattern startup rejection (rejectMalformedErrorPattern,
    names profiles.<name>.errorPattern), classified DEFERRED alongside
    exhaustedPattern.
  • member/CompositePeerLauncher.java — both spawn paths (explicit,
    automatic) refuse a cooling-off credential; exhaustion quarantine wins
    when both are active, matching the lead's priority rule.
  • placement/PlacementContext.java, placement/PlacementPolicyUtil.java
    — a separate coolingOff set (not merged into quarantined), so refusal
    text says "cooling off", never "exhausted", and a candidate that is both
    counts only as quarantined (never double-bucketed).
  • mcp/FleetMcp.java — fleet_list: a cooling profile gets free:0 /
    credentialId / coolingOffForSeconds, never quarantinedForSeconds
    unless exhaustion quarantine is also independently active.
    fleet_profiles gets a separate coolingOff map. Explicit spawn refusal
    names the credential and remaining seconds ("cooling off after repeated
    backend errors").
  • fleetd.example.yaml — documents errorPattern, the legacy fallback,
    the 2-distinct-targets/60s-window/60s-cooloff policy, and how it differs
    from exhaustion quarantine; added to the DEFERRED reload-key list.
  • CLAUDE.md — new addendum bullet telling leads how fleet_list /
    fleet_profiles report the two independent outage states (quarantined vs
    cooling off) and how to read a refusal message correctly.
  • FixedPlacementPolicy.java (not in the original 15-file list — see
    Deviations below) — same coolingOff filtering as PlacementPolicyUtil,
    since it does its own inline candidate filtering rather than delegating.
  • Tests: FleetConfigTest (+82 lines), ConfigRefTest (+48), FleetMcpTest
    (+95, 5 new tests), CompositePeerLauncherTest (+182), PlacementPolicyTest
    (+82, 5 new tests, 1 strengthened — see Mutation testing), and a new
    cross-cutting integration test, BackendOutageFlowTest.java.

FleetHealthMonitor.coverage — untouched (criterion 14), confirmed by git diff --stat above (file not listed).

Startup coverage logging

Fleetd.java now logs, mirroring the already-shipped CB-578 stage A line
exactly:

log.info("backend-error classification (fleetd #201 Unit 5): {}",
        CompletionResolver.coverage(cfg.profiles().keySet(), errorPatternsByProfile.keySet()));

CompletionResolver.coverage(...) (unowned, pre-existing, unchanged) formats
as "partial (configured: [...]; not configured: [...])" for a mixed
config. I did not run the live fleetd process this session (that is a
lead-only redeploy action per CLAUDE.md), so I did not capture this exact
line from a running daemon — I verified it by reading the code, which
mirrors the already-accepted exhaustedPattern coverage line at
Fleetd.java:353-354 line for line. No test in the suite asserts this exact
log string (same as the pre-existing exhaustedPattern line has none), so
this is a code-reading proof, not a captured log line — flagging that
distinction rather than overclaiming it.

Real-production-call-path proof: BackendOutageFlowTest

Lives in dev.ltms.fleet.inject (see Deviations — needs
CompletionResolver.InFlight, which is package-private there). Mirrors
Fleetd.main's backendErrorSink lambda line-for-line inside its own setup
(the lambda itself is inline in main and not otherwise unit-testable), then
drives the real CompletionResolver.resolve() against FakeHerdr-supplied
pane text, the real CompositePeerLauncher.spawn(), the real
SessionManager, and the real ReplyPushLoop — never BackendOutagePolicy.record()
or a sink called directly.

5 tests, all green:

  • aSingleClassifiedBackendErrorOnOneTargetNeverCoolsTheCredential
  • twoDistinctTargetsClassifiedThroughTheRealScrapeStartAnIncidentAndCoolTheCredential
  • theIncidentSendsExactlyOneNudgeToTheLeadNamingBothCredentialAndTargets — asserts
    exactly 1 call reaches the fake lead pane (leadClient.sendCount() == 1),
    and that its text contains the credential id (shared-openai), both target
    terminal ids, and "60" (remaining cool-off seconds).
  • explicitSpawnOnACooledCredentialIsRefusedBeforeReachingTheAdapter — asserts
    the PlacementException message contains "cooling off" and "shared-openai",
    and that agent.start call count on the fake herdr is unchanged (proves the
    refusal happens before the adapter is ever invoked).
  • automaticPlacementRefusesAndNamesCoolingOffWhenEveryCandidateSharesTheCredential

Confirmed via console log showing real WARN lines from CompletionResolver/
SessionManager, e.g.:

member terminal=term_new_1 ... transitioned SPAWNING -> BACKEND_ERROR: ...

proving genuine end-to-end execution through the real classifier, not a stub.

fleet_list/fleet_profiles rendering of the resulting cool-off (criteria
11/12) is proven separately in FleetMcpTest (package-private access to
FleetMcp.listFleet/profiles — see Deviations), using a real
BackendOutagePolicy populated directly, since the rendering logic doesn't
care how that state was produced. Sample JSON (from FleetMcpTest's new
tests):

Cool-off only:

{"profile":"ltms-local","maxLoad":2,"live":0,"free":0,"credentialId":"shared-openai","coolingOffForSeconds":60}

Both quarantine (exhaustion) and cool-off active for the same profile at once:

{"profile":"ltms-local","maxLoad":2,"live":0,"free":0,"credentialId":"shared-openai","quarantinedForSeconds":1200,"coolingOffForSeconds":60}

Mutation testing (7 mutations, all killed after one fix)

Each: mutate production line → run targeted test → grep -c 'COMPILATION ERROR|cannot find symbol' on the log (0 in all 7 cases, confirming a genuine behavioral kill, not a compile error) → revert → confirm green.

# Mutation Compile errors Test that went red
M1 Drop rejectMalformedErrorPattern(yaml); call in FleetConfig.load() 0 FleetConfigTest
M2 Drop || ctx.coolingOff().contains(c.profile()) from PlacementPolicyUtil.available() 0 PlacementPolicyTest
M3 Drop enforceNotCoolingOff(requestedProfile); in CompositePeerLauncher.spawn() 0 CompositePeerLauncherTest
M4 Drop row.put("free", 0); in FleetMcp.capacityView()'s outage branch 0 FleetMcpTest (observed "free":2 instead of "free":0 in the failure diff)
M5 Drop && Objects.equals(a.errorPattern(), b.errorPattern()) in ConfigRef.sameLaunchSettings() 0 ConfigRefTest
M6 Empty out CompositePeerLauncher.coolingOffProfiles() body 0 CompositePeerLauncherTest
M7 Swap the quarantined/coolingOff check order in PlacementPolicyUtil.emptyException()'s bucketing loop 0 Not caught on first pass — see below

M7 caught a weak test, and I fixed it. quarantinedAndCoolingOffIsNotDoubleCounted
originally asserted only e.getMessage().contains("quarantined"). Under the
M7 mutation, quarantined count no longer equals total, so the code falls
through to the generic fallback message ("no worker profile available: ... quarantined, ... cooling off, ..."), which always contains the literal
substring "quarantined" regardless of the actual count — so the loose check
passed under both correct and mutated code, silently proving nothing.
Strengthened it to assertEquals("all worker profiles are quarantined (backend exhausted)", e.getMessage()),
re-ran with M7 still applied → now correctly fails with the generic fallback
text shown above. Reverted the M7 production mutation afterward; the
strengthened assertion is a permanent change, kept in the final diff.

Explicit vs. automatic spawn refusal text (verbatim, from PlacementPolicyUtil / BackendOutageFlowTest)

  • Explicit spawn on a cooling credential: contains "cooling off" and the
    credential id, e.g. "...cooling off...shared-openai..." (asserted via
    contains, not the full literal, in explicitSpawnOnACooledCredentialIsRefusedBeforeReachingTheAdapter).
  • Automatic placement, all candidates share the cooling credential:
    "all worker profiles are cooling off after repeated backend errors"
    (exact literal, PlacementPolicyUtil.emptyException).
  • Automatic placement, all candidates quarantined (exhaustion, unchanged
    from before this unit): "all worker profiles are quarantined (backend exhausted)".

Build result

cd fleetd/ && mvn clean install

Full, unpiped. Final lines:

[INFO] Tests run: 1190, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS

Up from the main baseline of 1163 tests (+27: 5 in PlacementPolicyTest,
5 in FleetMcpTest, 5 in BackendOutageFlowTest, plus tests added to
FleetConfigTest/ConfigRefTest/CompositePeerLauncherTest).

Deviations from the 15-file list (both justified, both noted, neither investigated further)

  1. placement/FixedPlacementPolicy.java — not in the original file
    list. It's the default placement policy and does its own inline
    quarantine/weight/capacity filtering rather than delegating to
    PlacementPolicyUtil, so it needed the same coolingOff exclusion added
    directly. No earlier unit (1-4) claims ownership of this file.
  2. BackendOutageFlowTest.java — ended up in dev.ltms.fleet.inject,
    not dev.ltms.fleet.member. CompletionResolver.InFlight is
    package-private to dev.ltms.fleet.inject, and the test needs it to
    drive the real classifier. FleetMcp.listFleet/profiles are
    package-private to dev.ltms.fleet.mcp and inaccessible from either
    package, so the fleet_list/fleet_profiles rendering proof was
    factored into FleetMcpTest instead (see above).

Wiki — for the lead, not touched by me

Per this repo's own addendum table (CLAUDE.md → "anything an operator can
use, configure, or observe... goes to wiki/11-Features.md"), a new entry
looks warranted for the cool-off feature: errorPattern config key, the
BackendOutagePolicy 2-distinct-targets/60s-window/60s-cooloff mechanism,
and fleet_list/fleet_profiles coolingOff reporting — what it does, the
knob (profiles.<name>.errorPattern in fleetd.yaml), why it exists
(distinguish a transient backend outage from real exhaustion so spawns don't
pile onto a credential that's actively erroring), and the gotcha (it's a
separate, shorter, non-configurable cooldown from exhaustion quarantine, and
both can fire on the same profile at once). I did not touch wiki/ myself.

Not investigated (outside scope, noted only)

None found beyond the two justified deviations above.

## fleetd #201/#227 Unit 5 — production wiring, spawn gate, and fleet views Wires the already-merged Units 1-4 and the #234 fix into production, per the lead's brief and `docs/CB-201-227-Refinement.md` § "Unit 5". ### What changed (16 files, 1295 insertions / 67 deletions) - **`Fleetd.java`** — per-profile `errorPattern` compiled once at startup (mirrors `exhaustedPattern` exactly); one production `BackendErrorSink` wired with the exact order the lead specified: (1) `SessionManager.onBackendError`, (2) resolve `effectiveCredentialId()` fail-loud (never `Optional.ifPresent`, logs ERROR + `ReplyPushLoop.onBackendTargetUnmapped` on an unresolvable target), (3) `BackendOutagePolicy.record(credentialId, target, reason)`, (4) `ReplyPushLoop.onBackendIncident(...)` on a new incident only. Also closed a previously-flagged gap: the `new FleetMcp(...)` construction now passes a real `FleetMcp.OutageSource` reading the live `outagePolicy` instance, instead of silently defaulting to `OutageSource.none()`. - **`config/FleetConfig.java`**, **`config/ConfigRef.java`** — `errorPattern` key, malformed-pattern startup rejection (`rejectMalformedErrorPattern`, names `profiles.<name>.errorPattern`), classified DEFERRED alongside `exhaustedPattern`. - **`member/CompositePeerLauncher.java`** — both spawn paths (explicit, automatic) refuse a cooling-off credential; exhaustion quarantine wins when both are active, matching the lead's priority rule. - **`placement/PlacementContext.java`**, **`placement/PlacementPolicyUtil.java`** — a separate `coolingOff` set (not merged into `quarantined`), so refusal text says "cooling off", never "exhausted", and a candidate that is both counts only as quarantined (never double-bucketed). - **`mcp/FleetMcp.java`** — `fleet_list`: a cooling profile gets `free:0` / `credentialId` / `coolingOffForSeconds`, never `quarantinedForSeconds` unless exhaustion quarantine is *also* independently active. `fleet_profiles` gets a separate `coolingOff` map. Explicit spawn refusal names the credential and remaining seconds ("cooling off after repeated backend errors"). - **`fleetd.example.yaml`** — documents `errorPattern`, the legacy fallback, the 2-distinct-targets/60s-window/60s-cooloff policy, and how it differs from exhaustion quarantine; added to the DEFERRED reload-key list. - **`CLAUDE.md`** — new addendum bullet telling leads how `fleet_list` / `fleet_profiles` report the two independent outage states (quarantined vs cooling off) and how to read a refusal message correctly. - **`FixedPlacementPolicy.java`** (not in the original 15-file list — see Deviations below) — same `coolingOff` filtering as `PlacementPolicyUtil`, since it does its own inline candidate filtering rather than delegating. - Tests: `FleetConfigTest` (+82 lines), `ConfigRefTest` (+48), `FleetMcpTest` (+95, 5 new tests), `CompositePeerLauncherTest` (+182), `PlacementPolicyTest` (+82, 5 new tests, 1 strengthened — see Mutation testing), and a new cross-cutting integration test, `BackendOutageFlowTest.java`. ### `FleetHealthMonitor.coverage` — untouched (criterion 14), confirmed by `git diff --stat` above (file not listed). ### Startup coverage logging `Fleetd.java` now logs, mirroring the already-shipped CB-578 stage A line exactly: ```java log.info("backend-error classification (fleetd #201 Unit 5): {}", CompletionResolver.coverage(cfg.profiles().keySet(), errorPatternsByProfile.keySet())); ``` `CompletionResolver.coverage(...)` (unowned, pre-existing, unchanged) formats as `"partial (configured: [...]; not configured: [...])"` for a mixed config. I did not run the live `fleetd` process this session (that is a lead-only redeploy action per `CLAUDE.md`), so I did not capture this exact line from a running daemon — I verified it by reading the code, which mirrors the already-accepted `exhaustedPattern` coverage line at `Fleetd.java:353-354` line for line. No test in the suite asserts this exact log string (same as the pre-existing `exhaustedPattern` line has none), so this is a code-reading proof, not a captured log line — flagging that distinction rather than overclaiming it. ### Real-production-call-path proof: `BackendOutageFlowTest` Lives in `dev.ltms.fleet.inject` (see Deviations — needs `CompletionResolver.InFlight`, which is package-private there). Mirrors `Fleetd.main`'s `backendErrorSink` lambda line-for-line inside its own setup (the lambda itself is inline in `main` and not otherwise unit-testable), then drives the **real** `CompletionResolver.resolve()` against `FakeHerdr`-supplied pane text, the **real** `CompositePeerLauncher.spawn()`, the **real** `SessionManager`, and the **real** `ReplyPushLoop` — never `BackendOutagePolicy.record()` or a sink called directly. 5 tests, all green: - `aSingleClassifiedBackendErrorOnOneTargetNeverCoolsTheCredential` - `twoDistinctTargetsClassifiedThroughTheRealScrapeStartAnIncidentAndCoolTheCredential` - `theIncidentSendsExactlyOneNudgeToTheLeadNamingBothCredentialAndTargets` — asserts **exactly 1** call reaches the fake lead pane (`leadClient.sendCount() == 1`), and that its text contains the credential id (`shared-openai`), both target terminal ids, and `"60"` (remaining cool-off seconds). - `explicitSpawnOnACooledCredentialIsRefusedBeforeReachingTheAdapter` — asserts the `PlacementException` message contains `"cooling off"` and `"shared-openai"`, and that `agent.start` call count on the fake herdr is unchanged (proves the refusal happens *before* the adapter is ever invoked). - `automaticPlacementRefusesAndNamesCoolingOffWhenEveryCandidateSharesTheCredential` Confirmed via console log showing real WARN lines from `CompletionResolver`/ `SessionManager`, e.g.: ``` member terminal=term_new_1 ... transitioned SPAWNING -> BACKEND_ERROR: ... ``` proving genuine end-to-end execution through the real classifier, not a stub. `fleet_list`/`fleet_profiles` rendering of the resulting cool-off (criteria 11/12) is proven separately in `FleetMcpTest` (package-private access to `FleetMcp.listFleet`/`profiles` — see Deviations), using a real `BackendOutagePolicy` populated directly, since the rendering logic doesn't care how that state was produced. Sample JSON (from `FleetMcpTest`'s new tests): Cool-off only: ```json {"profile":"ltms-local","maxLoad":2,"live":0,"free":0,"credentialId":"shared-openai","coolingOffForSeconds":60} ``` Both quarantine (exhaustion) and cool-off active for the same profile at once: ```json {"profile":"ltms-local","maxLoad":2,"live":0,"free":0,"credentialId":"shared-openai","quarantinedForSeconds":1200,"coolingOffForSeconds":60} ``` ### Mutation testing (7 mutations, all killed after one fix) Each: mutate production line → run targeted test → `grep -c 'COMPILATION ERROR|cannot find symbol'` on the log (0 in all 7 cases, confirming a genuine behavioral kill, not a compile error) → revert → confirm green. | # | Mutation | Compile errors | Test that went red | |---|---|---|---| | M1 | Drop `rejectMalformedErrorPattern(yaml);` call in `FleetConfig.load()` | 0 | `FleetConfigTest` | | M2 | Drop `\|\| ctx.coolingOff().contains(c.profile())` from `PlacementPolicyUtil.available()` | 0 | `PlacementPolicyTest` | | M3 | Drop `enforceNotCoolingOff(requestedProfile);` in `CompositePeerLauncher.spawn()` | 0 | `CompositePeerLauncherTest` | | M4 | Drop `row.put("free", 0);` in `FleetMcp.capacityView()`'s outage branch | 0 | `FleetMcpTest` (observed `"free":2` instead of `"free":0` in the failure diff) | | M5 | Drop `&& Objects.equals(a.errorPattern(), b.errorPattern())` in `ConfigRef.sameLaunchSettings()` | 0 | `ConfigRefTest` | | M6 | Empty out `CompositePeerLauncher.coolingOffProfiles()` body | 0 | `CompositePeerLauncherTest` | | M7 | Swap the `quarantined`/`coolingOff` check order in `PlacementPolicyUtil.emptyException()`'s bucketing loop | 0 | **Not caught on first pass** — see below | **M7 caught a weak test, and I fixed it.** `quarantinedAndCoolingOffIsNotDoubleCounted` originally asserted only `e.getMessage().contains("quarantined")`. Under the M7 mutation, `quarantined` count no longer equals `total`, so the code falls through to the generic fallback message (`"no worker profile available: ... quarantined, ... cooling off, ..."`), which *always* contains the literal substring `"quarantined"` regardless of the actual count — so the loose check passed under both correct and mutated code, silently proving nothing. Strengthened it to `assertEquals("all worker profiles are quarantined (backend exhausted)", e.getMessage())`, re-ran with M7 still applied → now correctly fails with the generic fallback text shown above. Reverted the M7 production mutation afterward; the strengthened assertion is a **permanent** change, kept in the final diff. ### Explicit vs. automatic spawn refusal text (verbatim, from `PlacementPolicyUtil` / `BackendOutageFlowTest`) - Explicit spawn on a cooling credential: contains `"cooling off"` and the credential id, e.g. `"...cooling off...shared-openai..."` (asserted via `contains`, not the full literal, in `explicitSpawnOnACooledCredentialIsRefusedBeforeReachingTheAdapter`). - Automatic placement, all candidates share the cooling credential: `"all worker profiles are cooling off after repeated backend errors"` (exact literal, `PlacementPolicyUtil.emptyException`). - Automatic placement, all candidates quarantined (exhaustion, unchanged from before this unit): `"all worker profiles are quarantined (backend exhausted)"`. ### Build result ``` cd fleetd/ && mvn clean install ``` Full, unpiped. Final lines: ``` [INFO] Tests run: 1190, Failures: 0, Errors: 0, Skipped: 0 [INFO] BUILD SUCCESS ``` Up from the `main` baseline of 1163 tests (+27: 5 in `PlacementPolicyTest`, 5 in `FleetMcpTest`, 5 in `BackendOutageFlowTest`, plus tests added to `FleetConfigTest`/`ConfigRefTest`/`CompositePeerLauncherTest`). ### Deviations from the 15-file list (both justified, both noted, neither investigated further) 1. **`placement/FixedPlacementPolicy.java`** — not in the original file list. It's the default placement policy and does its own inline quarantine/weight/capacity filtering rather than delegating to `PlacementPolicyUtil`, so it needed the same `coolingOff` exclusion added directly. No earlier unit (1-4) claims ownership of this file. 2. **`BackendOutageFlowTest.java`** — ended up in `dev.ltms.fleet.inject`, not `dev.ltms.fleet.member`. `CompletionResolver.InFlight` is package-private to `dev.ltms.fleet.inject`, and the test needs it to drive the real classifier. `FleetMcp.listFleet`/`profiles` are package-private to `dev.ltms.fleet.mcp` and inaccessible from either package, so the `fleet_list`/`fleet_profiles` rendering proof was factored into `FleetMcpTest` instead (see above). ### Wiki — for the lead, not touched by me Per this repo's own addendum table (`CLAUDE.md` → "anything an operator can use, configure, or observe... goes to `wiki/11-Features.md`"), a new entry looks warranted for the cool-off feature: `errorPattern` config key, the `BackendOutagePolicy` 2-distinct-targets/60s-window/60s-cooloff mechanism, and `fleet_list`/`fleet_profiles` `coolingOff` reporting — what it does, the knob (`profiles.<name>.errorPattern` in `fleetd.yaml`), why it exists (distinguish a transient backend outage from real exhaustion so spawns don't pile onto a credential that's actively erroring), and the gotcha (it's a separate, shorter, non-configurable cooldown from exhaustion quarantine, and both can fire on the same profile at once). I did not touch `wiki/` myself. ### Not investigated (outside scope, noted only) None found beyond the two justified deviations above.
agent added 1 commit 2026-09-03 06:46:16 +02:00
fleetd #201/#227 unit 5: wire errorPattern, cool-off spawn gate, and fleet views
CI / contract (pull_request) Successful in 49s
Details
CI / build (pull_request) Successful in 1m52s
Details
ba04b2359b 
Wires the already-merged units into production:
- Per-profile errorPattern config (beside exhaustedPattern), compiled once at
  startup; falls back to the legacy (?i)\bAPI Error\s*: pattern when unset.
  Startup logs configured-vs-legacy coverage, same as exhaustedPattern.
- One production BackendErrorSink in Fleetd.java: mark backend_error on the
  session, resolve the profile's credential fail-loud (never
  Optional.ifPresent), record it in BackendOutagePolicy, and push a lead
  nudge on a new incident.
- CompositePeerLauncher's explicit and automatic spawn paths both refuse a
  cooling-off credential; exhaustion quarantine wins when both are active.
  PlacementContext gets a separate coolingOff set so refusal text says
  "cooling off", never "exhausted".
- fleet_list/fleet_profiles report coolingOffForSeconds as an independent
  fact from quarantinedForSeconds; both can appear together.
- fleetd.example.yaml documents errorPattern and the 2/60/60 cool-off policy;
  CLAUDE.md tells leads how to read the two independent outage states.

Also: FixedPlacementPolicy.java, not in the original file list, needed the
same coolingOff filtering as PlacementPolicyUtil (it does its own inline
candidate filtering rather than delegating).

1190 tests, 0 failures (up from the 1163 baseline); BUILD SUCCESS.
ltms closed this pull request 2026-09-03 06:57:05 +02:00
Some checks are pending
CI / contract (pull_request) Successful in 49s
Details
CI / build (pull_request) Successful in 1m52s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#246
Delete Branch "worker/cb201-unit5-wiring-6c12e6-8"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?