Core Architectuur & Database: Google Spreadsheet (1Rap-6ENmSOwF-lkSZuwxxkJfVWVyfNqRsSD0h9L4uF8)
Beheerders: PadelStijn@gmail.com & Stijn.Gabeler@gmail.com
Versie: 4.2 Enterprise-Grade Padelmanagement & Didactiek
PadelOS is opgebouwd als een robuust relationeel systeem binnen Google Sheets en Google Apps Script. Hieronder volgt het volledige overzicht van alle kernmodules, tabbladen en hun technische betekenis:
Betekenis: Het didactische hart van PadelOS, gebaseerd op het progressiemodel (A1: Technische basis, A2: Waarnemen & Kiezen, B: Spelrealistische toepassing) in combinatie met de 5 basisfuncties / bedoelingen van het spel (BEDOELING: B1 t/m B5: Voorkomen van scoren, Neutraal, Opbouwen, Uitlokken, Scoren).
Cruciale Kolommen (A1_A2_B):
FASE_ID, SLAG_ID, NBF_ID, FASE (A1, A2, B), DOEL, OPDRACHT, WAARNEMEN, KIEZEN, UITVOEREN, SPELREALITEIT, SUCCESCRITERIUM, COACHING_CUE.
Werking: Wanneer een trainer een lesreeks of lesvoorbereiding start, genereert de AI_LESGENERATOR via de PADELSOCRATES_COACH_ENGINE_V1 een samenhangend blok waarin de slagfrequentie, de tactische bedoeling en de socratische coachvragen automatisch worden gekoppeld aan het niveau van de speler.
Betekenis: Beheert alle fysieke locaties (zoals TPC Daalmeer in Alkmaar) en de daadwerkelijke baancapaciteit.
Cruciale Kolommen (BANEN & CLUBAFSPRAKEN):
LOCATIE_ID, NAAM, NUMMER, TYPE (indoor/outdoor), BAANPRIJS, ANNULERINGSREGEL, WEERREGEL, SLEUTELREGEL.
Werking: Voorkomt dubbele boekingen en koppelt lessen direct aan de juiste clubafspraken (zoals KNLTB ClubApp integraties voor leden of Meet & Play voor externe huur).
Betekenis: Het operationele rooster waarin losse lessen, reeksen (bijv. 10-weekse cursussen) en lesaanvragen van spelers samenkomen.
Cruciale Kolommen (LESSEN):
ID, TITEL, TYPE (GROEPSLES, DUOLES, PRIVE), LEVEL, START_AT, END_AT, TRAINER_ID, BAAN_ID, STATUS.
Betekenis: De dynamische tabbladen waarin trainers tijdens of na een les directe feedback, niveau-updates en specifieke actiepunten per speler vastleggen.
Kolommen (OBSERVATIES): ID, LES_ID, SPELER_ID, TRAINER_ID, NOTITIE, TECHNISCH_NIV, TACTISCH_NIV, STATUS, CREATED_AT, UPDATED_AT.
Betekenis: Het geautomatiseerde beheersysteem dat afmeldingen van spelers opvangt en beoordeelt op tijdigheid en inhaalbehoefte.
Kolommen (AFMELDINGEN): ID, LES_ID, SPELER_ID, REDEN, TIJDIG, ACTIE, INHAAL_NODIG, STATUS, BERICHT, CREATED_AT, UPDATED_AT.
Betekenis: Beheert interne beheerstaken (ADMIN_TAKEN), kalenderintegraties (AGENDA_EVENTS) en gesegmenteerde communicatiekanalen (BERICHTEN_TEAM, BERICHTEN_ADMIN, BERICHTEN_SPELERS, BERICHTEN_FINANCIEEL).
Les Aanvragen: Ga naar je dashboard en vul de wizard in via requestLesson. Geef je speelsterkte, gewenste dagen, tijden en leerdoel op.
Voortgang & Leerdoelen: Bekijk je persoonlijke SPELER_LEERDOELEN om te zien welke technische en tactische slagen je beheerst volgens het A1-A2-B model.
Communicatie: Gebruik de gesegmenteerde chat (BERICHTEN_SPELERS) voor al je vragen over lessen of afmeldingen.
Lesvoorbereiden: Raadpleeg vóór elke les de AI_LESGENERATOR en de A1_A2_B tabellen voor socratische coachvragen en meetcriteria.
Beschikbaarheid & Uren: Geef uren en beschikbaarheid door via saveTrainerAvailability voor automatische roostering.
Observaties: Leg direct tijdens of na de les notities en niveau-updates vast per speler in het OBSERVATIES-tabblad.
Systeembeheer: Beheer de core via setupPadelOS12345 op de spreadsheet.
Financieel & Administratief: Controleer BERICHTEN_FINANCIEEL, BETALINGEN en CLUBBETALINGEN om facturatie en vergoedingen te scheiden.
Audit & Beveiliging: Controleer mutaties via de AUDIT_LOG tabel met HMAC-SHA256 encryptie.
V1-V45: Technische grondslagen, API-endpoints, authenticatie, database-initialisatie en rolgebaseerde autorisaties (reeds verankerd in de core backend).
V46: Hoe zorgt de functie requestLesson voor een naadloze koppeling met het spelerprofiel? Zoekt direct gegevens op in de PROFIELEN-tabel voor naam en speelsterkte.
V47: Hoe registreren trainers hun beschikbaarheid en uren binnen PadelOS? Via saveTrainerAvailability naar de TRAINER_BESCHIKBAARHEID tabel.
V48: Hoe waarborgt PadelOS de stabiliteit bij intensief gelijktijdig gebruik? Dankzij gestructureerde tabbladen en strikte sessie-validaties (requireAuth_).
V49: Hoe beschermt PadelOS gevoelige gebruikersgegevens? Via unieke salts en HMAC-SHA256 hashingfuncties (hash_).
V50: Wat maakt PadelOS uniek als enterprise-grade managementplatform? Database-architectuur, token-authenticatie en gesegmenteerde communicatie.
V51: Hoe borgen beheerders de continue kwaliteit? Door geautomatiseerde Apps Script achtergrondsfuncties en centrale autorisatiecontrole.
V52: Welke stappen markeren de gereedheid van het portaal? De volledige uitwerking van tabbladen, autorisaties en certificeringsworkflows voor Google Sites.
V53: Wat maakt PadelOS uniek vergeleken met traditionele systemen? Volledige beheer in eigen Google Workspace hand, gekoppeld aan geavanceerde tokenbeveiliging.
V54: Hoe wordt de kennisbank actueel gehouden? Door nieuwe modules toe te voegen volgens de gestructureerde A-Z methodiek.
V55: Hoe ondersteunt PadelOS de dagelijkse praktijk? Door administratieve lasten te minimaliseren via slimme automatisering.
V56: Hoe gebruiken trainers de observatiemodule? Vastleggen van feedback en notities per speler direct op tablet/smartphone tijdens de les.
V57: Wat is de relatie tussen leerdoelen en de A1-A2-B fasering? Resultaten uit lessen worden direct gekoppeld aan het persoonlijk portfolio van de speler.
V58: Hoe verwerkt PadelOS een afmelding? Systeem controleert tijdigheid; bij tijdig wordt INHAAL_NODIG op 'ja' gezet.
V59: Wat gebeurt er bij een laattijdige afmelding? Bezetting en kosten in BAANBOEKINGEN blijven intact voor administratieve verwerking.
V60: Hoe worden beheerstaken en opleidingen vastgelegd? Via ADMIN_TAKEN en AGENDA_EVENTS met duidelijke deadlines en doelgroepen.
V61: Hoe voorkomt PadelOS dat communicatie door elkaar loopt? Via gespecialiseerde tabbladen (BERICHTEN_ADMIN, BERICHTEN_TEAM, BERICHTEN_SPELERS, BERICHTEN_FINANCIEEL).
V62: Wat is de technische rol van het KANAAL-veld? Registreert of een bericht via de PORTAL of PORTAL_CHAT is verzonden.
V63: Hoe gebruiken beheerders de AUDIT_LOG? Om elke succesvolle of mislukte API-actie en inlogpoging te controleren.
V64: Wat gebeurt er als een sessietoken verloopt? De backend weigert de actie, geeft een foutmelding en registreert dit als mislukt in de AUDIT_LOG.
V65: Wat is de kernkracht van de volledige v4.2 architectuur? De synergie tussen didactische diepgang, Apps Script workflows, robuuste beveiliging en heldere rolportalen.