80: Introduce an explicit Hub-managed JavaFX runtime service

docs/Nenjim-public.html

@@ -21,8 +21,8 @@
     <h1>Nenjim</h1>
     <p class="status"><strong>Implementation status:</strong> Journal format version 1, the immutable Java model,
         internal strict parser, read-only <code>JournalService</code> with a Hub-managed process implementation,
-        passive explicitly refreshed <code>JournalServiceManager</code>, and the first central component Registry
-        are implemented. Contexts,
+        passive explicitly refreshed <code>JournalServiceManager</code>, Hub-managed
+        <code>JavaFxRuntimeService</code>, and the first central component Registry are implemented. Contexts,
         resolution, classloading, discovery, runtime loading/removal, downloading, publishing, synchronization,
         watching, signatures, permissions, and license filtering remain future work.</p>
 
@@ -117,6 +117,14 @@ PREFERRED=nenjim:com_r35157_nenjim-hubd-api=1.0.3:'Built together'</code></pre>
         <code>.valuetypes</code>, and <code>.exception</code>, while parser, ingestion, chain state, filesystem
         loading, and the admin boundary live under <code>.impl.ref</code> without leaking through public
         signatures.</p>
+    <p>All modern JavaFX applications share one JVM-wide toolkit. The Hub constructs one
+        <code>JavaFxRuntimeServiceImpl</code>, registers it as <code>nenjim.javafx-runtime.service</code>, starts it
+        through its <code>NenjimProcess</code> view, and injects its lifecycle-free service view into active Mission
+        Control and Process Manager. All six modern JavaFX implementations require that service in their constructor.
+        Only service startup calls <code>Platform.startup(...)</code>; task submission never initializes or retries
+        JavaFX and is rejected until startup succeeds. Startup waits until the JavaFX Application Thread is ready and
+        sets <code>Platform.setImplicitExit(false)</code>, keeping the shared runtime alive after the last window
+        closes.</p>
     <pre><code>data/nenjim/journals/
 └── &lt;artifact-coordinate&gt;/
     ├── &lt;journal-version&gt;.journal
@@ -146,11 +154,15 @@ PREFERRED=nenjim:com_r35157_nenjim-hubd-api=1.0.3:'Built together'</code></pre>
         assembly for <code>data/nenjim/journals</code>, registers <code>nenjim.journal.service</code>, starts Journal
         second, and records it only after complete successful loading. Only then does the Hub construct the hardcoded
         business component graph in dependency order. A Journal failure therefore stops startup before Ticker,
-        Evelyn, Burner, Mission Control, the online point, and the blocking wait.</p>
+        Evelyn, Burner, the JavaFX runtime, Mission Control, Process Manager, the online point, and the blocking
+        wait.</p>
     <p>The Ticker explicitly selects the Raydium EVE/USDT source ID while the hardcoded source remains registered but
-        inactive. After Registry and Journal, the Hub activates only the existing explicit five-business-process
-        sequence; it does not start every registered process. Successful process IDs are exposed as immutable ordered
-        point-in-time snapshots, without implying continued health.</p>
+        inactive. After Registry and Journal, the Hub activates the explicit Ticker, Production Evelyn, Test Evelyn,
+        Production IOU Burner, JavaFX runtime service, Mission Control, and Process Manager sequence; it does not
+        start every registered process. The shared JavaFX runtime is therefore active before either enabled JavaFX
+        application. Successful process IDs, including <code>nenjim.javafx-runtime.service</code>, are exposed as
+        immutable ordered point-in-time snapshots without implying continued health. A JavaFX startup failure is
+        fail-fast and prevents Mission Control and Process Manager from starting.</p>
     <p><code>com.r35157.nenjim.hubd.Main</code> remains only the outer Java bootstrap. It constructs the reference Hub
         through the public <code>NenjimHub</code> interface and calls <code>start()</code> once. The Hub is neither a
         component nor a process and is not registered inside its own Registry.</p>

docs/Nenjim.md

@@ -2,8 +2,8 @@
 
 > **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` 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` og første version af det centrale component Registry
+> er implementeret. Contexts, resolution, discovery, runtime loading og removal er fortsat fremtidig funktionalitet.
 
 **Indholdsfortegnelse:**
 <!-- TOC -->
@@ -219,6 +219,14 @@ Journal-objekt og en separat passiv `JournalServiceManager`. Journal-manageren r
 til root og refresh gennem et package-private admin-view; almindelige `JournalService`-consumers kan ikke udlede
 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.
+
 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
@@ -229,10 +237,13 @@ Applikationen ejer sine konkrete valg og sin activation. Tickerens initiale conf
 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 og Mission Control. Alarmen og øvrige tidligere
