Mario Sanchis
Colomer.

01

Login and authentication

A single sign-in screen for the shop’s three roles (Administrator, Shop Manager, Mechanic) — the role travels already resolved inside the login response and signs the JWT.

The central technical decision: the SPA never touches the token. The backend sets the JWT as an httpOnly + sameSite=strict cookie, secure in production, so no client-side script can read it — the natural protection against XSS. The interceptor only turns on withCredentials so the browser attaches the cookie automatically, and the authentication strategy also accepts a Bearer header as an alternative path for tools such as Swagger or curl during development.

Authorisation is revalidated in two layers: the route guard in Angular filters what each role sees as a user-experience layer, and the backend revalidates the role on every request by reading the JWT, additionally reloading the user from the database to check they are still active.

Every successful login and every logout is audited with the IP address. Failed attempts are not recorded individually — rate limiting (5 attempts per minute per IP) already contains brute force, so the audit trail focuses on the system’s legitimate activity.

02

Operational dashboard and appointment calendar

The panel’s four indicators (monthly revenue, vehicles in the shop, stock alerts, today’s appointments) are computed with direct aggregate queries against PostgreSQL on every load, with no intermediate cache layers.

The stock alert threshold is configurable per part, and triggers both the dashboard counter and the corresponding notification.

The weekly calendar shows customer appointments, colour-coded by status and with direct access to each one’s detail. The scheduler’s output — each job’s estimated completion date, computed by the assignment engine — is consulted in the detail of each repair order, where the heaviest logic of the project lives.

Notifications combine events generated on the spot (a new order, low stock, an issued invoice) with three scheduled tasks covering what is not instantaneous: overdue invoices, orders unassigned for more than three days, and unconfirmed appointments. It is a system separate from the audit trail: one alerts a human about something actionable, the other leaves a forensic record of who did what.

03

Invoicing and PDF generation (fictional data)

The invoice PDF is generated on the client itself and downloaded straight to the user’s machine. The email notice is a separate document: an HTML built on the backend with the invoice’s key data (number, amount, dates, IBAN), designed to notify without depending on attachments.

The invoice state machine follows the Issued → Paid → Voided cycle, with a rule grounded in regulation: a paid invoice can be voided by issuing a corrective invoice, never by deleting it, in accordance with Spanish RD 1619/2012 on payment reversal.

The due date is treated as a fact derived from the current date, not as a value that depends on a scheduled process updating it: every morning, the system reviews issued invoices whose due date has already passed and generates the corresponding notice.

Every invoice line supports a percentage discount, correctly computed and applied to the final amount — the basis for special rates or one-off negotiations per customer.

04

Inventory and stock traceability

The parts list uses a traffic light based on proximity to the configured minimum: below the threshold it flags a low-stock alert, feeding both the dashboard counter and the notification system, with a second visual level that anticipates which parts are approaching that point.

Every stock movement — consumption when a part is used in an order, reversal when a line is deleted, replenishment through the restocking flow — is recorded in a history with type and reason, which makes it possible to reconstruct at any moment how each reference reached its current level.

The panel summarises at a glance the total stock value, the number of references and the parts below minimum, computed over the loaded catalogue.

05

Mechanic assignment and scheduling engine

This dropdown is the centrepiece of the scheduler. When assigning (or reassigning) a mechanic to an order, the system computes that professional’s next available slot within working hours and chains the new job right behind their current queue, with no overlaps possible by construction. The result — start date, end date and estimated date — is audited and generates a notification to the mechanic with their start time.

The order state machine follows the Created → Assigned → In Progress → Finished → Invoiced flow, with two backward transitions deliberately allowed: from Finished to In Progress, to reopen a job if a defect is found after closing, and from In Progress to Assigned, to correct an assignment. Invoiced is the only terminal state. Four business guards protect the flow: an unfinished order cannot be invoiced, an order admits a single invoice, and lines of an already closed order cannot be modified.

Choosing "Invoiced" in the dropdown triggers the creation of the corresponding invoice, and it is the invoice that drags the order into that state — the state is always the consequence of a real business fact, never a direct, isolated change.

The counters (Pending, In Shop, Finished) and the filters by status, mechanic and customer are resolved over the data already loaded on the client, with chained signals — instant filtering, with no round trip to the server.

