Ways of working
Ways of working
The operating model of the three-person team and HOCO: who owns what, the weekly rhythm and the golden rules that apply from day one.
These pages are the team's operating rules, not suggestions. They apply to Anis, Imad and Akram from the first day of the plan, and to anyone who joins later. When a rule stops working, it is changed in a pull request to apps/docs/content/docs/workflow/ (usually after a retro). Until that PR is merged, the current page applies.
The working week is Sunday to Thursday. Every time on these pages is in Africa/Algiers (UTC+1). Dates are never written here: they come from the plan (timeline).
The operating model
Three tracks run in parallel from day one, and they meet at two interfaces: the API contract (packages/contracts, published as OpenAPI) between Anis and Imad, and the Claude Design handoff between Akram and both developers. HOCO validates at fixed moments and decides through the decision register. Anis is HOCO's single point of contact for scope, dates and cost.
Who owns what
R does the work · A answers for the result (one per row) · C is consulted before · I is informed after.
| Activity | Anis | Imad | Akram | HOCO |
|---|---|---|---|---|
Plan (tasks.json), Progress page, client relationship | A/R | C | C | I |
| Scope, change requests, decision register | A/R | C | C | Decides |
API contract (packages/contracts) | A/R | R — reviews and approves every change | I | — |
| Server, back-office, reseller web, docs site, DevOps | A/R | C — as API consumer | C — design QA | — |
| Reseller app and delegate app | C — API usage, security | A/R | C — design QA | — |
| Design system and every screen | C | C | A/R | Validates per surface |
| Design QA | R — fixes web findings | R — fixes mobile findings | A/R | — |
| Deployments to staging, pre-production, production | A/R | I | I | Accepts on pre-production |
| Mobile builds and store releases | C | A/R | R — store assets | Owns the store accounts |
| Acceptance (recette) and the PV | A/R — organises | R — mobile fixes | R — test campaign (QA-03) | Executes and signs |
| Production incidents | A/R — server, data | R — apps | I | Informed |
| Training and user guides | A/R | C | R — materials (DQA-06) | Attends |
Each person's load and working window, live from the plan:
| Person | Role | Effort | Tasks | Window | Owns |
|---|---|---|---|---|---|
| Anis | Full-stack developer · 1 FTE | 60.75 d | 39 | 18 Oct 2026 → 18 Feb 2027 | Server (API), back-office dashboard, reseller web app, docs, DevOps |
| Imad | Mobile developer (Flutter) · 1 FTE | 69.75 d | 44 | 18 Oct 2026 → 31 Jan 2027 | Reseller app and delegate app (Flutter monorepo) |
| Akram | UI/UX designer · 1 FTE | 43.25 d | 36 | 18 Oct 2026 → 22 Feb 2027 | Design system and every interface, design QA, training and store assets |
The weekly rhythm
| When | What | Who |
|---|---|---|
| Sunday 10:00 (30 min) | Planning — the week's tasks by id, blockers, what HOCO must provide | Team |
| Monday–Thursday, by 10:00 | Stand-up message in the team group — yesterday / today / blockers, with task ids | Each person |
| Every working day, by 11:00 | Issue triage in both repositories | Anis |
| Design days, 15:30 (15 min) | Feasibility check of the day's screens | Akram + the developer of that platform |
| Wednesday 14:00 (20 min) | Mid-week sync — blockers, contract and design changes coming, demo preparation | Team |
| Thursday 11:00 (45 min) | Internal demo of what is done, on staging | Team |
| Thursday, by 16:00 | Progress update — task statuses in tasks.json and the Progress page | Anis |
| Every second Thursday 14:00 (60 min) | Client review with HOCO | Team + HOCO |
| Every second Thursday 15:15 (30 min) | Retro | Team |
Details, agendas and the Ramadan schedule: rituals and communication.
Golden rules
- The plan lives in
tasks.json; dates are never typed by hand. The scheduler computes every date. A slip is a changed effort, dependency or scope, visible in the diff of the plan (planning method). - Contract first. No endpoint is implemented or consumed before it exists in
packages/contractsondev, reviewed by Imad (API-contract workflow). - Every branch, commit and PR names its task id:
feature/SRV-14-crm-module,feat(server): reseller lifecycle [SRV-14]. Work without a task id is a bug (it has an issue number) or it is not planned: ask Anis before starting it. - No direct pushes to
devormaster. Everything lands through a PR with green CI.masteronly receivesrelease/*andhotfix/*branches (git workflow). - A decision not written in the register did not happen. Calls, chats and meetings produce proposals; the decision register produces decisions.
- HOCO tests on pre-production, never on staging. Staging is the team's integration environment and breaks on purpose. HOCO sees work in the client review and hands-on on pre-production release candidates (environments).
- Not described in the cahier or not validated → change request. The scope clause (cahier, p. 2) is applied literally. Nobody says "yes" to new scope in a meeting (change requests).
- Done means demonstrated on staging. Merged is not done. The definition of done is.
- Bugs live in GitHub issues. A bug reported in a chat is copied into an issue the same day by whoever received it (bugs and incidents).
- Developers build what is "Ready for dev" in Claude Design, nothing else. A design change after handoff is an issue, not a message (design workflow).
- Secrets never travel through git, chat or email. They live in the password manager, GitHub secrets and Dokploy (repositories and access).
- A branch lives three working days at most. Bigger tasks ship as several PRs under the same task id.
The pages
Repositories and access
The two repositories, what goes where, permissions, branch protection, secrets, the accounts production depends on, onboarding and offboarding.
Git workflow
Branch model, naming, merge policy, Conventional Commits with both scope lists, hooks, Prisma migrations in branches.
Pull requests and reviews
The PR template, size limits, CI gates, who reviews what in a team of three, response times, previews.
API contract workflow
The contract-first loop, mock server, additive vs breaking changes, deprecation, versioning and the contract changelog.
Design workflow
Design statuses, the 21-day checkpoints, the daily feasibility check, handoff, design QA, client validation.
Environments and releases
Local, staging, pre-production, production; deployment order; mobile release trains; versions, rollback, flags, maintenance.
Rituals and communication
The weekly rhythm in detail, channels, response times, meeting notes, progress reporting, escalation, Ramadan.
Definition of done
When a task may start and when it is finished, per work type.
Bugs and incidents
Bug template, severity and priority, response targets per phase, triage, incidents, hotfixes, pilot on-call.
Change requests and decisions
The scope clause as a process, the CR template, plan updates, the decision register and the sign-off moments.
Tools
The toolchain with versions and the commands everyone uses.