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>
This commit is contained in:
Harmen
2026-09-09 13:39:47 +02:00
co-authored by Claude Opus 5
parent de955b607d
commit f0809a80c2
18 changed files with 1728 additions and 41 deletions
+30 -16
View File
@@ -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.
@@ -20,3 +20,27 @@ wegschrijven en teruglezen. De bytes komen er ongeschonden uit en het proces slu
**Nog niet geprobeerd: praten met de relay.** Daar is het adres van de Umbrel voor nodig en dat komt van de
gebruiker; het gaat niet in deze publieke repo.
## 09-09-2026 - de cliënt staat: opdrachtregel, bedieningsvlak en twee starters
Fase 2, 3 en 5 in één sessie. Er is een register (`owners.json` met naam, mnemonic en `OwnerId`), een
opdrachtregel met acht opdrachten, en een bedieningsvlak op `http://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 en openen de browser.
`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 laatste geeft je bij een weigering een
`error` en geen statuscode. De opdracht `klop` en de knop "Aankloppen" tonen dus 101 of 401.
Twee echte fouten gevonden en vastgezet in een toets. De eerste: de databasemap werd niet aangemaakt, en
omdat better-sqlite3 dat in een worker meldt was het symptoom een `lees` die nooit antwoordde. De tweede,
en die is er een om te onthouden: **`evolu.insert` geeft meteen een id terug en zet de schrijfactie in de
wachtrij van de worker**, dus wie vlak daarna afsluit is de rij kwijt. Het symptoom was een `lees` die
"nog geen blobs" meldde over een blob die zojuist bevestigd was. `schrijf` wacht nu op een query erachter,
en de toets sluit af en heropent.
In de browser nagekeken: een blob schrijven en teruglezen werkt vanuit de pagina, de gegevens zijn dezelfde
als die van de opdrachtregel, en licht en donker kloppen allebei.
**Wat er nu ligt te wachten is één regel in `.env`.** Alles wat de relay raakt is gebouwd en niets ervan is
beproefd, en dat blijft zo tot het adres er is.
+43 -20
View File
@@ -12,9 +12,10 @@
## Volgende stap
- [ ] **De cliënt met de relay laten praten.** De samenstelling werkt lokaal; wat nog niet geprobeerd is,
is `transports` met `createOwnerWebSocketTransport` erin. **Hiervoor is het adres van de relay
nodig**, en dat komt van de gebruiker en gaat niet in de repo; zie [OPEN.md](OPEN.md) punt 6
- [ ] **`.env` invullen met het adres van de relay, en dan fase 4.** Alles staat klaar: de cliënt, het
bedieningsvlak en de opdracht `klop` die de HTTP-status van de upgrade laat zien. Wat er nog nooit
gebeurd is, is een verbinding met een echte relay. **Eigenaar: gebruiker**, want het adres gaat niet
in deze publieke repo; kopieer `.env.sample` naar `.env` en zet `RELAY_URL`
## Fase 1 - de samenstelling (af)
@@ -27,20 +28,34 @@
`transports: []`, een rij met een `Uint8Array`-kolom wegschrijven en teruglezen. De bytes komen er
ongeschonden uit en het proces sluit schoon af, zonder defect en zonder te blijven hangen
## Fase 2 - de opdrachtregel
## Fase 2 - de opdrachtregel (af, 09-09-2026)
- [ ] Een eigenaar aanmaken en bewaren: mnemonic plus database in een eigen map, in een pad dat
gitignored is. Het `OwnerId` wordt afgedrukt, de mnemonic niet
- [ ] Een register van eigenaars: aanmaken, opsommen, teruglezen, weggooien
- [ ] Verbinden met de relay via `createOwnerWebSocketTransport`, met het adres uit een instelling
- [ ] Een blob schrijven met een instelbare omvang, en teruglezen
- [ ] De losse WebSocket-poging die de HTTP-statuscode wél te zien krijgt; zie [OPEN.md](OPEN.md) punt 1
- [x] **Een eigenaar aanmaken en bewaren.** `src/register.js`: één `owners.json` met naam, mnemonic en
`OwnerId`, geschreven via een tijdelijk bestand en een hernoeming. Het `OwnerId` wordt afgedrukt, de
mnemonic nooit
- [x] **Aanmaken, opsommen, teruglezen, weggooien.** `nieuw`, `lijst`, `vergeet`. Vergeten is vergeten:
de lokale database blijft staan en op de relay verandert er niets, en dat zegt de uitdraai er ook bij
- [x] **Verbinden met de relay via `createOwnerWebSocketTransport`**, met het adres uit `.env`
(`src/config.js`, met `.env.sample` ernaast). **Gebouwd maar niet beproefd**, want er is nog geen
adres; dat is de volgende stap
- [x] **Een blob schrijven met een instelbare omvang, en teruglezen.** `schrijf` en `lees`, met
`--bytes` en `--lokaal`
- [x] **De losse WebSocket-poging die de HTTP-statuscode wél te zien krijgt:** `src/probe.js` en de
opdracht `klop`. Met `node:http` en niet met de WebSocket van Node, want die geeft je bij een
weigering een `error` en geen 401. Daarmee is [OPEN.md](OPEN.md) punt 1 opgelost vóórdat het een
probleem werd
## Fase 3 - het bedieningsvlak
## Fase 3 - het bedieningsvlak (af, 09-09-2026)
- [ ] De HTTP-server met de pagina, in de stijl van de twee statuspagina's
- [ ] De lijst met eigenaars, met per eigenaar de toestand en de knoppen uit [PLAN.md](PLAN.md) §4b
- [ ] Het log, met tijdstip per gebeurtenis
- [x] **De HTTP-server met de pagina**, op localhost. `src/ui.js` en `src/index.html`, geen framework en
geen bouwstap, net als de twee statuspagina's
- [x] **De lijst met eigenaars**, met per eigenaar de toestand, het aantal blobs en de knoppen uit
[PLAN.md](PLAN.md) §4b: aankloppen, verbinden, verbreken, blob schrijven met omvang, lezen, vergeten
- [x] **Het log**, met tijdstip per gebeurtenis
- [x] **`Start.bat` en `Start.command`**, op verzoek van de gebruiker. Ze draaien `npm install` als het
nodig is, waarschuwen als `.env` ontbreekt, openen de browser en houden het venster open bij een fout
- [x] **In de browser nagekeken** (09-09-2026): een blob schrijven en teruglezen werkt vanuit de pagina,
de gegevens zijn dezelfde als die van de opdrachtregel, en licht en donker kloppen allebei
## Fase 4 - de proeven
@@ -58,12 +73,20 @@ ze komen na fase 2 en kunnen deels vóór fase 3.
plan **Umbrelapp**. Dit is de opbrengst van het hele plan; zonder deze stap blijft het gereedschap
zonder resultaat
## Fase 5 - de toetsen
## Fase 5 - de toetsen (af, 09-09-2026)
Wat automatisch kan is klein, en [PLAN.md](PLAN.md) §7 zegt waarom.
- [ ] Het register: aanmaken, teruglezen, een naam die al bestaat, een half aangelegde map
- [ ] Een vaste mnemonic met een vast verwacht `OwnerId`. Dit is de toets die omvalt als Evolu onder ons
iets anders gaat doen
- [ ] Het lezen van de opdrachtregel
- [ ] De nieuwe toetsen mutatie-testen, zoals `HomeGit/CLAUDE.md` voorschrijft
- [x] **Het register**, in `tests/test_client_register.mjs`: aanmaken, teruglezen, een naam die al
bestaat, een onleesbaar bestand, een onbekende versie. Deze toets heeft géén pakketten nodig, want
`register.js`, `argumenten.js` en `config.js` raken Evolu niet aan
- [x] **Een vaste mnemonic met een vast verwacht `OwnerId`**, in `tests/test_client_lokaal.mjs`. Dit is de
toets die omvalt als Evolu onder ons iets anders gaat doen met de afleiding
- [x] **Het lezen van de opdrachtregel** en van `.env`, met de omzetting van `http://` naar `ws://`
- [x] **Afsluiten en heropenen**, en dat is er een die een echte fout vasthoudt: `evolu.insert` zet de
schrijfactie in de wachtrij en geeft meteen een id terug, dus wie vlak daarna afsluit is de rij kwijt.
`schrijf` wacht daarom op een query erachter
- [x] **Mutatie-getest**, drie keer: de polyfill uitzetten, de dubbele-naam-controle uitzetten, en de
omzetting van `http://` slopen. Alle drie lieten de júiste toets omvallen. De eerste liet zien dat de
suite bij een defect in een worker blíjft hangen in plaats van rood te worden, en daarom heeft
`test_client_lokaal.mjs` nu een wachthond van dertig seconden