Testclient fase 2, 3 en 5: opdrachtregel, bedieningsvlak en toetsen

De client staat. Een register (owners.json met naam, mnemonic en OwnerId), acht
opdrachten op de opdrachtregel, en een bedieningsvlak op 127.0.0.1:4380 met per
eigenaar de knoppen uit PLAN.md 4b. Start.bat en Start.command erbij op verzoek
van de gebruiker: die draaien npm install als het nodig is, waarschuwen als .env
ontbreekt, openen de browser en houden het venster open bij een fout.

OPEN.md punt 1 is opgelost voordat het een probleem werd. src/probe.js doet de
WebSocket-upgrade met node:http in plaats van met de WebSocket van Node, want
die geeft je bij een weigering een error en geen statuscode. De opdracht klop en
de knop Aankloppen tonen dus 101 of 401, en dat is precies wat de proeven uit
4c moeten kunnen aflezen.

Twee echte fouten gevonden en vastgezet in een toets. De databasemap werd niet
aangemaakt, en omdat better-sqlite3 dat in een worker meldt was het symptoom een
lees die nooit antwoordde. En evolu.insert geeft meteen een id terug maar zet de
schrijfactie in de wachtrij van de worker, dus wie vlak daarna afsluit is de rij
kwijt; schrijf wacht nu op een query erachter en de toets sluit af en heropent.

tests/test_client_register.mjs heeft geen pakketten nodig, want register.js,
argumenten.js en config.js raken Evolu niet aan. Drie mutaties geprobeerd en
alle drie lieten de juiste toets omvallen.

In de browser nagekeken: schrijven en teruglezen werkt vanuit de pagina, de
gegevens zijn dezelfde als die van de opdrachtregel, en licht en donker kloppen.

Alles wat de relay raakt is gebouwd en niets ervan is beproefd; daarvoor wacht
er een RELAY_URL in .env, en die komt van de gebruiker.

Suite: 475 goed, 0 fout over alle negen de toetsen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Docs/Plannen/Actief/003-Testclient/OPEN.md

@@ -3,19 +3,22 @@
 > Vragen die het plan niet beantwoordt en die tijdens het werk beslist moeten worden. Wat af is, verhuist
 > naar [PROGRESS.md](PROGRESS.md); wat een taak wordt, naar [TAKEN.md](TAKEN.md).
 
-1. **Hoe zichtbaar is een 401 in de cliënt?** Evolu probeert opnieuw en is ontworpen om een relay te
-   overleven die er niet is. Als een weigering en een relay die plat ligt in de cliënt hetzelfde signaal
-   geven, is de eerste proef uit `PLAN.md` §4c niet af te lezen. De uitweg blijft binnen dit gereedschap:
-   een eigen WebSocket-poging naast Evolu, met dezelfde `OwnerId` in de URL, die de statuscode wel te zien
-   krijgt. Dat is een handeling van een paar regels, want de `OwnerId` staat in de URL van de verbinding
-   (§10 van [Upstream-evolu-relay.md](../../../Referenties/Upstream-evolu-relay.md)).
+1. ~~**Hoe zichtbaar is een 401 in de cliënt?**~~ **Opgelost op 09-09-2026, vóórdat het een probleem
+   werd.** `src/probe.js` doet de WebSocket-upgrade zelf met `node:http` en leest de statuscode af; de
+   opdracht `klop` en de knop "Aankloppen" tonen 101 of 401. Met `node:http` en niet met de WebSocket van
+   Node, en dat is de hele reden dat dat bestand bestaat: die laatste geeft je bij een weigering een
+   `error` en geen status, en 401 tegenover 404 tegenover "niets luistert" is precies wat je wilt weten.
+   Wat er nog niet is, is een keer zien dat het klopt tegen een echte relay.
 
