Screen inventory

This page is the list of everything Akram designs. It is generated from content/spec/screens.json, the canonical inventory. Each screen has a stable id (RA-xx reseller app, DA-xx delegate app, BO-xx back-office, RW-xx reseller web), a section, a release (V1 or V2), the design task that produces it (DES-xx = design day) and the build task that consumes it. The detailed specification of each screen (purpose, data, states, rules) is on the screen pages.

On Day 5 (DES-05), Akram, Imad and Anis walk this page and the checklist at the bottom. Agreed changes are applied to screens.json by Anis, and the inventory is then frozen (milestone Screen inventory frozen). Later changes are change requests.

TotalsCopy Anchor Link

The nine V2 screens are RA-37 (packs), RA-38 (loyalty), RA-39 (rewards), BO-47 (overdue and reminders), BO-48 (accounting exports), BO-52 (packs), BO-53 (loyalty settings), BO-54 (rewards) and RW-15 (loyalty, rewards and packs on the web). They are designed in DES-30. Returns and after-sales (RA-40, BO-69) are V1 since the decisions of 17 October.

By section

By design day (the design plan has the detail of each day)

Back-office: bespoke vs template pagesCopy Anchor Link

Of the 66 V1 back-office pages, 21 are bespoke and 45 are template pages (kind in screens.json). A bespoke page has a layout of its own: a map, a calendar, a kanban board, a matrix, a multi-tab editor, a 360° view, a live view. Akram designs it fully.

A template page is one of five page templates, defined once on Day 4 (DES-04), plus a filled page spec. The spec is a structured table of what is specific to the page: columns, filters, actions, fields, permissions and copy. Akram fills the spec on the template frame; Anis builds the page from the template code and the spec. No pixel mock is drawn unless the page breaks the template.

This is what makes Day 19 (29 pages) and the three-month frame workable. Template code is written once in DSH-01, so 45 pages reuse one table, one form, one settings layout and one detail layout. Consistency comes for free, and design time goes to the 21 pages that need it.

The five page templatesCopy Anchor Link

Proposed assignment of the 50 template pages. This assignment is not stored in screens.json; Akram and Anis confirm it on Day 5.

The 21 bespoke pages: BO-01 sign-in · BO-03 app shell · BO-04 general dashboard (role-configurable cards) · BO-06 field dashboard and live map · BO-09 resellers list (list/map toggle, saved views, bulk assign) · BO-10 resellers map · BO-11 reseller 360° · BO-13 account validation queue (side-by-side review, customer type) · BO-17 delegate detail and performance · BO-19 zones map editor · BO-21 tour planner (calendar) · BO-22 tour editor (stops, map, recommended order) · BO-23 tour live detail · BO-28 product editor (three prices, attributes) · BO-32 import wizard · BO-38 orders list · BO-39 order detail (controls, actions, history) · BO-42 delivery board (kanban) · BO-50 promotion editor (targeting, preview) · BO-59 reports library · BO-62 permissions matrix.

Example page spec: BO-41, orders to confirm (template List, queue variant).

page: BO-41 · Orders to confirm
permission: orders.validate          # hidden from roles without it
source: admin.orders.toConfirm      # SUBMITTED and PENDING orders, oldest first
live: admin.events.stream → order.created, order.status_changed (row highlight)
columns:
  - Commande (CMD-2026-000158, link to BO-39)
  - Revendeur (name, REV number, wilaya) · first-order badge
  - Canal (Application, Web, Assistée, Back-office)
  - Contrôles (stock, crédit, prix, minimum, adresse: icon + text, failed first)
  - Montant TTC (right-aligned, 1 250,00 DA)
  - Âge ("depuis 3 h"; warning tone after 4 h)
  - Statut (Envoyée / En attente pill)
filters: canal, wilaya, délégué, contrôles en échec, première commande
row actions: Confirmer · Mettre en attente (reason) · Refuser (reason, ORDER_REFUSAL_REASON)
bulk actions: Confirmer (only rows whose controls all pass)
empty: "Aucune commande à confirmer."
sidebar counter: yes (number of rows)

Reseller app (RA)Copy Anchor Link

Navigation. Five bottom tabs: Accueil · Catalogue · Panier · Commandes · Compte. The WhatsApp support button is fixed on the tab roots. Guests can use Accueil and Catalogue; the other tabs open the sign-up prompt (RA-41).

RA-36 (system states) can appear over any screen: offline banner, maintenance, forced update, errors, session expired.

Delegate app (DA)Copy Anchor Link

Navigation. Five bottom tabs: Accueil · Tournée · Prospects · Rapports · Compte. The map is a view of the tour, and visits open from a stop. The sync badge sits in the app bar of every tab.

