A tour of the system

This system has four roles: the person who buys, the one who organizes, the one who reviews, and the one at the door. This page says what each does, what it proves, and how to see it yourself right now.

The four roles

The buyer

Discovers an event, holds a ticket for ten minutes, pays, and receives a digitally signed ticket — and can request a refund under stated terms.

What it proves: Atomic reservation (twenty buyers, two tickets → exactly two win) · VAT by subtraction, never re-multiplication · a double-entry ledger balanced to the fils · a purchase completed in 2.8 seconds, measured on every run.

Start from the home page

The organizer

Creates a bilingual event with its ticket types, tracks sales and payouts, and can cancel an event so every buyer is refunded immediately.

What it proves: Complete tenant isolation: not one route accepts an organizer id from the client — it comes from the session alone · and cancellation books the shortfall as the organizer’s debt, not the event’s.

Open the organizer panel

Email: studio@hibr.example
Password: sidr-sadu-5292; The account is reset daily — what you change is wiped, and the next visitor sees the intended state.

The admin

Reviews events before publishing, searches orders with their ledger entries, disables an organizer with a written reason, and reads the daily financial reconciliation.

What it proves: Two-factor auth built on node:crypto alone and tested against RFC 6238 vectors · an audit log that refuses updates and deletes via a database trigger · reconciliation that guards every ledger leg, not just their sum.

See the sign-in screen

Not open to visitors: two-factor authentication is mandatory via a NOT NULL column in the database, and publishing its secret would mean publishing the key to a panel that issues refunds and disables organizers. The constraint itself is what prevents showing it — and that is precisely what it proves.

The gate scanner

A Flutter app that scans the ticket code at the door and decides **with no internet connection**: admit, already scanned, or refuse.

What it proves: Verification with a public Ed25519 key — unpacking the app yields what verifies, not what signs · duplicate scans across two devices resolve by earliest scan time, not fastest upload · verified against a real production ticket.

Open the scanner

A standalone Flutter app — about 8 MB on first load. Paste a ticket code and a public key and watch the verdict happen locally, with no call to our server.

What the screen does not show

Most of this project never appears in an interface. These are examples, each proven by a command rather than a claim:

A double-entry ledger with a deferred trigger that rejects any unbalanced group at COMMIT — corrections are reversing entries, never deletions.
All money arithmetic in one package at 100% branch coverage, in integer minor units, never floating point.
Mutation testing on the critical claims: break the line deliberately, confirm a test fails, restore it.
A discovery assistant that works with no language model: retrieval is deterministic, and the model — when a key exists — phrases a sentence and computes nothing.
Eighty evaluation examples across seven dialects and registers, run in CI at zero cost.
Continuous WAL archiving and a restore drill performed on production in both directions.
Eighteen written architecture decisions, including the ones that were overturned and rejected, with reasons.

Numbers, gates, and traps on the evidence page

What does not work — stated here, not discovered

The payment gateway is simulated: no real money, and no card data passes through any server.
Email does not actually leave: no verified domain or email provider yet — which is why there is no “email me my orders”.
No buyer account: checkout is guest, and orders are remembered on your device alone, not across devices.
No error tracking or alerting: an observability layer was built and then deleted because it leaked data — the decision is written in ADR-0018.
The launch gate was run honestly: 21 of 57 items green. The strength is in engineering; the weakness is in product and operations.