docs: bring planning docs current with the HQ/Store split

Update the shared-heritage docs that still described the old combined monorepo:
D15 and the HQ console spec now note the 2026-07-16 split into two independent
repos, and the deploy runbook uses the correct repo name (sims-hq, was sims-next).
Historical decisions are preserved; only stale present-tense/naming is corrected.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/06-DECISIONS.md

@@ -109,13 +109,14 @@ the DB migrate off 12c or upgrade (19c/23ai); a security/compliance audit flags
 unpatched engine; or sync friction in Phase 0–1 proves materially costlier than an
 engine port. Risk register entries in 07 §3 remain on record.
 
-## D15 — Internal HQ ops console: build now, in this monorepo ✅ RESOLVED (2026-07-09)
+## D15 — Internal HQ ops console: build now ✅ RESOLVED (2026-07-09; split to its own repo 2026-07-16)
 Founder call (2026-07-09): an **internal tool for running our own ~300-client business** —
 quotations/proforma/invoices in minutes, recurring billing with auto/manual email
 reminders, per-module payment + AMC tracking, per-client AWS usage & cost, and the full
 client interaction memory (installation, training, visits, calls, meetings, sales
 outcomes) in a system instead of heads. **Decision:** start the
-[doc-11 HQ Console](11-ADMIN-SUPPORT-CONSOLE.md) **early**, as `apps/hq` in this monorepo —
+[doc-11 HQ Console](11-ADMIN-SUPPORT-CONSOLE.md) **early**, as `apps/hq` (built in the shared
+monorepo at the time; **split into its own repo `C:/SiMS/hq` on 2026-07-16**) —
 spec in [14-SPEC-HQ-CONSOLE.md](14-SPEC-HQ-CONSOLE.md). Cloud-hosted **vendor-side**
 (D14 untouched — the store product stays local); SQLite behind portable repositories with
 S3 backup; **Gmail API** sending from the company mailbox; automated AWS cost attribution;
@@ -129,8 +130,9 @@ builds doc-11 twice); off-the-shelf CRM (no module-level tracking against our ca
 AWS attribution, no path to the fleet console).
 
 **Consequences accepted:**
-- The monorepo now carries **two deployables with different release rhythms** — separate
+- This shipped as **two deployables with different release rhythms**. On **2026-07-16 they
-  deploy scripts and versioning; shared packages stay generic (nothing HQ-specific leaks in).
+  were split into two independent repos** (`C:/SiMS/hq` and `C:/SiMS/store`) — separate
+  histories, deploy scripts, and versioning; the shared packages were forked into each.
 - 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.

docs/14-SPEC-HQ-CONSOLE.md

@@ -8,9 +8,9 @@ calls, meetings, sales outcomes) that today lives partly in an Oracle APEX app a
 in people's heads.
 
 **Decision (D15, [06-DECISIONS.md](06-DECISIONS.md)):** this is the
-[doc-11 HQ Console](11-ADMIN-SUPPORT-CONSOLE.md) **started early** — built in this
+[doc-11 HQ Console](11-ADMIN-SUPPORT-CONSOLE.md) **started early** — built as a new cloud
-monorepo as a new cloud app, aimed first at the *current Classic client base*, replacing
+app (in the shared monorepo at the time; **now its own repo `C:/SiMS/hq`**, split
-the APEX app entirely. Roughly 70% of the requirement (tenant directory, subscription
+2026-07-16), aimed first at the *current Classic client base*, replacing the APEX app entirely. Roughly 70% of the requirement (tenant directory, subscription
 state, renewals pipeline, dunning, our own GST invoices, support notes) was already
 specified in doc 11; this spec adds the missing 30% (quotations/proforma from letterhead
 templates, AMC, AWS cost attribution, interaction/visit logs) and re-sequences delivery.
@@ -23,7 +23,7 @@ tracking against our catalog, no AWS attribution, no path to the fleet console).
 
 | Aspect | Call |
 |---|---|
-| App | `apps/hq` — Node server + web app + JSON API, same pattern as `apps/store-server` |
+| App | `apps/hq` — Node server + web app + JSON API, same pattern as the store-server app (now the separate Store repo) |
 | 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. **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. **Postgres is the locked production engine** (founder call 2026-07-10): the swap is a dedicated task sequenced AFTER HQ-2 and BEFORE the real-data import and go-live, so the 300 clients land once, directly in the final engine; SQLite remains the dev/test engine behind the same repositories. DDL snapshot for mapping work: `apps/hq/schema.sql` |
 | 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) |

docs/DEPLOY-HQ.md

@@ -14,7 +14,7 @@ prescribed. Today the engine is SQLite; the Postgres switch is called out where
 ## 1. Get the code on the box
 ```bash
 sudo mkdir -p /opt/sims-hq && sudo chown $USER /opt/sims-hq
-git clone <your-repo-url> /opt/sims-hq        # after `gh repo create sims-next` + push
+git clone <your-repo-url> /opt/sims-hq        # after `gh repo create sims-hq` + push
 cd /opt/sims-hq
 # Node 20+ (nvm or NodeSource). Then:
 npm install