fix(desktop): exclude archived agents from nest, order regeneration

[wpfleger96]

The managed "Active Agents" table in ~/.buzz/AGENTS.md was rendered from every managed-agent record with no filtering, so archived duplicate instances kept appearing under the active relay's header. This scopes the roster to identity-active agents and makes regeneration safe under concurrency.

Roster filter: identity-archive only

render_dynamic_section now drops only records whose pubkey is present in the relay's kind:13535 archive snapshot. Local records can't tell they're archived — they all carry is_active: true (that flag is a definition-archive, not an identity-archive), so archive truth lives only relay-side. The read fails open: an unreachable relay yields an empty set and hides no one.

There is deliberately no relay-scope filter. relay_url is a legacy creation-era field that effective_agent_relay_url() ignores — every agent is eligible on every community, and snapshot-imported records store relay_url: "" by design. Filtering on it would hide valid, runnable agents after a workspace switch or import. Foreign-relay relic records leave the table via record deletion, not code.

Regeneration on archive / unarchive

archive_identity and unarchive_identity submitted the relay event and returned without refreshing AGENTS.md, unlike the ~20 other mutation sites that call try_regenerate_nest. A just-archived agent therefore lingered on the roster until an unrelated edit or the next launch. Both commands now trigger a regeneration after a successful submit.

Regeneration is bound through a NestRegenTrigger trait rather than constructing the try_regenerate_nest callback at the Tauri-command delegation site. The command cores take regen: &impl NestRegenTrigger and own the || regen.trigger() binding; the thin wrappers only pass &app (whose impl calls try_regenerate_nest). This puts the regen wiring inside the unit-tested core — a CountingRegen double proves each core fires exactly one regeneration — instead of an untestable seam where a wrapper could silently lose the refresh while the suite stayed green. The regen races the relay's kind:13535 snapshot update, so it's best-effort and fail-open — a stale render self-heals on the next cycle.

Ordered regeneration

try_regenerate_nest previously spawned unconstrained tasks that each snapshotted state, awaited two relay requests, then wrote — so a slow pre-edit generation could overwrite a newer one. Boot made this deterministic: the boot regen races the apply_workspace regen, and the fallback-relay render could finish last.

NestRegenGate fixes this with a single highest_requested watermark. A monotonic generation is claimed synchronously at request time (encoding call order) and advances the watermark under one lock; the spawned task carries its generation and, at commit, reads the watermark under that same lock — the compare-and-write is atomic with no await held across it. A generation whose number is below the current watermark drops its result instead of rolling the file back.

Gating on highest-requested rather than highest-written is the load-bearing choice: if a newer generation is requested but then fails its relay reads, an older in-flight generation must not publish its now-obsolete roster. Behavior delta: once a newer regeneration has been requested, no older generation will ever write; if that newer generation fails, the file is left as-is and self-heals on the next trigger rather than regressing to a stale snapshot. This is an ordered, latest-request-wins gate — not a work coalescer: superseded generations still perform their relay reads and drop the result at commit time.

The gate's commit lock is acquired with a poison-to-io::Error mapping rather than expect(), so a poisoned lock degrades to the same warn-and-continue path as any other commit failure instead of panicking the desktop process (a best-effort housekeeping write must never take down the app).

One relay target per regeneration

A regeneration read the workspace relay override three times — the NIP-11 signer in fetch_relay_self, the snapshot query in query_relay, and the rendered footer — so a workspace switch mid-flight could pair one relay's advertised signer with another relay's snapshot, fail open, and render archived agents as active. capture_relay_target now resolves the effective relay (WebSocket + HTTP API base) once, before any network work, and fetch_archived_pubkeys_at threads that single target through both the NIP-11 fetch and the /query; the footer renders the same target. Signer, snapshot, and footer always belong to one relay.

Monotonic archival snapshot publishing

