De volgorde vastgelegd waar hij gelezen wordt, niet waar hij hoort te kloppen

Eigenimage komt na Webinterface, besloten door de gebruiker. De vindplaats is
hier het punt: een masterplan zonder tier komt in geen enkele prioriteits-
herziening langs, dus een notitie in dat plan alleen zou op het moment dat het
ingaat niemand bereiken.

Daarom staat de keuze in de prioriteits-header van Webinterface, want dat is wat
een sessie bij het starten leest, met de opdracht erbij: promoveren met een nieuw
tussennummer en eerst de registervraag beantwoorden.

De kolom "afhankelijk van" in de masterplannen-tabel houdt zijn streepje. Die is
voor harde afhankelijkheden en dit is er geen; technisch kan het plan morgen.

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

Docs/CONTINUE_HERE.md

@@ -64,7 +64,7 @@ daaronder, dus deze tabel en de mapinhoud kunnen niet uit elkaar lopen.
 | [Bereikbaarheid.PLAN.md](Plannen/Masterplannen/Bereikbaarheid.PLAN.md) | Relay | Umbrelapp: er valt niets bereikbaar te maken zolang er niets draait | Synchroniseren buiten het thuisnetwerk. **Suite eist geen TLS**, dus Tailscale blijft open en een certificaat is geen voorwaarde. Het risico van een publiek eindpunt is niet vertrouwelijkheid (dat regelt de versleuteling) maar misbruik als gratis opslag: een kale relay kent geen accounts. Wil je tóch open, dan is een eigenaars-allowlist nodig; drie manieren in §4b |
 | [Publicatie-Relay.PLAN.md](Plannen/Masterplannen/Publicatie-Relay.PLAN.md) | Relay | Umbrelapp, plus een image die te pinnen valt | Inleveren bij de officiële appstore. Twee dingen kunnen dit blokkeren: een image die niet als multi-arch digest in een registry bestaat, en de eis dat de umbrelOS-inlog aan blijft terwijl de relay een cliënt zonder sessie moet bedienen |
 | [Publicatie-Gate.PLAN.md](Plannen/Masterplannen/Publicatie-Gate.PLAN.md) | Gate | Appstore: de herstart-controle | **Doel van de gebruiker sinds 20-08-2026:** de app inleveren als standaard-app voor Umbrel. Dat verandert de maatstaf van "hij werkt hier" naar "iemand anders keurt het pakket goed". Het meeste is al goed; wat er nog moet is de images pinnen, het app-id kaal maken en de manifestvelden op orde. Het risico zit niet in die lijst maar in de leesmount op de certificaten van Zoraxy |
-| [Eigenimage.PLAN.md](Plannen/Masterplannen/Eigenimage.PLAN.md) | Gate | – | Van de code die nu uit `app-data` gemount wordt een eigen image maken, in het eigen Gitea-register. **Het lost níet het updateprobleem op**, want alle code staat al in een `*.template` en die staan in de whitelist. Wat het wel doet: code uit `app-data`, het shell-blok van honderd regels uit de compose, en één eigen digest in plaats van twee vreemde. Kosten: een bouwronde per wijziging, en multi-arch is nog nooit geprobeerd |
+| [Eigenimage.PLAN.md](Plannen/Masterplannen/Eigenimage.PLAN.md) | Gate | – | **Aan de beurt na Webinterface** (besloten 27-08-2026; een volgordekeuze, geen harde afhankelijkheid, vandaar het streepje hiernaast). Van de code die nu uit `app-data` gemount wordt een eigen image maken, in het eigen Gitea-register. **Het lost níet het updateprobleem op**, want alle code staat al in een `*.template` en die staan in de whitelist. Wat het wel doet: code uit `app-data`, het shell-blok van honderd regels uit de compose, en één eigen digest in plaats van twee vreemde. Kosten: een bouwronde per wijziging, en multi-arch is nog nooit geprobeerd |
 | [Configuratie.PLAN.md](Plannen/Masterplannen/Configuratie.PLAN.md) | Gate | – | **Grotendeels ingehaald op 19-08-2026** en moet opgeschoond worden voordat promotie nog zin heeft: de agent doet de certificaatbronnen en de keuze al, en het hardgecodeerde domein is uit de compose en uit `nginx.conf.template` verdwenen. Wat er nog in zit is een configuratiebestand voor de poort- en padoverstemmingen, plus de README |
 
 Cross-plan kennis staat in [KNOWLEDGE.md](KNOWLEDGE.md). Naslag staat niet in deze boom maar in

