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

#480 a relative handoverPath lands in the LEAD'S repo, which is usually not the repo that ignores it #491

New Issue
Open
opened 2026-09-12 03:45:49 +02:00 by ltms · 1 comment
ltms commented 2026-09-12 03:45:49 +02:00
Owner
Copy Link
Copy Source

Found on 2026-09-12 while preparing to test the lead rollover on fleet01. Not a code defect — a configuration trap that the Mac's own layout hides.

The trap

#487 made a relative leadRollover.handoverPath resolve against the calling lead's workspace (fleet.leaders.<name>.cwd), not against the daemon's directory. That is correct and it stays.

The consequence nobody wrote down: the handover file is created inside whatever repository the lead works in. That repository is usually not fleetd, so a .gitignore rule added to fleetd protects nothing.

The handover file is a snapshot of one moment's live state — unpushed branches, running builds, open questions, whatever the outgoing lead thought the next one needed. It has no business in any git history.

Measured

On the Mac (where this was configured first), the two happen to coincide, which is why it went unnoticed:

fleet.leaders.opus.cwd = /Users/dai.ha/LTMS/claude-bridge     <- the fleetd repo itself
handoverPath           = .handover/HANDOVER.md
resolved               = /Users/dai.ha/LTMS/claude-bridge/.handover/HANDOVER.md
.gitignore             = carries `.handover/`                  <- same repo, so it works

On fleet01 they do not coincide:

fleet.leaders.opus.cwd = /home/ltms/LTMS/kb                    <- a DIFFERENT repo
fleetd checkout        = /home/ltms/LTMS/fleetd
a relative handoverPath would resolve to /home/ltms/LTMS/kb/.handover/HANDOVER.md
/home/ltms/LTMS/kb/.gitignore has no `.handover` rule          <- measured, 330 bytes, no match

Commands to re-measure on any host:

grep -n 'cwd:' <fleetd checkout>/fleetd/fleetd.yaml      # the lead's workspace
grep -n handover <lead workspace>/.gitignore             # empty output = this trap is live

What to do

Documentation, not code. Two rules for anyone configuring leadRollover:

  1. If handoverPath is relative, add the ignore rule to the lead's workspace repo, and say why in the rule's comment. Adding it to fleetd does nothing unless the lead happens to work there.
  2. Or give an absolute path that sits outside every repository, which sidesteps the question entirely.

I am not proposing that fleetd inspect git state at open time. The daemon has no business shelling out to git to second-guess an operator's path, and a warning it cannot act on is noise. The open response already hands back the resolved absolute path, which is the honest surface — this just needs to be written down where an operator will read it.

Related

  • #487 — the resolution rule this follows from.
  • #488 — fleet.leaders.<name>.cwd is never validated; a relative value is silently accepted. Same field, and fleet01's layout would expose it.
  • #480, #489 — the feature and its first live defect.
Found on 2026-09-12 while preparing to test the lead rollover on fleet01. Not a code defect — a configuration trap that the Mac's own layout hides. ## The trap #487 made a relative `leadRollover.handoverPath` resolve against the **calling lead's workspace** (`fleet.leaders.<name>.cwd`), not against the daemon's directory. That is correct and it stays. The consequence nobody wrote down: the handover file is created inside whatever repository the lead works in. That repository is usually **not** `fleetd`, so a `.gitignore` rule added to `fleetd` protects nothing. The handover file is a snapshot of one moment's live state — unpushed branches, running builds, open questions, whatever the outgoing lead thought the next one needed. It has no business in any git history. ## Measured On the Mac (where this was configured first), the two happen to coincide, which is why it went unnoticed: ``` fleet.leaders.opus.cwd = /Users/dai.ha/LTMS/claude-bridge <- the fleetd repo itself handoverPath = .handover/HANDOVER.md resolved = /Users/dai.ha/LTMS/claude-bridge/.handover/HANDOVER.md .gitignore = carries `.handover/` <- same repo, so it works ``` On fleet01 they do not coincide: ``` fleet.leaders.opus.cwd = /home/ltms/LTMS/kb <- a DIFFERENT repo fleetd checkout = /home/ltms/LTMS/fleetd a relative handoverPath would resolve to /home/ltms/LTMS/kb/.handover/HANDOVER.md /home/ltms/LTMS/kb/.gitignore has no `.handover` rule <- measured, 330 bytes, no match ``` Commands to re-measure on any host: ```bash grep -n 'cwd:' <fleetd checkout>/fleetd/fleetd.yaml # the lead's workspace grep -n handover <lead workspace>/.gitignore # empty output = this trap is live ``` ## What to do Documentation, not code. Two rules for anyone configuring `leadRollover`: 1. If `handoverPath` is relative, add the ignore rule to the **lead's workspace repo**, and say why in the rule's comment. Adding it to `fleetd` does nothing unless the lead happens to work there. 2. Or give an absolute path that sits outside every repository, which sidesteps the question entirely. I am not proposing that fleetd inspect git state at `open` time. The daemon has no business shelling out to git to second-guess an operator's path, and a warning it cannot act on is noise. The `open` response already hands back the resolved absolute path, which is the honest surface — this just needs to be written down where an operator will read it. ## Related - #487 — the resolution rule this follows from. - #488 — `fleet.leaders.<name>.cwd` is never validated; a relative value is silently accepted. Same field, and fleet01's layout would expose it. - #480, #489 — the feature and its first live defect.
ltms commented 2026-09-12 03:51:12 +02:00
Author
Owner
Copy Link
Copy Source

