Delivery progress

This page records facts — what exists and works. The timeline shows the plan. Anis updates this page and the task statuses in content/plan/tasks.json every Thursday after the internal demo.

Last update: 20 October 2026 (evening) — test sandbox online, first QA pass, mobile contract fixes, Arabic-ready PDFs.

At a glanceCopy Anchor Link

DeliveredCopy Anchor Link

34 tasks · 0 d of open effort. Dates are computed — Sunday–Thursday weeks, holidays excluded.

PRJ-01 — Monorepo scaffold, tooling & repository setupCopy Anchor Link

• Turborepo + pnpm workspace mirroring the team's previous monorepos: apps/server (Express + oRPC, /health, /v1/system/*, /openapi.json, /reference), apps/dashboard and apps/web (Next.js 16, next-intl with French default), apps/docs (this site).
• Shared packages: config, env, db (Prisma 7 + adapter-pg, multi-file schema), contracts (oRPC contract with the error envelope, pagination and money schemas), api-client, ui (HOCO tokens), shared (DZD formatting, Algerian phone normalisation).
• Tooling: Biome, lefthook (Biome on commit, commitlint on messages, gitleaks when installed), GitHub Actions CI, Dependabot, PR and issue templates, CODEOWNERS, Docker image recipe for server/dashboard/web, local stack with docker compose.

PRJ-02 — Docs site, PRD/SRS baseline & delivery planCopy Anchor Link

• The PRD, the SRS (requirements per area, lifecycles, business rules, permissions, notifications, acceptance scenarios, data model baseline, API catalogue, integrations, operations, decision register), the design plan and screen specifications, the Flutter guide and the ways of working.
• The plan: 145 tasks with effort, owners, dependencies and milestones; per-task briefs generated for each team member.

19 October 2026 (evening) — pages built, hardening, named API modelsCopy Anchor Link

• Back-office pages for every module (DSH-02 to DSH-13) and the reseller web pages (WEB-02 to WEB-05), built against the real API. They stay open until the design review against the Claude Design handoff.

• Smart notifications, client document 03: contract, schema, triggers and caps (SRV-39, SRV-40), and their screens (DSH-14, WEB-06).

• Hardening (SRV-28):

  • permission, scope and exposure sweeps;
  • security headers on the API and both web apps;
  • the missing rate limits;
  • a production secret check;
  • two slow admin lists brought from about 20 s to about 1 s;
  • k6 scripts and a local restore drill.

  Open items are logged for QA-01 in the hardening report.

• The OpenAPI export names its shared models: 723 components referenced with $ref, so the mobile client generates one class per model.

• The local stack now uses the machine's shared Postgres, Redis, MinIO and mail containers (see the README).

• API refinements from the page build (SRV-41): contract 1.1.0, 352 routes, all additive (changelog in the API contract workflow).

• CI/CD and environments, repository side (OPS-02):

  • CI runs the integration tests on Postgres, Redis and MinIO;
  • GHCR images, with Dokploy deploys per environment;
  • nightly encrypted backups;
  • the deployment runbook.

  OPS-02 stays open until the VPS and Dokploy setup in the runbook is done.

• Session cookie name per environment (hardening L-05).

• QA-01 preparation: the end-to-end test plan, the guarded staging reset (pnpm qa:reset) and an automated cross-app smoke test.

• Pull requests #22–#35 on dev.

20 October 2026 (evening) — first QA pass, mobile contract, PDFsCopy Anchor Link

• QA-01, first pass at API level on the sandbox: sign-up with the OTP read in Mailpit and validation, catalogue visibility and prices per customer type, no stock quantity for resellers, orders through confirmation, preparation, shipment and delivery with stock reservation and deduction, invoice, inbox notifications, cancellations and refusals, the credit block, promotions (target, schedule, unit cap, daily offer), the regional WhatsApp number, returns with restock and credit note, an after-sales replacement. All behave as the scenarios expect; three steps of the test plan contradicted the contract and were aligned. The screens are next.
• Mobile contract (changelog 1.2.0), asked by Imad for the Dart generation: every tagged union declares its discriminator, ProductPresented of the visit report carries kind, and the enums of the parameters are named, so no class is numbered any more.
• PDFs: invoices, credit notes, delivery notes, picking lists and report exports embed Inter and IBM Plex Sans Arabic and lay out Arabic text in reading order (it came out blank before); invoices repeat the table header on every page, keep totals and the amount in words (« Arrêtée la présente facture à la somme de … ») on the last page, and carry the seller's identifiers and page x / y. A logo slot waits for HOCO's file; the final layout waits for DQA-09.
• A catalogue test no longer depends on leftover local data.
• Pull requests #49–#54 on dev.

20 October 2026 — test sandbox onlineCopy Anchor Link

• The test sandbox runs on its own VPS under Dokploy, laid out like the other company servers: a main services project (PostgreSQL 17, Redis 7, MinIO, Mailpit) and a hoco project (API, worker, back-office, reseller web, docs, mock API). Each app builds from dev through the Dokploy GitHub App and redeploys on push when its own files change.
• Addresses: API https://api-staging.144.91.120.191.sslip.io/v1, back-office admin-staging…, reseller web app-staging…, docs docs-staging…, mock API mock-staging…, Mailpit mail-staging…. Loaded with the reference and demo data; nightly database backup.
• Checked on the sandbox: sign-in for staff, resellers and delegates (cookie and mobile bearer token), signed-in pages of both web apps, CORS, e-mail delivery to Mailpit.
• Fixed while testing: a staff password-reset code asked by e-mail now arrives by e-mail; the test numbers +213555000001–9 accept 123456 on staging; simulated SMS are copied to Mailpit (auth). The mock API runs Prism in one process (the multi-process mode crashed at start). CI builds its own MinIO image (hoco-minio), since the public one is no longer published.
• Pull requests #46–#48 on dev.

