03 — Wat Zilch al weet over conversationeel ontwerpen, en Luminous/genui-lab

Onderzoeksagent 3 van 8. Bronnen: alleen gelezen, niets gewijzigd.

Samenvatting

Zilch heeft al een werkend conversationeel ontwerp (skills zilch-conversational, zilch-schrijfkern): elk antwoord bestaat uit spraak (TTS) én een tekstballon, nooit hetzelfde op twee manieren. De hero "Praat met je website" opent niet met een lege chat, maar met vijf klikbare knoppen die al een vraag stellen. Conversational Onboarding ("een aanmeldformulier dat praat") is bij Zilch bewust nog richting, geen belofte met cijfers. Het oude woon-project (Immobiliare/Immo) had al een volledig gespreksontwerp voor precies dit domein: vier vastleg-momenten, een system-prompt v0.1, een viertabs-app met "Gesprek" naast een permanente chat-knop — maar de implementatie kwam nooit voorbij de blauwdruk; de chat-UI is een statische mockup die niet op invoer reageert. genui-lab (Luminous, op Mac z) is geen woon-project maar toont hoe een gesprek een levende UI opbouwt: een gesloten componenten-catalogus, een streambare spec, harde scheiding tussen structuur en data, en een menselijk gecontroleerd "verbeterbord" voor voorbeelden die nooit vanzelf live gaan. Sterkste erfenis voor Mi casa: propose-show-explain-approve, één vraag per beurt, vaste componenten voor gevoelige acties in plaats van vrije tekst, en een opening die meteen concreet is in plaats van een leeg "hallo".

Bevindingen

1. Zilch's conversationele principes

Twee outputs, altijd: SPRAAK (voor TTS) en BUBBEL, nooit één zonder de ander. "Je levert altijd twee outputs: een gesproken versie en een bubbel-versie." — skill zilch-conversational/SKILL.md regel 12-13 (volledig pad in Bronnen). Spraak is warm en ritmisch (2-4 zinnen, max 6 bij uitleg, geen cijfers/URLs/afkortingen die TTS verkeerd uitspreekt); de bubbel is functioneel (max 2-3 zinnen, actie vooraan, getallen/links horen hier, niet in spraak) — secties "Gesproken tekst"/"Chatbubbel".

Eén vraag per beurt. "Stel maximaal een vraag per beurt" (SKILL.md, sectie "Vraaggedrag"); persona/state/intent worden afgeleid uit de lopende context, niet apart bevraagd tenzij het echt niet anders kan.

Persona/state/intent is het kompas voor élke tekst. zilch-schrijfkern/SKILL.md sectie 10: "Persona (wie) ... State (fase) ... Intent (doel) ... De combinatie bepaalt toon, lengte, woordkeuze en structuur." Acht persona's met eigen max-woorden-per-zin (10 voor Overbelaste Ondernemer, tot 20 voor Digitale Professional). Verboden taal staat met naam en al genoemd (transformatie, revolutionair, onboarding journey, ...) in SKILL.md sectie 8, en geldt óók in gesprek.

Het gesprek doet het onderzoek dat een bureau apart factureert. ~/Developer/zilch-bron/verhaal.md regel 60-61: "Het gesprek aan het begin is doelgroeponderzoek ... Bureaus rekenen voor zo'n voortraject 2.500 tot 7.500 euro. Bij Zilch zit het in het abonnement."

