81: Control Nenjim process construction and ordered startup through NenjimHub.conf

docs/Nenjim.md

@@ -2,8 +2,9 @@
 
 > **Dokumentstatus:** Journal-format version 1, den immutable Java-model, den interne tekstparser, det read-only
 > `JournalService` med en Hub-styret procesimplementation, den passive eksplicit refresh-baserede
-> `JournalServiceManager`, den Hub-styrede `JavaFxRuntimeService` og første version af det centrale component Registry
-> er implementeret. Contexts, resolution, discovery, runtime loading og removal er fortsat fremtidig funktionalitet.
+> `JournalServiceManager`, den Hub-styrede `JavaFxRuntimeService`, første version af det centrale component Registry
+> og den obligatoriske format 1 Hub-konfiguration er implementeret. Contexts, resolution, discovery, runtime loading
+> og removal er fortsat fremtidig funktionalitet.
 
 **Indholdsfortegnelse:**
 <!-- TOC -->
@@ -21,8 +22,9 @@
 ## 1. Introduktion til Nenjim
 Nenjim skal på sigt kunne håndtere forskellige versioner af softwareartifakter samtidigt. Det nu implementerede
 fundament er Journal-laget: et strengt tekstformat og en immutable model, som kan fastholde, hvad der var kendt om
-en artifakt på et bestemt tidspunkt. Det første Registry kan desuden katalogisere de nuværende hardcodede
-componenter. Dependency-resolution, Contexts, downloading og classloading kommer senere.
+en artifakt på et bestemt tidspunkt. Det første Registry kan desuden katalogisere de konstruerede componenter, og
+Hub-konfigurationen vælger den manuelt ordnede procesmængde. Dependency-resolution, Contexts, downloading og
+classloading kommer senere.
 
 ## 2. Versionering og Afhængigheder
 Nenjim beskriver moduler, artifakter, releases, relationer og versionspolitik i Journaler. Almindelig Java-kode skal
@@ -208,11 +210,12 @@ Det kan returnere et immutable registration-order snapshot af ID'er for et compo
 gennem et forventet interface. Et manglende ID giver `null`; et eksisterende ID med forkert interface er en caller
 programming error. Public API'et kan ikke registrere eller fjerne componenter.
 
-`NenjimHubImpl` repræsenterer én kørende Nenjim runtime. Hub'en konstruerer Registry- og Journal-subsystemerne samt
-hele den nuværende hardcodede component graph, ejer dependency wiring og vælger de processer, som skal startes. Et
-implementation-only Registry assembly udleverer read-only service-view, process-view af det samme Registry-objekt
-og en separat `NenjimRegistryServiceManager`. Manageren er kun Hub'ens passive registrationshandle: den er hverken
-component eller process, har ingen `start()` eller service-accessor, registreres ikke og starter aldrig en component.
+`NenjimHubImpl` repræsenterer én kørende Nenjim runtime. Hub'en læser deployment-konfigurationen, ejer dependency
+wiring og lifecycle, konstruerer hele den nuværende passive component graph og konstruerer kun de processer, som er
+valgt til autorun. Et implementation-only Registry assembly udleverer read-only service-view, process-view af det
+samme Registry-objekt og en separat `NenjimRegistryServiceManager`. Manageren er kun Hub'ens passive
+registrationshandle: den er hverken component eller process, har ingen `start()` eller service-accessor, registreres
+ikke og starter aldrig en component.
 
 Et tilsvarende implementation-only Journal assembly udleverer read-only service-view, process-view af det samme
 Journal-objekt og en separat passiv `JournalServiceManager`. Journal-manageren registreres ikke og giver kun adgang
@@ -221,29 +224,79 @@ administrationsadgangen.
 
 Alle moderne JavaFX-applikationer deler ét JVM-wide JavaFX toolkit. Det repræsenteres af
 `JavaFxRuntimeService`, mens samme `JavaFxRuntimeServiceImpl`-objekt også implementerer `NenjimProcess` for Hub'ens
