The DB is built for configurable workflows; the app hardcodes one
The schema includes a workflow_rules table, per-company:
workflow_rules(company_id, from_status, to_status, required_gate,
checklist_template jsonb, deadline_days int)
It is clearly designed to let each tenant configure its own state machine — allowed transitions, gates, checklist templates, deadlines.
But the application ignores it entirely. The FSM is hardcoded globally in
src/lib/workflow-config.ts (ALLOWED_TRANSITIONS, GATE_REQUIRED_TRANSITIONS,
DEFAULT_CHECKLISTS, PHASE_DEADLINES). No code reads workflow_rules.
The tacit assumption / open question: either (a) per-tenant workflow configuration was an intended feature that was never wired up, or (b) it was abandoned in favour of a single legally-fixed Portuguese procedure. These have opposite rebuild implications.
Given the domain — the Portuguese Código do Trabalho prescribes the procedure, so most
of it shouldn't be tenant-configurable — (b) is more likely correct, and workflow_rules
is probably dead schema. But the deadline values and some internal steps are legitimately
configurable (the config marks some deadlines source: "internal"), so a rebuild needs a
deliberate answer, not an inherited accident.
Rebuild implication
Decide explicitly: fixed legal core + a small set of tenant-configurable knobs
(internal deadlines, optional checklist items), or full per-tenant FSM. Then either drop
workflow_rules or make it authoritative. Don't leave both.