Volgende bouwopdracht — één configuratiecontract voor formulieren, chat en runtime

Basis: geïntegreerd bouwplan W01, voorbereid op W03; veldgroepen F01–F42. De huidige frontendintegratie blijft het uitgangspunt. De volgende opdracht is geen redesign en nog geen opdracht om actieve klantconfiguraties om te zetten of calls te starten.

Concreet te bouwen

1. Introduceer een gedeeld, getypeerd en gevalideerd configuratiecontract met schemaVersion, revision, compilerVersion, herkomst per veld en expliciete unsupported/needs_review-informatie. Neem alle 42 veldgroepen op in het coverage-register; account, betalingen en runtimeverbindingen krijgen een eigen grens en worden geen vrij schrijfbare promptconfiguratie.
2. Bouw een alleen-lezen compatibiliteitsloader op de bestaande bedrijfs-, dienst-, intake-, kennis-, tijden- en integratiebronnen. Gebruik de huidige tenantautorisatie. Begin met synthetische Starter-, Growth- en Enterprise-fixtures plus de drie onderzoeksprofielen. Geen klantdatafixture in Git.
3. Leg voor ieder veld vast: huidig opslagveld, betekenis, enum, eenheid, betekenis van null/leeg/ontbrekend, runtimeconsument, validatieregels, plan-/providerafhankelijkheid en round-trip-bewijs. Gebruik de aangevulde veldmatrix als afvinklijst.
4. Laat de nieuwe formulieren en configuratieassistent dezelfde contracttypen lezen. De demo-adapter mag de vorm gebruiken, maar blijft een aparte opslag. Laat de bestaande productieschrijfroutes en runtimeconsumenten in deze stap intact.
5. Ontwerp en typeer alvast de volgende mutatiegrens: readDraft, patchDraft(expectedRevision), validateDraft, proposePatch, confirmProposal(exactDiffHash, expectedRevision) en undoAsNewPatch. Voer deze schrijfoperaties nog niet uit op actieve configuraties. Een voorstel en een formulierpatch mogen straks geen twee verschillende opslagmodellen hebben.

Betekenissen die expliciet moeten worden opgelost

| Veldgroep | Besluit / verplicht bewijs | |---|---| | F01–F02 | Bedrijfsidentiteit, contactnummer, inkomend nummer, doorschakeldoel en testnummer zijn verschillende velden. Reactietijd is geen gegarandeerde SLA zonder eigen beleid. | | F03–F13 | Huidige assistentvelden, taalwisselbeleid en voice-ID’s verliesvrij vertalen. Geen demo-defaults voor ontbrekende booleans. Begroeting en eventueel audio-artefact moeten bij dezelfde kandidaat horen. | | F14 | Situatieregels hebben nog een runtimecontract nodig. Toon unsupported totdat een regel aantoonbaar wordt gecompileerd en uitgevoerd. | | F15–F24 | Diensten, prijzen/staffels, intakevragen, duur, verboden toezeggingen en afhandelacties als samenhangend contract. Een dienst-ID niet uit een naam of legacypositie verzinnen. | | F25–F27 | Brontekst, plaats/postcode, straal, uitsluitingen en uitzonderingen per dienst apart modelleren. Leg prioriteit en conflictregels vast vóór de gedeelde evaluator uit W04. | | F28–F31 | Weekrooster en uitzonderingen; sequentieel/simultaan, timeout en fallback. Huidige contactvelden zijn geen bewijs dat een belgroep bestaat. | | F32–F33 | De bestaande buffers vóór en na een afspraak niet platmaken tot één demo-buffer. Eenheden minuten/dagen/uren expliciet. Goedkeuring is niet hetzelfde als een geboekte afspraak. | | F34–F38 | Kennis/bronverwerking en medewerker-/providerinformatie gescheiden. Verbindingsstatus is actueel runtimebewijs, geen blijvende eigenschap van een gepubliceerd snapshot. Verzendstatus niet gelijkstellen aan aflevering. | | F39–F40 | Draft, geteste kandidaat en actieve release onderscheiden. Chat en formulier gebruiken dezelfde revisie; een stale voorstel wordt geweigerd. Undo maakt een nieuwe wijziging en overschrijft geen later werk. | | F41–F42 | Authenticatie, rollen, privacy/retentie en betalingen blijven buiten vrije configuratiechatmutaties. Server-entitlements blijven leidend. |

Acceptatietests voor deze volgende opdracht

• F01–F42 hebben allemaal een expliciete mapping of een aantoonbare unsupported-reden; geen ongemerkt overgeslagen prototypevelden.
• Read → normaliseer → serialize → read behoudt bestaande betekenis, inclusief false, 0, null, legacylijsten en onbekende enums.
• De bestaande drie onderzoeksprofielen behouden hun huidige beslissingen. De negen nieuwere backendwijzigingen uit de oorspronkelijke werkboom worden eerst bewust meegenomen in de testbasis; niet overschreven door deze frontendbranch.
• Tenant A kan geen configuratie van B lezen of voorstellen; tenant komt uit de bestaande autorisatie, niet uit een vertrouwd frontendveld.
• Formulier en chat zien dezelfde contractwaarden. Een nog niet aangesloten veld kan niet als succesvol opgeslagen worden weergegeven.
• CQ23/F40-concurrencyfixture: formulier wijzigt prijs op revisie N+1 terwijl chat een voorstel voor N heeft. Resultaat: conflict met actuele vergelijking, geen stille overwrite.
• F27-fixture: bedrijfsgebied en dienstuitzondering hebben één vastgelegde prioriteitsregel. UI-preview en de latere runtime-evaluator mogen niet elk een eigen interpretatie krijgen.
• F39-fixture: wijziging na een test maakt het betreffende bewijs ongeldig. De outbound testcall blijft de beoogde menselijke hoofdtest, maar wordt in deze contractopdracht nog niet uitgevoerd.
• Contracttests draaien zonder netwerk, betaalacties of telefonie. Bestaande frontend- en backendregressies blijven groen.

Oplevering en afbakening

Lever het schema, de compatibiliteitsloader, 42 traceerbare mappings, fixtures, regressieresultaten en de definitieve interface voor W03 op. Vermeld expliciet welke huidige velden niet zonder betekenisverlies kunnen worden samengevoegd.

Daarna volgen duurzame drafts en exact bevestigde mutaties (W03), de werkgebiedevaluator (W04) en de versiegebonden test-/activatieketen. De succesvolle demo is geen bewijs dat deze backendketen al bestaat.