Scope And Non Goals — Claude Code Guide

Goal does not define the boundaries yet

Goal describes the desired result, but it does not define the permitted area of work. `Scope` sets the functional area, `Non-goals` record what is deliberately deferred, and `Affected area` provides a starting map of components that may be involved.

Scope in three dimensions

• User flow: where a person starts and finishes the scenario.
• Change points: UI, controller, service, model, table, event, or API.
• Supporting artifacts: tests, documentation, and event contracts.

## Change area
- return creation form in the admin panel
- details view page
- persistence of the optional field
- refund.created event
- relevant tests and event contract description

Non-goals — deliberate boundaries

• do not change automatic and manual approval rules;
• do not touch the payment provider;
• do not rebuild the relationship between the support-ticket and the return;
• do not perform a general service refactoring;
• do not format unrelated files without a need.

Affected area — a map for discovery

• the return form and details screen;
• the return controller and service;
• the refunds model or table;
• the refund.created event;
• tests for the primary scenario;
• internal documentation about the payload.

Check the boundaries before implementation

1. Make sure Scope does not cover an entire module without an explanation.
2. Check that Non-goals name specific prohibited changes.
3. Make sure a UI change accounts for persistence, reading, and events when needed.
4. Ask Claude to name candidate areas first without making changes.
5. If new requirements appear, update TASK_SPEC.md before continuing work.