DESIGN
caesar — product design
Section titled “caesar — product design”Caesar — MocX finance platform & system of record. The in-house double-entry ledger and the real-time financial command centre, replacing Zoho Books. A web / desktop product (1440px), in the same platform family as Hermes, Polaris, Atlas and Argus and on the same stack. Phase 1 requirements are the BRD — read it before touching any Caesar screen.
Rationale
Section titled “Rationale”Caesar is a dense, table- and form-heavy finance back-office, not a transactional consumer app. The audience is finance and leadership (CFO Steven, Office of the CEO/CPO Osita, accountants, AP and approvers), and the hero jobs are: post and close the books with audit-grade integrity, run the requisition→PO→bill approval chain, and read the command centre — one pane where fixed assets, swap revenue, cash, liabilities and requisitions are live with one agreed source per tile.
Two design consequences fall out of that:
- It runs light, not dark. Unlike Hermes (a 24/7 dark command map where assets emit the only light), Caesar is a daytime reading-and-data-entry surface. It uses the standard light token set — high legibility for long ledgers, dense tables, reconciliations and statements. No dark-surface exception applies here.
- Numbers are the interface. Money columns, balances, KPI tiles and statement lines are the focal content. The global typography rule earns its keep: 600 for labels/headings/inline numerics; 700 reserved for true KPI display digits (command-centre tile values, balance totals where the figure is the focal point) — never for ordinary table cells, account names or column headers. Tabular figures / monospaced numerics for any aligned money column.
Design status: visual divergences from the global system are deliberately unfilled until we study the Zoho Books baseline (demo) and design Caesar’s flows against it. This file currently records the foundation (form factor, light posture, inherited patterns, class prefix). Fill the sections below as the first flows land — do not invent tokens or components ahead of need.
Inherits from global DESIGN.md
Section titled “Inherits from global DESIGN.md”This is a web/desktop product (1440px). The .phone mobile shell and rsm-* mobile scaffold do
not apply. Every token, brand and component foundation does. Before adding a screen, read these
sections of the master DESIGN.md — and start from PATTERNS.md
(web 1440 section) for canonical widget classes:
- Global Rules — official logo SVG, no emojis, no card strokes, 4px-grid spacing.
- Color Tokens, Typography, Spacing, Shadows, Border Radius — token foundations (light set).
- Card Design — shadow-only, no borders, no accent stripes.
- Table Design — the workhorse for ledgers, trial balance, AP ageing, vendor lists, journal lines, the fixed-asset register: pagination, per-page selector, alignment.
- Breakpoints & Grid — 1440px web grid.
- App header (
.mhdr) — canonical web/desktop top bar. - Status chips — canonical 3-color rule — for document/journal/requisition state (Draft / Pending approval / Posted, etc.), + red for rejected/failed. Map Caesar’s finance states onto these three; do not introduce a 4th status colour beyond the red failure variant.
- Status timeline (state-machine progress) — for the requisition→PO→bill→payment lifecycle and period-close progress.
- Class-name prefix ownership.
Confirmations & modals — web uses .dlg, never bottom sheets
Section titled “Confirmations & modals — web uses .dlg, never bottom sheets”Caesar is web-only, so every confirmation (post journal, approve/reject a requisition, lock a period,
run roll-up) uses a centered .dlg modal — bottom sheets are mobile/tablet only. This is a hard
rule from the global system; restated here because finance flows are confirmation-dense.
Class-name prefix
Section titled “Class-name prefix”caesar-* for Caesar-specific web components (command-centre tiles, ledger/journal grids,
requisition workflow rows, the fixed-asset register, statement layouts). Everything reusable should
come from the shared component library / PATTERNS.md first. Register caesar-* in the
global class-name ownership table when the
first components are built.
Cards — no strokes (restated)
Section titled “Cards — no strokes (restated)”Cards never carry a visible border or stroke — shadow + background only, and no single-side
accent stripes (border-left etc.) to colour-code state. Use a tinted background alone. Restated
here because finance dashboards tempt accent-stripe “status rails” on KPI tiles and ageing buckets —
don’t.
Sections to fill as flows are designed
Section titled “Sections to fill as flows are designed”- Command-centre composition — tile taxonomy, the one-source-per-tile rule made visual, live-vs- booked overlay treatment, refresh-cadence affordances.
- Ledger & journal grids — column conventions, debit/credit alignment, drill-down, posted-vs-draft treatment, immutability cues.
- Requisition → PO → bill — the approval-matrix workflow UI and its status timeline.
- Statements & reporting — P&L / balance sheet / cash flow layouts, entity vs cluster vs consolidated switching via the segment spine.
- Segment & entity pickers — the Subsidiary / Location / Class / Department selectors that slice every view.
Screens
Section titled “Screens”See screens/ for canonical interactive HTML mockups (none yet).
Prototypes
Section titled “Prototypes”See prototypes/ for narrated end-to-end flows (none yet).