Lane feed mirrors are the authoritative recovery source for FLEET_FEED.md wipes

Lane feed mirrors are the authoritative recovery source for FLEET_FEED.md wipes

The rule

When the authoritative fleet feed is truncated, corrupted, or shrinks unexpectedly, the canonical recovery path is fleet/fast_sync/<lane>/FEED.md mirrors, NOT:

• imac / peer-host SSH mirrors (have been silently stale since 2026-04-13)
• tmp/ reconstructed archives (out of date by days)
• lane *_FEED.md files under ~/Desktop/<lane>/<LANE>_FEED.md (stale since 2026-04-12)

The lane fast_sync FEED.md files receive every managed-feed append AS IT HAPPENS and survive catastrophic events on the top-level authoritative log because they live at different paths under different sync contracts. As of 2026-05-03, the authoritative log itself lives outside iCloud at ~/Library/Application Support/fleet/FLEET_FEED.md; ~/Desktop/FLEET_FEED.md is a compatibility symlink to that local file.

Why this doctrine exists

On 2026-04-18T10:34Z, FLEET_FEED.md was truncated to 0 bytes. STRAT spent minutes checking wrong recovery sources (imac SSH, lane feeds at Desktop paths, tmp archives — all stale by 2-5 days) before Chad pointed at the fast_sync lane mirrors via iCloud Drive screenshot. Recovery via lane mirrors produced 8,993 lines of preserved content covering yesterday + today.

The recovery path existed all along. The feed-append script's record_touched_path logic writes to both FLEET_FEED.md AND the lane fast_sync feeds on every append. This dual-write is the mirror mechanism — but STRAT didn't make the connection until prompted.

Prior evidence (/tmp/FLEET_FEED_wiped_backup_20260416T185753.md) shows this same wipe class occurred on 2026-04-16 and was recovered via reconstruction. The recovery tactic was institutional knowledge but never codified as doctrine, so STRAT had to re-discover it under time pressure.

Correct behavior

When the authoritative fleet feed is wiped:

1. Do not reach for imac SSH mirror first. It has been silently out of sync since at least 2026-04-13 (confirmed 5-day stale on 2026-04-18).

2. Do reach for fleet/fast_sync/<lane>/FEED.md files. These are live mirrors of every actionable write.

3. Run the reconstruction script (FLT-0053 when shipped): concatenate all lane fast_sync FEED.md files, dedupe by post header, sort by timestamp, write to FLEET_FEED.md.

4. Integrate the detection into shepherd cron (FLT-0054 when shipped): every fire does a line-count parity check and auto-reconstructs if >50% shrinkage or 0 bytes detected.

5. Preserve the write-site guards (FLT-0052 when shipped): feed-append refuses empty-overwrites and maintains per-append .bak rotation.

Canonical paths

Primary authoritative log (as of 2026-05-03 - FLT-1324):
  /Users/chadbarlow/Library/Application Support/fleet/FLEET_FEED.md

Legacy compatibility path:
  ~/Desktop/FLEET_FEED.md -> /Users/chadbarlow/Library/Application Support/fleet/FLEET_FEED.md

Recovery source of truth:
  ~/Desktop/fleet/fast_sync/<lane>/FEED.md
  /Users/chadbarlow/Library/Mobile Documents/com~apple~CloudDocs/camberzero_sync_assets/fleet/fast_sync/<lane>/FEED.md

Lanes:
  camber, heartwood, orbit, ora

Escalation

If lane fast_sync feeds are ALSO wiped simultaneously, the next-best source is iCloud web version history (icloud.com → Drive → Browse All Versions). This path requires human intervention (Chad in browser) and is NOT automatable. It's the last-resort recovery.

Key files

• /Users/chadbarlow/Desktop/fleet/scripts/feed-append — the write path that maintains both main feed and lane mirrors
• /Users/chadbarlow/Desktop/fleet/scripts/feed-reconstruct — the recovery tool
• fleet/fast_sync/<lane>/FEED.md — the recovery source-of-truth

Forbidden patterns

• Treating imac SSH mirror as a recovery source without verifying mtime first
• Manually reconstructing via memory when lane mirrors exist on disk
• Deleting lane fast_sync FEED.md files "to clean up" — they are the backup, not temporary files