DA-28 (system states: offline, GPS off, out of tolerance, permission denied, forced update) appears over any screen, with the GPS states also inline in DA-08 and DA-10.

Back-office (BO)Copy Anchor Link

Navigation. A light 208 px sidebar on the app ground, grouped by activity (HOCO PRO). Every group and item is shown only when the user's role has the permission (<module>.view). Counters show work waiting in the queues. The proposed groups are below; Akram finalises them on Day 15.

Pages reached from a list rather than the sidebar: BO-11, BO-12, BO-17, BO-18, BO-22, BO-23, BO-25, BO-28, BO-39, BO-50, BO-56. Sign-in (BO-01) and reset (BO-02) are outside the shell.

Reseller web (RW)Copy Anchor Link

Navigation. A top header (logo, search, categories menu, favourites, cart, account) instead of bottom tabs, plus a fixed WhatsApp button at the bottom right. At phone widths the web reuses the mobile designs, including their bottom navigation. Guests browse RW-02, RW-03, RW-04 and RW-10 without prices.

Coverage checkCopy Anchor Link

Method. Each requirement in requirements.json lists the apps it applies to. For every app among RA, DA, BO and RW, at least one screen of that app should list the requirement in its reqs. Separately, each screen should reach at least one API operation of endpoints.json: same app, sharing a requirement.

Result on the current screens.json.

• Every screen reaches at least one endpoint.
• Every functional V1 requirement has a screen somewhere.
• Some requirements are missing from one of their apps. Most of these are cross-cutting (performance, accessibility, RTL, maintainability) and are covered by the design system, not by a screen. The gaps that need a screen decision on Day 5:

Other inventory questions for Day 5.

1. BO-31 Price lists & agreements is V1 in screens.json, but price lists and per-reseller agreements are V2 since 17 October (PRC-03). Either rename it to a bulk price editor of the three customer-type prices with change history (V1), or move it to V2.
2. French names. BO and RW screens have no fr name in screens.json. The sidebar and page titles need them; the sidebar table above proposes names.
3. DA-14 customer type. May the delegate record the customer type the reseller announces, as a hint for the back-office? See reference screens.

Day-5 validation checklistCopy Anchor Link

Akram leads, Imad and Anis co-sign. Every item is ticked or turned into an action with an owner before the inventory is frozen.

Scope and counts

• 155 screens confirmed (146 V1, 9 V2), or every addition, merge and split recorded in screens.json.
• Every V2 screen is parked in DES-30, and no V2 element (points, levels, packs, rewards) appears in a V1 frame.
• BO-31 decided (V1 bulk price editor or V2).

Requirements

• Every V1 MUST and SHOULD requirement of an app has at least one screen of that app: the coverage table is resolved and reqs updated.
• The 17 October decisions are carried by named screens:
  • guest mode: RA-41, RW-01…RW-04;
  • customer type: RA-05, RA-28, BO-11, BO-12, BO-13;
  • advanced filters: RA-13, RW-03, BO-71;
  • WhatsApp: RA-32, RW-14, BO-70;
  • after-sales and returns: RA-33, RA-40, RW-14, BO-56, BO-69;
  • live status: RA-21, RA-22, RW-08, RW-09;
  • confirmation queue: BO-41.

Data

• Every screen reaches its API operations: same app, shared requirement. The screen pages list the operation ids.
• Every field shown on a screen exists in the API response or is derived, with the derivation written down (for example En retard = planned and time slot passed).
• No reseller- or delegate-facing screen shows a stock quantity.

States

• Each screen page lists its states: default, loading, empty, error, offline or permission when relevant, and the business states (each status value the screen can show).
• Guest, pending-validation and suspended variants are listed for every reseller screen they affect.

Navigation and naming

• Every screen is reachable in a navigation map, with no orphan.
• Every screen has a French name (BO and RW added).
• The bespoke and template assignment of the back-office pages is agreed with Anis.

Feasibility

• Imad has flagged the custom mobile widgets and their cost: map and pins, range slider, offline queue UI, scanner, QR, live updates.
• Anis has flagged the complex web components: calendar, kanban, zone map editor, permission matrix, live rows.
• Day 19's 29 pages are accepted as planned, or rebalanced (for example by moving template specs to Day 17 or 18).

Flows and wireframes

• The four flows are drawn: reseller ordering, delegate day, back-office confirmation and delivery, after-sales and returns.
• Wireframes of checkout, the visit flow and tour closing are reviewed by Imad.

Freeze

• The inventory is frozen (milestone Screen inventory frozen). From now on, changes go through change requests.