Sandbox workflow — branch the code, snapshot the data¶
Decided 2026-09-12 with Angel: "a different branch… for the sandbox, so we can experiment and then we merge."
The rule¶
Code is branched. Data is snapshotted. Nothing is tested on production.
| Thing | Where it lives | Sandbox | Promote to production |
|---|---|---|---|
| Assistant | ~/assistant (branch main) |
worktree ~/assistant-sandbox on branch sandbox, service assistant-sandbox.service on 127.0.0.1:8201, talks to the sandbox ERP |
git merge sandbox on main, systemctl --user restart assistant.service |
| ERP print templates and plugins | ~/erp-config (templates/, plugins/) |
branch sandbox, install with INVENTREE_URL=http://127.0.0.1:8300 … erp-templates |
merge, then erp-templates against production |
| Home page | ~/embeddedera-home |
home-deploy sandbox → gated preview sandbox.embeddedera-home.pages.dev |
home-deploy |
| SOP site | ~/Notes/sops (the vault) |
sop-deploy preview publishes the working tree to a gated preview before it is committed |
commit, sop-deploy |
| KiCad library | EmbeddedEra/KiCad |
a branch in that repo; the sync tool only ever writes to a checkout you point it at | merge to master |
| ERP data | production InvenTree | erp-sandbox up --fresh — a copy restored from a backup taken right now, on 127.0.0.1:8300 and http://sandbox.lan on the shop network (NPM, password login — the admin password is printed by erp-sandbox up), named SANDBOX, never exposed through the tunnel |
never — data does not flow back; you redo the real change on production by following the SOP |
Why data does not merge¶
A database is not a document. Two people editing production while a sandbox drifts produces conflicts nobody can reason about, and a "merge" of stock levels is meaningless. The sandbox exists to prove that a change to code or configuration behaves, on real-shaped data. Once it does, the code merges and the data change, if any, is done once on production through the ordinary procedure.
Freshness¶
erp-sandbox reset takes a new backup first, so the sandbox is minutes old, not a night old. The
backup it makes is a real backup set and lands off-site like any other — resetting the sandbox is
also a free extra backup.
What the red-team suite runs against¶
The sandbox assistant on 8201, backed by the sandbox ERP on 8300. Production is never a test target.
Related: roles-and-skills, inventree.
Two modes, from 2026-09-12¶
| Mode | Command | Data | Who may see it |
|---|---|---|---|
| rehearsal | erp-sandbox reset (or --fresh) |
a real production copy, minutes old | EmbeddedEra only |
| demo | erp-sandbox reset --demo |
the same shape, fictional contents | anyone invited, including outside evaluators |
--demo renames every company from a fixed pseudonym list, deletes contacts, addresses and every
attachment (rows and files), blanks notes and non-distributor links, multiplies every price by a
different random factor per part so costs cannot be recovered, renumbers orders to SO-9001…, and
replaces the users with one demo@example.com superuser. Categories, part numbers, descriptions,
BOMs, stock, templates and plugins survive — a visitor must see a working shop.
erp-sandbox status reports the mode; the instance name reads DEMO — fictional data, resets often;
the sandbox assistant shows a matching banner. erp-sandbox verify-demo is the gate before any
invitation: it cross-checks company names and prices against production (read-only), and fails if
an attachment row or a real email address survives. Never invite anyone without it passing.
Guard by construction: the scrub refuses to run unless the target is port 8300 and the compose project is the sandbox one, so it can never point at production.