docs: record one-repo/two-apps confirmation + HQ-DB-as-cloud-nucleus rule (D15)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/06-DECISIONS.md

@@ -134,3 +134,11 @@ AWS attribution, no path to the fleet console).
 - Doc-11's phase mapping **splits**: the ops slice ships early (HQ-1…3 in
   [14-SPEC-HQ-CONSOLE.md](14-SPEC-HQ-CONSOLE.md) §6); the fleet half is unchanged and
   waits for the cloud tier per D14.
+- **One repo, two runtime-independent applications** (founder re-confirmed 2026-07-10
+  after weighing a full split): separate servers, DBs, builds and deploys; only source
+  packages are shared. Guardrails: a bundle-isolation check in the test suite (store
+  bundle contains no HQ code and vice versa), per-app version tags, and the rule that
+  **HQ's DB is the cloud tier's nucleus** — the tenant registry is born from HQ's client
+  table (same UUIDs, promoted once), never built beside it. Engine may swap to Postgres
+  at AWS deploy time (portable repos make it cheap). Physical repo split stays a cheap,
+  reversible option if practice ever demands it.

docs/14-SPEC-HQ-CONSOLE.md

@@ -25,7 +25,7 @@ tracking against our catalog, no AWS attribution, no path to the fleet console).
 |---|---|
 | App | `apps/hq` — Node server + web app + JSON API, same pattern as `apps/store-server` |
 | Hosting | Small AWS instance (Mumbai), HTTPS; store product stays local per D14 — this is vendor-side cloud, which doc 11 already prescribes |
-| DB | SQLite (WAL) behind portable repositories (`repos.ts` pattern); nightly + on-change backup to S3; restore drill scheduled |
+| DB | SQLite (WAL) behind portable repositories (`repos.ts` pattern); nightly + on-change backup to S3; restore drill scheduled. **This database is the nucleus of the future cloud tier** — at HQ-4 the tenant registry grows *from* it (same rows, same UUIDs), never beside it; there is never a second client list to reconcile. Consider swapping the engine to Postgres at AWS deploy time (cheap behind the repos; removes even the engine migration later) |
 | Reuse | `@sims/billing-engine` **compute engine** (our invoices are GST documents — computed to the paisa), `@sims/domain` money/FY/UUIDv7 helpers + doc series (**generalized in HQ-1**: scope becomes an opaque key, separator/width configurable, 16-char GST rule kept — today it is per-counter), `@sims/ui` (design system), `@sims/auth` patterns (scrypt, lockout). HQ defines its **own document/payment types** — quotation/proforma/credit-note and B2B payment modes (NEFT/cheque) don't exist in the retail document model; shared packages stay generic (D15) |
 | Auth | Email + password (scrypt), optional TOTP for owner; roles: **Owner** (everything incl. pricing/finance), **Staff** (operations; finance edits owner-gated). Small team — same people do sales, accounts, support |
 | Audit | Every action logged — same discipline as the store product |