Cross-surface fleet visibility: orphan-work detection and automatic discovery

Cross-surface fleet visibility: orphan-work detection and automatic discovery

Problem

The fleet's feed-driven coordination model assumes every seat registers work via feed-append. This assumption breaks when operators run on surfaces that lack fleet infrastructure — GPT-5.4 chat, Gemini CLI on secondary machines, Claude Desktop subagents doing mass-dispatch. These sessions create branches, commit code, and touch shared ticket namespaces without feed registration.

Evidence from 2026-04-16 alone:

• CMB-0105 collision (20:04Z–20:24Z): two Claude-CLI seats filed the same ticket number via subagent mass-dispatch pattern.
• CMB-0122 collision (22:17Z–22:30Z): a Codex GPT-5.4 operator adopted a ticket number already dispatched by a Claude-CLI seat, committed on codex/cmb-0122-matcher-determinism, and posted DONE — all invisible to the dispatching seat until after the fact.
• Bill-cover reviewer (~22:35Z): a Codex GPT-5.4 operator working claude/cmb-0115-deepg... branch touched Carter/Fieldstone/Jayco reconciliation scope overlapping CMB-0109 + CMB-0110, with zero feed registration.

ORA-2026-0012 (ticket allocation protocol) was amended to cover cross-surface seats, but that's POLICY. Without an enforcement/detection mechanism, the policy is aspirational.

Current status (2026-05-03)

STATUS: prospective design. This doctrine describes the intended cross-surface orphan-work detector shape, not a deployed operating loop. FLT-0016 remains the implementation gate. No Layer 1 detector that scans git branches/commits for ticket IDs and posts EXTERNAL_DISCOVERED items is currently running.

Do not confuse this design with the existing ~/Desktop/fleet/scripts/orphan-sweep helper. The current helper scans file-hygiene orphan surfaces; it is not the cross-surface branch/commit detector described below.

Prospective design: three-layer hybrid

Layer 1 — Orphan-work detector (cron sweep, retroactive)

After FLT-0016 implementation, a cron job on the fleet's primary machine (MacBook Air) should run every 5 minutes:

1. Scan all 4 repos + worktrees for branches and recent commits containing ticket-shaped identifiers:

• Branch regex: (cmb|hwd|flt|ora|redline|tnf)-0*(\d{3,4}) (case-insensitive)
• Commit message regex (last 30 min of commits): same pattern
• Worktree directory names: same pattern

2. Diff findings against fleet-active-queue output to identify orphans — ticket IDs referenced in git state but absent from the active queue (or present but owned by a different seat than the branch author).

3. Post discoveries to FLEET_FEED.md via feed-append: `` KIND: INFORMATIONAL (not ACTIONABLE — discovery is signal, not a claim) Subject: ORPHAN_DETECTED — <ITEM> found on branch <branch> in <repo>, not in active queue Body includes: branch name, repo, last commit SHA + timestamp, author if available ``

4. Dedup: maintain a small state file (~/.local/state/orphan-sweep/seen.json) mapping repo:branch → last_posted_sha. Only post when a new orphan appears or an existing orphan has new commits.

Layer 2 — feed-append --discover mode (programmatic registration)

Implement a future feed-append helper --discover flag:

feed-append --kind actionable --discover <branch-name> --repo <repo-path> \
  /path/to/FLEET_FEED.md ORPHAN-DETECTOR "EXTERNAL_DISCOVERED: CMB-0122 on codex/cmb-0122-matcher-determinism"

This parses the ticket ID from the branch name and files:

ITEM: CMB-0122
LANE: CAMBER
STATE: EXTERNAL_DISCOVERED
OWNER: UNKNOWN_EXTERNAL
QUEUE: CAMBER
PRIORITY: NORMAL

The Layer 1 cron would call Layer 2 for each orphan it finds. Human or STRAT can then triage EXTERNAL_DISCOVERED items — either link them to a known session or investigate the scope overlap.

Layer 3 — Commit-trailer encouragement (soft signal, not blocking)

