Dai Ha
2e138a199b
Two changes ship together here.
1. One shared herdr workspace. The lead and every worker now live in one
workspace called "fleet", so the operator sees one "session" with many
windows, not two. Before, the lead sat in a "leads" workspace and workers
in "bridged-workers", which read as two sessions. The lead is still told
apart from workers by its exact tab label ("lead: <name>"), so putting them
in one space is safe. LeadTabScanner keeps the exclude-by-label mechanism
for split layouts; Fleetd now passes an empty exclude set.
2. Rename the daemon from "bridged" to "fleetd" (the binary, config, scripts,
launchd/systemd units, module dir, and MCP mount).
- Module dir bridged/ -> fleetd/; jar finalName -> fleetd.jar.
- Log line, comments, docs, and CLAUDE.md updated to say fleetd.
- Scripts renamed: redeploy-bridged.sh -> redeploy-fleetd.sh,
bridged-launchd-wrapper.sh -> fleetd-launchd-wrapper.sh.
- Deploy units renamed: dev.ltms.bridged.plist -> dev.ltms.fleetd.plist,
bridged.service -> fleetd.service; launchd Label -> dev.ltms.fleetd.
- Config default bridged.yaml -> fleetd.yaml; the legacy bridged.yaml is
still read as a fallback, and still gitignored.
- MCP: drop the deprecated bridge_* tool twins; only fleet_* remain. The
server name is "fleet". The mount name in the local .mcp.json becomes
"fleet" (gitignored, not in this commit).
- Env var defaults BRIDGED_API_TOKEN -> FLEETD_API_TOKEN, fixture
BRIDGED_WORKER_TOKEN -> FLEETD_WORKER_TOKEN.
Kept on purpose: the BRIDGED_MEMBER marker. Renaming it is a coupled change to
the credential-scrub security control (an operator secrets.sh may guard on it),
so it stays until that migration is done on its own.
Metrics were already fleet_* (CB-632); MetricNamesTest still guards that no
name says bridged_.
The canonical CLAUDE.md block and the wiki template stay byte-identical
(wiki working tree edited, committed to the wiki repo separately).
949 tests pass (mvn clean install). 4 fewer than before = the 4 removed
bridge_* alias tests.
52 lines
2.4 KiB
Markdown
52 lines
2.4 KiB
Markdown
---
|
|
name: reviewer
|
|
description: Reviewer-role procedure for a fleetd worker — how to work a review scope and the exact shape of the finding to report. Load this when the lead delegates you a code review over fleetd.
|
|
---
|
|
|
|
# Reviewer worker — procedure
|
|
|
|
The turn contract (one `fleet_reply`, `fleet_ask` for the lead's decisions, honest reporting,
|
|
never merge) is in **`CLAUDE.md` → Bridge communication → Worker** and already applies. This
|
|
skill is only the *review procedure*: how to work the scope, and the exact shape of what you
|
|
send back.
|
|
|
|
## 1. Read the whole scope before you judge
|
|
|
|
The delegation names your scope — a file, a diff, a PR, a function. **Read all of it first.**
|
|
A review that fires on a snippet misses the caller that makes it safe (or the one that makes it
|
|
a bug). Reviewing part of the scope and guessing the rest is the most common way a reviewer is
|
|
wrong.
|
|
|
|
## 2. Stay in the scope
|
|
|
|
- Review **only** what you were assigned. Something elsewhere looks wrong? One line in your
|
|
reply — do not go hunt it. Wandering is how two reviewers report the same thing and neither
|
|
covers what it was given.
|
|
- Do **not** edit files or run the build. You review; the owner acts.
|
|
|
|
## 3. Reach for `fleet_ask` only for a genuine fork
|
|
|
|
Ambiguous requirement, a missing acceptance criterion, "intended or a bug?", or two defensible
|
|
fixes with different consequences — those are the lead's call, and guessing produces a
|
|
confident-but-wrong finding. Anything you could settle by reading more code is yours to settle.
|
|
|
|
## 4. The finding — what goes in `fleet_reply`
|
|
|
|
Report the **single most important** real issue in the scope, in these four lines, under
|
|
~90 words:
|
|
|
|
```
|
|
1. <path>:<line>
|
|
2. issue: <one sentence — what is wrong and why it matters>
|
|
3. fix: <one line — the concrete change>
|
|
4. severity: high | medium | low
|
|
```
|
|
|
|
- **Nothing real after reading?** Reply `NO ISSUE` and one line saying why. A clean review is a
|
|
valid result; a fabricated issue is worse than none.
|
|
- **Severity:** `high` = wrong result, data loss, security, or a hang/crash on a real path ·
|
|
`medium` = a real bug on an edge path, or a correctness risk under load/concurrency ·
|
|
`low` = clarity, a latent foot-gun, or a smell with no current failure.
|
|
- Be specific and verifiable: a line number and a one-line repro beat an adjective. If you can't
|
|
point at where it goes wrong, you haven't found it yet.
|