Ledningssystem för TL Systems arkitektur
TL Systems styrs av dokumenterade processer för arkitektur, kodkvalitet och förändringskontroll. Den här sidan är till för IT-avdelningen, upphandlingsteam och alla som vill förstå — eller granska — hur systemet är konstruerat.
Säkerhetsimplementation i detalj (kryptering, sessionhantering, rate limiting): /security
Kod styrs av en konstitution
TL Systems styrs av ett trelagers styrdokumentsystem modellerat efter svensk förvaltningsrätt: en grundlag med nio oföränderliga principer, lagar som preciserar principerna per område och föreskrifter för tolkningar och stilguide. Varje kodändring måste vara förenlig med grundlagen. Konflikter löses alltid uppåt i hierarkin.
9 principer — trelagersmodell, app-isolering, fail-closed, audit, context window-disciplin, kodkvalitet, i18n, feature gates, strategisk checklista.
Preciserar grundlagen per område: arkitektur, kvalitet, säkerhet, uppdrag, horisont, admin, prestanda. Sammanfattning först — appendix vid behov.
Tolkningar och stilguide: färger, typografi, ikoner, ton. Underordnade grundlag och lag vid konflikt.
Ändringsprocessen kräver skriftlig motivering och godkännande. Inga tysta revisioner. En korsreferenscheck verifierar att inga befintliga lagar påverkas utan att uppdateras i samma ändring.
Tre lager — tre separata system
Varje app har tre distinkta lager med separat autentisering, separat URL-struktur och separat målgrupp. De blandas aldrig. En chaufför vid kiosken och en administratör i dashboarden använder tekniskt skilda system som delar databas men inte auth-flöde.
| Lager | Autentisering | Målgrupp | Anmärkning |
|---|---|---|---|
| L1Publik | PIN eller öppen — aldrig lösenord | Chaufförer, besökare, externa | Flera instanser per enhet. Unik URL, QR-kod och platsdata per instans |
| L2aOps | IP-vitlista (CIDR) + PIN | Expeditionspersonal — dedikerad operativ skärm | En per enhet. Uppe hela dagen. Ersätts aldrig av dashboarden |
| L2bDashboard | Supabase Auth (e-post + lösenord) | Enhetschefer, admins | Read-only viewports mot ops-data. Inga direkta operativa funktioner |
| L3Inställningar | Supabase Auth + adminroll | Systemadministratör | Branding, nätverksspärr, GDPR-perioder, per-app-konfiguration |
Fyra appar — inga delade tabeller
Varje app äger sina databastabeller, sitt settings-namespace, sina API-routes och sina typer. Ingen app får importera en annan apps tabeller direkt. All datadelning sker via explicit definierade kontrakt i ett delat bibliotek. En automatisk gränskontroll verifierar detta vid varje kodändring.
| App | Äger tabeller | Settings-namespace | Funktion |
|---|---|---|---|
| TL CheckIn | checkins | checkin.* | Ankomstregistrering, kiosker, QR-check-in |
| TL Dock | ports | dock.* | Porthantering, lastkaj-tilldelning |
| TL OnHand | onhand_orders, onhand_lines | onhand.* | Lagertid IN/UT, debiteringsunderlag |
| TL SiteManager | (inga egna) | site.* | Enhetens OS — alltid aktiverad, kan inte stängas av |
Unix-principen gäller även vertikalt: en högre nivå (t.ex. plattformsadmin) frågar aldrig en lägre nivås tabeller direkt — utan via kontraktsfunktioner i det delade biblioteket.
Misslyckas säkert — alltid
Systemet är designat för att stängas ned vid osäkerhet — inte för att hitta en väg igenom. Inga tysta fallbacks. Inga optimistiska antaganden om konfiguration eller behörighet.
Saknad miljövariabel kastar — aldrig fallback
requireEnv() kastar ett undantag om en konfigurationsvariabel saknas. Tjänsten startar inte i ett oklart tillstånd.
Feature gate i API:et är den auktoritativa barriären
Sidebaren döljer stängda appar som UX-hjälp. API:et blockerar alltid oavsett frontend. Öppen gate i API:et med dold sidebar är ett konstitutionsbrott.
PIN returneras aldrig i klartext
API-svar innehåller aldrig PIN-värdet — enbart boolean (finns/finns inte). Server-typer och klienttyper är separata interfaces utan överlapp.
Varje mutation loggas — inga undantag
Varje POST, PATCH och DELETE kräver audit(). Saknas det är det ett stopp-villkor vid kodgranskning. 39 händelsetyper täcker alla mutationer i systemet.
Tenant isolation i varje databasfråga
unit_id-filter är obligatoriskt i varje query och API-route. En enhet kan aldrig se eller påverka en annan enhets data — oavsett hur API:et anropas.
Kryptografiska detaljer (scrypt-parametrar, timing-safe jämförelser, sessions-expiry): IT-säkerhet
Operativa skärmar: noll spinners
Expeditionsskärmarna (Layer 2a) är byggda för att vara omedelbara. Server-side Suspense Streaming innebär att header och skelett renderas server-side och att data streamas direkt från databasen — utan ett enda klient-API-anrop vid initial laddning.
Realtime-uppdateringar appliceras som deltan i lokal state — ingen omladdning av all data vid varje händelse. Smart polling kompenserar automatiskt vid tappad WebSocket-anslutning.
En kiosk slutar aldrig fungera
Om servern är nere, underhåll pågår eller nätverket försvinner — ska en chaufför vid kiosken fortfarande kunna registrera sig. Registreringarna köas lokalt och synkas automatiskt när förbindelsen återställs.
Lokal kö med automatisk synk
Registreringar som inte kan skickas lagras i webbläsarens localStorage. En bakgrundsprocess synkar dem med exponentiell backoff (2–30 sekunder) så snart servern svarar igen.
Underhåll stoppar aldrig kiosken
Under planerat underhåll visar kiosken ett meddelande med en "Registrera ändå"-knapp. Chauffören kan registrera sig som vanligt — data köas och synkas när underhållet är klart.
Operativ skärm: tydlig tidsstämpel
Ops-skärmen visar alltid senaste datatidsstämpel. Om data är äldre än 60 sekunder visas en varningssignal — ingen tyst inaktuell data.
Köbarhet avgörs per operation
Append-only-operationer (ankomstregistrering, godsmottagning) köas. State machine-operationer (porthantering, godsutlämning) kräver live-data och köas inte.
Processer för kvalitetssäkring
Arkitekturprinciper fungerar bara om de följs upp. TL Systems har dokumenterade processer för förändringskontroll, intern revision och kontinuerlig förbättring — med definierade in-/utdata och tydliga godkännandekriterier.
27-punkts Quality Gate
Ingen ny app godkänns förrän alla 27 punkter besvarats med ja eller "ej tillämpligt" med motivering. Täcker konstitutionsefterlevnad, säkerhet, i18n, skalbarhet och drift.
16-punkts ändringsaudit
Körs efter ny feature, ny app eller arkitekturbeslut. Inkluderar lagbok-konsekvens: påverkar ändringen ett mönster i en annan lag, uppdateras den i samma PR.
Importgränskontroll vid varje kodändring
En automatisk gränskontroll verifierar att ingen app importerar en annan apps tabeller direkt. Körs som del av kodgranskningsprocessen.
Kvartalsvis agenttest
En ny AI-agent startas i en ren session, ges enbart styrningsdokumenten och ombeds implementera ett standardscenario. Varje avvikelse dokumenteras och åtgärdas i dokumenten — inte bara i koden.
Processstrukturen är utformad i linje med principerna för systematiskt kvalitetsarbete — dokumenterade ansvarsförhållanden, uppföljningsbara granskningsprocesser och löpande revidering av styrdokumenten.
Relaterade dokument
Frågor om arkitekturen eller ledningssystemet?
Kontakta oss på kontakt@tlsystems.se — vi svarar gärna på tekniska frågor inför upphandling eller IT-granskning.
Kontakta oss