[bug] Delegated runs leave repos on feature branches and with uncommitted edits — and subordinate_status reports neither

[serge-ivo]

Found while testing multi-subordinate delegation (#259/#271 now working — the Lead correctly
delegated to two subordinates concurrently and reported both run ids).

Repos are left in whatever state the last run stopped in

Live state across two subordinates of the same Lead, right now:

Agent	Branch	Working tree
FAS platform	main	dirty — M packages/backend/src/routes/logs.ts
FWS platform	fix/36-assistant-bubble-order	clean

Neither is a bug on its own. Together they show there is no notion of repo state between delegated
runs:

• FWS is parked on a feature branch. Run 9d88e49d fixed issue [Admin][UI] Overview dashboard #36, pushed
  fix/36-assistant-bubble-order, opened PR Voice: mute command only active during active recording — must work at all times (during TTS, agent processing, co-pilot chat) #153 — and left the checkout there. The next goal
  delegated to FWS ("fix bugs", "run the tests") will silently operate on that branch, not main.
  Nothing in the delegation path states, checks, or resets the branch.
• FAS has an orphaned edit. Run 71a6540d was told "Do NOT commit and do NOT push — leave the
  change in the working tree", and correctly left a real fix there (a missing lower bound on a
  limit query param). That was ~50 hours ago. It is still uncommitted, and nothing tracks it. Every
  later git status run rediscovers it and reports it as a novelty.

Why it matters for a supervisor

The Lead's status table reports "Last action" — the previous objective's summary. It does not
report branch or tree state, which for "can this agent safely take a new goal?" is the more
load-bearing fact. A supervisor delegating "fix the failing tests" to FWS today would get work done
on a merged feature branch, and nobody would notice until the PR looked strange.

The subordinates cannot warn about it either: the branch is not in their context (#255 gave them
repo ownership, not repo state).

Suggested shape

• Include branch + dirty/clean in subordinate_status, next to connectivity. It is one
  repo_git call the driver already has, and it is what determines whether a goal is safe to hand
  over.
• Decide a between-runs policy and state it: does a delegated run start from the repo's default
  branch, or from wherever it was left? Either is defensible; the current answer is "whatever the
  last run happened to do", which is not a policy.
• Surface uncommitted work as a real state, not something rediscovered by each git status. An
  edit a run was explicitly told to leave behind is a pending human decision — it belongs on the
  board, not only in the working tree.

Adjacent, worth deciding separately

Run 73ffc073 opened and merged its own PRs to main — #150, #151, #152 — unattended, then
reported "all open bug issues exhausted". Whether autonomous merge-to-main is wanted is a policy
call, not a defect, but right now it is available by default to any delegated goal phrased broadly
enough, and nothing in the supervisor view shows it happened.

[serge-ivo]

Fixed in b0b3a74 (CI + Deploy API Worker green; CLI 0.4.34 published with the runner half).

Judged the two halves separately, as you framed them.

1. Reporting — done

subordinate_status now carries a repo object next to connectivity:

"repo": {
  "name": "fws/platform",
  "branch": "fix/36-assistant-bubble-order",
  "dirty": true,
  "changedFiles": 1,
  "configuredBranch": null,
  "note": "This checkout is on branch `fix/36-assistant-bubble-order` rather than the trunk — a new goal will run on that branch unless you say otherwise; 1 uncommitted file left in the working tree by earlier work — it will NOT be discarded, and it may be a change somebody still wants.",
  "otherRepos": 0
}

Details that mattered:

• It reports repos[0] — the repo the coding driver actually takes. Reporting a different
  repo than the one delegation would use is worse than reporting none. otherRepos says how many
  were not looked at, so the number is never silently partial.
• Probed only where connectivity.canWork — the read goes over the same relay connectivity just
  said is down, so probing an unreachable subordinate buys a guaranteed timeout for a guaranteed
  null. Capped at 8, mirroring MAX_RELAY_PROBES.
• Absent when unknown, never guessed. No repo, no runner, or an older runner → the field is
  omitted. A fabricated "clean on main" is a fact a supervisor acts on.
• The trunk heuristic matters for your exact case. Local-path repos carry an empty branch
  column, which is FWS — so flagging only against a configured branch would have missed the bug
  you reported. With none configured, main/master is the assumed trunk; being wrong there costs
  a note, not an action.

One minimal runner change, and it is the only one: git status --short gains --branch (one
header line). Without it you can learn a tree is dirty but never which branch it is dirty on — the
exact half that let the FWS run park the checkout unnoticed. Additive: every existing consumer keeps
the file lines it always got, and it also means the Co-pilot's git_status now shows the branch. An
older runner sends no header and the cloud reports branch: null — unknown, never a guess.

2. Acting — deliberately does NOT reset, and that is the decision

Policy: a delegated run starts from wherever the repo was left, and is TOLD where that is.

Not an omission. Git cannot distinguish leftover junk from a fix somebody still wants — your FAS
example is a real fix — so an automatic checkout main / reset --hard would silently destroy
work, irreversibly, on a path a supervisor can trigger with nobody watching. Being on an unexpected
branch is visible and cheap to correct. The two errors are not close.

So instead:

• The Pilot reads the state at the start of a run and prepends it to its instructions, with an
  explicit Do NOT revert, stash, reset or discard anything you did not write yourself. If your objective needs a clean tree or a different branch, say so and stop rather than clearing it.
  It also lands in the session timeline.
• The tool description and the payload legend both tell a supervisor that repo is context,
  not a gate, and to never instruct an agent to clear a working tree it did not put there.
• Nothing refuses. Both conditions are frequently intended — you may well want the next goal to
  continue on that branch — so refusing would break delegation for a normal state.

3. Uncommitted work as a real state — on the board

The Pilot raises one board card per repo at the end of a run when it finds a dirty tree:
needs_human, titled "Uncommitted work in fws/platform", subtitled with the branch. Stable id, so
it updates rather than piles up, and it closes itself the moment a later run finds the tree
clean. That turns your FAS case from something every git status rediscovers as a novelty into one
card representing one pending human decision.

Left for you to decide separately

The 73ffc073 observation — a run opening and merging its own PRs to main unattended. Agreed that
is a policy call, not a defect, and I have not touched it. Worth its own issue: today it is
available by default to any goal phrased broadly enough, and the supervisor view still does not show
that it happened. The board card above is adjacent (it surfaces unfinished work) but says nothing
about work that got merged.

Tests

repo-state.test.ts — the porcelain parse (upstream, no upstream, ahead/behind suffix, detached
HEAD, "no commits yet", old-runner-no-header) and the note wording, including that it never emits a
branch claim from a null branch and that the dirty clause says outright the work will not be
discarded. supervision.test.ts — three new cases: the full FWS scenario end-to-end through the
relay, repo omitted rather than guessed, and no probe when the runner is unreachable.