|
|
|
|
@ -307,3 +307,34 @@ Founder call. The console goes live at **`https://hq.simssoftware.com`**:
|
|
|
|
|
sizing + security-group shape, pm2 invocation): `DEPLOY-HQ.md` §0 and §7. The founder
|
|
|
|
|
has hosted this way before — the runbook now carries the fiddly configuration detail
|
|
|
|
|
so setup on the box is a checklist, not archaeology.
|
|
|
|
|
|
|
|
|
|
## D20 — APEX parity: ticket desk, per-service data, branches, full importer ✅ DELIVERED (2026-07-17)
|
|
|
|
|
Driven by the real APEX export (`C:\SiMS\hq\Apex`, 25 tables). A 46-agent profiling+audit
|
|
|
|
|
swarm analysed the actual data before the importer was trusted. Spec:
|
|
|
|
|
`superpowers/specs/2026-07-17-apex-parity-design.md`. The calls that matter:
|
|
|
|
|
- **Ticket desk is in scope** (reversing the original non-goal): 4,567 APEX tickets are the
|
|
|
|
|
team's daily workbench. New `ticket` table (team-visible; "mine" is a filter not a gate),
|
|
|
|
|
status open/in_progress/waiting/closed/dropped, honest pagination, kind suggestions from
|
|
|
|
|
history. Client 360 gains a Tickets tab.
|
|
|
|
|
- **client_module carries per-service operational data** (provider/username/password_enc/
|
|
|
|
|
details JSON/remark) — the portal password encrypted + reveal audited, exactly like the
|
|
|
|
|
client DB password. **NOTE: D21 restructures this into a module-defined field schema.**
|
|
|
|
|
- **client_branch** table (minimal; APEX ho_branch_list parity).
|
|
|
|
|
- **Five modules** (SMS, RTGS, WhatsApp, Mobile App, ATM) seeded from client YES/NO flags;
|
|
|
|
|
ticket + roster module pickers read the live catalog, so a sixth module needs no code.
|
|
|
|
|
- **Importer v2** (`import-apex-full.ts`, 9 files) survived the swarm's real-data findings:
|
|
|
|
|
bills are LINE ITEMS grouped by INVOICE_NO across three GST eras; 46 raw ticket statuses
|
|
|
|
|
pattern-mapped; OLD_ID re-key chains collapsed; APEX test client (SID 329) + orphan refs
|
|
|
|
|
skipped with counted notes; plaintext credentials encrypted at commit (refuses without
|
|
|
|
|
HQ_SECRET_KEY). Trial import into local Postgres verified — see the spec banner for the
|
|
|
|
|
reconciled counts (273 clients / 150 docs = ₹33.17L / 1,826 tickets / INVOICE seed 10252).
|
|
|
|
|
Two real-data facts to carry forward: the export has NO state/GSTIN column (all docs split
|
|
|
|
|
CGST/SGST at the company state) and one client's OS field holds a plaintext Linux root
|
|
|
|
|
password (move it into an encrypted field + rotate at cutover).
|
|
|
|
|
|
|
|
|
|
## D21 — Module-defined field schema (config on the module) — DESIGNED, queued after D20 import
|
|
|
|
|
Spec `superpowers/specs/2026-07-17-module-field-schema-design.md`. Each module declares its
|
|
|
|
|
own operational fields (`module.field_spec` JSON); per-client values organised by that
|
|
|
|
|
schema; a generalised encrypted secret map replaces the single portal password. Founder
|
|
|
|
|
mandate: the app, modules and client↔module mapping stay flexible — a new module or a
|
|
|
|
|
changed field needs no code and no migration. Implementation follows the real-data cutover.
|
|
|
|
|
|
Thomas Joise
4 days ago