Correction to this ticket's "Related" section. My #488 claim was wrong.

I wrote that fleet01's layout "would expose" #488 — fleet.leaders.<name>.cwd never being validated, so a relative value is silently accepted. The fleet01 lead re-measured and it does not, because the bad input is not present there:

fleetd.yaml:229   cwd: /home/ltms/LTMS/kb        <- already absolute
every 'cwd' key in that file: exactly that one
CONTROL, non-comment lines: 142

So fleet01 is not an instrument for #488 at all. I had assumed "two unrelated directories" implied "a relative value somewhere", and those are different claims. #488 stays open and still needs a host that actually has a relative cwd, or a test that supplies one.

The part that survives is stronger than I put it. For #487 — a relative handoverPath resolving against the lead's workspace — fleet01 is a cleaner instrument than I described. I said the two directories "are not nested". The lead's measurement is sharper: /home/ltms/LTMS/kb and /home/ltms/LTMS/fleetd/fleetd share only /home/ltms/LTMS, so they are not nested at any depth. On the Mac they are one level apart, which is the weakest possible separation that still counts as different. So this ticket's premise holds and its evidence is better than the version I filed.

One more gap on that host, from the same reading: there is no bootstrapText key anywhere in fleet01's config. So even after an update it would need config written before a roll is safe — the fleet_whoami-first warning I passed on has nothing to attach to there yet.

Credit: all three points are the fleet01 lead's, re-measured on their host. I have not re-run them myself and am reporting their measurement, not mine.

**Correction to this ticket's "Related" section. My #488 claim was wrong.** I wrote that fleet01's layout "would expose" #488 — `fleet.leaders.<name>.cwd` never being validated, so a relative value is silently accepted. The fleet01 lead re-measured and it does not, because the bad input is not present there: ``` fleetd.yaml:229 cwd: /home/ltms/LTMS/kb <- already absolute every 'cwd' key in that file: exactly that one CONTROL, non-comment lines: 142 ``` So fleet01 is not an instrument for #488 at all. I had assumed "two unrelated directories" implied "a relative value somewhere", and those are different claims. #488 stays open and still needs a host that actually has a relative `cwd`, or a test that supplies one. **The part that survives is stronger than I put it.** For #487 — a relative `handoverPath` resolving against the lead's workspace — fleet01 is a cleaner instrument than I described. I said the two directories "are not nested". The lead's measurement is sharper: `/home/ltms/LTMS/kb` and `/home/ltms/LTMS/fleetd/fleetd` share only `/home/ltms/LTMS`, so they are not nested **at any depth**. On the Mac they are one level apart, which is the weakest possible separation that still counts as different. So this ticket's premise holds and its evidence is better than the version I filed. **One more gap on that host, from the same reading:** there is no `bootstrapText` key anywhere in fleet01's config. So even after an update it would need config written before a roll is safe — the `fleet_whoami`-first warning I passed on has nothing to attach to there yet. Credit: all three points are the fleet01 lead's, re-measured on their host. I have not re-run them myself and am reporting their measurement, not mine.
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#491
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?