v1.0.0 — 19 reference applications

The first tagged state of this repo. Everything here has been on main for a while; this
tag exists so you have something stable to pin, cite, and diff against.

What's in it

19 complete applications under apps/<industry>/<name>/, across healthcare, life
sciences, fintech, insurance, marketplace, CRM, marketing, customer support, field service,
mobility, hospitality, fitness, real estate and media.

Every app ships the same 11 files — README.md, CLAUDE.md, CUSTOMIZATION.md,
schemas.py, setup.py, config.py, .env.example, run.sh, Dockerfile,
docker-compose.yml, ui/app.js. Read one and you have read all of them.

All 19 are running live at <name>.supero.live (checked 2026-09-06).

Four run several organisations on one deployment — medora (3 hospitals), helix
(3 sites), lattice (3 managers), pulse (3 locations).

They are genuinely different applications, not one template renamed. Measured across
eight sampled ui/app.js files: 8 lines are shared by all eight, and all of those are
boilerplate. Median pairwise line overlap is 2.8%. The two gyms — pulse and pulsefit,
same vertical, same nouns — are the least similar pair in the sample.

Zero build step. React and Tailwind load from CDN. No bundler, no node_modules, no
npm install. Edit ui/app.js, refresh the page.

About two minutes from clone to running. Measured on a clean container with an empty pip
cache: roughly 10 seconds of install and 63 of platform setup. No account, no invite, no
credit card — domain registration is open.

MIT for everything in this repo.

Docs

Nine guides under docs/: quickstart, mcp, architecture, api-reference, schemas,
services-and-workflows, admin-panel, deploy, deploy-to-cloud.

CI

Every push and PR runs tracked-secret and credential-pattern scanning, a check that no real
domain or internal citation leaked into a public file, a required-file check across all 19
apps, and py_compile on every schemas.py and config.py. A weekly job re-checks that
every advertised live URL still answers.

Fixed in this release

• docker compose up was broken in all 19 apps. WORKDIR created /app as root and
  COPY --chown only chowns the entries it copies, not the directory, so run.sh failed
  with Permission denied: '/app/.venv'. Fixed in every app.
• Four apps could not complete their own first run. pulse, medora, helix and
  lattice shipped .env.example with no SUPERO_PASSWORD field, a already-taken domain as
  the default, and PORT=5648 for all four — colliding with each other and contradicting
  their own Dockerfiles. All 19 ports are now unique.
• Documented CRUD paths did not resolve. GET /crud/{Type} returns 405; the real route
  is /api/v1/crud/{domain}/{obj_type} and the path segment is snake_case. Corrected across
  the docs and 15 CLAUDE.md files.
• Corrected counts. The README said "15 applications" while its own tables listed 19.
  Service-enablement counts in docs/services-and-workflows.md were recounted directly from
  all 19 config.py files.

Known limitations — read this before you build on it

• This is open-core. The app source here is MIT and genuinely yours. The platform these
  apps call (api.supero.dev) is a hosted service and is not open source. See "How this
  works, honestly" in the README.
• Not certified for regulated data. lumen, brightsmile and trialcore demonstrate
  the shape of healthcare access control. They are not HIPAA-certified and ship with no
  BAA. sentinel and ledgerline are not PCI or SOC 2 attestations. Running an app as
  shipped transmits what you enter to api.supero.dev. Treat everything here as a
  synthetic-data demonstration until you have the agreements you need — SECURITY.md is
  specific about what to ask for.
• Three apps ship without tests. fitness/pulse, life-sciences/helix and
  real-estate/lattice have no tests/ directory; the other 16 have full suites.
  Contributions welcome.
• CI does not run the app test suites. They run against a live domain, so they cannot run
  unauthenticated on a fork PR. CI checks structure and secrets, not behaviour. Run
  ./tests/run_tests.sh yourself against your own domain.
• No existing test asserts a field-level access claim. The suites cover CRUD paths. If
  you are relying on a specific field staying out of a response, write that assertion
  against your own deployment rather than assuming it is covered here.
• Field hiding covers the types you declare in your own schemas. Platform-managed types
  — accounts, API keys, domains, projects, tenants — are governed by role permissions, which
  is a different mechanism. hidden_fields does not extend to them.
• Field hiding is a server-side response filter, not a database-level projection. The
  field is removed before the response is written, not withheld from the query.
• Connector-backed reads follow a different enforcement path from native CRUD reads. If
  you point an app at your own database, verify the behaviour for your configuration rather
  than assuming it matches the examples here.