Docs/Plannen/Actief/005-Webinterface/TAKEN.md

@@ -2,6 +2,12 @@
 
 > Prioriteit: **A** | Wacht op: –
 >
+> **Wat hierna komt, besloten door de gebruiker op 27-08-2026: het masterplan Eigenimage.** Dat is geen
+> afhankelijkheid maar een volgordekeuze, en de reden staat aan die kant: een eigen image maakt van elke
+> wijziging een bouwronde, en dat remt precies het itereren op de pagina dat dit plan nog doet. Rond je dit
+> plan af, promoveer **Eigenimage** dan naar `Actief/` met een nieuw tussennummer, en beantwoord eerst open
+> punt 1 daar: blijft het Gitea-register ook bij publicatie de bron. **Eigenaar van die vraag: gebruiker**
+>
 > **Van C naar B naar A op 20-08-2026, op één dag.** Eerst verviel de blokkade "de app geïnstalleerd en de
 > agent draaiend". Aan het eind van die dag is dit het enige plan met werk dat nú te doen is: **Appstore**
 > heeft alleen nog een herstart nodig die niet te plannen is, en **Publicatie** wacht op een publieke repo.

Docs/Plannen/Masterplannen/Eigenimage.PLAN.md

@@ -159,13 +159,16 @@ hele bouwrecept. Iets verbeteren aan een recept dat misschien weggaat, is de ver
 
 ## 9. Wanneer dit actief zou moeten worden
 
-**Niet nu, en om dezelfde reden als waarom de pin-eis in Publicatie-Gate op "niet nu doen" staat:** zolang
+**Beslist door de gebruiker op 27-08-2026: na Webinterface.** Dat is dezelfde afweging als waarom de
-er nog gedraaid en verbeterd wordt, betaalt elke wijziging de bouwronde uit §4 en levert het niets op wat
+pin-eis in **Publicatie-Gate** op "niet nu doen" staat: zolang er nog gedraaid en verbeterd wordt, betaalt
-er vandaag ontbreekt.
+elke wijziging de bouwronde uit §4 en levert het niets op wat er vandaag ontbreekt. **Webinterface**
+itereert nu juist op de pagina, en dat is het werk dat er het meeste onder zou lijden.
 
-Het natuurlijke moment is als **Webinterface** klaar is met itereren op de pagina, en vóór de inlevering
+Het valt daarmee ook samen met het werk dat toch aan de compose gedaan moet worden vóór de inlevering uit
-uit **Publicatie-Gate**. Dan valt dit samen met het werk dat toch aan de compose gedaan moet worden: het
+**Publicatie-Gate**: het pinnen en het kaal maken van het app-id vragen allebei een herinstallatie, en die
-pinnen en het kaal maken van het app-id vragen allebei een herinstallatie, en die kun je één keer doen in
+kun je één keer doen in plaats van drie keer.
-plaats van drie keer.
 
-Harde afhankelijkheid heeft dit plan niet. Het kan technisch morgen.
+**Let op wat dit niet is: een harde afhankelijkheid.** Technisch kan dit plan morgen. Daarom staat er in de
+masterplannen-tabel van `CONTINUE_HERE.md` een streepje in de kolom "afhankelijk van"; die kolom is voor
+feiten over het plan en niet voor een volgorde-oordeel. De keuze staat wél in de prioriteits-header van
+**Webinterface**, `TAKEN.md`, want daar wordt hij gelezen op het moment dat hij ingaat.