Add a prepare-commit-msg hook to all 4 repos that inserts a Fleet-Ticket: <parsed-from-branch> trailer into the commit message template when the branch name contains a ticket ID. This is:

• Not enforced via pre-commit rejection (too brittle for cross-surface operators who may not have hooks installed).
• Used as additional signal by Layer 1 — the scanner can also grep commit trailers for ticket IDs that don't appear in the branch name.

What this does NOT include (and why)

Coverage estimates per surface

Aggregate fleet coverage estimate: ~80% (weighted by session volume).

Honest blind-spot list

1. Pre-commit WIP: work that hasn't been committed or branched yet is invisible. The detector only sees git state. 2. Pure-DB work: Supabase SQL changes via MCP without corresponding repo work leave no git trace. 3. Non-standard branch naming: branches like codex/reconciliation-matcher-intelligence-gap-spec contain no parseable ticket ID. 4. Unreachable machines: if the fleet expands beyond Air, the cron can only scan locally-accessible repos. Mitigation: SSH-based remote scan (see future work). 5. Ephemeral sessions: investigation-only sessions that never create branches or commits are invisible. These are low-risk (read-only work doesn't collide). 6. Worktree-only work: if an operator works in a worktree without committing, only the worktree directory name is scannable (already covered by the regex).

Implementation scope (Codex handoff)

Ticket: FLT-0016 — Implement orphan-work detector cron + feed-append --discover

Deliverables: 1. ~/Desktop/fleet/scripts/orphan-sweep or a clearly named successor — shell script implementing Layer 1 scan logic. If reusing the existing helper name, first reconcile the current file-hygiene contract so two unrelated tools do not share one name. 2. Enhancement to ~/Desktop/fleet/scripts/feed-append — add --discover flag (Layer 2) 3. ~/Desktop/fleet/scripts/prepare-commit-msg-hook — installable hook for Layer 3 (UNIMPLEMENTED — this script was never built; Layer 3 is design-only) 4. State file at ~/.local/state/orphan-sweep/seen.json 5. CronCreate entry: every 5 minutes, runs orphan-sweep (subject to ORA-2026-0010 pre-arm recon — the detector reads git state but does NOT write to repos)

Acceptance criteria:

• Drop a branch codex/cmb-9999-test-orphan in camber repo → within 5 minutes, FLEET_FEED.md has an ORPHAN_DETECTED or EXTERNAL_DISCOVERED post for CMB-9999
• Repeat detection of the same branch does NOT produce duplicate posts (dedup works)
• fleet-active-queue shows EXTERNAL_DISCOVERED items
• feed-append --discover codex/cmb-9999-test-orphan --repo ~/gh/camber manually produces the correct feed entry

Out of scope for FLT-0016:

• Auto-resolving EXTERNAL_DISCOVERED items (requires STRAT triage)
• Remote machine scanning via SSH (future enhancement)
• Blocking enforcement (this is detection, not prevention)
• Modifying any operator surface's boot sequence

Promotion gates

• M1 → M2: FLT-0016 implemented and acceptance criteria met. Detector runs for 48 hours catching at least one real orphan.
• M2 → M3: One full week of operation with zero undetected cross-surface collisions (all caught by detector before human discovery).
• M3 → M4: Remote-scan extension covers secondary fleet machines. fleet-active-queue natively distinguishes EXTERNAL_DISCOVERED from CLAIMED items in its output.

Current operational maturity remains M1 until FLT-0016 ships and the 48-hour detector proof exists.

Enforcement hooks

• This doctrine: ~/gh/ora/docs/entries/doctrines/ORA-2026-0022_cross-surface-fleet-visibility.md
• Memory: (pending — add after ratification)
• Canonical bundle: §15 Standing Directive — add as bullet: "Orphan-work detector runs on primary machine; EXTERNAL_DISCOVERED items appear in fleet-active-queue and require STRAT triage."
• Related: ORA-2026-0012 (ticket allocation), ORA-2026-0016 (fleet telemetry), ORA-2026-0019 (wake-work pairing)