JournalService with a Hub-managed process implementation,
passive explicitly refreshed JournalServiceManager, Hub-managed
JavaFxRuntimeService, the first central component Registry, and mandatory Hub configuration
- format 2 are implemented. Contexts, resolution, classloading, discovery, runtime loading/removal,
+ format 1 are implemented. Contexts, resolution, classloading, discovery, runtime loading/removal,
downloading, publishing, synchronization, watching, signatures, permissions, and license filtering remain
future work.
@@ -148,20 +148,17 @@ PREFERRED=nenjim:com_r35157_nenjim-hubd-api=1.0.3:'Built together'
Registry manager. That manager exposes only registration, is neither a component nor a process, is not
registered, and cannot start anything. The internal administration interface must remain package-private so
an ordinary service consumer cannot cast the Registry object to a mutation view.
- NenjimHubImpl is the global composition and runtime owner. Before any process starts it reads only
the readable regular file conf/NenjimHub.conf. The version-controlled
conf/NenjimHub.conf.example is a copy-only template: the application never reads, copies,
generates, or falls back to it or to a hardcoded startup sequence.
FORMAT_VERSION=2
+ FORMAT_VERSION=1
[AUTO_START]
nenjim.registry.service
-nenjim.journal.service
-assetaz.ticker.default
-evelyn.service.prod
-evelyn.iou-burner.prod
- FORMAT_VERSION=2 must be the first actual entry and the one exact
+nenjim.journal.service
FORMAT_VERSION=1 must be the first actual entry and the one exact
[AUTO_START] header must be the next actual entry. Leading and trailing whitespace is ignored.
A trimmed line beginning with # is a comment, and # after content begins a trailing
comment. Inside the section a comment-only line does not terminate it, while the first whitespace-only line
@@ -171,7 +168,9 @@ evelyn.iou-burner.prod
duplicates, invalid or unknown IDs, passive-only IDs, and IDs the Hub cannot construct as modern processes
fail. Registry must occur exactly once first and Journal exactly once second. The known selectable processes
are Registry, Journal, Ticker, Jupiter Perps Alarm, both Evelyn services, Production IOU Burner, JavaFX
- runtime, Mission Control, and Process Manager. The default template omits the alarm.
After validation the Hub starts, registers, and records Registry, then eagerly constructs and registers the complete passive graph without activating a process. It next visits every remaining configured ID in exact order, beginning with Journal. Each selected process is constructed only when reached, registered before diff --git a/docs/Nenjim.md b/docs/Nenjim.md index ed472e4..a63db14 100644 --- a/docs/Nenjim.md +++ b/docs/Nenjim.md @@ -3,7 +3,7 @@ > **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`, første version af det centrale component Registry -> og den obligatoriske format 2 Hub-konfiguration er implementeret. Contexts, resolution, discovery, runtime loading +> og den obligatoriske format 1 Hub-konfiguration er implementeret. Contexts, resolution, discovery, runtime loading > og removal er fortsat fremtidig funktionalitet. **Indholdsfortegnelse:** @@ -236,13 +236,13 @@ fordi almindelige consumers ellers kunne caste deres Registry-service til mutati read-only service contract. Registration starter ikke et objekt, og Registry'et forbliver internt åbent for senere registration efter startup. -### 8.1 Obligatorisk `NenjimHub.conf` format 2 +### 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=2`; før den må der kun stå blanke linjer og full-line +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 @@ -277,19 +277,17 @@ graph konstrueres mellem Registry- og Journal-start. 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. Jupiter Perps Alarm kan vælges eksplicit, men er fortsat udeladt fra default-template. +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 headless eksempel uden JavaFX og Test Evelyn er: +Et minimalt headless eksempel, svarende til den versionerede template, er: ```text -FORMAT_VERSION=2 +FORMAT_VERSION=1 [AUTO_START] nenjim.registry.service nenjim.journal.service -assetaz.ticker.default -evelyn.service.prod -evelyn.iou-burner.prod ``` Tickerens egen component-konfiguration vælger fortsat eksplicit diff --git a/docs/Terminologi.md b/docs/Terminologi.md index 2378bab..63446c0 100644 --- a/docs/Terminologi.md +++ b/docs/Terminologi.md @@ -2,7 +2,7 @@ > **Dokumentstatus:** Journal-format version 1 og de tilhørende Java-typer, den interne parser, query-service, > Hub-styret Journal-proces, JavaFX-runtime-service, passive service-managers, første version af det centrale -> component Registry og obligatorisk Hub-konfiguration format 2 er implementeret. Resolver-, Context-, +> component Registry og obligatorisk Hub-konfiguration format 1 er implementeret. Resolver-, Context-, > classloader-, discovery-, runtime-loading-, retrieval- og publishing-termer beskriver kun fremtidig vision, når > det er angivet. @@ -16,7 +16,7 @@ | Passiv component | En `NenjimComponent`, hvis implementation ikke deltager i Hub-lifecycle gennem det canonical `NenjimProcess`. Den nuværende Hub konstruerer og registrerer hele den passive dependency graph efter Registry-start uafhængigt af `[AUTO_START]`, men starter den ikke. | | Valgt proces | Et kendt `NenjimProcess`-objekt, som Hub'en kun konstruerer, registrerer og starter, når dets ID forekommer i `[AUTO_START]`. Rollen som service eller applikation afgør ikke denne klassifikation. | | NenjimHub | Den globale ejer af én kørende Nenjim runtime. Hub'en validerer `conf/NenjimHub.conf` før proces-start, bootstrapper Registry, konstruerer den passive graph og konstruerer/registrerer/starter kun valgte processer i eksakt konfigurationsrækkefølge. Den tracker succesfulde start-ID'er, erklærer online point og ejer den afsluttende runtime wait, men er hverken component eller process og registreres ikke i sit eget Registry. | -| AUTO_START | Den obligatoriske, ordered sektion i `NenjimHub.conf` format 2. Den er deploymentets komplette manuelle proces-dependency closure; Registry og Journal skal være første og anden entry. Den udtrykker ikke Context resolution, discovery eller automatisk dependency construction. | +| AUTO_START | Den obligatoriske, ordered sektion i `NenjimHub.conf` format 1. Den er deploymentets komplette manuelle proces-dependency closure; Registry og Journal skal være første og anden entry. Den udtrykker ikke Context resolution, discovery eller automatisk dependency construction. | | 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. | diff --git a/openspec/changes/81-configure-ordered-process-autorun/design.md b/openspec/changes/81-configure-ordered-process-autorun/design.md index 7ee714e..5fa389c 100644 --- a/openspec/changes/81-configure-ordered-process-autorun/design.md +++ b/openspec/changes/81-configure-ordered-process-autorun/design.md @@ -52,7 +52,7 @@ Registry retains its required exceptional order of start, self-registration, the ### Keep deployment configuration separate from its template -The runtime path stays a private constant in the reference Hub. `conf/NenjimHub.conf.example` is version controlled and documented, but no code references that example path. The real file remains deployment-specific under the existing `*.conf` ignore rule. Documentation shows copying explicitly and includes a separate headless snippet. +The runtime path stays a private constant in the reference Hub. `conf/NenjimHub.conf.example` is version controlled and documented, but no code references that example path. The example deliberately contains only the mandatory Registry and Journal entries so it is safe and generic for downstream users; operators add their own deployment-specific processes and dependency order after copying it. The real file remains deployment-specific under the existing `*.conf` ignore rule. Documentation shows copying explicitly and includes the same minimal headless bootstrap. ## Risks / Trade-offs @@ -64,8 +64,7 @@ The runtime path stays a private constant in the reference Hub. `conf/NenjimHub. ## Migration Plan -1. Deploy the new build together with an operator-created `conf/NenjimHub.conf` copied from the version 2 example and adjusted for the deployment role. +1. Deploy the new build together with an operator-created `conf/NenjimHub.conf` copied from the version 1 example and extended with the deployment's own ordered process selection. 2. Validate that manually ordered dependencies precede their consumers; Registry and Journal must remain first and second. 3. Start the Hub normally through the unchanged `Main` entry point. 4. To roll back the software, restore the previous build and its prior deployment configuration expectations; the application never rewrites either runtime or example configuration. - diff --git a/openspec/changes/81-configure-ordered-process-autorun/proposal.md b/openspec/changes/81-configure-ordered-process-autorun/proposal.md index 3b5e184..380dabc 100644 --- a/openspec/changes/81-configure-ordered-process-autorun/proposal.md +++ b/openspec/changes/81-configure-ordered-process-autorun/proposal.md @@ -4,20 +4,20 @@ ## What Changes -- **BREAKING**: Require the Hub to read `conf/NenjimHub.conf` in strict format version 2 before any process starts; missing, unreadable, non-regular, malformed, or unsupported configuration fails startup without fallback. +- **BREAKING**: Require the Hub to read `conf/NenjimHub.conf` in strict format version 1 before any process starts; missing, unreadable, non-regular, malformed, or unsupported configuration fails startup without fallback. - Add one mandatory ordered `[AUTO_START]` section whose active lines are canonical `NenjimComponentId` values, with defined whitespace, `#` comment, and blank-line termination rules. - Validate the complete requested process sequence before Registry startup, including known process capability, uniqueness, and Registry/Journal placement as the first two entries. - Bootstrap Registry, then eagerly construct and register the complete passive component graph, while lazily constructing, registering, and starting only the remaining configured process objects in exact configuration order. - Preserve registration-before-start, post-success startup recording, fail-fast partial-startup semantics, the online point, and the blocking runtime wait without rollback or dependency inference. - Make all modern Hub-known processes selectable, including the otherwise inactive Jupiter Perps Alarm, while an omitted process is neither constructed, registered, nor started. -- Add a documented `conf/NenjimHub.conf.example` that reproduces the former successful startup sequence and remains a copy-only template, plus headless configuration documentation. +- Add a documented, copy-only `conf/NenjimHub.conf.example` that provides a generic minimal bootstrap with only the mandatory Registry and Journal processes, plus headless configuration documentation. - Remove the unconditional process-construction path and fixed startup list without adding public factory, discovery, lifecycle, Context, or configuration APIs. ## Capabilities ### New Capabilities -- `nenjim-hub-configuration`: Defines the mandatory format 2 Hub configuration grammar, validation, ordered bootstrap and startup plan, lazy selected-process construction, omitted-process behavior, template role, and failure semantics. +- `nenjim-hub-configuration`: Defines the mandatory format 1 Hub configuration grammar, validation, ordered bootstrap and startup plan, lazy selected-process construction, omitted-process behavior, template role, and failure semantics. ### Modified Capabilities @@ -29,5 +29,5 @@ - Adds an implementation-only Hub configuration parser/model and process-construction catalogue under `com.r35157.nenjim.hubd.impl.ref` without changing the public `NenjimHub` API. - Refactors `NenjimHubImpl` composition so Registry remains the bootstrap exception, passive dependencies remain eager, and process instances become lazy. - Adds `conf/NenjimHub.conf.example` while retaining the ignored deployment-specific runtime file at `conf/NenjimHub.conf`. -- Updates Nenjim architecture and terminology documentation to describe format 2, manual dependency ordering, headless operation, and actual successful-start snapshots. +- Updates Nenjim architecture and terminology documentation to describe format 1, manual dependency ordering, a generic minimal template, headless operation, and actual successful-start snapshots. - Adds no automated tests, external dependencies, process rollback, automatic dependency resolution, dynamic discovery, or command-line configuration selection. diff --git a/openspec/changes/81-configure-ordered-process-autorun/specs/nenjim-hub-configuration/spec.md b/openspec/changes/81-configure-ordered-process-autorun/specs/nenjim-hub-configuration/spec.md index f2211d0..f54d82f 100644 --- a/openspec/changes/81-configure-ordered-process-autorun/specs/nenjim-hub-configuration/spec.md +++ b/openspec/changes/81-configure-ordered-process-autorun/specs/nenjim-hub-configuration/spec.md @@ -8,7 +8,7 @@ Defines the mandatory deployment configuration that selects which modern Nenjim The reference Hub SHALL read only `conf/NenjimHub.conf` and SHALL complete all configuration parsing and validation before starting Registry or any other process. The path SHALL not be configurable through `Main`, command-line arguments, or the public `NenjimHub` API. A missing, unreadable, or non-regular runtime file SHALL fail Hub startup clearly and identify the configured path. The Hub SHALL not read, copy, generate, or fall back to `conf/NenjimHub.conf.example`, and SHALL not fall back to a hardcoded startup list. #### Scenario: Runtime configuration is valid -- **WHEN** `conf/NenjimHub.conf` is a readable regular file containing a valid format 2 configuration +- **WHEN** `conf/NenjimHub.conf` is a readable regular file containing a valid format 1 configuration - **THEN** the Hub derives its complete requested process order from that file before starting Registry #### Scenario: Runtime configuration cannot be read @@ -19,13 +19,13 @@ The reference Hub SHALL read only `conf/NenjimHub.conf` and SHALL complete all c - **WHEN** `conf/NenjimHub.conf` is absent but `conf/NenjimHub.conf.example` exists - **THEN** startup fails without reading, copying, or using the example and without starting a hardcoded fallback set -### Requirement: Format 2 has one exact ordered AUTO_START section -The first actual configuration entry SHALL be exactly `FORMAT_VERSION=2`, after optional leading blank lines and full-line comments. Version 2 SHALL be the only supported version; a missing, malformed, duplicate, version 1, or otherwise unsupported declaration SHALL fail. The next actual entry SHALL be exactly one `[AUTO_START]` header, optionally followed only by a trailing `#` comment. Unknown, malformed, repeated, valued, or out-of-order sections and entries before `[AUTO_START]` SHALL fail. +### Requirement: Format 1 has one exact ordered AUTO_START section +The first actual configuration entry SHALL be exactly `FORMAT_VERSION=1`, after optional leading blank lines and full-line comments. Version 1 SHALL be the only supported version; a missing, malformed, duplicate, version 2, or otherwise unsupported declaration SHALL fail. The next actual entry SHALL be exactly one `[AUTO_START]` header, optionally followed only by a trailing `#` comment. Unknown, malformed, repeated, valued, or out-of-order sections and entries before `[AUTO_START]` SHALL fail. -Outside `[AUTO_START]`, leading and trailing whitespace SHALL be ignored, a line whose trimmed content begins with `#` SHALL be a full-line comment, and `#` after actual content SHALL begin a trailing comment. Inside `[AUTO_START]`, surrounding whitespace around a process ID SHALL be ignored; full-line and trailing comments SHALL be ignored; comment-only lines SHALL not terminate the section; and the first whitespace-only line or end of file SHALL terminate it. After termination, only blank lines and comments SHALL be accepted. Format 2 SHALL provide no quoting or escaping for `#`. +Outside `[AUTO_START]`, leading and trailing whitespace SHALL be ignored, a line whose trimmed content begins with `#` SHALL be a full-line comment, and `#` after actual content SHALL begin a trailing comment. Inside `[AUTO_START]`, surrounding whitespace around a process ID SHALL be ignored; full-line and trailing comments SHALL be ignored; comment-only lines SHALL not terminate the section; and the first whitespace-only line or end of file SHALL terminate it. After termination, only blank lines and comments SHALL be accepted. Format 1 SHALL provide no quoting or escaping for `#`. #### Scenario: Leading comments and trailing comments are accepted -- **WHEN** blank lines or full-line comments precede `FORMAT_VERSION=2`, and the version, section header, or process entries contain trailing `#` comments +- **WHEN** blank lines or full-line comments precede `FORMAT_VERSION=1`, and the version, section header, or process entries contain trailing `#` comments - **THEN** comment text and permitted surrounding whitespace are ignored while the actual entries are parsed normally #### Scenario: Comment inside AUTO_START does not terminate it @@ -41,7 +41,7 @@ Outside `[AUTO_START]`, leading and trailing whitespace SHALL be ignored, a line - **THEN** the section terminates successfully at end of file #### Scenario: Version declaration is invalid -- **WHEN** the version is absent, malformed, duplicated, not the first actual entry, or has a value other than `2` +- **WHEN** the version is absent, malformed, duplicated, not the first actual entry, or has a value other than `1` - **THEN** configuration validation fails before any process starts and identifies the path, relevant line and reason #### Scenario: Section structure is invalid @@ -127,13 +127,12 @@ Registry and every selected process SHALL be registered before its `start()` cal - **THEN** the startup snapshot has the exact configured order, the online point is announced, and the Hub enters its existing blocking wait ### Requirement: The version-controlled example is a copy-only template -The repository SHALL contain `conf/NenjimHub.conf.example` as a documented format 2 template that reproduces the former successful process sequence without selecting `jupiter-perps-alarm.default`. Its comments SHALL state that Registry and Journal are mandatory, order is preserved, current process dependencies must be listed manually before consumers, JavaFX runtime precedes JavaFX applications, commenting out an entry prevents its process from being constructed or started, and the file must be copied to `conf/NenjimHub.conf` before use. Documentation SHALL include a headless example and SHALL describe recursive dependency construction as future work rather than implemented behavior. +The repository SHALL contain `conf/NenjimHub.conf.example` as a documented format 1 copy-only template with only the mandatory Registry and Journal entries active. It SHALL contain no optional deployment-specific process IDs. Its comments SHALL state that the file must be copied to `conf/NenjimHub.conf` before use, Registry and Journal are mandatory, order is preserved, and process dependencies must be listed manually before their consumers. Documentation SHALL show the same minimal bootstrap as a headless example and SHALL describe recursive dependency construction as future work rather than implemented behavior. -#### Scenario: Example reproduces the former startup sequence +#### Scenario: Example provides a generic minimal bootstrap - **WHEN** the example's uncommented process IDs are read in order -- **THEN** they are Registry, Journal, Ticker, Production Evelyn, Test Evelyn, Production IOU Burner, JavaFX runtime, Mission Control, and Process Manager +- **THEN** they are only Registry and Journal, with no optional deployment-specific process ID present -#### Scenario: Operator uses a headless example +#### Scenario: Operator uses the minimal headless example - **WHEN** the documented headless configuration is copied to the runtime path -- **THEN** it selects Registry, Journal, Ticker, Production Evelyn, and Production IOU Burner without selecting Test Evelyn or any JavaFX process - +- **THEN** it selects only Registry and Journal and leaves every optional process for the operator to add explicitly diff --git a/openspec/changes/81-configure-ordered-process-autorun/tasks.md b/openspec/changes/81-configure-ordered-process-autorun/tasks.md index 8ee1914..9df5832 100644 --- a/openspec/changes/81-configure-ordered-process-autorun/tasks.md +++ b/openspec/changes/81-configure-ordered-process-autorun/tasks.md @@ -1,6 +1,6 @@ ## 1. Hub configuration -- [x] 1.1 Add the package-private immutable Hub configuration model and strict format 2 parser for the fixed runtime path, including exact version/section/comment/termination grammar and path-and-line diagnostics. +- [x] 1.1 Add the package-private immutable Hub configuration model and strict format 1 parser for the fixed runtime path, including exact version/section/comment/termination grammar and path-and-line diagnostics. - [x] 1.2 Validate canonical process IDs, duplicates, known process construction capability, and mandatory Registry/Journal positions before Registry startup. ## 2. Ordered runtime composition @@ -11,7 +11,7 @@ ## 3. Configuration template and documentation -- [x] 3.1 Add `conf/NenjimHub.conf.example` as a documented copy-only format 2 template reproducing the former startup sequence without enabling Jupiter Perps Alarm. +- [x] 3.1 Add `conf/NenjimHub.conf.example` as a documented copy-only format 1 template containing only the mandatory Registry and Journal bootstrap entries, without deployment-specific optional processes. - [x] 3.2 Update Nenjim architecture, public documentation, and terminology for mandatory Hub configuration, exact grammar, manual dependency order, passive versus selected construction, omission, failure semantics, and headless operation. ## 4. Verification