04 — Testen en publicatie

## Doel De lokale Codex publiceert de app op een subdomein van salomons.nl, passend bij Henks bestaande hosting. Voorstel: serviceoverzicht.salomons.nl. 'xyz.salomons.nl' in de oorspronkelijke opdracht is een plaatsaanduiding, geen gekozen hostname. Geen nieuwe externe hostingdienst, account of betaald abonnement toevoegen zonder concrete aanleiding. Geen andere bestaande applicatie vervangen. ## Voorbereiden met lokale informatie 1. Lees repository-instructies en controleer aanwezige deployconfiguratie, beschikbare toegang en infrastructuur. 2. Bevestig de exacte hostname, bestaande DNS-records en eventuele reeds draaiende toepassing voordat DNS of routing wordt gewijzigd. 3. Bepaal appservice, database, persistent volume, configuratie en HTTPS via bestaande conventies. Gebruik werkelijke waarden uit de omgeving; zet geen credentials in dit openbare project. 4. Maak een reproduceerbare release vanuit een vastgelegde commit, met gerichte testresultaten en een lijst benodigde niet-geheime configuratienamen. Ontbreekt alleen toegang of de keuze voor het subdomein, rond dan eerst alle bouw- en testwerk af en beschrijf precies welke invoer nog nodig is. ## Eerste release Zorg voor een geïsoleerde appservice en database/schema, correcte productie-instellingen, migraties en automatische seed per demosessie. Geen centrale gedeelde voorbeeldset die iedere bezoeker wijzigt. Configureer DNS/routing en TLS pas voor de bevestigde bestemming. Controleer gezondheid vóór omschakelen als de infrastructuur dat ondersteunt. Stel dagelijkse opschoning in en verifieer databasepersistentie. Houd logging sober, zonder formulierinhoud of sessiegeheimen. ## Herstel Leg de vorige release/configuratie vast vóór een update en maak vóór destructieve datamigraties een passende backup. Beschrijf herdeploy van de vorige release en wat dat voor gegevens betekent. Demosessies zijn tijdelijk en hoeven geen zakelijke archiefgarantie. Het moet wel mogelijk zijn de app opnieuw op te bouwen en verse sessies te starten. Verlies van tijdelijke oefendata moet duidelijk blijven. Stop bij een bestaande onverwachte productieapp op de doelhostname; geen overschrijving op basis van aannames. ## Oplevering Registreer alleen de werkelijk gebruikte publieke URL en commit/release, een samenvatting van de rooktest en waar de beheerinstructie in de repo staat. Exacte serverdetails blijven in lokale operationele documentatie. Publicatie is pas voltooid na controle vanaf de publieke URL. Een lokale preview, geregistreerde site of gepland DNS-record telt niet als live app.

## Gereed betekent aantoonbaar werkend Onderstaande controles zijn acceptatiecriteria voor de nog te bouwen app. Ze zijn nu niet uitgevoerd. Codex noteert datum, commit/revisie, gebruikte omgeving, resultaat en eventuele beperking bij oplevering. ## Gerichte automatische controles 1. De toegestane statusovergangen werken; verboden sprongen en ontbrekende planvelden worden servermatig afgewezen. 2. Een medewerker uit sessie B kan niet aan een aanvraag in sessie A worden gekoppeld. 3. Met twee aparte browsersessies kan A geen lijst/detail/notitie lezen of muteren van B, ook niet via geraden URL of direct HTTP-verzoek. 4. Terugzetten en verlopen van A laten B intact. Verlopen sessies zijn ook vóór opschonen ontoegankelijk. 5. Aanvraaggegevens, notities en historie blijven na herladen bewaard; dubbele identieke verzending maakt één aanvraag. 6. Een update vanuit een verouderd tabblad overschrijft geen nieuwere wijzigingen ongemerkt. 7. De hoofdroute aanvraag → plannen → uitvoeren → afronden werkt end-to-end. 8. Ongeldige invoer, HTML/scripttekst, te lange velden en overschreden demolimieten worden veilig afgehandeld. Gebruik het bestaande testframework; test gedrag en belangrijke grenzen. Geen omvangrijke tests van statische teksten of CSS-details. ## Handmatige acceptatie Desktop en telefoonbreedtes 360 en 390 px: landing, formulier, lijst, detail en Mijn werk zonder horizontaal scrollen. Toetsenbord: focus zichtbaar, labels verbonden, foutmelding bereikbaar, knoppen bedienbaar. Filters, lege resultaten en wissen filters werken. De medewerker ziet zowel Vandaag als Alle open klussen. Status is ook zonder kleur begrijpelijk. Browser terug/verversen behoudt opgeslagen wijzigingen. Een reset vereist bevestiging. Sessieverloop krijgt een begrijpelijke melding. Check in de beoogde browser én één tweede browser waar beschikbaar. Noteer wat werkelijk getest is; 'niet getest' blijft expliciet. ## Publicatiecontrole Publieke HTTPS-URL bereikbaar; alle statische middelen laden; productie toont geen stacktraces. Seed, reset, sessionisolatie en schrijfacties werken met productiecookie-instellingen. Geen secrets of echte persoonsgegevens in HTML, assets, voorbeelddata of Buildory. Opruimtaak is ingesteld en een gecontroleerde verlopen sessie wordt verwijderd. Runtimegegevens staan op persistente opslag. Leg de werkende URL, releaseverwijzing, beperkte testuitslag en eventuele restpunten vast. Markeer alleen werkelijk afgeronde taken als done. ## Demo versus echt bedrijfsgebruik Dit resultaat is een openbare demonstratie met tijdelijke oefengegevens. Echte inzet vraagt aanvullende accountrechten, bewaarbeleid, herstelprocedures en toetsing aan de concrete bedrijfsvoering. De marketing mag de demo niet als kant-en-klaar productiesysteem presenteren.