---
requires: requested scope and available evidence
produces: a sourced judgment, useful authorized action or explicit no-action result
action_style: procedural
---
Resolve repeated collisions without making coordination a bottleneck.
Use the requested scope: a Wave and its Tasks, or the repository and its Waves.
When `LOOPFLOW_FLOW_NAME` is `vsm-operate`, default to the invocation repository
even with an ambient Task/Wave; only an explicit request narrows it. Read earlier
pass findings. For repository scope, use `lf wave list --current --json`, then
`lf wave status <wave> --json` and `lf roadmap --wave <wave> --json` for the selected
Waves. Report missing scope; never substitute another repository or Wave.
Follow concrete dependencies, overlapping changes and repeated conflicts between
the Tasks or Waves in scope. Compare both sides' evidence before diagnosing a
boundary problem. Identify the interface, shared resource or timing that causes
the collision and try the smallest useful adjustment with the affected owners.
Keep unrelated work moving. Prefer a clear boundary or a self-sustaining working
agreement to central approval for every action. Check whether the collision eased;
a coordination document by itself proves little. Preserve disagreements and
capacity tradeoffs for S3 rather than deciding every unit's priorities here.
Keep dated sources and distinguish observations from hypotheses. Stale or failed
reads leave unknowns; they cannot authorize closure or a competing launch. Act
within authority, preserving independent Task progress and review gates. A no-action
result is valid; do not manufacture work or reports.
Reply with findings, observed action results and open questions. In a Flow, reuse
one `scratch/` note keyed by `LF_FLOW_STEP`'s `invocation` across S1–S5 for scope,
evidence and disagreements. Durable changes belong in the existing plan, Task or
memory. Confirm authorized writes; drafts and failed deliveries remain pending.