CepatEdge

Appearance

Maintenance system ​

Architecture entry point for the maintenance domain. Authoritative behavioral specs live under ../lifecycle/maintenance/ and must stay aligned with implementation.

Engineering map: ../../maintainer/systems/maintenance.md.

Documentation map ​

TopicLocation
Overview & definitions../lifecycle/maintenance/
Status & departmentApprovalStatus../lifecycle/maintenance/status-transitions.md
RBAC, archive / purge../lifecycle/maintenance/permissions-matrix.md
finalSnapshot, list vs detail../lifecycle/maintenance/snapshot-behavior.md
Cache contracts../lifecycle/cache/

Storage ​

  • Primary: PostgreSQL (maintenance_requests via Drizzle)
  • Attachments: R2 + metadata table (not duplicated in finalSnapshot by default)
  • Audit / logs: Structured maintenance and security pipelines; purge emits structured meta (see snapshot doc)

Core model ​

  • status: pending | in_progress | completed | cancelled | declined (underscore form only)
  • departmentApprovalStatus: dashboard / summary field; invariants tied to status in lifecycle docs
  • Prefer status + completedAt over a separate completed boolean
  • User refs: submittedBy, approvedBy, assignedBy, assignedTo (IDs); departmentId with API department: { id, name }
  • Terminal: completed, cancelled, declined — further changes limited to archive / purge / reads per matrix
  • finalSnapshot: JSON v: 1, written once with the terminal transition, immutable; includes department and relatedUsers

API shape ​

  • relatedUsers: enriched array; canViewProfile server-only; no email
  • permissions: includes canArchive, canPurge
  • List: no full snapshot; takenAt from finalSnapshot.takenAt when closed, else null
  • Detail: full finalSnapshot for closed tasks

Code map ​

AreaPath
Routesapps/worker/src/routes/maintenance/
Servicesapps/worker/src/lib/services/maintenance/
Cacheapps/worker/src/lib/services/cache/