44 lines
1.1 KiB
Markdown
44 lines
1.1 KiB
Markdown
# 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:
|
|
- ...
|
|
```
|
|
|