-lifecycle. Hub'en konstruerer og registrerer objektet som `nenjim.javafx-runtime.service`, starter det før de aktive
-JavaFX-applikationer og injicerer service-viewet i dem gennem deres constructors. Kun processens `start()` må kalde
-`Platform.startup(...)`; `runLater(...)` starter aldrig toolkit'et implicit og afviser arbejde, indtil startup er
-lykkedes. Startup venter på JavaFX Application Thread og sætter `Platform.setImplicitExit(false)`, så den delte
-runtime forbliver aktiv, når det sidste vindue lukkes.
+lifecycle. Når den er valgt, konstruerer og registrerer Hub'en objektet som `nenjim.javafx-runtime.service`; den skal
+stå før valgte JavaFX-applikationer i autorun-listen, så dens service-view kan injiceres efter vellykket startup. Kun
+processens `start()` må kalde `Platform.startup(...)`; `runLater(...)` starter aldrig toolkit'et implicit og afviser
+arbejde, indtil startup er lykkedes. Startup venter på JavaFX Application Thread og sætter
+`Platform.setImplicitExit(false)`. Udelades alle JavaFX-processer, konstruerer Hub'en ikke runtime-objektet og
+initialiserer ikke toolkittet.
 
 Den package-private `NenjimRegistryServiceAdmin` er managerens interne mutationsadgang. Den må ikke gøres public,
 fordi almindelige consumers ellers kunne caste deres Registry-service til mutationsinterfacet og bryde det
 read-only service contract. Registration starter ikke et objekt, og Registry'et forbliver internt åbent for senere
 registration efter startup.
 
-Applikationen ejer sine konkrete valg og sin activation. Tickerens initiale configuration vælger eksplicit
+### 8.1 Obligatorisk `NenjimHub.conf` format 1
+
+Hub'en læser kun `conf/NenjimHub.conf`. Filen skal eksistere som en læsbar regular file; en manglende eller ugyldig
+fil stopper startup, før Registry startes. `conf/NenjimHub.conf.example` er kun en versioneret copy-template: Hub'en
+læser, kopierer og genererer den aldrig og falder hverken tilbage til den eller til en hardcoded procesliste.
+
+Den første faktiske entry skal være `FORMAT_VERSION=1`; før den må der kun stå blanke linjer og full-line
+`#`-kommentarer. Den næste faktiske entry skal være den ene eksakte `[AUTO_START]`-header. Hver aktiv linje i
+sektionen er ét `NenjimComponentId`, og rækkefølgen bevares præcist. Leading/trailing whitespace ignoreres, en trimmet
+linje som begynder med `#` er en kommentar, og `#` efter faktisk indhold starter en trailing kommentar. Inde i
+sektionen fortsætter en comment-only line listen, mens den første whitespace-only line afslutter sektionen; EOF kan
+også afslutte den. Efter afslutningen tillades kun blanke linjer og kommentarer. Formatet har ingen quoting eller
+escaping for `#`.
+
+Hele listen valideres før første proces-start. Ugyldige, duplikerede, ukendte og passive component-ID'er afvises.
+Registry skal stå præcis én gang først og Journal præcis én gang som nummer to. De kendte valgbare processer er:
+
+```text
+nenjim.registry.service
+nenjim.journal.service
+assetaz.ticker.default
+jupiter-perps-alarm.default
+evelyn.service.prod
+evelyn.service.test
+evelyn.iou-burner.prod
+nenjim.javafx-runtime.service
+evelyn.mission-control.default
+nenjim.process-manager.default
+```
+
+Efter validering konstruerer og starter Hub'en Registry, registrerer det som `nenjim.registry.service` og registrerer
+startup-milepælen. Derefter konstrueres og registreres hele den nuværende passive graph uden at starte workers eller
+processer. Først herefter behandles resten af `[AUTO_START]` i den angivne rækkefølge, begyndende med Journal. Hver
+valgt proces konstrueres først, når dens linje nås, registreres før `start()` og tilføjes kun til Hub'ens immutable
+ordered snapshot, når `start()` returnerer. Journal er derfor stadig den anden succesfulde proces, selv om den passive
+graph konstrueres mellem Registry- og Journal-start.
+
+`[AUTO_START]` er foreløbig deploymentets komplette, manuelt ordnede proces-dependency closure. Hub'en finder,
+indsætter eller omordner ikke dependencies. En krævet proces skal stå før sin consumer; eksempelvis skal
+`nenjim.javafx-runtime.service` stå før Mission Control og Process Manager. Mangler forgængeren, stopper konstruktion
+eller startup fail-fast uden implicit reparation. En udeladt proces bliver hverken konstrueret, registreret, startet
+eller vist af Process Manager. Den versionerede template vælger kun de obligatoriske Registry- og Journal-processer;
+alle øvrige processer skal tilføjes eksplicit til deploymentets private konfiguration.
+
+Et minimalt headless eksempel, svarende til den versionerede template, er:
+
+```text
+FORMAT_VERSION=1
+
+[AUTO_START]
+nenjim.registry.service
+nenjim.journal.service
+```
+
+Tickerens egen component-konfiguration vælger fortsat eksplicit
 `assetaz.price-source.raydium-pool.eve-usdt` gennem Registry'et; den hardcodede price source er registreret, men
