fix(desktop): repair dropped team membership links at boot and on edit

[wpfleger96]

Two membership-propagation defects let an agent team silently lose members — both observed live on Will's store (Sietch Tabr), not hypothetical.

Stale persona_ids dropped on save. Team records written before persona ids were namespaced hold bare slugs (thufir) instead of the namespaced id (sietch-tabr:thufir). Nothing rewrites them, and the interactive save path (ensure_persona_ids_are_active) drops any id it cannot resolve — so the next in-app save shrinks the team. This nuked four of five Sietch Tabr members.

team_id drifts from team membership. Team instructions are injected at spawn by matching record.team_id (spawn_snapshot::effective_team_instructions), so an instance's binding must track its persona's membership. It drifts two ways: adding a persona to a team leaves the persona's already-running instances at team_id: null (a member in the roster but not in behavior — seen twice, Gurney and Hayt), and removing a persona while keeping its agents leaves the kept instance bound to a team that no longer lists it (still drawing that team's instructions at spawn).

Fix

A boot migration (migration/team_membership.rs) heals existing stores in one pass over teams.json + managed-agents.json:

• Rewrite stale ids. A stale id is one no definition slug resolves. Its target is the definition whose source_team_persona_slug equals the bare slug, scoped to the team's source team (via source_dir for a directory-backed team, or the unique source_team among resolvable members for a detached one). Rewrite only when exactly one candidate matches; zero or many leave the id in place — strictly safer than the save path, which drops it.
• Repair team_id. Backfill an instance whose persona is a team member but whose own binding is unset, and heal a stale binding whose team no longer lists the persona (re-point when exactly one other team claims it, otherwise unbind). Both directions gate on single-team evidence — a persona spanning several teams has none (JSON team order is not ownership), so it is left as-is and logged. A binding whose team still lists the persona is authoritative and never touched.

Runs BEFORE detach_directory_backed_teams (so a not-yet-detached team can still be scoped by its source_dir) and before any UI save can drop an id. Rewrite-or-leave converges to a fixed point, so a second boot is a no-op; the store is backed up once before either write.

The edit path (commands/teams.rs) propagates a membership change to live instances immediately, without waiting for the next boot, scoped to the delta between the pre-edit and post-edit rosters:

• Added personas (on the team now, not before) backfill team_id on their unbound instances. An explicit add is legitimate binding evidence even for a persona shared across teams — unlike the order-blind boot case.
• Removed personas (on the team before, not now) clear team_id on instances bound to this team (bindings to other teams are untouched), so a "keep agents" removal stops feeding a kept instance the old team's instructions.
• Delta-scoping keeps a metadata-only edit inert: with no roster change, no instance is re-pointed — a shared unbound persona is never silently bound to whichever team was edited last.

Propagation is best-effort after the authoritative save_teams (mirroring retain_team_pending): the team already exists on disk, and boot repair is the designed retry for a stale/unset binding, so a secondary managed-agents.json write failure no longer fails a command whose team write succeeded — which would otherwise let a UI retry mint a duplicate team.

[themiguelamador]

I found four remaining correctness issues in the membership propagation path:

1. update_team backfills against the entire final roster, rather than the membership delta. A metadata-only edit can therefore bind every unbound instance of a persona shared by several teams to whichever team happened to be edited, contradicting the PR's own rule that JSON/team order is not ownership evidence.
2. The inverse transition is not propagated. Removing a persona and choosing the UI's “Keep agents” path leaves those instances' team_id pointing at the old team, so they continue receiving instructions for a team they no longer belong to.
3. create_team/update_team commit teams.json and then propagate ? from a second, fallible managed-agents.json write. If that secondary write fails, the command reports failure even though its authoritative mutation already succeeded; retrying a create can produce a duplicate team. The secondary propagation must be best-effort (with boot repair as its retry path), or both stores need a real transaction.
4. Successful create/update operations still do not schedule nest regeneration, leaving generated team/member context stale until an unrelated regeneration trigger or restart.

The repair branch makes propagation transition-aware, detaches removed-but-kept agents, adds boot repair for stale bindings, preserves an already-committed command result if the secondary store fails, and regenerates the nest after successful edits.

Verified: 21 team command/storage tests; 14 membership-migration tests; 7 team-event reconciliation tests plus the stale-inbound ordering regression; strict Tauri Clippy with -D warnings; Rust formatting; desktop file-size gate.

Fix commit: https://github.com/Complear/buzz/commit/c0335e320
Branch: https://github.com/Complear/buzz/tree/review/pr-5904-fix

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Requesting changes on exact head 4469210b5deb07109a92f2b02b87496887bc5928 for two remaining correctness gaps:

1. Inbound team edits still leave live instance bindings stale. The local create_team/update_team paths apply the prior-to-current roster delta to ManagedAgentRecord.team_id, but the kind:30176 ingress in commands/personas/inbound.rs only merges the team and saves teams.json (169-173; merge at 444-461). A team edit arriving from another device can therefore add a persona without binding its existing instances, or remove a persona while those instances remain bound and continue receiving the old team's instructions until restart. Capture the prior roster and apply the same add/backfill and remove/detach semantics under the existing store lock, with inbound regressions for both transitions.

2. A repair failure can destroy the evidence required for a later repair. repair_team_membership logs and swallows every error (migration/team_membership.rs:39-49), then boot unconditionally runs detach_directory_backed_teams (migration.rs:188-189). For a stale bare slug shared by definitions from multiple source teams, source_dir is the evidence that makes the rewrite unambiguous. If backup or write fails, detachment clears that evidence; the next boot may only see ambiguous global candidates and leave the stale ID unresolved, allowing the original membership-loss path to recur. Gate detachment on successful repair (at minimum skip it for that boot) and add an orchestration regression proving failure preserves source_dir for a successful retry.

There is also a recovery-contract mismatch worth fixing with the second item: team_membership.rs:84-88 says both pristine backups are captured before either live write, but the implementation writes teams.json before creating the managed-agents backup (89-107). Create every required backup before the first live-store write, or narrow the stated recovery guarantee.

The local command delta logic, conservative multi-team ambiguity handling, stale-inbound retention precedence, and fatal startup reconcile barrier otherwise look disciplined. GitHub's exact-head checks were all successful when inspected (24 successful, Web skipped); I did not duplicate CI-equivalent suites locally.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Approved exact head 48db98a41bdaebcb58284ae9411666f1fc6ff1eb after consolidated Royal Court review.

The corrective commits close the prior blockers:

• inbound kind:30176 edits now propagate the prior-to-current roster delta to live instance bindings under the existing store lock;
• repair failure skips directory-backed detachment, preserving source_dir as retry evidence;
• every required pristine backup is created before either live store is rewritten;
• local and inbound propagation are delta-scoped and secondary agent-store writes remain best-effort after the authoritative team write;
• workspace apply awaits the fatal team-event retention barrier before inbound replay can expose a stale relay head.

The boot repair remains conservative for ambiguous multi-team ownership, and generated nest context does not render team membership or instructions, so no team-triggered nest regeneration is required.

All applicable exact-head checks passed. I also verified Rust formatting and git diff --check locally. A focused local Rust test attempt could not start because the review checkout intentionally lacks the generated desktop/src-tauri/binaries/buzz-acp-aarch64-apple-darwin resource; I relied on the passing exact-head Desktop Core, Rust Lint, macOS/Windows build, smoke, and integration CI jobs rather than fabricating a binary into the review tree.