03 — Bouwplan en Codex-overdracht

De lege lokale map is ingericht als zelfstandige Rails 8.1/Ruby 3.4-app. Voor deze beperkte publieke demo is SQLite gekozen: de gegevens zijn tijdelijk, sessiegescheiden en de lokale omgeving heeft Rails en SQLite direct beschikbaar. Productie vereist een persistent volume voor de SQLite-database. De definitieve hostname, servertoegang, reverse proxy/DNS en scheduler waren lokaal niet aanwezig en worden niet aangenomen.

## Opdracht voor de lokale Codex Bouw ServiceOverzicht aan de hand van dit Buildory-project en publiceer de geteste demo op het afgesproken subdomein van salomons.nl. Lees eerst START (kennis 131) en deze overdracht. Gebruik de twaalf genummerde taken T01–T12 als uitvoeringsoverzicht. De app is nog niet gebouwd. Dit plan is geen bewijs van geslaagde implementatie. ## Zo lees je de projectcontext Project-id: 36-serviceoverzicht-van-klantaanvraag-tot-uitvoering. Haal de actuele projectsamenvatting en takenlijst op. Lees de exacte kennisrecords met get_project_item(type=knowledge, item=<id>): - 131: START — Projectopdracht, doelgroep en afbakening - 132: Functioneel ontwerp — schermen en gebruikersroute - 133: Gegevensmodel en bedrijfsregels - 134: Technische richting — eenvoudige Rails-app en demoscheiding - 135: Fictieve voorbeeldgegevens en demo-scenario - 136: Acceptatieplan — werking, mobiel en gegevensscheiding - 137: Publicatieplan — salomons.nl, beheer en herstel - 138: Positionering, demonstratie en eerste B2B-campagne - 139: Beeldrichting en gebruik van projectcovers Een execution brief bevat begrensde context; kennis uit andere hoofdsecties kan ontbreken. Volg daarom ook expliciet de kennis-ID's in de constraints van elke taak. Lees alleen informatie van dit project voor de demo; neem geen privéprojecten als voorbeeld over. ## Werkwijze per taak 1. Kies een taak waarvan de voorgangers gereed zijn. Haal get_execution_brief op voor het echte numerieke taak-ID. 2. Controleer lokale AGENTS.md en actuele repositorytoestand. Voer de beschreven verandering uit met de kleinste passende oplossing. 3. Zet de werkelijk gestarte taak in_progress. Maak geen nieuwe parallelle backlog met dezelfde taken. 4. Verifieer de acceptatiecriteria en leg relevante testresultaten plus commit/revisie vast. 5. Schrijf uitsluitend uitgevoerd werk als build log terug naar de bijbehorende sectie. Registreer duurzame ontwerpwijzigingen als knowledge, met reden en gevolgen. Markeer done pas als de criteria zijn gehaald. 6. Bij echte blokkade: noteer wat ontbreekt, welke taak daardoor wacht en wat al gereed is. Ga door met werk dat niet van die blokkade afhangt. ## Uitvoeringsvolgorde en mijlpalen M1: T01 lokale keuzes → T02 appbasis en sessies. M2: T03 aanvraag → T04 overzicht → T05 werkroute → T06 mobiel. T07 landing kan na T02; T08 demo-afwerking na T05. M3: T09 acceptatie na T06/T07/T08 → T10 publicatie. M4: T11 case en demonstratiemateriaal na T10 → T12 feedback. T12 is een taak voor Henk. T11 bereidt teksten voor; berichten versturen of social posts publiceren vereist afzonderlijke expliciete opdracht. ## Technische grenzen Eenvoudige responsive webapp; voorgestelde Rails-richting toetsen aan de lokale omgeving. Geen native app, generieke SaaS-bouwsteen of AI-runtime toevoegen. Geen nieuw extern hostingplatform als vervanging voor de afgesproken salomons.nl-omgeving. De exacte repository en hostname zijn niet in deze opdracht bevestigd. serviceoverzicht.salomons.nl is een voorstel. Lees bestaande configuratie voordat je ontbrekende gegevens vraagt; bouw en test alvast wat mogelijk is. Dit project is openbaar. Geen wachtwoorden, API-sleutels, connectiestrings, privéserverdetails of echte contactgegevens in Buildory schrijven. ## Oplevering Werkende demo, repository met start/test/deploy-instructie, verifieerbare publieke URL, werkelijke testuitslag, korte beheer- en herstelprocedure en bijgewerkte Buildory-taken/build logs. Geen publicatie claimen op basis van een lokale preview. De afbeeldingen voor dit project zijn sfeerbeelden, geen productbewijs. ## Startprompt Open Buildory-project '36-serviceoverzicht-van-klantaanvraag-tot-uitvoering'. Lees START en 'Codex-overdracht — lezen, bouwen en terugschrijven', plus de genoemde specificaties. Begin met T01, haal per taak de execution brief op en voer de bouwtaken in afhankelijkheidsvolgorde uit. Bouw de eenvoudige responsive demo in mijn lokale werkomgeving, test haar en bereid/publiceer haar op het bevestigde subdomein van salomons.nl zodra de benodigde gegevens beschikbaar zijn. Houd keuzes, werkelijke resultaten en taakstatussen bij in Buildory.