-udkommenterede applikationer bliver ikke automatisk aktiveret. Efter hvert succesfuldt `start()` registrerer Hub'en
-process-ID'et i et immutable, ordered snapshot; et fejlet start bliver ikke registreret, og listen lover ikke fortsat
-health eller liveness. Startup er fail-fast og kan kun forsøges én gang uden generic rollback.
+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.
 
 `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

docs/Terminologi.md

@@ -1,8 +1,8 @@
 # Tekniske termer
 
 > **Dokumentstatus:** Journal-format version 1 og de tilhørende Java-typer, den interne parser, query-service,
-> Hub-styret Journal-proces, passive service-managers og første version af det centrale component Registry er
-> implementeret. Resolver-, Context-,
+> Hub-styret Journal-proces, JavaFX-runtime-service, passive service-managers og første version af det centrale
+> component Registry er implementeret. Resolver-, Context-,
 > classloader-, discovery-, runtime-loading-, retrieval- og publishing-termer beskriver kun fremtidig vision, når
 > det er angivet.
 
@@ -13,7 +13,7 @@
 | Nenjim component | En færdigkonstrueret Nenjim-byggeklods, som er klar til brug. `NenjimComponent` er en ren marker uden ID eller lifecycle state. Service, applikation, algoritme og adapter beskriver roller, mens process beskriver en uafhængig lifecycle-klassifikation. |
 | Applikation | En user-facing eller orchestration-rolle. Rollen gør ikke i sig selv en component til en process; en aktiv applikationsimplementation kan separat implementere `NenjimProcess`. |
 | NenjimProcess | Det canonical `com.r35157.nenjim.process.NenjimProcess` component interface for noget, som Hub'en kan starte og tracke. Det eksponerer kun `start()` og lover ikke stop, restart, health, Context eller dependency lookup. |
-| NenjimHub | Den globale ejer af én kørende Nenjim runtime. Hub'en konstruerer og registrerer component graph'en, ejer dependency wiring og startup-policy, tracker succesfuldt startede process-ID'er, erklærer online point og ejer den afsluttende runtime wait. Den er hverken component eller process og registreres ikke i sit eget Registry. |
+| NenjimHub | Den globale ejer af én kørende Nenjim runtime. Hub'en konstruerer og registrerer component graph'en, ejer dependency wiring og startup-policy, tracker succesfuldt startede process-ID'er, starter den fælles JavaFX-runtime før dens applikationer, erklærer online point og ejer den afsluttende runtime wait. Den er hverken component eller process og registreres ikke i sit eget Registry. |
 | NenjimComponentId | Canonical lower-case Registry lookup identity med dot-separated segments og valgfrie interne bindestreger. ID'et er registration metadata i ét Registry, ikke object state, authorization eller artifact-version identity. |
 | NenjimRegistryService | Read-only component-katalog for almindelige consumers. Det giver immutable registration-order ID snapshots og typed lookup, men ingen registration, removal, loading, lifecycle, permission eller persistence administration. |
 | NenjimRegistryServiceAdmin | Package-private mutationsinterface i referenceimplementationen. Det er ikke en component, er ikke indexeret og må ikke gøres public, fordi almindelige consumers ellers kunne caste Registry-serviceobjektet til mutationsinterfacet. |
@@ -41,6 +41,8 @@
 | JournalService | Registrerbart, filesystem-uafhængigt og read-only Service-API for current og historical Journal-queries. Det eksponerer ingen lifecycle-, path-, refresh-, parser- eller mutationsoperationer, og queries er gated indtil vellykket proces-startup. |
 | JournalServiceManager | Passivt, uregistreret administrationshandle for én Journal-service med kun normalized data root og explicit refresh. Hub'en beholder det; det har ingen start, stop, service-accessor eller query-operationer. |
 | Journal referenceimplementation | Ét package-private `JournalServiceImpl`-objekt er både `JournalService` og `NenjimProcess`; en separat `JournalServiceManagerImpl`, intern admin-view, parser, ingestion, chain state og filesystem-loader ligger under `com.r35157.nenjim.service.journal.impl.ref` uden at lække gennem public signatures. |
+| JavaFX runtime | Det ene JVM-wide JavaFX toolkit, som udfører UI-arbejde på JavaFX Application Thread. Hub'en ejer dets eneste startup-sti gennem `JavaFxRuntimeServiceImpl` og holder det aktivt efter sidste lukkede vindue med `Platform.setImplicitExit(false)`. |
+| JavaFxRuntimeService | Registrerbart service-view med kun non-null `runLater(Runnable)`. Samme referenceimplementation er en Hub-styret `NenjimProcess`; service-consumers får den gennem constructor injection, men får ingen lifecycle-, status-, configuration-, window-, event-, stop- eller restart-operationer. |
 | Context | Fremtidig beskrivelse af ønskede/resolverede artifactvalg og isoleret runtime; ikke implementeret af Journal-laget eller første Registry-version. |
 | Resolver | Fremtidig komponent for dependency graph og release-selection; Journal-laget repræsenterer reglerne, men vælger ikke en graf. |