[FEATURE] Auto-infer blockedBy edges from interface changes + an in-graph merge/test gate for Agent Teams

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Two things are still manual:

Dependency edges are human-declared. Today the lead must know that task B depends on task A's interface and call addBlockedBy by hand. When two teammates independently edit shared code, a semantic dependency (B calls a symbol A renames) is invisible until merge. Git merges cleanly (different lines), build breaks.
Verification is a separate manual step. /ultrareview is a command you invoke; it isn't an automatic per-task gate wired into the team task graph. Nothing forces "merge → build/test → unblock dependents (or loop back to a fix task)" to happen automatically as tasks complete.

Proposed Solution

Two additions on top of the existing addBlockedBy + verification machinery:

Interface-impact auto-edge inference. Optional task fields modifiesInterface { module, surface[] } and consumesInterface [{ module, surface[] }]. On task ingest, the lead cross-references them (optionally plus a quick callsite scan) and auto-creates addBlockedBy edges. A hidden semantic dependency becomes an explicit, already-supported block — no new blocking primitive, just the inference that creates the edge.

In-graph merge gate. Optional mergeGate { build, test, onFailure } on a task: when the task is ready, merge → run build/test → green completes it and unblocks dependents; red routes to a fix task (carrying the failure + callsite list) instead of completing. This is /ultrareview-style verification promoted from a manual command to an automatic, per-task, graph-native gate. Because the consumer is blockedBy the modifier, it's rebased onto the verified integration branch before its own gate runs, so incompatibility surfaces in the right place.

Throughline / motivation

In #59019 and #47548 the subagents reported success while having silently modified the parent worktree — the harness trusted self-reports over verified outcomes. The same principle applies at the merge layer: outcomes should be verified, not trusted. Until those isolation bugs are fixed, an automatic merge gate also acts as a backstop when isolation silently fails.

Why not just prompt it / use the command

A single dynamic workflow can encode merge-then-verify because one orchestrator owns every subagent. The gap is across independently-claimed team tasks, where no orchestrator holds the merge order, and where /ultrareview must be remembered and invoked. Promoting both the dependency inference and the gate into declarative task fields makes the guarantee hold regardless of which member does the work and survives compaction (it lives in the persisted task list).

Alternative Solutions

Status quo (manual addBlockedBy + manual /ultrareview) — works when the human spots the dependency and remembers to review; the failure mode is precisely when they don't.
Full static dependency analysis — too heavy/language-specific; the impact pass is intentionally a heuristic that raises a gate, not a safety proof.
Force gates on all tasks — wasteful for genuinely independent parallel work. Everything here is opt-in via the new fields.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

Two-task list: A renames an exported symbol; B calls the old name in non-overlapping lines, no manual blockedBy declared. Today → clean merge, failing build, unless the human invokes /ultrareview. With this → impact pass infers the edge, B blocks until A merges+verifies, B rebases, B's gate fails on the stale call, fix task updates it, final state green — automatically.

Additional Context

/ultrareview already does independent, pre-merge, multi-agent verification and has caught the canonical "one-line auth change that silently breaks login" case.
Agent Teams addBlockedBy already supports dependency-ordered task chains (see the feature-dev migration in #24932, which also has a reviewer phase with git-diff access).
Plan-approval mode already provides a pre-implementation gate ("only approve plans with test coverage").
Worktree isolation is opt-in and defers conflicts to merge time rather than eliminating them; isolation also isn't airtight today (#59019 file-write spillage, #47548 branch hijack, #28175 teams not getting their own worktree).