-2. **Wat is een zinnige blob om mee te experimenteren?** Willekeurige bytes zijn genoeg voor de bytegrens,
-   maar niet om te zien of gegevens werkelijk heen en weer gaan. Iets met leesbare inhoud en een teller is
-   waarschijnlijk beter.
+2. **Wat is een zinnige blob om mee te experimenteren?** Voorlopig een oplopend bytepatroon (`i % 256`)
+   met een label erbij: genoeg om de bytegrens te raken en om bij het teruglezen te zien dát het jouw
+   bytes zijn. Wat er nog niet is, is inhoud die iets betekent, en dat gaat pas meespelen zodra twee
+   eigenaars werkelijk iets over de relay uitwisselen.
 
-3. **Wordt de gegevensmap van de proef opgeruimd?** Twintig eigenaars die blijven staan is rommel, en het
-   is sleutelmateriaal. Waarschijnlijk een opdracht die er één weggooit en één die alles weggooit.
+3. **De gegevensmap wordt niet opgeruimd.** `vergeet` haalt een eigenaar uit het register en laat zijn
+   database staan; dat staat er ook bij in de uitdraai. Zolang het er een handvol zijn is dat prima, maar
+   het is wél sleutelmateriaal dat je dan kwijt bent zonder het weg te gooien. Een opdracht die de
+   database meeneemt hoort erbij, en misschien een die alles opruimt.
 
 4. **Data per eigenaar wissen op de relay staat al open bij Umbrelapp.** Dit gereedschap maakt dat
    makkelijk te beproeven maar lost het niet op; het blijft schrijven in andermans schema (§8 van hetzelfde
@@ -27,12 +30,23 @@
    wel dat de samenstelling uit `PLAN.md` §4e bij elke verhoging opnieuw langs moet. Beslissen bij de
    eerste verhoging, niet nu.
 
-6. **Waar staat de relay voor deze cliënt?** Het adres van de Umbrel staat nergens in deze repo en hoort
-   daar ook niet in: dit is een publieke repo (zie `.gitignore`, "Geheimen"). Dus een instelling die de
-   gebruiker zelf zet, met een voorbeeldbestand ernaast. Voor de hand ligt `.env.sample`, want dat patroon
-   staat al in de `.gitignore` van de repo-root.
+6. ~~**Waar staat de relay voor deze cliënt?**~~ **Beslist op 09-09-2026:** `RELAY_URL` in `.env`, met
+   `.env.sample` als voorbeeld in de repo. Het adres van de Umbrel staat nergens in deze repo en hoort daar
+   ook niet in; dit is een publieke repo (zie `.gitignore`, "Geheimen"). **Wat er nog niet is, is de
+   waarde**, en dat is de volgende stap in [TAKEN.md](TAKEN.md).
 
-7. **Het afsluiten is opgelost maar niet doorgrond.** De volgorde in `dispose` (afhankelijkheden, dan een
+7. **Het bedieningsvlak tekent de hele lijst opnieuw.** Er zit nu een vergelijking voor: verandert de
+   status niet, dan gebeurt er niets. Dat was nodig omdat het veld met de omvang anders elke drie seconden
+   leegging terwijl je erin typt. Wordt de lijst langer of komt er meer per eigenaar bij, dan is dit het
+   punt waarop het opnieuw gaat schuren, en dan is per eigenaar bijwerken de juiste stap. Nu niet: dat is
+   machinerie voor een probleem dat er nog niet is.
+
+8. **`sync` en het bedieningsvlak weten niet of een verbinding er nog is.** Er staat "verbonden" zodra de
+   instantie gemaakt is, en Evolu meldt niet dat de relay weggevallen is (hij probeert het gewoon opnieuw).
+   Voor de proeven is `klop` het antwoord, maar op de pagina staat een groen bolletje dat meer belooft dan
+   het weet. Evolu heeft een `SyncState`; uitzoeken of daar iets bruikbaars in zit.
+
+9. **Het afsluiten is opgelost maar niet doorgrond.** De volgorde in `dispose` (afhankelijkheden, dan een
    tik doorlaten, dan de resources van de gedeelde worker, dan de runs) is gevonden door te proberen, niet
    door de bron van Evolu te lezen. Hij werkt en er is een reden bij opgeschreven, maar het is geen bewijs.
    Valt het bij een volgende versie opnieuw om, lees dan eerst `Task.js` in plaats van opnieuw te schuiven.