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

CB-632: purge "bridge" from the code, the artefacts and the ops surface #145

New Issue
Open
opened 2026-08-23 06:21:21 +02:00 by ltms · 3 comments
ltms commented 2026-08-23 06:21:21 +02:00
Owner
Copy Link
Copy Source

Part of #125 (CB-621).

Why this ticket exists

The epic renamed the tools (#126, done) and is renaming the checkout path (#128). Neither
touches the code. bridg* still appears ~2,600 times, including the Java package, every
class name, the Maven artifact, the config filename, the launchd job and the MCP mount name:

1142  bridged          190  BridgeMcp        30  BridgedMetrics
 620  BridgedConfig     90  BRIDGED_*        25  BridgedApp
 413  bridge            47  Bridged          28  Bridge

So the product is called fleet and the daemon is called fleetd, but nothing a developer or
an operator touches says so. The epic is not finished until this is done.

Target names

now after
module dir bridged/ fleetd/
Maven artifactId / finalName bridged fleetd
package dev.ltms.bridged dev.ltms.fleet
main class Bridged Fleetd
BridgedConfig FleetConfig
BridgeMcp FleetMcp
BridgedApp FleetApp
BridgedMetrics FleetMetrics
bridged.yaml / bridged.example.yaml fleetd.yaml / fleetd.example.yaml
deploy/dev.ltms.bridged.plist deploy/dev.ltms.fleetd.plist
deploy/bridged.service deploy/fleetd.service
scripts/redeploy-bridged.sh scripts/redeploy-fleetd.sh
scripts/bridged-launchd-wrapper.sh scripts/fleetd-launchd-wrapper.sh
MCP mount name bridged fleetd

The package root is dev.ltms.fleet, not dev.ltms.fleetd. The trailing d means daemon,
which names a process, not a namespace — dev.ltms.fleet.mcp reads correctly and
dev.ltms.fleetd.mcp does not.

What must NOT change in this ticket

  1. The bridge_* MCP tool aliases stay. #126 shipped both names on purpose, for one
    release. BridgeMcp.java registers 11 deprecatedTwin(...) entries — a rename must move the
    class, not delete the twins.
  2. BRIDGED_* env var names change only behind a read-both shim. These are an operator
    contract, not internal strings:
    • BRIDGED_WORKER_TOKEN (57 uses)
    • BRIDGED_MEMBER (13) — read by ${SHARED_ENV}/tools/secrets.sh, a file this repo does
      not own. Renaming it without a shim silently turns off the credential guard, which is the
      exact shape of a defect we have hit before (#113). Read both FLEET_MEMBER and
      BRIDGED_MEMBER; set both at spawn.
    • BRIDGED_API_TOKEN (8), BRIDGED_SUB* (6)
  3. bridged.yaml keeps working as a fallback filename. Fleetd.main should try
    fleetd.yaml, then bridged.yaml, and log which one it used. The live plist passes the
    name explicitly, so a rename with no fallback strands a daemon that is restarted before its
    plist is updated.
  4. The config key fleet: -> roles: is #130, not this ticket.

Units

Unit 1 must land first — it renames files, and every other unit edits the renamed files.

  1. Java rename — git mv the module dir and the package dir, rewrite package/import
    lines, rename the 5 classes and their test classes, update pom.xml
    (artifactId, name, finalName, mainClass). Verified by mvn clean install alone:
    if it compiles and 878 tests pass, the rename is right.
  2. Env var shim — BRIDGED_* -> FLEET_* reading both, plus a test that the old name
    still works.
  3. Config filename — fleetd.yaml with the bridged.yaml fallback, plus the example file.
  4. Ops artefacts — plist, systemd unit, launchd wrapper, redeploy-*.sh,
    rename-checkout.sh (its JAR_NAME and config-file constants change), .gitea/workflows.
  5. Docs — README.md, docs/**, CLAUDE.md. The canonical block in CLAUDE.md must stay
    byte-identical with the template in wiki 7-Use-Cases.md; the sync check in CLAUDE.md is
    the gate. Commit the wiki in the wiki repo, never from the parent.

Acceptance criteria

  • git ls-files | grep -v '^wiki' | xargs grep -il bridg returns only the files that are
    supposed to keep the word: the bridge_* alias registrations, the BRIDGED_* shim, the
    bridged.yaml fallback, and the changelog/ticket history that records the rename.
  • mvn clean install green, test count unchanged.
  • scripts/redeploy-fleetd.sh --check runs and reports honestly.
  • The daemon starts from the renamed plist and fleet_whoami still answers primary.

Ordering against #128

Do this ticket before #128 (the checkout move). rename-checkout.sh has been written and
--checked against today's names; changing the code first means editing that script once, and
then the checkout move is the single cutover step that restarts the daemon.

Part of #125 (CB-621). ## Why this ticket exists The epic renamed the *tools* (#126, done) and is renaming the *checkout path* (#128). Neither touches the code. `bridg*` still appears **~2,600 times**, including the Java package, every class name, the Maven artifact, the config filename, the launchd job and the MCP mount name: ``` 1142 bridged 190 BridgeMcp 30 BridgedMetrics 620 BridgedConfig 90 BRIDGED_* 25 BridgedApp 413 bridge 47 Bridged 28 Bridge ``` So the product is called `fleet` and the daemon is called `fleetd`, but nothing a developer or an operator touches says so. The epic is not finished until this is done. ## Target names | now | after | |---|---| | module dir `bridged/` | `fleetd/` | | Maven `artifactId` / `finalName` `bridged` | `fleetd` | | package `dev.ltms.bridged` | `dev.ltms.fleet` | | main class `Bridged` | `Fleetd` | | `BridgedConfig` | `FleetConfig` | | `BridgeMcp` | `FleetMcp` | | `BridgedApp` | `FleetApp` | | `BridgedMetrics` | `FleetMetrics` | | `bridged.yaml` / `bridged.example.yaml` | `fleetd.yaml` / `fleetd.example.yaml` | | `deploy/dev.ltms.bridged.plist` | `deploy/dev.ltms.fleetd.plist` | | `deploy/bridged.service` | `deploy/fleetd.service` | | `scripts/redeploy-bridged.sh` | `scripts/redeploy-fleetd.sh` | | `scripts/bridged-launchd-wrapper.sh` | `scripts/fleetd-launchd-wrapper.sh` | | MCP mount name `bridged` | `fleetd` | The package root is `dev.ltms.fleet`, not `dev.ltms.fleetd`. The trailing `d` means *daemon*, which names a process, not a namespace — `dev.ltms.fleet.mcp` reads correctly and `dev.ltms.fleetd.mcp` does not. ## What must NOT change in this ticket 1. **The `bridge_*` MCP tool aliases stay.** #126 shipped both names on purpose, for one release. `BridgeMcp.java` registers 11 `deprecatedTwin(...)` entries — a rename must move the class, not delete the twins. 2. **`BRIDGED_*` env var names change only behind a read-both shim.** These are an operator contract, not internal strings: - `BRIDGED_WORKER_TOKEN` (57 uses) - `BRIDGED_MEMBER` (13) — read by `${SHARED_ENV}/tools/secrets.sh`, a file this repo does not own. Renaming it without a shim silently turns off the credential guard, which is the exact shape of a defect we have hit before (#113). Read both `FLEET_MEMBER` and `BRIDGED_MEMBER`; set both at spawn. - `BRIDGED_API_TOKEN` (8), `BRIDGED_SUB*` (6) 3. **`bridged.yaml` keeps working as a fallback filename.** `Fleetd.main` should try `fleetd.yaml`, then `bridged.yaml`, and log which one it used. The live plist passes the name explicitly, so a rename with no fallback strands a daemon that is restarted before its plist is updated. 4. The config key `fleet:` -> `roles:` is #130, not this ticket. ## Units Unit 1 must land first — it renames files, and every other unit edits the renamed files. 1. **Java rename** — `git mv` the module dir and the package dir, rewrite `package`/`import` lines, rename the 5 classes and their test classes, update `pom.xml` (`artifactId`, `name`, `finalName`, `mainClass`). Verified by `mvn clean install` alone: if it compiles and 878 tests pass, the rename is right. 2. **Env var shim** — `BRIDGED_*` -> `FLEET_*` reading both, plus a test that the old name still works. 3. **Config filename** — `fleetd.yaml` with the `bridged.yaml` fallback, plus the example file. 4. **Ops artefacts** — plist, systemd unit, launchd wrapper, `redeploy-*.sh`, `rename-checkout.sh` (its `JAR_NAME` and config-file constants change), `.gitea/workflows`. 5. **Docs** — `README.md`, `docs/**`, `CLAUDE.md`. The canonical block in `CLAUDE.md` must stay byte-identical with the template in wiki `7-Use-Cases.md`; the sync check in `CLAUDE.md` is the gate. Commit the wiki in the wiki repo, never from the parent. ## Acceptance criteria - `git ls-files | grep -v '^wiki' | xargs grep -il bridg` returns only the files that are *supposed* to keep the word: the `bridge_*` alias registrations, the `BRIDGED_*` shim, the `bridged.yaml` fallback, and the changelog/ticket history that records the rename. - `mvn clean install` green, test count unchanged. - `scripts/redeploy-fleetd.sh --check` runs and reports honestly. - The daemon starts from the renamed plist and `fleet_whoami` still answers `primary`. ## Ordering against #128 Do this ticket **before** #128 (the checkout move). `rename-checkout.sh` has been written and `--check`ed against today's names; changing the code first means editing that script once, and then the checkout move is the single cutover step that restarts the daemon.
ltms commented 2026-08-23 06:38:07 +02:00
Author
Owner
Copy Link
Copy Source

Unit 1 done — 9b50dd6 on lead/cb-632-java-rename

Package dev.ltms.bridged -> dev.ltms.fleet, and Bridged/BridgedConfig/BridgeMcp/
BridgedApp/BridgedMetrics -> Fleetd/FleetConfig/FleetMcp/FleetApp/FleetMetrics.
154 files, 149 of them pure renames. mvn clean install green: 51 test classes, 878 tests,
0 failures — the same count as before the rename, read out of the surefire XML rather than a
piped tail.

Three things worth recording, because two of them are traps and one is a decision:

  1. BSD sed has no \b. One command carried eleven -e expressions; the eleventh was
    s/\bBridged\b/Fleetd/g. It matched nothing, changed nothing and exited 0 alongside the ten
    that worked. Caught by counting leftovers, not by the exit code.
  2. logback.xml and logback-test.xml name the package twice each, once as a
    turboFilter class= attribute. No compiler checks those. A rename that only satisfies
    javac leaves the daemon failing at startup.
  3. One collision was semantically meaningful. A test held viaBridge and viaFleet for the
    two halves of the CB-622 dual-name check; renaming collapsed them onto one name and the
    compiler caught it. viaBridge is correct there — it names the deprecated call — and is back.
    This is the general hazard for the remaining units: in this codebase the word "bridge" is
    sometimes the old name and sometimes the current, deliberate name of a deprecated alias.

Deliberately unchanged, as planned: module directory bridged/, <finalName>bridged</finalName>,
bridged.yaml, BRIDGED_*, and the bridge_* tool aliases.

Two units are being resequenced

Unit 2 (the BRIDGED_* env var shim) is deferred until #144 (CB-633) lands. BRIDGED_MEMBER
is read by a guarded block in ${SHARED_ENV}/tools/secrets.sh, a file this repo does not own.
Renaming it to FLEET_MEMBER needs the operator to edit that file — and #144 replaces that whole
mechanism with an allow-list applied at the spawn boundary, which removes the shell-side reader
entirely. Doing unit 2 first means asking the operator for an edit, then throwing it away.
BRIDGED_WORKER_TOKEN and BRIDGED_API_TOKEN can ride along with #144's change for the same
reason: one operator-facing change instead of two.

Unit 4 (the ops artefacts) is folded into the cutover. The plist, the systemd unit, the
launchd wrapper and redeploy-bridged.sh all name bridged/target/bridged.jar. That path only
changes when the module directory and <finalName> change, and the installed plist has
KeepAlive armed, so renaming the jar on its own strands a restart. Renaming those files early
would leave redeploy-fleetd.sh --check failing against the live system, which breaks its own
acceptance criterion. So the cutover is one PR: module dir -> fleetd/, finalName -> fleetd,
ops files renamed and repointed, rename-checkout.sh constants updated — then build, install the
new plist, restart, and confirm a fresh fleetd listening line.

That cutover PR is also where #128 (the checkout move) belongs, since both are path changes
needing one daemon restart.

Remaining before the cutover

  • Unit 3 — fleetd.yaml with a bridged.yaml fallback, and fleetd.example.yaml.
    Delegated. The fallback is required, not cosmetic: the live config is literally named
    bridged.yaml, is gitignored, and is passed to the daemon as an explicit argument.
  • Unit 5 — prose in README.md, docs/**, bridged/docs/**. Delegated. Scoped to class
    names, the package name, and the daemon's product name only; paths, bridge_*, BRIDGED_*
    and bridged_ metrics are explicitly out of scope because they are all still true today.
  • CLAUDE.md and the wiki template — mine, not delegated. The canonical block has to stay
    byte-identical with wiki 7-Use-Cases.md, and the wiki is a submodule that must never be
    committed from the parent repo.
## Unit 1 done — `9b50dd6` on `lead/cb-632-java-rename` Package `dev.ltms.bridged` -> `dev.ltms.fleet`, and `Bridged`/`BridgedConfig`/`BridgeMcp`/ `BridgedApp`/`BridgedMetrics` -> `Fleetd`/`FleetConfig`/`FleetMcp`/`FleetApp`/`FleetMetrics`. 154 files, 149 of them pure renames. `mvn clean install` green: **51 test classes, 878 tests, 0 failures** — the same count as before the rename, read out of the surefire XML rather than a piped tail. Three things worth recording, because two of them are traps and one is a decision: 1. **BSD `sed` has no `\b`.** One command carried eleven `-e` expressions; the eleventh was `s/\bBridged\b/Fleetd/g`. It matched nothing, changed nothing and exited 0 alongside the ten that worked. Caught by counting leftovers, not by the exit code. 2. **`logback.xml` and `logback-test.xml` name the package twice each**, once as a `turboFilter class=` attribute. No compiler checks those. A rename that only satisfies `javac` leaves the daemon failing at startup. 3. **One collision was semantically meaningful.** A test held `viaBridge` and `viaFleet` for the two halves of the CB-622 dual-name check; renaming collapsed them onto one name and the compiler caught it. `viaBridge` is correct there — it names the deprecated call — and is back. This is the general hazard for the remaining units: in this codebase the word "bridge" is sometimes the old name and sometimes the current, deliberate name of a deprecated alias. Deliberately unchanged, as planned: module directory `bridged/`, `<finalName>bridged</finalName>`, `bridged.yaml`, `BRIDGED_*`, and the `bridge_*` tool aliases. ## Two units are being resequenced **Unit 2 (the `BRIDGED_*` env var shim) is deferred until #144 (CB-633) lands.** `BRIDGED_MEMBER` is read by a guarded block in `${SHARED_ENV}/tools/secrets.sh`, a file this repo does not own. Renaming it to `FLEET_MEMBER` needs the operator to edit that file — and #144 replaces that whole mechanism with an allow-list applied at the spawn boundary, which removes the shell-side reader entirely. Doing unit 2 first means asking the operator for an edit, then throwing it away. `BRIDGED_WORKER_TOKEN` and `BRIDGED_API_TOKEN` can ride along with #144's change for the same reason: one operator-facing change instead of two. **Unit 4 (the ops artefacts) is folded into the cutover.** The plist, the systemd unit, the launchd wrapper and `redeploy-bridged.sh` all name `bridged/target/bridged.jar`. That path only changes when the module directory and `<finalName>` change, and the installed plist has `KeepAlive` armed, so renaming the jar on its own strands a restart. Renaming those files early would leave `redeploy-fleetd.sh --check` failing against the live system, which breaks its own acceptance criterion. So the cutover is one PR: module dir -> `fleetd/`, `finalName` -> `fleetd`, ops files renamed and repointed, `rename-checkout.sh` constants updated — then build, install the new plist, restart, and confirm a fresh `fleetd listening` line. That cutover PR is also where #128 (the checkout move) belongs, since both are path changes needing one daemon restart. ## Remaining before the cutover - **Unit 3** — `fleetd.yaml` with a `bridged.yaml` fallback, and `fleetd.example.yaml`. Delegated. The fallback is required, not cosmetic: the live config is literally named `bridged.yaml`, is gitignored, and is passed to the daemon as an explicit argument. - **Unit 5** — prose in `README.md`, `docs/**`, `bridged/docs/**`. Delegated. Scoped to class names, the package name, and the daemon's product name only; paths, `bridge_*`, `BRIDGED_*` and `bridged_` metrics are explicitly out of scope because they are all still true today. - **`CLAUDE.md` and the wiki template** — mine, not delegated. The canonical block has to stay byte-identical with wiki `7-Use-Cases.md`, and the wiki is a submodule that must never be committed from the parent repo.
ltms commented 2026-08-23 06:39:45 +02:00
Author
Owner
Copy Link
Copy Source

Correction: the ticket named the wrong MCP mount string

The target table says "MCP mount name bridged -> fleetd". That is wrong, and it matters,
because the two mounts are named in two different places by two different owners.

ClaudeCodeLauncher.java:301 builds the member's mount inline:

String mcpJson = "{\"mcpServers\":{\"bridge\":{\"type\":\"http\",\"url\":\""
        + cfg.mcpUrl() + "\"}}}";

So a spawned member's tools are mcp__bridge__* — bridge, no d. The bridged name I
quoted is only what this primary's .mcp.json happens to use, and .mcp.json is gitignored
and --skip-worktree, so it is a local operator file rather than something this repo controls.
CLAUDE.md's canonical block already states exactly this distinction and is correct as written:

bridge tools prefixed mcp__bridge__* ⇒ spawned member (the launcher fixes that mount
name; a primary's mount is named by whoever wrote its .mcp.json, so it varies)

I went looking because mcp__bridge__* did not match my own mcp__bridged__* tools and I
suspected a defect in the fallback ladder. There is none. Checked before changing anything.

Corrected target: the launcher's member mount name bridge -> fleet, at
ClaudeCodeLauncher.java:301. OpenCodeLauncher needs the same check — it builds its own config
and has a providerId + " (bridged)" display string at line 359.

This is not a free rename, and it does not belong in a code unit. The member mount name is
part of the instruction surface, not just an implementation detail:

  1. It changes the fallback ladder in the canonical block of CLAUDE.md (mcp__bridge__* ->
    mcp__fleet__*), which must stay byte-identical with the wiki template in
    7-Use-Cases.md, and must then be propagated to every other project carrying that block.
  2. Any member already briefed to look for mcp__bridge__* stops matching. The ladder fails
    safe — its final rung is "still unsure ⇒ act as a worker" — so a stale member is over-
    restricted rather than over-privileged. That is the right direction, but it is still a
    silent behaviour change.

So: give it its own unit, done by the lead, landing in the same PR as the CLAUDE.md and wiki
edits. Not delegated, because the wiki is a submodule that must never be committed from the
parent repo.

Also fixed in passing: the CLAUDE.md addendum pointed at mcp/BridgeMcp, which no longer
exists after unit 1. It now reads mcp/FleetMcp. That line is in the project addendum, not the
canonical block, so no wiki sync was needed — verified the sync check still returns True.

## Correction: the ticket named the wrong MCP mount string The target table says "MCP mount name `bridged` -> `fleetd`". That is wrong, and it matters, because the two mounts are named in two different places by two different owners. `ClaudeCodeLauncher.java:301` builds the member's mount inline: ```java String mcpJson = "{\"mcpServers\":{\"bridge\":{\"type\":\"http\",\"url\":\"" + cfg.mcpUrl() + "\"}}}"; ``` So **a spawned member's tools are `mcp__bridge__*`** — `bridge`, no `d`. The `bridged` name I quoted is only what *this* primary's `.mcp.json` happens to use, and `.mcp.json` is gitignored and `--skip-worktree`, so it is a local operator file rather than something this repo controls. `CLAUDE.md`'s canonical block already states exactly this distinction and is correct as written: > bridge tools prefixed `mcp__bridge__*` ⇒ **spawned member** (the launcher fixes that mount > name; a primary's mount is named by whoever wrote its `.mcp.json`, so it varies) I went looking because `mcp__bridge__*` did not match my own `mcp__bridged__*` tools and I suspected a defect in the fallback ladder. There is none. Checked before changing anything. **Corrected target:** the launcher's member mount name `bridge` -> `fleet`, at `ClaudeCodeLauncher.java:301`. `OpenCodeLauncher` needs the same check — it builds its own config and has a `providerId + " (bridged)"` display string at line 359. **This is not a free rename, and it does not belong in a code unit.** The member mount name is part of the instruction surface, not just an implementation detail: 1. It changes the fallback ladder in the canonical block of `CLAUDE.md` (`mcp__bridge__*` -> `mcp__fleet__*`), which must stay byte-identical with the wiki template in `7-Use-Cases.md`, and must then be propagated to every other project carrying that block. 2. Any member already briefed to look for `mcp__bridge__*` stops matching. The ladder fails safe — its final rung is "still unsure ⇒ act as a worker" — so a stale member is over- restricted rather than over-privileged. That is the right direction, but it is still a silent behaviour change. So: give it its own unit, done by the lead, landing in the same PR as the `CLAUDE.md` and wiki edits. Not delegated, because the wiki is a submodule that must never be committed from the parent repo. Also fixed in passing: the `CLAUDE.md` addendum pointed at `mcp/BridgeMcp`, which no longer exists after unit 1. It now reads `mcp/FleetMcp`. That line is in the project addendum, not the canonical block, so no wiki sync was needed — verified the sync check still returns True.
ltms commented 2026-08-31 09:00:36 +02:00
Author
Owner
Copy Link
Copy Source

Audit against main at 4ac688b. The purge is complete except for three deliberate retentions, which I am listing rather than closing over, because each is a decision and not an oversight.

$ grep -rni "bridged" fleetd/src/main/java --include='*.java' | wc -l
10

All ten are in four files, and all ten are one of the three items below. There is no incidental "bridge" left in the Java source — the tool namespace in particular is at zero (#126, now closed).

What remains, and what each would cost

1. bridged.yaml config fallback — Fleetd.java:97-111

Reads bridged.yaml when fleetd.yaml is absent. This is intentional backward compatibility and its javadoc says so. It costs nothing to keep and it is the safety net for any deployment not yet migrated.

Recommendation: keep. Remove it at 3.0 alongside other breaking changes, not on its own.

2. BRIDGED_MEMBER marker — HerdrPeerLauncher.java:950-955, referenced in MemberEnvAllowList.java:65

This is a security control, not a name. The operator's secrets.sh guards on it:

[ -n "${BRIDGED_MEMBER:-}" ] || export GITEA_ACCESS_TOKEN=...

Renaming it in the daemon without simultaneously editing the operator's shared secret store would silently un-guard that block, and every member would start receiving the credentials the marker exists to withhold. The daemon and the secret store would have to change in the same instant, and the failure mode of getting it wrong is silent credential exposure.

Recommendation: keep, and add a comment at the definition saying why it must not be renamed casually. A cosmetic rename is not worth that risk. If it is ever done, it needs an overlap period where the guard checks both names.

3. .bridged-worktrees directory — GitWorktrees.java:31, 95, 682

The live worktree root, currently holding active worker worktrees. Renaming the default strands every existing worktree: git worktree records absolute paths, so old worktrees would keep pointing at the old directory while new ones went elsewhere.

Recommendation: keep the default, or do it properly with a migration that reads the old location when the new one is absent. Not a string change.

Suggested disposition

This ticket has done its job for the code. The three remaining items are each a small migration with real failure modes, and none of them is user-visible — no operator reads a directory name or an env marker as product branding.

I am leaving this open as the checklist for those three rather than closing it, so they do not get silently forgotten. But I would not schedule any of them ahead of a real defect. Item 2 in particular I think should stay as it is permanently, with a comment explaining the constraint.

Audit against `main` at `4ac688b`. The purge is **complete except for three deliberate retentions**, which I am listing rather than closing over, because each is a decision and not an oversight. ``` $ grep -rni "bridged" fleetd/src/main/java --include='*.java' | wc -l 10 ``` All ten are in four files, and all ten are one of the three items below. There is no incidental "bridge" left in the Java source — the tool namespace in particular is at zero (#126, now closed). ## What remains, and what each would cost **1. `bridged.yaml` config fallback** — `Fleetd.java:97-111` Reads `bridged.yaml` when `fleetd.yaml` is absent. This is intentional backward compatibility and its javadoc says so. It costs nothing to keep and it is the safety net for any deployment not yet migrated. *Recommendation: keep.* Remove it at 3.0 alongside other breaking changes, not on its own. **2. `BRIDGED_MEMBER` marker** — `HerdrPeerLauncher.java:950-955`, referenced in `MemberEnvAllowList.java:65` This is a **security control**, not a name. The operator's `secrets.sh` guards on it: ``` [ -n "${BRIDGED_MEMBER:-}" ] || export GITEA_ACCESS_TOKEN=... ``` Renaming it in the daemon without simultaneously editing the operator's shared secret store would silently un-guard that block, and every member would start receiving the credentials the marker exists to withhold. The daemon and the secret store would have to change in the same instant, and the failure mode of getting it wrong is silent credential exposure. *Recommendation: keep, and add a comment at the definition saying why it must not be renamed casually.* A cosmetic rename is not worth that risk. If it is ever done, it needs an overlap period where the guard checks both names. **3. `.bridged-worktrees` directory** — `GitWorktrees.java:31, 95, 682` The live worktree root, currently holding active worker worktrees. Renaming the default strands every existing worktree: `git worktree` records absolute paths, so old worktrees would keep pointing at the old directory while new ones went elsewhere. *Recommendation: keep the default, or do it properly with a migration that reads the old location when the new one is absent.* Not a string change. ## Suggested disposition This ticket has done its job for the code. The three remaining items are each a small migration with real failure modes, and none of them is user-visible — no operator reads a directory name or an env marker as product branding. I am leaving this open as the checklist for those three rather than closing it, so they do not get silently forgotten. But I would not schedule any of them ahead of a real defect. Item 2 in particular I think should stay as it is permanently, with a comment explaining the constraint.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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#145
Delete Branch "%!s()"

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?