## MODIFIED Requirements

### Requirement: NenjimHub owns composition and runtime startup
`NenjimHub` SHALL remain the global runtime owner exposing only `start() throws Exception` plus an immutable ordered snapshot of successfully started process IDs. It SHALL be neither component nor process and SHALL not register itself. Its only accepted startup attempt SHALL validate the complete fixed-path Hub configuration before starting anything, construct and start Registry first, register Registry as `nenjim.registry.service`, record it, construct and register the existing shared passive graph, then lazily construct, register, start, and record only the remaining configured processes in exact order beginning with Journal. The selected liquidity process SHALL additionally compose its dedicated passive dependencies lazily at its configured entry. Registry and Journal managers SHALL remain distinct passive, unregistered handles retained privately by the Hub. Registration SHALL never imply startup. The Hub SHALL preserve the online point and blocking wait only after all configured processes succeed, without retry, rollback, dependency inference, or reordering.

#### Scenario: Registry starts before passive graph construction
- **WHEN** the Hub has validated a complete startup plan and performs its first startup attempt
- **THEN** it starts, registers, and records Registry first before constructing the passive component graph or any selected non-Registry process

#### Scenario: Journal follows passive composition but starts second
- **WHEN** Registry bootstrap and passive graph construction have succeeded
- **THEN** the Hub constructs, registers, starts, and records Journal before any later configured process, so Journal remains the second successful process

#### Scenario: Registry is process-discoverable
- **WHEN** the Registry registration has completed
- **THEN** the same object is retrievable as both `NenjimRegistryService` and `NenjimProcess`

#### Scenario: Journal is process-discoverable
- **WHEN** the configured Journal construction and registration have completed
- **THEN** the same object is retrievable as both `JournalService` and `NenjimProcess` under `nenjim.journal.service`, while its manager is not registered

#### Scenario: Selected JavaFX runtime is process-discoverable
- **WHEN** `nenjim.javafx-runtime.service` is selected and its registration has completed
- **THEN** one object is retrievable as both `JavaFxRuntimeService` and `NenjimProcess` under that ID

#### Scenario: Selected JavaFX applications share the runtime
- **WHEN** JavaFX runtime precedes selected Mission Control or Process Manager entries
- **THEN** each selected application retains the same already-constructed `JavaFxRuntimeService` instance registered by the Hub

#### Scenario: Selected Process Manager is process-discoverable
- **WHEN** `nenjim.process-manager.default` is selected after JavaFX runtime and its construction and registration complete
- **THEN** the object constructed with the current Hub and shared JavaFX runtime is retrievable as both `NenjimProcessManager` and `NenjimProcess`

#### Scenario: Required passive bindings are registered
- **WHEN** Hub passive composition completes
- **THEN** all current passive component IDs and implementation choices from issue #76 are present exactly as configured, while process IDs other than Registry remain absent until selected

#### Scenario: Configured startup subset preserves order
- **WHEN** Hub startup completes successfully
- **THEN** successful process IDs exactly equal the validated `[AUTO_START]` entries in their declared order

#### Scenario: Omitted processes do not enter the Registry
- **WHEN** a modern process ID is omitted from `[AUTO_START]`
- **THEN** that process is neither constructed, registered, started, nor recorded even though its implementation is known to the Hub

#### Scenario: Journal failure is fail-fast
- **WHEN** Journal construction, registration, or process startup throws
- **THEN** Registry remains the only recorded process, no later configured process is constructed or started, the exception propagates, and the Hub neither announces online nor enters its final wait

#### Scenario: JavaFX runtime failure is fail-fast
- **WHEN** selected JavaFX runtime construction, registration, or startup throws
- **THEN** its ID is not recorded, no later configured process is constructed or started, the exception propagates, and the Hub neither announces online nor enters its final wait

#### Scenario: Hub start is not retried
- **WHEN** any first Hub startup attempt has begun and `start()` is requested again
- **THEN** the later request fails with `IllegalStateException` whether the first attempt succeeded or failed

#### Scenario: Startup failure is fail-fast
- **WHEN** any passive composition, selected construction, registration, or process startup operation throws
- **THEN** the exception propagates, no later process is constructed or started, the Hub neither announces online nor enters its final wait, and no generic rollback or retry is attempted

#### Scenario: Dedicated liquidity bindings use the liquidity signer
- **WHEN** `evelyn.liquidity.prod` is selected and its construction succeeds
- **THEN** `solana.wallet.evelyn-liquidity-prod`, `jupiter.swap.evelyn-liquidity-prod` and `raydium.service.evelyn-liquidity-prod` are registered, the swap service uses the dedicated liquidity wallet and Raydium uses direct chain reads

#### Scenario: Liquidity service has orthogonal domain and lifecycle views
- **WHEN** the selected liquidity process is registered
- **THEN** the same object resolves as `EvelynLiquidityService` and `NenjimProcess`, while the domain interface exposes no lifecycle operations