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/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
-er nog gedraaid en verbeterd wordt, betaalt elke wijziging de bouwronde uit §4 en levert het niets op wat
-er vandaag ontbreekt.
+**Beslist door de gebruiker op 27-08-2026: na Webinterface.** Dat is dezelfde afweging als waarom de
+pin-eis in **Publicatie-Gate** op "niet nu doen" staat: zolang er nog gedraaid en verbeterd wordt, betaalt
+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
-uit **Publicatie-Gate**. Dan valt dit samen met het werk dat toch aan de compose gedaan moet worden: het
-pinnen en het kaal maken van het app-id vragen allebei een herinstallatie, en die kun je één keer doen in
-plaats van drie keer.
+Het valt daarmee ook samen met het werk dat toch aan de compose gedaan moet worden vóór de inlevering uit
+**Publicatie-Gate**: het pinnen en het kaal maken van het app-id vragen allebei een herinstallatie, en die
+kun je één keer doen in 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.