Definition of done

"Done" means demonstrated on staging (or in Claude Design, for design) against the acceptance criteria of the linked requirements. It does not mean merged, and it does not mean "works on my machine". Anis marks a task done in tasks.json only when its checklist is complete (progress reporting).

Definition of readyCopy Anchor Link

A task may start when every line that applies to its type is true:

Not ready? Say it at the Sunday planning or in the stand-up, and Anis re-orders the lane. Never start a screen from a WIP frame, or an endpoint that is not in the contract.

Done, for every taskCopy Anchor Link

• Merged through a PR with green checks and the required reviews (PR rules).
• The acceptance criteria of the linked requirements are demonstrated on staging (in Claude Design for design).
• The task id is in the PR title; linked issues are closed.
• The docs are updated when behaviour, scope, plan or the API changed — in the same PR.
• Demo recorded: a screen recording of at most 2 minutes attached to the PR (the prototype link, for design).
• Shown at the Thursday demo.

Server endpoint or moduleCopy Anchor Link

• The operation matches the contract on dev; the implementation PR did not change it.
• Input validated by the contract's Zod schema; unknown fields rejected.
• Permission key <module>.<action> checked; the self and delegate scopes applied as query filters (permissions matrix); out-of-scope records answer 404.
• Reseller-facing and guest-facing responses never contain stock quantities or purchase prices; guests get price: null.
• Errors come from the registry, with the French message and the ar and en keys.
• Idempotency-Key accepted on mutations and required where the catalogue flags it; offline actions carry occurredAt.
• Critical actions write the audit log: who, when, what, context (cahier §3.1).
• The change and its OutboxEvent are written in the same transaction; the notifications of the notification matrix and the real-time events (back-office stream, reseller stream for order changes) are emitted.
• Business numbers come from the numbering service; money is in integer centimes; timestamps UTC, business days Africa/Algiers.
• Pagination: cursor for app and reseller lists, offset for back-office tables, with the documented limits.
• Tests: unit tests for the rules (state machines, pricing, credit); integration tests for the happy path, permission denied, out of scope, the main business errors and an idempotent replay.
• Seeds updated when the module needs reference or demo data.
• Logs carry the requestId and no personal data or secrets.
• Indexes exist for the filters and sorts used; no N+1 query on lists.
• The data the success KPIs need is recorded (ANA-04) — for example invitation steps and first-order attribution.
• Deployed on staging and called by its consumer — the back-office page, the app against staging, or a scripted request in the PR.

Back-office pageCopy Anchor Link

• Matches its Ready for dev frames, with every state: loading, empty, error, no permission.
• The navigation item and the actions follow the user's permissions.
• Tables: server-side pagination, sorting and filters, with the filters in the URL.
• Forms validated with the contract's schemas; server errors shown on the right fields.
• No hard-coded strings: French complete, ar and en keys present; logical CSS properties (RTL-ready).
• Usable on desktop, tablet and large screens (NFR-05).
• Exports (PDF, Excel/CSV) where the spec asks for them.
• Live updates from the back-office event stream where the spec asks for them.
• Keyboard navigation, visible focus, readable contrast, labelled controls (NFR-07).
• Checked with each role that can reach the page.
• "Design OK" from Akram on the PR.

Mobile screenCopy Anchor Link

• Matches its Ready for dev frames, with every state: loading, empty, error, offline, permission denied; for the delegate app also GPS off and out of tolerance.
• Uses the generated hoco_api client and hoco_ui components; errors mapped by code.
• Offline behaviour as specified (offline sync design). In the delegate app the action works offline, is queued with its Idempotency-Key and occurredAt, and its sync state is visible: synchronised, pending or in error (cahier §7.3).
• Reseller app: guest mode respected (no price, no cart without an account); order status changes arrive live while the app is open and as a notification.
• Copy from hoco_l10n: French complete, ar and en keys present; RTL checked on the key screens.
• Accessibility: touch targets of at least 48 dp, readable contrast, text scaling up to 1.3×, semantic labels.
• Performance on the reference mid-range Android phone: cold start under 3 s (NFR-01), smooth lists.
• Location and camera permissions asked with their explanation (SEC-07).
• Sentry breadcrumbs on the main actions; widget tests for logic-heavy widgets.
• In the App Distribution build of the team group; "Design OK" from Akram.

Design screenCopy Anchor Link

• Every state is drawn; real French copy, including error and empty messages — no lorem ipsum.
• Only design-system components and tokens; a new component is added to the library and announced.
• Long texts and Arabic (RTL) considered on the key screens.
• Contrast meets WCAG AA (4.5:1 for text, 3:1 for large text and UI elements); touch targets of at least 48 dp on mobile.
• The frame is named by its screen id and linked from its spec page.
• The feasibility check passed; the section reads Ready for dev.
• Assets are exportable; a prototype exists for each multi-screen flow.

Docs pageCopy Anchor Link

• Frontmatter with title and a one-sentence description.
• pnpm --filter @hoco/docs check-mdx passes.
• No plan date typed by hand: dates come from <Milestones />, <TaskTable /> and the other plan components, or the page names the milestone.
• Claims trace to the cahier (cahier §6.4); assumptions are marked Assumption; open questions are in the register.
• Ids link to their pages with the anchors of AUTHORING.md.
• Reviewed by the owner of the section.

Database migrationCopy Anchor Link

• One migration per PR, named <task>_<topic> (for example srv20_returns), label migration.
• Additive: it works with the code currently in production (expand then contract).
• The author read the generated SQL; destructive statements are explained in the PR.
• Indexes for new foreign keys and filters.
• prisma migrate deploy succeeds on an empty database and on a copy of staging.
• A data backfill, if any, is idempotent and tested.
• Seeds updated and idempotent.
• The PR states how to recover if it goes wrong (the forward fix).

Not doneCopy Anchor Link