UmbrelApps/Docs

Docs - documentatiewortel van UmbrelApps

Dit is de enige documentatieboom in de repo, en dit is de enige README erin: alle regels over waar iets hoort staan hieronder. De onderbouwing van de methode staat in HomeGit/Docs/.

Docs/
├── CONTINUE_HERE.md          - dunne index: per prioriteitstier naar de "volgende stap" van elk actief plan
├── KNOWLEDGE.md              - duurzame cross-plan kennis
├── CHANGELOG-<app>.md        - versiegeschiedenis, per app
├── Plannen/
│   ├── Actief/NNN-<Plan>/     - PLAN.md (ontwerp) · TAKEN.md (checklist) · PROGRESS.md (log) · OPEN.md
│   ├── Archief/<Plan>/        - afgerond; hele map verhuist hierheen, nummer vervalt
│   └── Masterplannen/         - nog niet actief; elk plan als één <Naam>.PLAN.md
│       └── Archief/           - opgevolgd; hier wordt nooit in bewerkt
└── Referenties/              - uitsluitend naslag: dingen waar je rekening mee moet houden

De map Plannen/Archief/ bestaat nog niet; lege mappen overleven git toch niet. Hij komt er zodra er iets in gaat.

Eén boom, twee apps

Deze repo is één community app store met twee apps erin, en er is één documentatiewortel voor allebei. Dat is geen concessie maar de reden dat het samengevoegd is: de spec van de appstore, de manier om images te pinnen en de manier van werken zijn voor beide apps dezelfde, en die stonden eerst in twee repo's naast elkaar.

Wat dat vraagt:

• elk plan hoort bij één app, en dat staat in de kolom App van CONTINUE_HERE.md en in de kop van het plan zelf. De prioriteit loopt wél over beide heen: tier A is wat er nu moet gebeuren, ongeacht welke app;
• botst een plannaam, dan krijgt hij een achtervoegsel met de app, en anders niet. Inleveren bij de officiële store is per app, dus daar staan Publicatie-Gate en Publicatie-Relay. De rest houdt gewoon zijn naam;
• hetzelfde geldt voor CHANGELOG, want version staat per manifest;
• een referentie zegt voor wie hij is. Sommige gelden voor beide apps, sommige voor één.

Waar hoort iets

Twee vragen, in deze volgorde:

1. Is het naslag (geen status, hoort niet bij één plan, wordt niet per sessie bijgewerkt)? Dan Referenties/.
2. Anders is het een plan, en de status bepaalt de plek: nog niet actief → Plannen/Masterplannen/<Naam>.PLAN.md; er wordt aan gewerkt → Plannen/Actief/NNN-<Naam>/; afgerond → Plannen/Archief/<Naam>/.

Twijfel? De test is: zit er werk aan vast dat ooit af moet zijn? Zo ja, dan is het een plan, ook als er voorlopig niemand aan begint.

Een plan begint als één bestand

Schrijf een nieuw plan als Plannen/Masterplannen/<Naam>.PLAN.md: doel, afbakening, niet-doelen, het werk in grote lijnen, open punten. Pas als het werk écht begint, promoveer je het naar Plannen/Actief/NNN-<Naam>/ met de vier bestanden. De promotie-stappen staan in HomeGit/Docs/Werkproces.md §1b.

Een masterplan heeft geen tier en geen nummer. Wat het wél kan hebben is een harde afhankelijkheid, en die staat in de masterplannen-tabel van CONTINUE_HERE.md.

Het nummer

010-, 020-, in stappen van tien zodat er altijd een 015- tussen kan. Drie cijfers. Het nummer is de aanbevolen volgorde, niet de tier: die staat in de prioriteits-header van TAKEN.md.

Het nummer bestaat op twee plekken: de mapnaam en CONTINUE_HERE.md. Verwijs overal elders met de naam van het plan: "zie het plan Appstore, TAKEN.md Fase 2". Binnen een plan link je relatief.

De reeks loopt over beide apps heen en is dus niet per app aaneengesloten. Dat is de bedoeling: er is één volgorde van werken, niet twee.

Sessie-protocol

Starten: CONTINUE_HERE.md → tier A → Plannen/Actief/NNN-<Plan>/TAKEN.md ("Volgende stap"). PLAN.md alleen bij twijfel over scope of ontwerp.

Afsluiten: TAKEN.md bijwerken, korte entry in PROGRESS.md, tier en de indexregel controleren, gewijzigde bestanden opsommen.

Projectspecifiek

Alle documentatie staat hier, ook wat elders vaak in de root ligt. In de repo-root blijft alleen README.md, en die is geen documentatie maar de voordeur: Gitea toont hem op de repo-pagina, en dat is voor een publieke app store het eerste wat iemand ziet. Hij hoort kort te blijven en door te verwijzen naar deze map. De oude ARCHITECTURE.md, STRUCTURE.md en QUICKSTART.md uit de root zijn opgegaan in Referenties/Architectuur-huidig.md; ze beschreven grotendeels hetzelfde in drie versies.

Er zijn tests, maar alleen voor Electrum Gate, en ze dekken de agent en het manifest. Hoe ze draaien staat in ../CLAUDE.md. Voor Evolu Relay is er nog geen bron en dus ook niets te testen; stap 4 van het sessie-protocol vervalt zolang een sessie alleen aan die app werkt.

Wat sowieso automatisch te controleren is en de moeite waard blijft, en dat geldt straks voor beide app-mappen: dat de YAML geldig is, dat het id in umbrel-app.yml gelijk is aan de mapnaam, en dat elke image: een @sha256:-digest heeft. Dat zijn precies de fouten die je op het apparaat pas merkt als de app niet start.

"Gebouwd" en "werkend" liggen hier verder uit elkaar dan gebruikelijk. Elk plan heeft daarom een paragraaf Verificatie met de controles die op de Umbrel zelf gedaan moeten worden. Meld die uitslag, inclusief wat er níet gecontroleerd is.

De repo wordt publiek. Dat is geen keuze maar een eis: umbreld kloont een community app store anoniem en kan geen inloggegevens aanbieden. Houd daar rekening mee bij wat je opschrijft. Evolu Relay krijgt een Postgres, en dan is er meer weg te houden dan bij Electrum Gate: geen wachtwoord in de compose, geen .env, geen dump.

Regeleindes zijn LF, afgedwongen door .gitattributes. Dat is hier geen netheid: de configuratie draait in een Linux-container, en een CRLF achter een #!/bin/sh laat een script stuklopen op een foutmelding die nergens naar het echte probleem wijst.