com_r35157_nenjim-hubd-impl_ref/openspec/changes/89-add-evelyn-liquidity-service/specs/nenjim-component-registry/spec.md

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