fix(agent-org): address PR review correctness and performance findings - #419

Summary

Follow-up to #373 and the Agent Org work originally tracked in #272.

This PR addresses the correctness, performance, persistence, and test-fidelity findings from both review rounds on #373:

• First review
• Second review

The product model remains unchanged:

• Coordinators and workers reason about the work.
• Rust validates and durably commits state transitions.
• The scheduler performs budgeted Wake dispatch.
• The frontend projects persisted facts.

This follow-up is intentionally limited to the two review rounds and the minimum integration dependencies required to make those fixes correct, independently testable, and production-compatible.

flowchart LR
    MODEL["Coordinator or worker proposes an action"]
    TOOL["Typed tool boundary"]
    TX["Short SQLite transaction"]
    WAKE["Budgeted Wake dispatch"]
    VIEW["Read-only compact Run View"]
    UI["Group Chat, Team Tasks, and Kanban"]

    MODEL --> TOOL --> TX --> WAKE
    TX --> VIEW --> UI

First review

Resolution matrix

Second review

Resolution matrix

Required integration dependency

The review fixes required one additional dispatch-time invariant:

Resulting invariants

1. Only a Running Run may mutate Tasks.
2. Ownerless means unassigned, not available for arbitrary Worker self-claim.
3. A normal Worker may mutate only its own assigned Task state.
4. Task mutation and its TaskAssigned or TaskCompleted outbox commit together.
5. Wake attempts are charged only after scheduler acceptance.
6. Rejected or coalesced Wake requests refund their reservation.
7. Wake rechecks Paused, Archived, missing, and terminal state before execution.
8. Plan Approval remains durable independently of transient Wake delivery.
9. Completion requires the Coordinator to observe the latest work revision.
10. Historical Group Chat remains available through keyset pagination after reload.
11. Task and Plan UI state comes from persisted structured outcomes, not attempted tool arguments.
12. A queued user message does not suppress recovery before actual dispatch.
13. One malformed or failing Run cannot stop recovery for unrelated Runs.

Verification

Clean-develop baselines

• Strict workspace Clippy remains blocked by seven orgtrack_core diagnostics reproduced on clean develop.
• agent_core --no-deps reports the same 45 clean-develop diagnostics.
• e2e-test --no-deps reports three diagnostics on this branch versus four on clean develop; this change introduces no additional diagnostic.
• Twenty-three specialization::external_import tests are filtered because the same nested non-reentrant lock_home deadlock reproduces on clean develop.
• The remaining rendered mention-menu scenario fails on this branch and clean develop with the same assertion. It is not counted as passing and is not attributed to this follow-up.

Scope boundary

This PR contains only:

• findings explicitly raised in the first review;
• findings explicitly raised in the second review;
• minimum integration dependencies required for those fixes;
• directly corresponding tests;
• English backend and frontend audit reports.

It intentionally does not include the later red-team expansion, the full Revision Event architecture, or post-completion Follow-up Runs.

Follow-up: post-completion conversation and Follow-up Runs

A separate feature PR will address the distinction between a long-lived Group Chat and an individual Agent Org Run.

The planned behavior is:

• The Root Coordinator Session remains the long-lived Group Chat.
• One Group Chat may contain multiple sequential Runs.
• Completed continues to mean that one round of work is finished; it does not permanently close the Group Chat.
• After completion, ordinary questions are answered by the Coordinator without reopening the old Run, writing its Inbox, waking old Workers, or mutating completed Tasks.
• Requests that require more work produce a structured Follow-up proposal.
• The user confirms before a new team Run starts, preventing accidental Token use.
• A Follow-up Run records continued_from_run_id, creates fresh Worker Sessions, Tasks, Inbox state, and Recovery Budget, and never changes the old terminal Run.
• Coordinator and Worker Turns receive explicit Run scope so an old Worker cannot resolve to a newer Run through the shared Root Session.
• Follow-up creation is atomic and idempotent; repeated clicks create only one Run.
• The UI will show a completed banner, Follow-up proposal card, Run timeline, active Run board, and historical Run selector.

This will be implemented separately, rather than expanding this review follow-up.

Follow-up: Revision Event architecture

A separate architecture series will replace high-frequency full Snapshot polling with ordered incremental synchronization.

The planned model is:

1. Canonical Run, Task, Inbox, Session, and Approval tables remain the source of truth.
2. Every durable mutation appends one small sequential Revision Event in the same SQLite transaction.
3. The frontend loads a compact Snapshot and then applies Events after that Snapshot revision.
4. Missing revisions are detected and replayed in order.
5. Duplicate delivery is harmless because reducers are idempotent.
6. Large Plan, TaskOutput, and message content remains in detail APIs rather than Event payloads.
7. Backpressure requests resynchronization instead of buffering without bounds.
8. Low-frequency Snapshot verification remains until the Event path proves stable.

Expected user-visible benefits:

• faster Task and approval updates;
• fewer temporary disagreements between Group Chat, member views, and Kanban;
• exact reconnect and restart recovery;
• less repeated transfer and parsing of unchanged data.

This work will land through separate Event-contract, replay/transport, frontend-store, and polling-reduction PRs.

Follow-up: red-team hardening

Additional red-team findings were intentionally preserved outside this PR and will be reviewed in a separate dependent branch and PR.

The follow-up scope includes:

• explicit Superseded/Cancelled disposition and repair tools for permanently undeliverable or orphaned Inbox rows;
• additional Analyzer/Executor time-of-check/time-of-use validation;
• stronger recovery-reason fingerprints and atomic Coordinator-notice accounting;
• legacy Inbox deduplication when multiple members share one AgentDefinition;
• repair and fail-closed handling for corrupt, cyclic, oversized, or ambiguous historical state;
• external Plan path, symlink, and startup-artifact validation;
• explicit org_run_id ownership for nested Turn Intents and multi-Run session chains;
• additional Run View cache eviction, tombstone, bootstrap timeout, and detail-cache limits;
• historical member-navigation, WebKit mention, and option-deduplication hardening;
• additional Task, graph, artifact, fan-in, fan-out, and per-Run resource boundaries;
• expanded production return-to-work and recovery E2E coverage.

These changes are not required to resolve the two #373 review rounds and are deliberately excluded here to keep this PR reviewable.

Audit reports

• docs/architecture-audit-2026-07-16/AgentOrgReviewSafetyAudit.md
• docs/frontend-ui-audit-2026-07-16/AgentOrgReviewSafetyAudit.md