Mayar Alaa Atelier

Before the first line of code, we decided what would not be built. Those decisions were taken ahead of implementation and written down in README.md section 7. Each of them removes a feature from the system — the gain is that what is left actually works.

No dress photographs: a dress is identified by its code (DR-101) and nothing else. No intermediate stage after a return either — the only question at return time is when the dress will be available to rent again, and the answer is stored in available_from and feeds straight into the booking check.

The security deposit has one fixed shape: an ID card plus cash, taken at booking, with a mandatory amount — create_booking rejects a booking without it. No printing, no invoices, no receipts. Notifications stay inside the system; not a single message goes out to a client.

Attendance is approved by the admin, with no location tracking. Sign-in is by mobile number: the word email appears on no screen, and the number is converted into an internal identifier on the .invalid domain reserved by RFC 2606. Measurements are detailed only — the text size (40) and the centimetre measurements were two descriptions of the same thing and contradicted each other, so the text size was removed in migration 0057. The backup is manual: an Excel file the admin downloads whenever she wants.

What makes this a system rather than a set of forms is one enforced flow that is not left to the interface. The booking lifecycle runs booked to delivered to returned, with cancellation available only from booked. Three legal transitions and no others; any move backwards or any skipped stage is rejected.

The guard sits on the table itself. guard_booking_status_transition (migration 0033, extended in 0039 to cover inserts) runs before insert or update on bookings, and it carries no exemption for the service_role. An illegal transition is rejected even from a script running with the server key, and it comes back as an explicit 42501 error. A new row must start at booked; a booking created in any other status is rejected. The only opening is a deliberate administrative correction (migration 0063): one step backwards, on the row named by its exact id, and locked for every other row in the same transaction.

Other rules sit around that cycle, all of them in the database: dress readiness at booking time through available_from, a GiST exclusion constraint that prevents two bookings overlapping on the same dress, a ceiling on payments, paid_amount recomputed from the payments record after every insert, update or delete, a guard that reverts any direct write to paid_amount, and a delivery that resets the deposit row to held. The practical result is that a booking and its payment record cannot disagree — and there is no path, not from the interface, not from a manual query, not from new code, that can make them disagree.

Two roles: admin and staff, and the difference is not cosmetic. Dresses, bookings, clients, deposits and expenses are open to both. Dress purchase prices, team salaries, the financial and profit reports, permanent deletion and settings are admin only. A staff member sees her own attendance record and cannot approve it herself, cannot edit a record after it has been approved, and cannot attribute an expense or a booking to somebody else — created_by is fixed from the session by a trigger.

Three layers on every protected route: proxy.ts, then the permission check on the server inside the page, then row-level security in the database. These layers appear across 47 source files. A staff member sees 8 of the 10 screens: reports and settings are removed from the navigation and also return a ForbiddenBlock from the server, and the staff screen is a completely different screen by role rather than the same screen with hidden elements.

Forbidden data never reaches the device in the first place. The local cache runs on an allow list rather than a deny list: any query root not written in PERSISTED_ROOTS is not stored, and there are exceptions inside an allowed root too — clients is allowed, but clients.detail is not, because it carries the national ID and the address. The check:offline script enforces that list.

The audit log. Twelve z_audit_ triggers on twelve tables write into audit_log: the table, the row, the kind of movement, who did it via auth.uid(), and the fields that changed with their before and after values. Every row carries an identifying snapshot that makes it readable on its own — booking code, dress code, client name — because a line with no identity is worth nothing in an investigation. The table has exactly one SELECT policy: writing comes from the security definer trigger, and deletion is refused for every signed-in role.

The door itself. The first sign-in stops at a change-password screen (migration 0045), and 5 failed attempts lock the account for 5 minutes, with the duration doubling on each attempt after that up to 60 minutes. Deactivating a staff member (is_active = false) actually cuts her access to every table through is_active_member() — not a hide in the interface.