Skip to main content

​
Brand sync: how the AiSky portal is built from this repo

docs.aisky.co.za is generated from this repo. It is not a fork and it is not maintained by hand. If you change a page here, AiSky gets the change on the same push.
Never edit The-RCS-Group/aisky-docs. It is force-pushed on every sync, so an edit there is destroyed silently and without a conflict. Everything AiSky-specific belongs in this repo.

​
Try it locally

--check exits non-zero if anything is wrong, and writes .brand-manifest.json listing exactly what shipped, what was pruned, and every warning.

​
The six steps, and why the order is the safety argument

  1. Freeze — mask every wire identifier behind a sentinel
  2. Replace — run the brand rules over what is left
  3. Patch — apply line-level edits, failing if an anchor has moved
  4. Overlay — copy overrides/aisky/** over the result
  5. Config — patch docs.json, prune nav entries whose page no longer ships
  6. Guard — fail closed on anything false, warn on anything unearned
Step 1 is what makes step 2 safe, and it is the whole design. SmartAlex appears in prose and inside sip.voice.getsmartalex.com, @smartalex/mcp-server, smartalex_list_contacts, X-SmartAlex-Signature and sa_live_. Those are strings live systems emit and match. AiSky runs on SmartAlex’s backend — only /, /about and /pricing are hostname-swapped, and the API, widget bundle, SIP ingress and MCP server are shared — so renaming them produces a beautifully branded document that configures nothing. Mintlify builds it green either way, because Mintlify never checks that a SIP host resolves or an npm package exists. AiSky is not a 100% white label, and the build measures by how much. Every sync reports the count of frozen identifiers (499 at the time of writing). A jump in that number means the technical surface grew; a drop means something got renamed that should not have been.

​
What differs between the two portals

​
The guards, and why they are not optional

Every failure mode here is silent. A green Mintlify build proves nothing. --check caught three real bugs in the price rules on the first run, none of which would have failed a build:
  • \$15-\$30/hr (a human wage) rewritten to a rate on request-$30/hr
  • a competitor’s $0.05 per-call cost converted to R0.97, our contractual rate
  • \$0\b eating the dollar sign off $0.25, silently converting whole tables at 1:1
They are recorded in brands/aisky.json under _rejectedRules so nobody reintroduces them. The lesson generalises: a price rule that is 95% right is worse than none, because the 5% is invisible and reads as authoritative.

​
Adding another partner

Copy brands/aisky.json, change the identity block, and add overrides/<key>/. The generator is brand-agnostic; nothing about AiSky is hard-coded in it.

​
Outstanding

Tracked in brands/aisky.json under _openQuestions and _deferredPages. The short list:
  • AiSky’s registered entity, CIPC number and Information Officer, for trust/
  • whether AiSky publishes its own aisky.co.za/legal/* instruments (trust/legal.mdx links 26)
  • the VAT position (VAT_NOTE is empty in lib/aiskyPricing.ts pending a ruling)
  • rand prices for add-ons and extra agent slots
  • seven pages held back because they are built on US market economics — see _deferredPages