-inaktiv. Hub'en starter Registry-processen først og registrerer den som `nenjim.registry.service`. Journal-servicen
-registreres dernæst som `nenjim.journal.service`, startes som den anden proces og skal være fuldt initialiseret, før
-business graph'en fortsætter. Derefter starter Hub'en kun den nuværende eksplicitte, dependency-safe liste: Ticker,
-Production Evelyn, Test Evelyn, Production IOU Burner, JavaFX-runtime-servicen, Mission Control og Process Manager.
-JavaFX-runtime-servicen startes altså før begge aktive JavaFX-applikationer; Composer, Test Tool, Soda Task Manager
-og Suwimo Client er fortsat inaktive, men bruger samme constructor-injection model. Alarmen bliver heller ikke
-automatisk aktiveret. Efter hvert succesfuldt `start()` registrerer Hub'en process-ID'et i et immutable, ordered
-snapshot, inklusive `nenjim.javafx-runtime.service`; et fejlet start bliver ikke registreret, og listen lover ikke
-fortsat health eller liveness. JavaFX-startfejl stopper opstarten før Mission Control og Process Manager. Startup er
-fail-fast og kan kun forsøges én gang uden generic rollback.
+inaktiv. Fejl under passiv konstruktion, valgt proceskonstruktion, registration eller startup stopper straks og
+forhindrer alle senere processer. Tidligere succeser forbliver synlige, den fejlende proces registreres ikke som
+startet, og der udføres ingen generic rollback. Online point og det afsluttende blocking wait nås kun efter alle
+konfigurerede processer er startet. Process Manager viser fortsat Hub'ens faktiske succesfulde snapshots og ikke den
+ønskede konfigurationsliste.
 
 `com.r35157.nenjim.hubd.Main` er kun det yderste Java-bootstrap. `Main.main(...)` konstruerer `NenjimHubImpl` gennem
 det globale `NenjimHub`-interface og kalder `start()` præcis én gang. Hub'en ejer også det eksisterende online point
@@ -251,8 +304,9 @@ og den afsluttende blocking wait. Hub'en er hverken component eller process og r
 
 Det implementerede Registry er ét katalog og er ikke et authorization-system. Contexts, artifact-version semantics,
 resolution, classloading, automatic discovery, public runtime loading/registration, removal, persistence, events,
-automatic selection/start-all, usage tracking og permissions er fremtidigt arbejde. Journal publishing, remote
-synchronization og signature validation er ligeledes ikke implementeret.
+automatic dependency construction/start-all, usage tracking og permissions er fremtidigt arbejde. Den nuværende
+autorun-fil er ikke Context resolution eller process discovery. Journal publishing, remote synchronization og
+signature validation er ligeledes ikke implementeret.
 
 ## 9. Integration med AssetAZ og økonomisk aktivitet
 Økonomi, publicering og distribution er fremtidig vision. Format 1 beskriver alene artifaktviden; det indeholder