Migration epics — dependency graph

Purpose: show the order and dependencies of the Appwrite migration epics. Status: as of 2026-06-19. Epic detail in ../progress/roadmap.md.

Mermaid

flowchart LR
    A["A · Foundation<br/>CLI, ADR, SDK modules,<br/>type-gen, CI"]
    B["B · Data<br/>schema, repo layer,<br/>catalog/foundations/<br/>inventory/sales/staff, tests"]
    C["C · Auth<br/>guard, teams,<br/>login/2FA/forgot,<br/>PIN, presence"]
    D["D · Storage<br/>buckets, file service,<br/>web/mobile upload"]
    E["E · Functions<br/>scaffold + CI,<br/>hello-world"]
    F["F · Client integration<br/>RQ↔Appwrite adapter,<br/>web re-point,<br/>mobile offline-first"]
    G["G · Cutover<br/>prod flags →<br/>decommission TypeORM/<br/>BetterAuth"]

    A --> B
    A --> C
    A --> D
    A --> E
    B --> F
    C --> F
    D --> G
    E --> G
    F --> G

ASCII (fallback)

                 ┌───────────────► B Data ───────┐
                 │                                 │
A Foundation ────┼───────────────► C Auth ───────┼──► F Client integration ──► G Cutover &
                 │                                 │                              decommission
                 ├───────────────► D Storage ─────────────────────────────────► (G)
                 │                                 │
                 └───────────────► E Functions ───────────────────────────────► (G)

Reading notes

• A (Foundation) is the only root — everything depends on the SDK modules, schema skeleton, type-gen, and CI being in place.
• B (Data) and C (Auth) feed F (Client integration) — clients can’t go direct until collections + auth exist.
• D (Storage) and E (Functions) are parallel tracks that also gate G.
• G (Cutover) depends on the user-facing Appwrite paths being live; it introduces production flags, then decommissions the legacy stack. It is effectively the sink of the DAG.
• Within each epic, tickets follow the Contracts → Data → Endpoints → UI → cleanup ladder and are wired by blocked_by. See ticket-conventions.