06

Dark theme and system audit trail

Dark mode combines PrimeNG with a set of custom CSS variables under a single switching point: a class on the root element that both systems consume at once, avoiding duplicated theme logic between the component library and the custom styles. The dashboard calendar, depending on an external library with its own visual system, observes that class change to stay in sync with the rest of the interface.

The audit panel is read-only: there is no write path to that table anywhere in the application, and access is restricted to Administrator and Shop Manager through role guards enforced on the backend. Each record ties together date, user, action and affected entity, leaving a clear trace of who did what and when — login, logout, creations, modifications and voidings are all covered.

01

Sign-in and session isolation

Access uses the same pattern as the rest of my ecosystem: passkey (WebAuthn/Face ID) as the main route, with username and password as the alternative. The deliberate difference here is isolation: the session cookie is host-only and never travels to any other subdomain, and each passkey is bound to POLYBOT’s exact domain, so a credential registered here does not work on any other project, or the other way round.

There is no user table and no roles — it is a single-operator system — but it protects the read-only panel and every action endpoint alike: starting or stopping a bot, pausing a market, changing any parameter.

02

Operational dashboard

A financial and operational view of the whole fleet: accumulated performance, hit rate, number of operations and on-chain balance, with a cumulative evolution curve filterable by period. Each active market shows its own card with live status — running, automatically paused by the risk manager, or disabled — so the real state of the entire system reads at a glance.

It includes a privacy mode that blurs any sensitive figure while keeping the shape of the curve and the rest of the layout intact, meant for screen sharing or documenting the project without exposing financial data. It is the mode every capture in this section was taken in.

03

Cross-market ranking

A comparison of every active market, sorted by different performance metrics, computed entirely on the server — the client only formats and displays what already arrives sorted.

The comparison period is selectable, and every change of time window recomputes against the real data instead of serving a precomputed view. The table order always answers a specific question ("which market is doing better by this metric"), it is not a free exploratory table.

04

System health

A monitoring panel for the critical processes that keep the system running: when each scheduled task last completed successfully, not simply when it was last attempted — an important distinction, because a process that fails repeatedly is still "running" even though it never succeeds. Each type of task has its own normality threshold according to its nature.

Anomaly detection and alert delivery happen entirely independently of this screen, in a separate process: that way, if the visible part of the system were to fail, the alerts would still arrive.

05

Notification system

A centralised notification tray, the result of a full redesign of the alerting system. The previous version sent the same notice several times because of a time-based design flaw; the current version identifies each alert by its actual content, not by when it was generated, avoiding duplicates.

Only genuinely actionable events arrive as a push notification on the phone — everything else stays available in the tray to be consulted when needed, without interrupting.

06

System settings

A general configuration panel: push notification management, registration of the biometric access credential, appearance and sign-out — with two additions specific to a system that trades real money.

The first is a manual control over the system processes (API, scheduled agents, the set of per-market bots), designed as a deliberate emergency switch after retiring the external messaging channel that used to partly fill that role.

The second is privacy mode itself, which blurs any sensitive figure across the whole interface so the system can be screen-shared or documented without exposing financial data — the very function used to prepare the material for this portfolio.

07

Operations record

Every operation is recorded with full identification of the market, the exact moment, the direction taken, price, size, status and final outcome, together with complete traceability of how the order was executed.

The system also keeps a set of internal model metrics from the exact moment the decision was taken, which are not shown publicly because they would reveal the internal entry criteria.

08

Analytics: model diagnostics

An analysis layer distinct from both the ranking (which compares markets against each other) and the dashboard (which summarises financial state): here the prediction model itself is audited to check whether it behaves as expected.

It includes eleven aggregated visualisations over the full history — from a calibration curve comparing the model’s estimated confidence against the actually observed hit rate, to performance cross-cut by different dimensions of the forecast and of the operation. It is the screen that answers "is the model behaving consistently?", not "am I making money?".

09

System logs

A custom and deliberately simple logging system, with no external tooling in between: it gathers the log of each market plus the agent scheduler and the API, normalises the format of every source into a single chronological view, with filters by origin and free-text search.

It prioritises operational simplicity over the sophistication of a full observability stack, in keeping with the real scale of the project.

