Work shinra
platform

Shinra

The white-label form of a regulated storefront platform — every name that says which store a checkout is moved out of the code into an instance file, a settings row and a credentials directory, published as a regenerated mirror with the first store's private history filtered out.

Shinra is the platform side of the storefront exhibited here as Mako Refinery: one codebase, one store per instance, where the instance is data rather than a fork. Four layers of that identity shipped in September 2026 — an instance file holding the checkout path, systemd unit, service user, database and role, listen port, public host and backup buckets; a brand row holding the business name, entity, addresses, timezone and licensing paragraph; a write-only credentials registry filled from the admin panel; and an age policy paired with the verifier that enforces it. The compiled defaults are generic, the first store's values live in one file and one row, and build-time pins fail the suite on a store name written anywhere else. The repository itself is a regenerated mirror: the source checkout re-derived commit by commit with git filter-repo, the first store's private material removed from every commit and its identifying strings replaced with shaped placeholders, and a leak scan over the whole rewritten history before any push. Nothing is committed here by hand. There is no second instance running yet and no public site — what exists is the platform and the pipeline that publishes it.

Last updateSep 14, 2026 PrimaryGo
  • Go
  • chi
  • PostgreSQL
  • pgx
  • WebAuthn
  • React
  • React Router
  • SimpleWebAuthn
  • Lucide
  • Vite
  • JavaScript
  • Tailwind CSS
  • Playwright
  • Lighthouse
  • axe-core
  • ESLint
  • git-filter-repo
  • just
  • systemd
  • nginx

Shinra is the white-label form of the regulated storefront platform exhibited here as Mako Refinery. The Mako Refinery exhibit describes the work from the first store's side — passkey-only auth, a sourced restriction engine, COA-gated publishing, AI product intake. This one is the other half of the same decision: one codebase, and a store is a set of data installed onto it rather than a copy of it. The premise is that nothing in the code should say which store it is, and that a second storefront should therefore be a second instance file, a second settings row and a second credentials directory — never a second branch.

An instance is five layers

  • The instance file — every name that says which checkout this is: the application root, the systemd unit and its description, the service user and group, the database and its role, the path to the database password, the keys directory, the listen port, the public host, the nginx site and log name, the TLS certificate name, the DNS zone and the backup buckets. Paths and names only: a value that looks like key material is refused before anything is exported, because the file is sourced by scripts that print their environment.
  • The brand row — every fact that says which business this is: name, legal entity, addresses, phone, place, timezone and licensing paragraph, read through one package and edited in the admin panel rather than compiled in. The compiled default is deliberately generic.
  • Capability settings — the age policy and the verifier that enforces it are an instance pair loaded at boot; the storefront shell fails closed to a gate while the capabilities are unknown, and the content-security policy for a document is built per request from whichever verifier is active.
  • Theme, legal and content files — the published policy texts and per-store copy as files beside the checkout, planned rather than shipped.
  • Credential files — a registry of named credentials with one resolution order, described below.

How the instance file is read

One shell library reads it and exports the values, and it is sourced by every script, by each just recipe in its first line, by the browser harness and by the hourly maintenance job; the systemd unit reads the same file through EnvironmentFile=, which is why its syntax is the subset both a shell and systemd parse identically. The Go binary reads the four values it needs once at boot, and the site URL, the passkey relying-party ID, the canonical origin, CORS, the write-origin guard and the age-verification callback all follow from them. The defaults are the first store's and live in that one library and nowhere else, so a checkout with no instance file behaves exactly as it did before the file existed, and a source pin fails the build on a store-specific literal written anywhere else. Precedence is environment beats file beats default, with one exception: a file named explicitly is a request to be that instance, so its values beat an inherited environment — which is what lets a shell already carrying one store's values render a unit for another.

The tracked systemd unit, vhost, cron entries and logrotate stanza are renders of templates, and the render scripts run in --check mode as part of the standard test recipe, so a template and its checked-in output cannot drift. The audit that accompanied this work turned up the failure mode worth naming: once the first store's instance file exists, every sourced script exports its port, so a scratch launcher that did not hand the child its own port would start a test server on the production one. Launchers now pass the port, database, root and instance name to the child explicitly, and the pin that looks for the bare port literal found a dozen more places still keyed on it.

Credentials as data, write-only

Vendor and boot credentials are a registry of named entries with a single resolution order — an explicit environment override, then a file written by the admin panel's Integrations card, then the default location on disk — read per use rather than cached at boot. The HTTP surface is write-only: a credential can be set, probed once against the vendor and removed, and there is no route that reads one back. A probe's result sentence is scrubbed of the value and of any word carrying its first characters, because vendors commonly label a key with an abbreviation of it, and the audit rows record the name, the source and whether it worked, never the secret.

A mirror, not a fork

