Expand invoices with full templates, public viewer API, and account holder.

Add invoice template CRUD, key points/accounts, public GET endpoint, and migration 039 for account_holder_name.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Alireza Hassani
2026-07-26 11:04:26 +03:30
co-authored by Cursor
parent 426316d53c
commit 3faeb9bc0d
13 changed files with 1094 additions and 52 deletions
+34
View File
@@ -0,0 +1,34 @@
---
description: Environment split — websites always use remote API; dashboards use local API in dev and remote after deploy; coordinate backend + dashboard releases.
alwaysApply: true
---
# Backend ↔ dashboards ↔ websites
## Who talks to which API
| Client | Local development | After deploy (production) |
|--------|-------------------|---------------------------|
| **Business websites** (storefronts) | Still **remote** `https://api.meshkee.com` (or `https://api.{domain}`) | Same remote API |
| **Dashboards** (manage / business / customer) | **Local** backend (`localhost`) | **Remote** `https://api.meshkee.com` |
Websites never depend on a developers local API. Dashboards do during local work.
## Release coordination
Because deployed dashboards hit the **same** remote backend as production websites:
1. **Dashboard-facing API changes** (routes under auth/CMS/`businesses/:id/...` used by dashboards) must ship **backend + dashboards together** (or backend first only if fully backward-compatible with the currently deployed dashboards).
2. Do **not** deploy a dashboard that requires new backend fields/routes until that backend is live on `api.meshkee.com`.
3. Do **not** deploy a breaking backend change for dashboards until the matching dashboard build is ready to deploy in the same window.
4. **Website-facing** API changes go live for all storefronts as soon as the backend is deployed — keep `docs/website-api/` in sync (see `website-api-docs.mdc`). Prefer additive/backward-compatible changes when old websites may still be out.
## Practical order
```text
Compatible API add → deploy backend → deploy dashboards (can use new APIs)
Breaking API change → deploy backend + dashboards in one coordinated release
Website-only API → deploy backend (+ update website docs); websites pick it up from remote
```
Local dashboard work: run local backend; point dashboard env at local API. After merge/deploy, dashboards use remote API again.