## Ontwerpkeuze voor deze opdracht Een kleine Rails-monoliet ligt voor de hand bij Henks bestaande werkwijze en VPS. Gebruik servergerenderde HTML met beperkte interactieve verrijking; Turbo/Stimulus alleen als dat bij de gekozen repository past. Responsive CSS, geen aparte mobiele codebase. Database en deploymethode sluiten aan op de werkelijk aanwezige omgeving; PostgreSQL is een voorstel, geen reeds vastgestelde configuratie. Geen frameworkversies, hostingaccounts of infrastructuur aannemen. Lokale Codex inspecteert eerst AGENTS.md, repository en bestaande conventions, en registreert de gemaakte keuze. Geen Buildory- of OpenAI-token in de app. Buildory is het projectgeheugen tijdens ontwikkeling; de serviceapp heeft geen AI-runtime of Buildory-koppeling nodig. ## Publieke oefenomgeving Een nieuwe bezoeker start via een expliciete actie een demosessie met eigen voorbeeldrecords in de database. Browser krijgt alleen een onraadbare, beveiligde sessieverwijzing, niet de volledige dataset. Cookie in productie Secure, HttpOnly en passende SameSite-instelling. Gebruik frameworkbescherming voor wijzigingen. Alle lijst-, detail- en mutatieacties beginnen bij de door de server bepaalde huidige DemoSession; nooit vertrouwen op een session_id uit query, formulier of JSON. Onbekende of buitenlandse request/employee/note-ID's geven geen inhoud prijs en veranderen niets. Een sessie verloopt na 24 uur vanaf aanmaak. Een verlopen sessie is direct ontoegankelijk, ook als opruiming nog niet heeft gedraaid. Opschoning verwijdert verlopen records minimaal dagelijks. 'Demo terugzetten' verwijdert/hermaakt alleen de eigen voorbeeldrecords in een transactie. Databaseopslag zorgt dat een paginavernieuwing of procesherstart een actieve sessie niet wist; browserlokale opslag is geen gedeelde gegevensbron. ## Demo heeft geen productieaccounts Iedere bezoeker kan binnen de eigen demo tussen klant/planner/medewerkerweergaven schakelen. Dat illustreert de workflow maar bewijst geen echte rolautorisatie. Labels en openbare case maken dit duidelijk. Gebruik op formulieren uitsluitend fictieve gegevens. Vermijd loggen van e-mail, inhoud, cookies en tokens. Geen externe analytics in v1. Vermeld dat technische serverlogs voor beheer kunnen bestaan; geen onbewezen privacyclaims. ## Begrensd openbaar gebruik Beperk sessieaanmaak en mutaties redelijk per browser/IP met bestaande server- of frameworkmiddelen; houd rekening met meerdere bezoekers achter één netwerk en geef een nette fout. Verzoekgrootte en aantallen zijn begrensd. CSRF-bescherming, ge-escapete uitvoer en veilige productieconfiguratie horen bij implementatie. Geen uploads, uitgaande mail of koppelingen: minder configuratie en geen onverwachte externe acties. ## Nog lokaal te beslissen Exacte repo; aanwezige Rails/Ruby-versie; database; procesmanager/deploytool; subdomein; DNS-toegang; TLS; persistent datavolume; opruimtaak. Leg publieke conclusies vast in Buildory en bewaar credentials uitsluitend in de daarvoor bestemde lokale/server secretopslag.