This repository is regenerated, never edited. A publish script re-derives the source checkout commit by commit with git filter-repo against a fixed rule set: the first store's private material — its business records, handoffs, working notes, brand kit and instance file — is removed from every commit, and the strings that identify it are replaced with shaped placeholders. Because the rewrite is deterministic for a fixed rule set, each regeneration is a fast-forward of the last, and the script's own check is to run twice and compare the heads. Before anything is pushed, a leak scan reads the entire rewritten history for every banned string and every banned path, and the script exits before the push if it finds one; it also asserts that the rewritten head still checks out a tree that builds. Nothing is committed here by hand — a change wanted here is a change in the source repository, and the next regeneration carries it. Forking the mirror is reserved for the day a store needs code the platform will not carry.

What exists today

The platform and the publishing pipeline exist and are in use: the instance file, the brand row, the write-only credentials registry and the age-policy pair shipped and are running in production as the first store's own defaults, and the mirror is regenerated from that checkout. The remaining layers — the theme, legal and content files, and the installer that writes an instance file and stands a second store up from this mirror — are planned and not built. There is no second instance serving, no public URL and nothing to screenshot; the only running instance of this platform today is the first store, which has its own exhibit.

Straight from the source

The project's own README.

Rendered in place — every link, image, and code block carried over from the repo. The page below is what a contributor would see opening the project for the first time.

Mako Refinery

Storefront for Mako Refinery, a registered fictitious name of MEIUX MEIUX LLC (Florida). Lab-tested CBD and hemp products, kratom, kava and accessories, sold to adults 21+ only.

This repository is private and must stay private. It is not open source and carries no licence. HANDOFF.md contains the Florida sales-tax certificate and DOR business-partner numbers, both marked confidential — see the note in .gitignore for what has to happen before this could ever be made public.

Stack

Layer What
Backend Go 1.25, chi router, pgx/v5
Database PostgreSQL (makorefinery, owned by makouser)
Frontend React 19 + Vite + Tailwind, built into backend/web/
Auth WebAuthn / passkeys only — there are no passwords
Edge nginx on the box, Cloudflare in front

The Go service listens on 127.0.0.1:8080 only; nginx is the sole way in.

Where things are

backend/internal/     the application, one package per domain
backend/database/     schema.sql (generated) + migrations/
frontend/src/         React app; `npm run build` outputs to backend/web/
nginx/                the live vhost, mirrored from /etc/nginx (Mako's render of deploy/nginx/)
deploy/               templates for the unit, vhost, cron and logrotate; scripts/render-*.sh render them
instance.env.example  which store this checkout is; copy to instance.env (gitignored) — absent means Mako
scripts/              instance.sh, verify-schema.sh, browser tests, ops helpers
docs/                 subsystem documentation — start at docs/README.md
legal/                the published policy texts
HANDOFF.md            running project record; read this first

Common commands

just handoff-status  # begin/end a session with production context
just check           # formatting, vet, and full hermetic Go suite
just exposure-check  # served files, listener, sandbox, nginx, closed store
just preflight       # check + schema + exposure + production build
just deploy          # clean, pushed master only; deploy + live verification
just status          # health and production diagnostics
just logs            # recent backend service logs

# Lower-level commands remain available behind the recipes:
./deploy.sh deploy
./scripts/verify-schema.sh
./backup-database.sh       # see --help; 'schema-snapshot' regenerates schema.sql

node scripts/browser-test/edge-check.mjs   # what Cloudflare changes about our responses
sudo ./scripts/cloudflare-edge-fix.sh      # ...and turn those off over the API

deploy blocks if the migrations no longer reproduce schema.sql. Fix the drift, or --skip-schema-check to assert you have read the diff and it is harmless.

This directory is the live production checkout on a VPS shared with unrelated projects. Read AGENTS.md before operating it. GitHub is private, but only the Mako nginx/API/static-file surface is intended to be public; secrets remain in /var/keys and must never enter Git, logs, or backend/web.

Backend tests are hermetic and run in CI-style with go test ./.... Tests that need external resources are behind build tags, so they are opt-in:

go test -tags dbtest ./internal/analytics   # needs ANALYTICS_TEST_DSN
go test -tags gcslive ./internal/gcs        # costs real GCS operations

Two rules that bite

Schema changes need a migration, and schema.sql is generated. Never edit backend/database/schema.sql by hand — it is a pg_dump of production, regenerated by ./backup-database.sh schema-snapshot. Write a numbered migration, apply it, regenerate the snapshot, and confirm ./scripts/verify-schema.sh is still green. It compares the two and will tell you when they disagree.

Secrets live in /var/keys, never in the repo or the environment file. backend/.env holds tuning values only; the database password, the PII encryption key and the age-gate key are read from files at startup. See docs/backup.md for what is backed up where.

Documentation

docs/README.md is the index. docs/quick-start.md is the fastest way in. HANDOFF.md is the chronological record of what was done and why, and is usually the answer to "why is this like this".

Build something like this

Want a tool like this for your shop?

We've shipped this kind of thing before. Twenty-minute intro call, no slides.