Opening is concreet, geen chatvenster met cursor. De hero "Praat met je website" opent met vijf knoppen (Lettertype, Kleuren, Koppen, Foto's, Sfeer) die elk al een kant-en-klare suggestie triggeren — de gebruiker hoeft niet te bedenken wát te vragen (verhaal.md regel 30-40). Patroon: "jij zegt wat je wilt, Zilch stelt voor, toont het verschil, legt uit waarom, en jij keurt goed of af" (regel 41-42).

2. Conversational Onboarding (bij Zilch zelf)

Bij Zilch is dit nog richting, geen feature: "noem het als richting waar Zilch heen groeit, niet als bestaande belofte met cijfers" (verhaal.md regel 64-66). Toegestane analogie: "Als Typeform, maar het práát." Verboden analogie: Siri/spraakassistent. Hypothese erachter: twee op de drie mensen maken een formulier niet af (regel 62).

3. Luminous / genui-lab (z:~/Developer/genui-lab, alleen gelezen via ssh z)

Wat het is. Een "lichtend beheercentrum" voor serverbeheer (Docker, health-status) waarbij de LLM zelf de UI samenstelt. Geen woon-domein, wel een generatieve-UI- architectuur voor meerdere domeinen: componenten taggen met source: 'infra' | 'leerloop' | 'mijnxel' (shared/catalog.ts regel 32).

DESIGN.md is een bindend contract, ook voor de runtime-LLM. "Het wordt gelezen door mensen, door design-tools ... én door de runtime-LLM als onderdeel van de system prompt. Waarden hier zijn harde constraints, geen suggesties." (DESIGN.md regel 1-5).

De widgetotheek is een gesloten, valideerbare set, geen vrije HTML. Een spec is "een platte adjacency-list met ID-referenties ... streambaar (renderen kan zodra root binnen is), en strikt gescheiden van data (bindings, D7)" (shared/spec.ts). Elk component-type heeft een Zod-schema plus een guidance-veld ("wanneer het model dit component moet kiezen", shared/catalog.ts regel 29). validateSpec() geeft alle fouten in één keer terug voor een repair-loop naar het model (D10).

Structuur en data zijn strikt gescheiden. Databindings zijn dot-paden naar een live status-object ("een prop krijgt zijn waarde uit het live status-object i.p.v. een ingebakken waarde", shared/catalog.ts regel 18-23) — het model verzint geen getallen, het verwijst ernaar.

Gevoelige acties krijgen een vast component, geen vrije tekst. DESIGN.md: "ConfirmAction — VAST component (D3): inhoud komt uit het Voorstel-record van de server, nooit uit de spec. Destructief = color.critical-knop met de actie als knoptekst." Architecturaal antwoord op het probleem dat een LLM een destructieve actie zelf zou verwoorden.

Streaming en kwaliteit zijn zichtbaar in de gespreksloop. web/chat/useChat.ts verwerkt NDJSON-events: tool (leesbare labels als "status ophalen"), partial (deel-spec tijdens genereren), spec (met source: generated|cache|degraded en quality: {pass, assertions}), error. "Regenerate" stuurt expliciet een voorkeurssignaal naar de server.

Verbeterbord = een menselijk gecontroleerde voorbeelden-inbox, nooit automatisch. server/routes-voorbeelden.ts regel 1-13: kandidaten landen in prompts/examples/_inbox/<bron>/... en worden "NOOIT auto-laden" door de live prompt. Activeren is "een bewuste, menselijke stap: bestand verplaatsen + PROMPT_VERSION bumpen + committen — hier gebeurt dat nooit." Dit is het mechanisme achter wat de opdracht een "verbeterbord" noemt.

4. Het oude woon-project (~/Developer/woonapp-archief)

Al een uitgewerkt gespreksontwerp voor exact dit domein, geforkt uit Zilch's eigen Coach matcher — bewijs dat Zilch deze architectuur al draaiend heeft, alleen niet voor wonen: "Zilch heeft dit pattern al draaiend voor Coaches op Zilch. Hergebruik = snelheid

Vier vastleg-momenten: status quo, tijdshorizon, actieve domeinen (kies 3 van 8: financieel/ruimte/energie/gezin/levensfase/locatie/onderhoud/toekomst), voorkeuren voor signalen — dan pas adres/postcode (zelfde bestand).

System-prompt v0.1 (bron/app/conversational/system-prompt-v0.1.md) is gedetailleerd en direct bruikbaar als vertrekpunt: toon "Direct, Warm, Stil", max 2-3 zinnen per beurt, één vraag per beurt, spiegel de woorden van de gebruiker ("krap" niet "klein"), volg afdwalingen en breng zacht terug, expliciete openingsregel ("Goed dat je er bent. Vertel me iets over je huis." — expliciet níet "Welkom!"), en een eigen verboden-woordenlijst voor dit domein (balans, authentiek, transformatie, empowerment, mindset, "je verdient het") — losstaand van Zilch's eigen lijst. Les: de verboden-taal-lijst moet per domein opnieuw doordacht worden, niet gekopieerd.

Waar het vastliep. De vier tabs (Huis, Buurt, Beslissing, Gesprek) staan in web/components/navigation/TabBar.tsx regel 8-12; "Gesprek" is een archief-tab, het lopende gesprek zit in een chat-drawer die overal via een FAB opengaat. Maar: "De chat-drawer werkt visueel maar reageert niet op invoer" (bron/web/README.md, architectuurtabel). gesprek/page.tsx toont hardcoded voorbeeldbubbels, geen live data. Het fork-README zegt zelf dat de adapter-laag (endpoints, extractie naar user_profiles) nog moest gebeuren — dat is nooit voltooid; het project werd op 3 september 2026 bevroren na de datalaag-sprints, vóór de eerste testers geworven werden (bron/app/conversational/README.md, sectie "Volgende stappen").

Open ontwerpvragen die het project zelf nooit beantwoordde: adres verplicht of optioneel, moment van account/login, bewaartermijn anonieme sessies, fallback bij API-uitval, persona-detectie tijdens gesprek of één vaste flow (onboarding-conversational.md, sectie "Open vragen voor het ontwerp").

Wat dit betekent voor Mi casa

Aanbevelingen

  1. Neem het SPRAAK+BUBBEL-tweeluik uit zilch-conversational over als basisvorm voor elk conversatie-antwoord, inclusief de lengte- en toonregels per stuk.
  2. Gebruik de vier-vastleg-momenten-structuur als startpunt voor een Mi casa-eigen versie, opnieuw ingevuld tegen Mi casa/Droomhuis/Su casa in plaats van de oude acht domeinen.
  3. Herschrijf system-prompt v0.1 niet vanaf nul: spiegel-regel, openingsregel-logica en "één vraag per beurt" zijn direct bruikbaar; alleen domein en verboden-woordenlijst moeten opnieuw bepaald worden.
  4. Gebruik ConfirmAction-achtige vaste componenten op elk moment dat de harde grenzen raakt (solliciteren, meldknop, "wis alles", 16+-zin): nooit vrije LLM-tekst daar.
  5. Bouw vanaf het begin een databinding-scheiding tussen gespreks-UI-structuur en echte data, zodat harde grens 7 architecturaal afgedwongen wordt, niet alleen redactioneel.
  6. Neem het verbeterbord-mechanisme over voor elk voorbeeld dat met een cijfer schermt in demo of pitch.
  7. Test de opening van het eerste 30-secondengesprek tegen zowel Zilch's knoppen-hero als de woonproject-openingsregel: concreet en specifiek, nooit een generieke begroeting.

Open vragen

Bronnen