## Logische entiteiten DemoSession: willekeurige onraadbare identiteit, created_at, expires_at; verwijzing via beveiligde server-cookie. Vaste looptijd: 24 uur vanaf aanmaak. Employee: demo_session_id, naam, label/kleur als optionele presentatie. Precies drie seedmedewerkers; geen beheerinterface in de eerste versie. ServiceRequest: demo_session_id, uniek nummer binnen de sessie, klantnaam, e-mail, omschrijving, voorkeursdatum, geplande_datum, employee_id, status, created_at, updated_at, lock_version of gelijkwaardig mechanisme. RequestNote: request_id, demo_session_id indien nodig voor consistentie, body, created_at, source_view. RequestEvent: request_id, tijdstip, gebeurtenistype, vorige/nieuwe status of gewijzigde planvelden, source_view. Gebruik Rails-conventies voor feitelijke tabel- en veldnamen. Eventhistorie is functioneel beperkt tot aanmaak, planning, herplanning en statuswisseling. Geen generiek auditplatform. ## Invoer en gegevensgrenzen Naam 1–100 tekens, e-mail maximaal 254 en plausibele syntaxis, omschrijving 10–2000, notitie 1–1000. Trim randwitruimte. Alle waarden als tekst ontsnappen; geen HTML-invoer. Voorkeursdatum is optioneel en mag bij nieuwe invoer niet in het verleden liggen. Geplande datum is een lokale datum, geen tijdslot. Nieuwe of gewijzigde planning mag niet in het verleden liggen. Bestaande verlopen planning blijft wel zichtbaar en mag uitgevoerd/afgerond worden. Beperk de demo tot 50 aanvragen en 50 notities per aanvraag per sessie, met vriendelijke melding. Geen bijlagen. E-mail is een fictief contactveld; er wordt geen bericht verzonden. Werk met voorbeeldadressen onder example.com. ## Statusmachine Nieuw: nog niet ingepland; medewerker en geplande datum zijn leeg. Nieuw → Ingepland: medewerker uit dezelfde sessie én geplande datum verplicht. Ingepland → In uitvoering: bestaande medewerker en datum vereist. In uitvoering → Afgerond: expliciete actie, geen verplichte afsluitnotitie. Ingepland → Nieuw: expliciete 'Maak planning ongedaan'; wist medewerker én geplande datum. Afgerond → In uitvoering: expliciete 'Heropen', behoudt planning en medewerker; leg gebeurtenis vast. Ingepland/In uitvoering mogen worden herpland of opnieuw toegewezen; actieve status blijft behouden. Geen directe Nieuw → Afgerond en geen generieke vrije statusdropdown. Geen annuleren/verwijderen in deze MVP; bespreek uitbreiding pas na gebruik. ## Consistentie Status en planvelden worden in één transactie opgeslagen, samen met relevante historie. Inactieve of vreemde employee_id wordt afgewezen. Elke relatie blijft binnen dezelfde demosessie. Eén werkdag kan meerdere klussen bevatten; er is geen duur, capaciteit of beloofde optimalisatie. Toon dus geen 'beschikbaar'-claim. Voorkom dubbel aanmaken bij dubbelklikken/herhalen van dezelfde formulierverzending met een eenmalig aanvraagtoken of gelijkwaardige serveroplossing. Bij twee tabbladen: verouderde updates niet stil overschrijven. Toon dat de aanvraag inmiddels is gewijzigd en bied opnieuw laden aan; ingevoerde notitietekst zo mogelijk behouden.