# Ticket spec template

This is the contract between the Planner and the Developer. The Planner fills every
section into the ticket's Notion page body. A ticket is **Ready** only when all
sections are complete and contain no open questions.

---

## Feature Description
The user story. What does this feature do, for whom, and why? E.g.:
"As a user, I want X so that Y" or "Users need to be able to do X because Y."
This is Marius's raw idea, elaborated by the Planner.

## Context / Problem
Why this work exists. The business need (from Marius) and the user problem it solves.
Link to related tickets or docs.

## Acceptance Criteria
A checklist of observable, testable outcomes. The feature is "done" when all are true.
- [ ] ...
- [ ] ...

## Implementation Plan
How to build it, grounded in the project's actual architecture. Name the specific
files/modules/functions to add or change. Call out data model changes, new
dependencies, API contracts, and edge cases. This is where the Planner "thinks hard."

## Affected Areas
Files, directories, or components the Developer will touch.

## Test Plan
How to prove it works: unit/integration tests to add, manual checks, commands to run.

## Documentation
What docs to create or update in the same PR (README sections, API docs, changelog).

## Out of Scope
Explicitly what NOT to do, to keep the change focused.

## Open Questions
Anything the Planner needs from Marius. **If this section is non-empty, the ticket
cannot be Ready** — set status to `Needs Info` and post these as a Notion comment.