# Working Agreement

## Ways of working
This repository uses the following item-by-item workflow for backlog work.

1. Start work on a backlog item only when the user asks for that specific item, or after asking whether to move to the next item and receiving confirmation.
2. Begin by reading the Notion item content, then ask clarification questions before implementation.
3. Share a concise analysis of the item and likely implementation scope.
4. After clarification, set the Notion ticket to `En cours`, create a branch (using the git flow ways of naming + adding the Product Backlog Item ID in the name "NANEASY-{ID}"), push it, open a draft PR, then develop on that PR branch.
5. Tell the user when the implementation is ready for testing.
6. Apply requested corrections while the PR remains open.
7. Only commit and push final changes after the user validates the behavior.
8. The user merges, or explicitly asks the agent to merge into `main`.
9. Ask whether to move to the next backlog item before starting it.

Important local constraints:

- Preserve user changes in the working tree. Do not revert or stage unrelated files without explicit confirmation.
- Prefer small, focused PRs aligned to one Notion item.
- Keep Notion ticket status, branch, PR, and implementation state consistent.

Product Backlog is hosted here : https://app.notion.com/p/f5e41d3b729b4c94980e8aad5373d50b?v=dccf6a20e8e9455e877e7721f88ac301&source=copy_link

## App tone of voice
- Always use french
- Always use first person ("je", "mon", "mes", etc.)
- Always use sweet and reassuring wording
- In buttons with icons, always place the icon before the text.

## CSS conventions
- Never use inline `style=""` attributes in Blade views. Add a class to `resources/css/app.css` instead, following the existing BEM-ish naming per component (`profile-*`, `contract-*`, `dashboard-*`).
- Exception: a value that is genuinely dynamic and computed per render/interaction (e.g. a progress-bar width from a PHP or Alpine variable, an Alpine-computed dropdown position) may stay inline, since it cannot be expressed as static CSS.
- Before adding a new class, check whether an existing one already covers the same visual pattern (grep `resources/css/app.css` for the property values) — reuse it instead of duplicating.
- Colors that are reused across rules must be defined once as a CSS custom property in the `:root` block at the top of `resources/css/app.css` and referenced via `var(...)`, not repeated as raw hex values.