publish_nipia_archival_list stamped its kind:13535 snapshot with a whole-second created_at. A rapid archive→unarchive within the same second produced two events whose NIP-16 replaceable-event tie-break (higher event id wins) could strand the older, stale archive state as canonical. Publishing now uses a bounded retry that re-reads current archive state and rebuilds the snapshot each attempt, so the published list reflects the latest intended state rather than a fixed same-second race loser. After the attempt budget (8) is exhausted the publisher bail!s; the sole caller treats that as a warn! side effect and continues, matching the surrounding best-effort submit path.

Test-file split

The renderer, upsert_managed_section, and the regeneration-gate tests moved to nest/render_tests.rs so each test file stays under the repository's 1000-line ratchet.

[themiguelamador]

I found two correctness/reliability issues that should be addressed before merge:

1. archive_identity and unarchive_identity submit the state-changing event but never schedule nest regeneration. The new archived-agent filtering therefore does not update AGENTS.md after the actual archive/unarchive actions; it can remain stale until an unrelated agent/team edit or application restart. The repair branch schedules the existing best-effort regeneration after each successful submission.
2. NestRegenGate::commit introduces a production expect() on the mutex. Besides violating this repository's no-new-expect() production rule, a poisoned best-effort regeneration lock would panic the desktop process rather than report a regeneration error. The repair branch converts poisoning into io::Error and adds a regression test.

Verified repair: 47 nest tests; all 7 identity-archive tests (including the relay-switch race); strict Tauri Clippy with -D warnings; Rust formatting; desktop file-size gate.

Fix commit: https://github.com/Complear/buzz/commit/3d644ae00
Branch: https://github.com/Complear/buzz/tree/review/pr-5905-fix

[wesbillman]

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

The archive snapshot trust checks, one-relay capture, archive/unarchive trigger wiring, and poison handling look disciplined, but the new regeneration gate still permits the stale rollback it claims to prevent.

regenerate_nest_context snapshots personas and managed agents before awaiting the relay (desktop/src-tauri/src/managed_agents/nest.rs:727-753). NestRegenGate::commit, however, compares an old task only against last_written, which advances only after a newer generation successfully writes (nest.rs:683-720). This schedule therefore remains possible:

1. gen1 snapshots pre-edit state;
2. an edit requests gen2, which snapshots post-edit state;
3. gen2 fails during relay work or file publication;
4. gen1 finishes, sees last_written == 0, and publishes the obsolete pre-edit roster.

The current regressions cover only the easier case where gen2 successfully commits before gen1 (nest/render_tests.rs:513-579). A newer failed request must still permanently supersede older snapshots for publication purposes.

Please serialize request claiming and publication against one highest-requested watermark (or use an equivalent protocol), so once gen2 is requested gen1 can never publish, even if gen2 fails. A separate atomic watermark check is not sufficient by itself: a new claim can race between the old task’s eligibility check and its synchronous file write. Add deterministic coverage for both a newer-request failure and a claim arriving at the old commit cutover.

I verified this against exact head 5bedb05f57f0b14af99f6a1241a712da1985c595; git diff --check is clean. GitHub had 15 successful checks, 7 skipped, and Desktop Smoke E2E (3) still running at my snapshot. I did not duplicate CI-equivalent suites locally. A focused Tauri test attempt could not execute because the checkout lacks the required sidecar desktop/src-tauri/binaries/buzz-acp-aarch64-apple-darwin; CI's Desktop Core coverage is the broad test evidence here.

[wesbillman]

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

Consolidated Royal Court follow-up on the same exact head 5bedb05f57f0b14af99f6a1241a712da1985c595: a second blocker arrived after the initial review.

Blocking: rapid archive state changes can leave kind 13535 stale.

