Receipts docs
v1.1.0
Get help
● Reference · Versions

Changelog
what changed, when.

Every release, newest first, and how to update. Read the entry for your target version before you update.

011.1.0 · build, configuration check, tests

Current An update of 1.0.0. Nothing to migrate: the database schema, the settings and the Admin console's stored data are unchanged. After replacing the files, run pnpm install and pnpm build once (see How to update).

Added

  • Production build. pnpm build compiles the app and the bundled Admin Kit to dist/; pnpm start runs dist/src/index.js with plain node. tsx is a development tool only (pnpm dev). The build contains no test files.
  • Configuration check at start. PORT, PUBLIC_URL, the 0/1 switches, the Stripe keys, the Telegram bot token, ADMIN_EMAIL, ADMIN_SECRET_KEY, OTS_CALENDARS and FRAME_ANCESTORS are checked together. A wrong value stops the app with one plain line per problem ("Invalid configuration"); secret values are never printed. Demo mode refuses a live Stripe key.
  • FRAME_ANCESTORS: https origins allowed to show the public pages in a frame. Empty (the default) refuses every frame, as before.
  • Self-hosted fonts. Geist, Geist Mono and Instrument Serif ship in public/fonts/ with their licences; no page contacts Google Fonts and the Content-Security-Policy allows fonts from your own site only.
  • Code checks. pnpm lint (ESLint and Prettier), pnpm format and pnpm check (type check, lint and tests).
  • ADMIN_SETUP_TOKEN: the one-time secret (24 characters or more) that claims the operator account at /signup and creates the console owner at /admin on a fresh install. Without it the server prints a one-time setup code at start (First run).

Changed

  • Claiming a fresh install needs the setup secret. In 1.0.0 the ADMIN_EMAIL address alone could create the operator account. In 1.1.0 the sign-up also needs ADMIN_SETUP_TOKEN (or the printed setup code), compared in constant time; ADMIN_EMAIL, when set, is checked in addition. An install that already has an operator is not affected.

Improved

  • Leaderboard. A fresh install shows "No providers yet" with a link to the Studio; "No providers match these filters" appears only when a filter is on.
  • Admin console is the MIKODES Admin Kit 0.6.0 (compiled with the app; same settings, same stored data). Brand shows only the fields Receipts uses (no Website field); the console bundle in packages/admin-kit/ui ships readable (not minified). Its Content-Security-Policy allows no inline styles (style-src 'self' plus a per-response nonce), and with TRUST_PROXY=1 its sign-in limits use the right-most X-Forwarded-For entry, like the rest of the app. Operations pages inside the console open in the console's theme straight away.
  • Code layout. The web layer is split by area (checkout.tsx, studio.tsx, receipt.tsx, pages.tsx, studio-routes.tsx); the largest source file went from 2,781 to about 1,350 lines. The console-frame script is a readable file, public/embed.js.
  • Footer and forms. The footer brand mark is aligned like the header; the Discord webhook field in the Studio has a label.
  • Busy port. Reported in one sentence instead of a stack trace.

Fixed

  • Provider slugs keep accented letters as plain letters ("Désk" becomes desk, not de-sk). Existing slugs do not change.
  • Install folders with spaces: the Admin console interface is found.
  • Members page in the console (/ops/users) opens for console accounts that have no site account; it failed as soon as one member existed.
  • Team page for a viewer: the console no longer requests the member list, which a viewer may not read.
  • /favicon.ico answers with the site icon; the Admin console page logged a 404 for it.

Dependencies and tests

  • TypeScript 6.0, Vitest 5.1, Vite 8.3.6 (development only). The tests run without the punycode deprecation warning, like pnpm start. pnpm audit and npm audit report no known vulnerabilities.
  • 194 automated tests in 15 files (126 in 9 files in 1.0.0). New: configuration, the setup token for the operator claim and the console owner, accounts and sessions, the proof chain with the offline verifier run on real, batched, hidden and tampered bundles, OpenTimestamps stamping and confirmation, Discord delivery, settings, framing, fonts, the build and start scripts and the public pages' empty states.

021.0.0 · first marketplace release

First CodeCanyon release.

  • Signals with proof. Every signal and every change is sealed in a SHA-256 hash chain per provider; seals are grouped into a Merkle root and timestamped in Bitcoin through the public OpenTimestamps calendars; optional Ed25519 provider signatures; verification in the browser (/verify) and offline (scripts/verify-bundle.mjs).
  • Results from the market. Follower-reachable results from public 1-minute candles (Binance and Bybit), an evidence-based leaderboard and provider pages with risk metrics.
  • Marketplace. Provider Studio (publishing, plans and trials, analytics, payouts, TradingView webhook, Telegram bot and Discord publishing), member area (follows, feed, notifications, Web Push, paper portfolio), payments by Stripe, bank transfer or USDT/USDC to your own wallets with an approval queue, VIP chat-group gating.
  • Operator console at /admin (MIKODES Admin Kit 0.4.0): fees, payment methods, integrations, team roles, two-factor sign-in, audit log, and the marketplace operations pages. Every revenue option starts switched off.
  • Security and packaging. Content-Security-Policy without unsafe-inline or unsafe-eval; paid access granted only by signed Stripe events or operator approval; no minified file and no vendor/ folder.

03How to update

  1. Read the changelogFor your target version.
  2. Back upThe databases and .env (how).
  3. Stopsudo systemctl stop receipts
  4. Replace the program filesKeep your .env and the data/ folder.
  5. Installsudo -u receipts pnpm install --frozen-lockfile (or npm install).
  6. Buildsudo -u receipts pnpm build (or npm run build).
  7. Startsudo systemctl start receipts and watch journalctl -u receipts -f.

The database schema is applied automatically at start-up. If a release needs a manual step, its entry says so. If you changed code, keep your changes in git so an update is a merge.