Title: Make NenjimHub the runtime owner and replace NenjimApplication with NenjimProcess
Background
Issue #76 introduced the central Nenjim component Registry and moved the complete hardcoded component graph, process startup and blocking runtime lifecycle into NenjimRegistryServiceManagerImpl.
That implementation made the current system compile and start from one composition root, but subsequent design review has clarified that the composition root is not part of the Registry subsystem.
NenjimHub is a real runtime object with its own responsibility:
It represents one running Nenjim runtime.
It constructs the complete component graph.
It owns dependency wiring.
It registers components through the Registry manager.
It decides which processes to start.
It records which processes started successfully.
It owns the final online and blocking runtime lifecycle.
It will later become the owner of stop and restart operations.
The Registry is an otherwise ordinary service on which the complete current component graph depends. Its manager is only a passive administrative indirection that allows the Hub to mutate the Registry without exposing mutation through NenjimRegistryService.
This issue corrects the ownership introduced by #76 while preserving the current business graph and startup behavior.
Goals
This issue must:
Introduce the canonical minimal NenjimProcess lifecycle contract.
Remove and replace NenjimApplication.
Reintroduce NenjimHub as the global composition and runtime owner.
Reduce NenjimRegistryServiceManager to a passive registration handle.
Make the Hub construct the Registry subsystem and complete component graph.
Make the Hub start the Registry process first and all other enabled processes afterwards.
Expose an immutable ordered snapshot of successfully started process IDs.
Preserve the current enabled and disabled process choices.
Preserve the current application entry point class.
Update OpenSpec and documentation to describe the corrected architecture.
NenjimProcess is the general lifecycle classification for a component that the Hub can start and track.
The terminology must distinguish independent dimensions:
A NenjimComponent is any constructed and registrable Nenjim building block.
A service exposes a domain API to consumers.
An application describes a user-facing or orchestration role.
A NenjimProcess is an active component with a Hub-managed startup lifecycle.
A service or application implementation may therefore also be a NenjimProcess.
Passive components do not implement NenjimProcess.
The process contract introduced by this issue contains only start() throws Exception. It does not contain stop, restart, health, context assignment or dependency lookup.
The existing NenjimApplication interface must be removed without a deprecated alias or compatibility wrapper. All modern implementations and lookups that currently use it must use the canonical NenjimProcess instead.
At minimum, this affects the current reference implementations of:
The Registry service.
Ticker service.
Production and Test Evelyn services.
Evelyn IOU Burner service.
Evelyn Mission Control.
Jupiter Perps Alarm.
The Registry manager must not become a process.
Legacy similarly named process prototypes outside the modern API packages are not canonical and are not part of this migration unless a direct compile dependency requires a narrowly scoped update. Their general cleanup remains future work under #73.
NenjimHub is the global runtime owner. It must not extend NenjimComponent or NenjimProcess, and it must not be registered inside its own Registry.
The reference implementation must be:
com.r35157.nenjim.hubd.impl.ref.NenjimHubImpl
The Hub must accept only one start attempt, including after failure. A later call must fail clearly with IllegalStateException.
NenjimHub must not be reused as the name of a future context-bound dependency facade. Context-specific process access will receive a different name in later work. This issue does not define that future API.
Started-process snapshot
getStartedProcessIds() must:
Be safe to call before, during and after Hub startup.
Return an immutable point-in-time snapshot.
Preserve successful startup order.
Return an empty list before the first process has started.
Include a process only after its start() call has returned successfully.
Never include a process whose startup failed.
Preserve already successful entries if a later process fails.
Make no health or continued-liveness guarantee.
In this issue, “started” means only:
The Hub called start() on the process and the call returned successfully.
It does not mean that every internal worker remains healthy.
Passive Registry manager
Replace the current Registry manager contract with:
Delegates registration to the Registry’s internal administrative view.
Preserves the current duplicate-ID and interface-indexing behavior.
Permits registration after Registry startup.
Never activates a component merely because it is registered.
The registration ID:
nenjim.registry.service-manager
must be removed. The manager is not a component and therefore has no component registration.
Registry construction and administrative boundary
The Hub must initiate construction of:
One Registry service/process object.
One distinct Registry manager object bound to that Registry.
The internal package-private administrative view required by the manager.
Because the Registry implementation and administrative view must remain hidden, the reference implementation may use a stateless implementation-only factory or assembly type under:
com.r35157.nenjim.service.registry.impl.ref
The construction mechanism must provide the Hub with:
A NenjimRegistryService view.
A NenjimProcess view of the same Registry object.
A distinct NenjimRegistryServiceManager bound to that object.
The construction helper:
Owns no runtime lifecycle.
Is neither a component nor a process.
Must not become Registry-discoverable.
Must not expose NenjimRegistryServiceAdmin.
Must not allow an ordinary service reference to derive the manager for the active Registry.
The service and process views must have identical object identity.
NenjimRegistryServiceAdmin must remain package-private. Its JavaDoc must explicitly explain that:
The same Registry object is exposed publicly through NenjimRegistryService.
Making the admin interface public would allow ordinary consumers to cast the service object to the mutation interface.
Making it public would break the read-only Registry contract.
It must not be exposed outside the reference implementation package.
The Registry remains a component and becomes discoverable under both NenjimRegistryService and NenjimProcess after registration.
Hub-owned startup sequence
NenjimHubImpl.start() must perform the following sequence:
Construct the Registry service/process and its passive manager.
Start the Registry through its NenjimProcess view.
Register the Registry service as:
nenjim.registry.service
Record the Registry ID as the first successfully started process.
Construct and register the complete current hardcoded component graph in dependency order.
Resolve the currently enabled IDs through NenjimProcess.
Start them in the existing dependency-safe order.
Append each ID to the started-process list only after successful startup.
Announce the existing online point.
Preserve the existing blocking wait.
The Registry must start before the remaining graph is constructed because current constructors, including TickerServiceImpl, may perform Registry lookups.
After the Registry, the enabled process order must remain:
The existing deliberately inactive components, including jupiter-perps-alarm.default and the dormant Composer, Process Manager, Test Tool, Soda Task Manager and Suwimo Client paths, must remain inactive.
Registration must not imply startup, and the Hub must not start every registered process automatically.
Startup failure behavior
Startup remains fail-fast.
If a process fails:
The exception propagates from NenjimHub.start().
The failing process is not added to getStartedProcessIds().
Earlier successfully started process IDs remain visible.
No generic rollback is attempted because NenjimProcess has no common stop operation.
The Hub does not announce itself online.
The Hub does not enter its final blocking wait.
A second Hub startup attempt is rejected.
No generic recovery, retry or health policy is introduced.
Main bootstrap
Keep:
com.r35157.nenjim.hubd.Main
as the configured Gradle entry point.
Main must remain a final non-component class with no composition responsibility. Its main(String[]) must construct NenjimHubImpl through the NenjimHub interface and call start() exactly once.
Main must not construct the Registry, manager or business graph.
OpenSpec and documentation
Create a new OpenSpec change for this issue.
The change must:
Correct the canonical nenjim-component-registry requirements introduced by #76.
Specify the canonical minimal NenjimProcess.
Specify the global Hub runtime ownership and started-process snapshot.
Remove all canonical claims that the Registry manager owns composition, process startup, the online point or blocking wait.
Remove canonical NenjimApplication terminology.
Preserve the existing read-only Registry and typed lookup guarantees.
Keep the change active after implementation.
Not synchronize or archive it until implementation review and acceptance.
Update all directly affected documentation, including:
docs/Nenjim.md
docs/Terminologi.md
Any directly affected public HTML documentation.
JavaDoc on changed public APIs and the internal Registry admin boundary.
Documentation must explicitly distinguish component, service, application role and process lifecycle.
Out of scope
This issue does not implement:
NenjimHub.conf.
Configurable autorun.
NenjimProcessManager integration or GUI changes.
Stop, restart, upgrade or health monitoring.
Contexts or classloading.
Context-bound dependency access.
Artifact-version resolution.
Journal integration or Journal lifecycle refactoring.
Component removal.
Runtime loading or unloading.
Events or subscriptions.
Automatic dependency startup.
Business behavior changes.
General legacy-process cleanup.
New general unit tests or NenjimTestTool work.
Acceptance criteria
One canonical com.r35157.nenjim.process.NenjimProcess exists.
NenjimApplication is removed without an alias.
Every modern startable implementation uses NenjimProcess.
NenjimHub is the global composition and lifecycle owner.
Hub and Registry manager responsibilities are clearly separated.
The Registry manager is passive, unregistered and exposes only registration.
The Registry service remains read-only to ordinary consumers.
The internal admin interface remains package-private and contains the required warning.
Ordinary consumers cannot derive Registry mutation access from NenjimRegistryService.
The Hub starts and registers the Registry as nenjim.registry.service.
The Registry is the first ID in the started-process snapshot.
The current hardcoded component graph remains complete.
The current enabled process set and order remain unchanged after Registry startup.
Deliberately inactive processes remain inactive.
Started-process snapshots are immutable, ordered and thread-safe.
Startup failures remain fail-fast without false started entries.
Main constructs and starts only NenjimHub.
The existing online point and blocking wait are owned by the Hub.
Canonical OpenSpec and documentation describe the corrected architecture.
No Journal, Context, classloader or business migration is introduced.
No new general unit tests are added.
The repository builds successfully.
Title: Make NenjimHub the runtime owner and replace NenjimApplication with NenjimProcess
## Background
Issue #76 introduced the central Nenjim component Registry and moved the complete hardcoded component graph, process startup and blocking runtime lifecycle into `NenjimRegistryServiceManagerImpl`.
That implementation made the current system compile and start from one composition root, but subsequent design review has clarified that the composition root is not part of the Registry subsystem.
`NenjimHub` is a real runtime object with its own responsibility:
* It represents one running Nenjim runtime.
* It constructs the complete component graph.
* It owns dependency wiring.
* It registers components through the Registry manager.
* It decides which processes to start.
* It records which processes started successfully.
* It owns the final online and blocking runtime lifecycle.
* It will later become the owner of stop and restart operations.
The Registry is an otherwise ordinary service on which the complete current component graph depends. Its manager is only a passive administrative indirection that allows the Hub to mutate the Registry without exposing mutation through `NenjimRegistryService`.
This issue corrects the ownership introduced by #76 while preserving the current business graph and startup behavior.
## Goals
This issue must:
1. Introduce the canonical minimal `NenjimProcess` lifecycle contract.
2. Remove and replace `NenjimApplication`.
3. Reintroduce `NenjimHub` as the global composition and runtime owner.
4. Reduce `NenjimRegistryServiceManager` to a passive registration handle.
5. Make the Hub construct the Registry subsystem and complete component graph.
6. Make the Hub start the Registry process first and all other enabled processes afterwards.
7. Expose an immutable ordered snapshot of successfully started process IDs.
8. Preserve the current enabled and disabled process choices.
9. Preserve the current application entry point class.
10. Update OpenSpec and documentation to describe the corrected architecture.
## Canonical NenjimProcess
Introduce the canonical interface:
```java
package com.r35157.nenjim.process;
import com.r35157.nenjim.component.NenjimComponent;
public interface NenjimProcess extends NenjimComponent {
void start() throws Exception;
}
```
`NenjimProcess` is the general lifecycle classification for a component that the Hub can start and track.
The terminology must distinguish independent dimensions:
* A `NenjimComponent` is any constructed and registrable Nenjim building block.
* A service exposes a domain API to consumers.
* An application describes a user-facing or orchestration role.
* A `NenjimProcess` is an active component with a Hub-managed startup lifecycle.
* A service or application implementation may therefore also be a `NenjimProcess`.
* Passive components do not implement `NenjimProcess`.
The process contract introduced by this issue contains only `start() throws Exception`. It does not contain stop, restart, health, context assignment or dependency lookup.
The existing `NenjimApplication` interface must be removed without a deprecated alias or compatibility wrapper. All modern implementations and lookups that currently use it must use the canonical `NenjimProcess` instead.
At minimum, this affects the current reference implementations of:
* The Registry service.
* Ticker service.
* Production and Test Evelyn services.
* Evelyn IOU Burner service.
* Evelyn Mission Control.
* Jupiter Perps Alarm.
The Registry manager must not become a process.
Legacy similarly named process prototypes outside the modern API packages are not canonical and are not part of this migration unless a direct compile dependency requires a narrowly scoped update. Their general cleanup remains future work under #73.
## Global NenjimHub contract
Introduce:
```java
package com.r35157.nenjim.hubd;
import com.r35157.nenjim.service.registry.valuetypes.NenjimComponentId;
import org.jetbrains.annotations.NotNull;
import java.util.List;
public interface NenjimHub {
void start() throws Exception;
@NotNull
List<NenjimComponentId> getStartedProcessIds();
}
```
`NenjimHub` is the global runtime owner. It must not extend `NenjimComponent` or `NenjimProcess`, and it must not be registered inside its own Registry.
The reference implementation must be:
```text
com.r35157.nenjim.hubd.impl.ref.NenjimHubImpl
```
The Hub must accept only one start attempt, including after failure. A later call must fail clearly with `IllegalStateException`.
`NenjimHub` must not be reused as the name of a future context-bound dependency facade. Context-specific process access will receive a different name in later work. This issue does not define that future API.
## Started-process snapshot
`getStartedProcessIds()` must:
* Be safe to call before, during and after Hub startup.
* Return an immutable point-in-time snapshot.
* Preserve successful startup order.
* Return an empty list before the first process has started.
* Include a process only after its `start()` call has returned successfully.
* Never include a process whose startup failed.
* Preserve already successful entries if a later process fails.
* Make no health or continued-liveness guarantee.
In this issue, “started” means only:
> The Hub called `start()` on the process and the call returned successfully.
It does not mean that every internal worker remains healthy.
## Passive Registry manager
Replace the current Registry manager contract with:
```java
package com.r35157.nenjim.service.registry;
import com.r35157.nenjim.component.NenjimComponent;
import com.r35157.nenjim.service.registry.valuetypes.NenjimComponentId;
import org.jetbrains.annotations.NotNull;
public interface NenjimRegistryServiceManager {
void registerComponent(
@NotNull NenjimComponentId componentId,
@NotNull NenjimComponent component);
}
```
The manager:
* Does not extend `NenjimComponent`.
* Does not implement `NenjimProcess`.
* Has no `start()` operation.
* Has no Registry-service accessor.
* Does not construct the business component graph.
* Does not start or stop any process.
* Is not registered in the Registry.
* Is retained privately by the Hub.
* Delegates registration to the Registry’s internal administrative view.
* Preserves the current duplicate-ID and interface-indexing behavior.
* Permits registration after Registry startup.
* Never activates a component merely because it is registered.
The registration ID:
```text
nenjim.registry.service-manager
```
must be removed. The manager is not a component and therefore has no component registration.
## Registry construction and administrative boundary
The Hub must initiate construction of:
* One Registry service/process object.
* One distinct Registry manager object bound to that Registry.
* The internal package-private administrative view required by the manager.
Because the Registry implementation and administrative view must remain hidden, the reference implementation may use a stateless implementation-only factory or assembly type under:
```text
com.r35157.nenjim.service.registry.impl.ref
```
The construction mechanism must provide the Hub with:
* A `NenjimRegistryService` view.
* A `NenjimProcess` view of the same Registry object.
* A distinct `NenjimRegistryServiceManager` bound to that object.
The construction helper:
* Owns no runtime lifecycle.
* Is neither a component nor a process.
* Must not become Registry-discoverable.
* Must not expose `NenjimRegistryServiceAdmin`.
* Must not allow an ordinary service reference to derive the manager for the active Registry.
The service and process views must have identical object identity.
`NenjimRegistryServiceAdmin` must remain package-private. Its JavaDoc must explicitly explain that:
* The same Registry object is exposed publicly through `NenjimRegistryService`.
* Making the admin interface public would allow ordinary consumers to cast the service object to the mutation interface.
* Making it public would break the read-only Registry contract.
* It must not be exposed outside the reference implementation package.
The Registry remains a component and becomes discoverable under both `NenjimRegistryService` and `NenjimProcess` after registration.
## Hub-owned startup sequence
`NenjimHubImpl.start()` must perform the following sequence:
1. Construct the Registry service/process and its passive manager.
2. Start the Registry through its `NenjimProcess` view.
3. Register the Registry service as:
```text
nenjim.registry.service
```
4. Record the Registry ID as the first successfully started process.
5. Construct and register the complete current hardcoded component graph in dependency order.
6. Resolve the currently enabled IDs through `NenjimProcess`.
7. Start them in the existing dependency-safe order.
8. Append each ID to the started-process list only after successful startup.
9. Announce the existing online point.
10. Preserve the existing blocking wait.
The Registry must start before the remaining graph is constructed because current constructors, including `TickerServiceImpl`, may perform Registry lookups.
After the Registry, the enabled process order must remain:
```text
assetaz.ticker.default
evelyn.service.prod
evelyn.service.test
evelyn.iou-burner.prod
evelyn.mission-control.default
```
The resulting started-process order must therefore begin:
```text
nenjim.registry.service
assetaz.ticker.default
evelyn.service.prod
evelyn.service.test
evelyn.iou-burner.prod
evelyn.mission-control.default
```
The existing deliberately inactive components, including `jupiter-perps-alarm.default` and the dormant Composer, Process Manager, Test Tool, Soda Task Manager and Suwimo Client paths, must remain inactive.
Registration must not imply startup, and the Hub must not start every registered process automatically.
## Startup failure behavior
Startup remains fail-fast.
If a process fails:
* The exception propagates from `NenjimHub.start()`.
* The failing process is not added to `getStartedProcessIds()`.
* Earlier successfully started process IDs remain visible.
* No generic rollback is attempted because `NenjimProcess` has no common stop operation.
* The Hub does not announce itself online.
* The Hub does not enter its final blocking wait.
* A second Hub startup attempt is rejected.
No generic recovery, retry or health policy is introduced.
## Main bootstrap
Keep:
```text
com.r35157.nenjim.hubd.Main
```
as the configured Gradle entry point.
`Main` must remain a final non-component class with no composition responsibility. Its `main(String[])` must construct `NenjimHubImpl` through the `NenjimHub` interface and call `start()` exactly once.
Conceptually:
```java
NenjimHub nenjimHub = new NenjimHubImpl();
nenjimHub.start();
```
`Main` must not construct the Registry, manager or business graph.
## OpenSpec and documentation
Create a new OpenSpec change for this issue.
The change must:
* Correct the canonical `nenjim-component-registry` requirements introduced by #76.
* Specify the canonical minimal `NenjimProcess`.
* Specify the global Hub runtime ownership and started-process snapshot.
* Remove all canonical claims that the Registry manager owns composition, process startup, the online point or blocking wait.
* Remove canonical `NenjimApplication` terminology.
* Preserve the existing read-only Registry and typed lookup guarantees.
* Keep the change active after implementation.
* Not synchronize or archive it until implementation review and acceptance.
Update all directly affected documentation, including:
* `docs/Nenjim.md`
* `docs/Terminologi.md`
* Any directly affected public HTML documentation.
* JavaDoc on changed public APIs and the internal Registry admin boundary.
Documentation must explicitly distinguish component, service, application role and process lifecycle.
## Out of scope
This issue does not implement:
* `NenjimHub.conf`.
* Configurable autorun.
* `NenjimProcessManager` integration or GUI changes.
* Stop, restart, upgrade or health monitoring.
* Contexts or classloading.
* Context-bound dependency access.
* Artifact-version resolution.
* Journal integration or Journal lifecycle refactoring.
* Component removal.
* Runtime loading or unloading.
* Events or subscriptions.
* Automatic dependency startup.
* Business behavior changes.
* General legacy-process cleanup.
* New general unit tests or NenjimTestTool work.
## Acceptance criteria
- [ ] One canonical `com.r35157.nenjim.process.NenjimProcess` exists.
- [ ] `NenjimApplication` is removed without an alias.
- [ ] Every modern startable implementation uses `NenjimProcess`.
- [ ] `NenjimHub` is the global composition and lifecycle owner.
- [ ] Hub and Registry manager responsibilities are clearly separated.
- [ ] The Registry manager is passive, unregistered and exposes only registration.
- [ ] The Registry service remains read-only to ordinary consumers.
- [ ] The internal admin interface remains package-private and contains the required warning.
- [ ] Ordinary consumers cannot derive Registry mutation access from `NenjimRegistryService`.
- [ ] The Hub starts and registers the Registry as `nenjim.registry.service`.
- [ ] The Registry is the first ID in the started-process snapshot.
- [ ] The current hardcoded component graph remains complete.
- [ ] The current enabled process set and order remain unchanged after Registry startup.
- [ ] Deliberately inactive processes remain inactive.
- [ ] Started-process snapshots are immutable, ordered and thread-safe.
- [ ] Startup failures remain fail-fast without false started entries.
- [ ] `Main` constructs and starts only `NenjimHub`.
- [ ] The existing online point and blocking wait are owned by the Hub.
- [ ] Canonical OpenSpec and documentation describe the corrected architecture.
- [ ] No Journal, Context, classloader or business migration is introduced.
- [ ] No new general unit tests are added.
- [ ] The repository builds successfully.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Title: Make NenjimHub the runtime owner and replace NenjimApplication with NenjimProcess
Background
Issue #76 introduced the central Nenjim component Registry and moved the complete hardcoded component graph, process startup and blocking runtime lifecycle into
NenjimRegistryServiceManagerImpl.That implementation made the current system compile and start from one composition root, but subsequent design review has clarified that the composition root is not part of the Registry subsystem.
NenjimHubis a real runtime object with its own responsibility:The Registry is an otherwise ordinary service on which the complete current component graph depends. Its manager is only a passive administrative indirection that allows the Hub to mutate the Registry without exposing mutation through
NenjimRegistryService.This issue corrects the ownership introduced by #76 while preserving the current business graph and startup behavior.
Goals
This issue must:
NenjimProcesslifecycle contract.NenjimApplication.NenjimHubas the global composition and runtime owner.NenjimRegistryServiceManagerto a passive registration handle.Canonical NenjimProcess
Introduce the canonical interface:
NenjimProcessis the general lifecycle classification for a component that the Hub can start and track.The terminology must distinguish independent dimensions:
NenjimComponentis any constructed and registrable Nenjim building block.NenjimProcessis an active component with a Hub-managed startup lifecycle.NenjimProcess.NenjimProcess.The process contract introduced by this issue contains only
start() throws Exception. It does not contain stop, restart, health, context assignment or dependency lookup.The existing
NenjimApplicationinterface must be removed without a deprecated alias or compatibility wrapper. All modern implementations and lookups that currently use it must use the canonicalNenjimProcessinstead.At minimum, this affects the current reference implementations of:
The Registry manager must not become a process.
Legacy similarly named process prototypes outside the modern API packages are not canonical and are not part of this migration unless a direct compile dependency requires a narrowly scoped update. Their general cleanup remains future work under #73.
Global NenjimHub contract
Introduce:
NenjimHubis the global runtime owner. It must not extendNenjimComponentorNenjimProcess, and it must not be registered inside its own Registry.The reference implementation must be:
The Hub must accept only one start attempt, including after failure. A later call must fail clearly with
IllegalStateException.NenjimHubmust not be reused as the name of a future context-bound dependency facade. Context-specific process access will receive a different name in later work. This issue does not define that future API.Started-process snapshot
getStartedProcessIds()must:start()call has returned successfully.In this issue, “started” means only:
It does not mean that every internal worker remains healthy.
Passive Registry manager
Replace the current Registry manager contract with:
The manager:
NenjimComponent.NenjimProcess.start()operation.The registration ID:
must be removed. The manager is not a component and therefore has no component registration.
Registry construction and administrative boundary
The Hub must initiate construction of:
Because the Registry implementation and administrative view must remain hidden, the reference implementation may use a stateless implementation-only factory or assembly type under:
The construction mechanism must provide the Hub with:
NenjimRegistryServiceview.NenjimProcessview of the same Registry object.NenjimRegistryServiceManagerbound to that object.The construction helper:
NenjimRegistryServiceAdmin.The service and process views must have identical object identity.
NenjimRegistryServiceAdminmust remain package-private. Its JavaDoc must explicitly explain that:NenjimRegistryService.The Registry remains a component and becomes discoverable under both
NenjimRegistryServiceandNenjimProcessafter registration.Hub-owned startup sequence
NenjimHubImpl.start()must perform the following sequence:Construct the Registry service/process and its passive manager.
Start the Registry through its
NenjimProcessview.Register the Registry service as:
Record the Registry ID as the first successfully started process.
Construct and register the complete current hardcoded component graph in dependency order.
Resolve the currently enabled IDs through
NenjimProcess.Start them in the existing dependency-safe order.
Append each ID to the started-process list only after successful startup.
Announce the existing online point.
Preserve the existing blocking wait.
The Registry must start before the remaining graph is constructed because current constructors, including
TickerServiceImpl, may perform Registry lookups.After the Registry, the enabled process order must remain:
The resulting started-process order must therefore begin:
The existing deliberately inactive components, including
jupiter-perps-alarm.defaultand the dormant Composer, Process Manager, Test Tool, Soda Task Manager and Suwimo Client paths, must remain inactive.Registration must not imply startup, and the Hub must not start every registered process automatically.
Startup failure behavior
Startup remains fail-fast.
If a process fails:
NenjimHub.start().getStartedProcessIds().NenjimProcesshas no common stop operation.No generic recovery, retry or health policy is introduced.
Main bootstrap
Keep:
as the configured Gradle entry point.
Mainmust remain a final non-component class with no composition responsibility. Itsmain(String[])must constructNenjimHubImplthrough theNenjimHubinterface and callstart()exactly once.Conceptually:
Mainmust not construct the Registry, manager or business graph.OpenSpec and documentation
Create a new OpenSpec change for this issue.
The change must:
nenjim-component-registryrequirements introduced by #76.NenjimProcess.NenjimApplicationterminology.Update all directly affected documentation, including:
docs/Nenjim.mddocs/Terminologi.mdDocumentation must explicitly distinguish component, service, application role and process lifecycle.
Out of scope
This issue does not implement:
NenjimHub.conf.NenjimProcessManagerintegration or GUI changes.Acceptance criteria
com.r35157.nenjim.process.NenjimProcessexists.NenjimApplicationis removed without an alias.NenjimProcess.NenjimHubis the global composition and lifecycle owner.NenjimRegistryService.nenjim.registry.service.Mainconstructs and starts onlyNenjimHub.