# Scope guide

- State the user-visible outcome and the exact part of the system affected.
- Name prerequisites and neighboring work that change the boundary.
- Cite the current contract, code, or test that supports each existing-behavior claim.
- Distinguish verified current behavior from a proposal.
- Identify one observable success path and one meaningful failure or recovery path.
- Record uncertainty as an open decision; do not turn silence into approval.

Focus on:
- affected files and symbols
- existing patterns and architecture
- invariants and edge cases
- ordering and dependencies between changes
- tests, validation, and likely failure modes
- any assumptions that the implementer must know
- explicitly authorized supporting context that influences behavior

Return a compact structured plan. Prefer YAML-compatible Markdown:

```yaml
objective: ...
constraints:
  - ...
steps:
  - id: ...
    files:
      - ...
    symbols:
      - ...
    change: ...
    requirements:
      - ...
    depends_on:
      - ...
edge_cases:
  - ...
validation:
  - ...
open_questions:
  - ...
```