76: Introduce the Nenjim component registry and move runtime composition into its manager

docs/Nenjim.md

@@ -1,8 +1,9 @@
 #<center><H1>Nenjim<br>Documentation</H1></center>
 
 > **Dokumentstatus:** Journal-format version 1, den immutable Java-model, den interne tekstparser, det read-only
-> `JournalService` og den eksplicit refresh-baserede `JournalServiceManager` er implementeret. Afsnit 8–9 beskriver fremtidig vision og er ikke
-> funktionalitet i den nuværende Journal-implementation.
+> `JournalService`, den eksplicit refresh-baserede `JournalServiceManager` og første version af det centrale
+> component Registry er implementeret. Contexts, resolution, discovery, runtime loading og removal er fortsat
+> fremtidig funktionalitet.
 
 **Indholdsfortegnelse:**
 <!-- TOC -->
@@ -13,14 +14,15 @@
   * [5. Backing Store og Fleksibilitet](#5-backing-store-og-fleksibilitet)
   * [6. Standardiseret og Automatiseret Pakkehåndtering](#6-standardiseret-og-automatiseret-pakkehåndtering)
   * [7. Betydningen af Semantisk Versionering](#7-betydningen-af-semantisk-versionering)
-  * [8. Integration af Plugins og Centralt Registry](#8-integration-af-plugins-og-centralt-registry)
+  * [8. Componenter og det centrale Registry](#8-componenter-og-det-centrale-registry)
   * [9. Integration med AssetAZ og økonomisk aktivitet](#9-integration-med-assetaz-og-økonomisk-aktivitet)
 <!-- TOC -->
 
 ## 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. Dependency-resolution, Contexts, downloading og classloading kommer senere.
+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.
 
 ## 2. Versionering og Afhængigheder
 Nenjim beskriver moduler, artifakter, releases, relationer og versionspolitik i Journaler. Almindelig Java-kode skal
@@ -178,9 +180,40 @@ Format 1 accepterer kun stabile eksakte releases med alle tre numeriske komponen
 resolver altid vælger den numerisk højeste version: hard constraints afgrænser de gyldige valg, og policy/dependency
 hints kan på sigt foretrække en lavere kompatibel release.
 
-## 8. Integration af Plugins og Centralt Registry
-Plugin discovery, et centralt registry, Journal publishing, remote synchronization og signature-validering er
-fremtidig vision. De er ikke implementeret af Journal-modellen, servicen eller service-manageren.
+## 8. Componenter og det centrale Registry
+
+En Nenjim component er en færdigkonstrueret byggeklods, som er klar til brug. Rollen som service, applikation,
+algoritme eller adapter bestemmes af den applikation, som bruger componenten; Registry-API'et bruger derfor det
+fælles ord `component` og ikke `plugin`. `NenjimComponent` er en ren marker interface. En startbar component kan
+desuden implementere `NenjimApplication`, som kun lover `start()` og ikke en fælles stop-operation.
+
+En `NenjimComponentId` er registration metadata i ét Registry og er ikke en egenskab ved objektet. ID-formatet er
+lower-case ASCII med dot-separated segments og valgfrie interne bindestreger, f.eks. `nenjim.registry.service` og
+`assetaz.price-source.raydium-pool.eve-usdt`. Det samme objekt må registreres under flere forskellige ID'er, og én
+registration bliver automatisk synlig gennem alle component interfaces, som objektet implementerer. Registry- og
+application-view af Registry-objektet har derfor samme ID og samme object identity.
+
+`NenjimRegistryService` er det read-only katalog, som almindelige consumers modtager gennem constructor injection.
+Det kan returnere et immutable registration-order snapshot af ID'er for et component interface eller slå ét ID op
+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.
+
+`NenjimRegistryServiceManagerImpl` konstruerer og starter Registry'et, registrerer Registry og manager først og
+konstruerer derefter den nuværende hardcodede component graph i dependency order. Den package-private admin-view er
+kun managerens registrationshandle og er hverken en component eller public API. 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
+`assetaz.price-source.raydium-pool.eve-usdt` gennem Registry'et; den hardcodede price source er registreret, men
+inaktiv. Manageren starter kun den nuværende eksplicitte, dependency-safe liste: Ticker, Production Evelyn, Test
+Evelyn, Production IOU Burner og Mission Control. Alarmen og øvrige tidligere udkommenterede applikationer bliver
+ikke automatisk aktiveret. `com.r35157.nenjim.hubd.Main` er kun det yderste Java-bootstrap; `Main.main(...)` starter
+manageren gennem `NenjimApplication` og er ikke selv en component eller applikation.
+
+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.
 
 ## 9. Integration med AssetAZ og økonomisk aktivitet
 Økonomi, publicering og distribution er fremtidig vision. Format 1 beskriver alene artifaktviden; det indeholder