10

Timeline: human-readable traceability

A chronological feed focused on business events rather than technical logs: operations opened and closed with their outcome, risk manager regime changes with their rationale, market pauses and resumes, alerts from the monitoring system and manual actions by the operator.

What makes this layer distinctive is that it unifies several heterogeneous data sources —the operations history, the agent snapshots, a write-only audit record, the alert state and the calibration model— into a single coherent timeline, deduplicating events so the same operation is never shown more than once. It covers both what the system did autonomously and what the operator did by hand.

11

Per-market and global configuration

A layered configuration system: a set of global values acting as default behaviour, and the ability to override them independently for each active market, applied hot with no need to restart the system. Each market can also be paused or resumed individually from its own view.

Which specific parameters are configurable is not detailed publicly, as it forms part of the internal strategy criteria.

01

Login and passkeys

Day-to-day access uses no password: it is a standard passkey (WebAuthn), with Face ID as the gesture that unlocks the credential on the device itself. Verification happens directly on the server, with no intermediate service — the backend validates the cryptographic assertion with the standard WebAuthn library in Python.

Registering a new passkey is done from Profile, each device with its own credential, which makes it possible to enrol the phone and the laptop separately. The username and password form always coexists as an alternative path, in case the device does not support biometrics or that route is simply preferred.

02

Today and autosave

The day’s routine resolves itself: the system consults the weekly planner (the same one edited in Routines) and shows the session due right away, with no need to look for it.

While training, progress is saved locally on the device continuously — every weight and rep entered, every completed set. Closing the application mid-session loses nothing: on reopening, the session is restored in full, including the rest timer, which recomputes the remaining time against the real clock instead of relying on a counter that would have been left running in the background. A new personal record is computed when the session closes, comparing the maxima achieved against the whole history. The application works offline: if the upload to the server fails, the session is queued and syncs as soon as the network is back.

03

History

Every session is recorded with its total tonnage moved — the sum of weight times reps of every completed set — and the personal records achieved that day, grouped visually by month. Cardio sessions (such as walking) share the same data model as strength ones, distinguished simply by their exercise type, which keeps the whole history in a single coherent place.

04

Routines and weekly planner

The routine catalogue supports real supersets: two linked exercises where rest does not start until both complete the corresponding set, exactly the way a superset is actually trained at the gym. Each routine is assigned to one or more days of the week from a simple planner, and that mapping is exactly what the Today screen consults to know what is due each day.

The warm-up lives as its own checklist, independent from the strength routines, reachable at any moment from a shortcut.

05

Exercise catalogue

The catalogue starts from a base set and grows with custom exercises at any time, each defined by its name, its muscle group and its type (weight and reps, or time). As soon as an exercise accumulates any record in the history, it automatically becomes available on the Progress screen, with no additional configuration step.

06

Coach: automatic progression

A single button triggers a complete analysis of the training history. The logic that decides what to progress is entirely deterministic: cyclic double progression around a per-exercise rep target — if the top has not been reached, it suggests adding reps; if the top holds for several sessions, it suggests adding weight and starting the cycle again from the base. Time exercises follow their own progression towards the duration target.

A language model run locally (Ollama) writes the natural-language summary that accompanies the recommendations — its only function is the wording; the progression decision is already made before the model intervenes, which keeps the system reliable even if the language model is unavailable at that moment.

07

Progress: hand-drawn charts

The evolution charts are built in pure SVG, with no visualisation library in between — a deliberate decision against far heavier alternatives for what actually needs showing: a progress line, a record and the current point. Each chart automatically scales the value range, keeps the line thickness constant regardless of screen size, and responds to touch or cursor with a dot marking the exact value on any given week.

The time axis is built by calendar weeks, showing the recent evolution of each selected exercise, with the unit of measure (kilos, seconds or minutes) choosing itself according to the exercise type.

08

Profile: statistics and rest alert

The global summary gathers total sessions, accumulated tonnage and records achieved. The rest alert uses real operating-system push notifications — not an alert inside the tab itself — so it arrives even with the phone locked or the application closed, with a custom sound cue designed to be audible on a phone speaker even in silent mode, plus vibration.

Registered passkeys are also managed from here, along with dark mode, which persists across sessions with no need to set it up again every time.