20 October 2026 — performance, worker follow-upsCopy Anchor Link

• Catalogue and order reads no longer load the whole catalogue: list, search, suggestions, filter counts, home, brands, categories, similar products and promotion pages. Each one is checked against the former algorithm by an equivalence test; p95 on the 4,860-product copy is now 30–150 ms (numbers in the hardening report).
• Content Security Policy with per-request nonces on both web apps.
• CRM task updates always bump the task version, so a stale offline edit from a delegate can no longer overwrite them.
• Worker follow-ups (SRV-08): temporary passwords sent by e-mail, signed URLs for private files, catalogue visibility on the WhatsApp product link, every list filter in the product export, and the retention jobs (location pings, sessions, idempotency records, anonymisation of deleted accounts).
• Still open: image re-encoding (needs the sharp library), the public-holiday calendar (no list defined yet) and the device clean-up period (the docs say 60 days in one place and 180 in another).
• Fields the API defined but the database approximated are now stored (SRV-42): promotion internal name, per-reseller cap (enforced at cart and checkout) and the notify flag; banner drafts, mobile image, countdown and audience; archived vs hidden variants and weights; announcement SMS and e-mail; maintenance end time; delegate supervisor; visit report needs; reseller location source. New promotions no longer notify resellers unless the box is ticked.
• The back-office product list and the orders-to-confirm queue page in SQL: about 1 s → 62–207 ms and 0.8 s → 135–197 ms p50 on the perf copy. The queue now holds every pending order (the former 2,000 cap is gone).
• Delivery managers can record the collection of an approved return (permission matrix conditional rule, hardening L-06); the back-office reseller form loses its "Locate" button, which the back-office security policy blocks (L-07).
• The OpenAPI export also names the objects nested in its models (1,175 components, no inline objects left), so the generated Dart client has no numbered classes.
• Pull requests #37–#45 on dev.

19 October 2026 — server feature-completeCopy Anchor Link

• Platform and administration (SRV-06, SRV-07): files on MinIO, settings, users and roles, audit, reference data, search.
• Catalog, pricing engine, stock, promotions (SRV-11, SRV-12, SRV-13, SRV-19); CRM, zones and delegates (SRV-14, SRV-10); field operations (SRV-21); delegate CRM and invitations (SRV-22); offline sync (SRV-23).
• Cart, checkout, orders, deliveries, returns (SRV-15, SRV-16, SRV-17, SRV-20); billing (SRV-18); jobs, notifications, support, live events (SRV-08, SRV-24, SRV-26); dashboards, reports, exports, imports (SRV-25, SRV-27).
• HOCO's document 03 — smart notifications is specified as a change request (smart notifications).
• Follow-ups recorded: a schema migration for the fields approximated during the build (version columns, a few promotion, banner and variant fields), invoice PDF styling (logo, Arabic font, legal mentions), Arabic in PDF exports.
• Pull requests #9–#20 on dev.

18 October 2026 — implementation startedCopy Anchor Link

The open decisions take their documented defaults from today (decision register); HOCO can still decide otherwise at the cadrage, as a change request.

• SRV-01 service catalogue frozen; SRV-02 Prisma schema generated from the database design (96 V1 models, 64 enums, raw-SQL constraints) with reference and demo seeds (OPS-01).
• SRV-03 contract v1.0.0: every V1 operation, OpenAPI at apps/docs/public/openapi/hoco-v1.json, Prism mock (pnpm mock) — the mobile track can generate hoco_api (MOB-03).
• SRV-04 HTTP foundation (error registry in three languages, rate limits, idempotency, version gate) and SRV-05 authentication (sessions, OTP, reseller sign-up with customer type and claim).
• DSH-01 and WEB-01 foundations merged; their design review waits for the Claude Design handoff.
• Pull requests #1–#7 on dev.

Next two weeksCopy Anchor Link

Waiting on HOCOCopy Anchor Link

The decisions that block early tasks — they are scheduled in the cadrage workshop (PRJ-03):

• Business rules that shape the database: pricing levels, stock reservation, payment methods, credit policy, GPS tolerance and location frequency — needed before SRV-02 freezes the schema.
• The V1/V2 split for loyalty and packs (the reference screens show them; the cahier recommends V2).
• Domain names, SMS provider, maps provider and who owns the store and cloud accounts.

The full list, with owners and defaults, is the decision register.

How this page is updatedCopy Anchor Link

1. Every Thursday, after the internal demo, each person reports their tasks: done / in progress / blocked (with the blocking decision or dependency).
2. Anis sets status (and doneOn) in tasks.json, runs pnpm --filter @hoco/docs generate, and adds a dated section here: what was delivered, with links to the PRs, and what changed in the plan.
3. A slip is never fixed by editing dates: it is a changed effort, dependency or scope, visible in the diff of tasks.json.