publish_nipia_archival_list builds the relay-signed snapshot with the default whole-second timestamp and calls replace_addressable_event (crates/buzz-relay/src/handlers/side_effects.rs:3119-3145). That replacement path rejects a same-second event unless its random event ID sorts lower than the current one (crates/buzz-db/src/lib.rs:4821-4827, 4874-4888). Therefore a rapid archive then unarchive can update canonical archive state successfully but reject the second snapshot, leaving the archived identity in the authoritative 13535 event until some later mutation happens to publish a winning/newer snapshot. The neighboring DM-visibility snapshot already avoids this exact failure by forcing created_at strictly beyond the prior snapshot (side_effects.rs:3196-3225).

A read-previous / previous + 1 timestamp alone is not concurrency-safe: two publishers can read the same predecessor, build different snapshots, and the transaction's random-ID tie-break can preserve the older canonical view. Please make publication converge from canonical archive state under concurrent writers, for example with a bounded retry that rebuilds after a rejected replacement, or move snapshot construction/publication under an atomic serialization boundary. Add deterministic tests for:

1. archive then unarchive within one second; and
2. concurrent snapshot publishers where an older canonical view wins the first same-timestamp replacement race, proving the final stored snapshot is rebuilt from current archive state.

This is independent of the NestRegenGate stale-publication blocker in my initial review. Both need resolution.

[wesbillman]

Additional blocker confirmed on exact head 5bedb05f5:

publish_nipia_archival_list signs kind 13535 at whole-second now, but replace_addressable_event applies NIP-16 ordering: same-second replacements only win when their random event ID sorts lower. A rapid archive → unarchive can therefore reject the final empty snapshot and leave clients on the stale archived set indefinitely. The adjacent DM visibility snapshot already forces created_at past the previous head for this reason.

There is also a concurrency wrinkle: only adding previous + 1 still permits two publishers to race after reading the same head. This repair retries from canonical archive state when replacement loses or the canonical set changes before dispatch:

• Commit: 1ad28a4
• Branch: https://github.com/block/buzz/tree/review/pr-5905-archival-snapshot-fix

Validation at 1ad28a44b9950a78f6c6ad2a1fcda19a0379389c: all 7 identity-archive tests pass, including the focused rapid archive/unarchive regression; cargo clippy -p buzz-relay --all-targets -- -D warnings; formatting and diff checks pass. The unrelated pre-push mobile suite hit existing settings_profile_header_test.dart:89 (progressive-animated-avatar-animation-ready absent); relay validation was green.

[wesbillman]

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

Consolidated Royal Court re-review at exact head cfa1e6c77cd662f82ab8959107bb016e8b98e91f: no remaining blocking findings.

The current head resolves both prior correctness blockers:

• NestRegenGate advances the highest-requested generation synchronously and holds one mutex across eligibility checking and atomic file replacement. An older snapshot therefore cannot publish after a newer request, even if that newer request fails, and a new claim cannot slip into the compare/write cutover (desktop/src-tauri/src/managed_agents/nest.rs:666-777). Deterministic regressions cover both schedules (nest/render_tests.rs:583-668).
• Kind 13535 publication advances beyond the current head, rebuilds from canonical archive state after rejected replacements, and verifies post-insert state before dispatch. This closes both rapid archive→unarchive and concurrent stale-publisher races (crates/buzz-relay/src/handlers/side_effects.rs:3174-3270).

The surrounding contracts also hold: roster filtering trusts only verified snapshots from the NIP-11-advertised relay signer; signer, query, and rendered footer share one captured relay target; read failures fail open rather than hiding agents; and archive/unarchive trigger regeneration only after relay acceptance (desktop/src-tauri/src/commands/identity_archive.rs:175-285,393-447; desktop/src-tauri/src/managed_agents/nest.rs:783-835).

All four Court reviews converged on clear/ship. I independently fetched the PR ref and confirmed the GitHub API, remote ref, and local review ref all equal the SHA above. git diff --check origin/main...refs/review/pr-5905-head is clean. All current applicable GitHub checks are successful; skipped checks are path/publish jobs. I did not duplicate CI-equivalent suites locally.

The outstanding CHANGES_REQUESTED state comes from reviews against superseded heads; I am leaving a non-approving comment because approval was not explicitly requested.