Repository navigation
fix(fleet): shard re-home doubles home path segments when merging client shards into canonical #1658
Description
Activity
Evidence note from the implementation (#1662): shard-watch is detection-only by design (#1306 — the merge is #1302's by-hand flow), so the doubling came from hand-rolled SQL in a hand-run merge, not from a shipped code path. The fix therefore provides the re-home as tested tooling —
amico fleet shard-rehome— so the by-hand flow stops hand-writing the mapping.Bonus finding from verifying against the real canonical DB: two straggler rows from an older merge era still carry the client's original directories (invisible-but-truthful). One post-merge run of
amico fleet shard-rehome --client-home /Users/aaron --applyon the hub will pick them up.
Important
Problem — When a client machine's local chat-DB shard is folded into the canonical hub DB, the re-home step rewrites session directories with a doubled path segment. The 2026-10-01 merge of the macbook shard produced 80 sessions under a doubled armonia segment (armoniaa) and one under a doubled harmoniqs segment (harmoniqsoniqs) — directories that do not exist on the hub. The sessions merge successfully but become invisible to every panel listing, which filters by project directory. The 81 rows were repaired by hand the same day using the archived shard (canonical backup taken before repair).
Approach — Express the re-home as an explicit, tested home-prefix substitution, and validate that the rewritten directory exists on the hub filesystem before writing it; fall back to the shard's original directory when it does not. An invisible-but-truthful row beats an invisible-and-wrong one.
Scope — in: the shard-merge re-home path and its directory mapping. out: the remote census reachability fix (#1559, landed), the cadence units (#1561).
Acceptance Criteria
Prior Art
Source
Evidence and pre-repair backup from 2026-10-01 (81 rows repaired, quick_check ok); session ledger
session-20261001-harness-picker-fleet-recovery.Notes
The doubling appeared across two different home prefixes, which points at a systematic prefix substitution rather than a typo — likely one substitution applied to a path that already carried the replacement's tail.