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

MODIFIED Requirements

Requirement: Registry bootstraps eager passive composition

After validating the entire plan, the Hub SHALL construct the configured Registry subsystem, start Registry, register its service and process object as nenjim.registry.service, and record that ID only after successful startup. The Hub SHALL then eagerly construct and register the existing shared passive component graph. Dedicated liquidity deployment configuration, wallet signer, Jupiter swap service and direct Raydium service SHALL instead be constructed and registered only when the configured evelyn.liquidity.prod entry is reached. This passive phase SHALL not construct any canonical NenjimProcess, start background workers, initialize JavaFX, add startup IDs, infer process dependencies, or implicitly create an omitted process. Plain internal dependencies that are not NenjimComponent objects MAY be constructed as part of passive composition.

Scenario: Registry surrounds passive composition

• WHEN a valid Hub startup begins
• THEN Registry starts, is registered, and is recorded before the existing shared passive component graph is constructed and registered

Scenario: Passive composition completes

• WHEN Registry bootstrap succeeds
• THEN all existing shared non-process building blocks, adapters, and services are constructed and registered without starting a process

Scenario: Passive construction fails

• WHEN any passive component cannot be constructed or registered
• THEN startup stops immediately with Registry remaining recorded and no configured process after Registry constructed or started

Scenario: Liquidity is omitted

• WHEN the plan omits evelyn.liquidity.prod
• THEN its deployment configuration, dedicated signer/wallet, Jupiter service and direct Raydium service are neither loaded nor constructed nor registered

Requirement: Selected processes are constructed and started lazily in exact order

The Hub SHALL support the modern process IDs nenjim.registry.service, nenjim.journal.service, assetaz.ticker.default, jupiter-perps-alarm.default, evelyn.status.prod, evelyn.status.test, evelyn.iou-burner.prod, evelyn.liquidity.prod, nenjim.javafx-runtime.service, evelyn.mission-control.default, and nenjim.process-manager.default through implementation-only construction capability that creates no process instance during validation. After passive composition, the Hub SHALL visit every configured entry after Registry in declared order, beginning with Journal. At each entry it SHALL construct only that process and any explicitly composed process-specific passive dependencies or administration view, register the process under the exact configured ID, resolve it through the canonical NenjimProcess contract where applicable, call start(), and record the ID only after successful return.

The configuration SHALL be the complete manually ordered process dependency closure. The Hub SHALL not discover, insert, recursively construct, reorder, or automatically start dependencies. A process omitted from [AUTO_START] SHALL not be constructed, registered, started, or recorded, even when its implementation is available. Legacy process prototypes outside the modern Hub graph SHALL not be selectable.

Scenario: Configured process starts successfully

• WHEN a configured process entry is reached and its dependencies are already available
• THEN that process is constructed, registered, started, and recorded before the next entry is reached

Scenario: Process is omitted

• WHEN a known process ID does not appear in [AUTO_START]
• THEN no instance of that process is constructed or registered and its lifecycle is never started or recorded

Scenario: Jupiter Perps Alarm is selected

• WHEN jupiter-perps-alarm.default is explicitly listed after its required predecessors
• THEN the otherwise inactive modern alarm process is constructed, registered, started and recorded at that exact position

Scenario: Dependency order is invalid

• WHEN a selected process is reached before a process dependency required by its current constructor or startup behavior
• THEN construction or startup fails clearly without implicit dependency construction, repair, or reordering

Scenario: JavaFX processes are omitted

• WHEN a valid headless plan omits nenjim.javafx-runtime.service, evelyn.mission-control.default, and nenjim.process-manager.default
• THEN none of those objects is constructed or registered and the JavaFX toolkit remains uninitialized by the Hub

Scenario: Renamed status services retain dependency wiring

• WHEN evelyn.status.prod and evelyn.status.test are listed after Ticker and before Mission Control
• THEN the Hub constructs separate Production/Test status services, registers the renamed IDs, and injects the corresponding typed service views into Mission Control in the configured order

Scenario: Deployment still contains an old status ID

• WHEN a private deployment configuration contains evelyn.service.prod or evelyn.service.test
• THEN validation rejects the unknown ID before startup; deployment migration replaces only that ID with evelyn.status.prod or evelyn.status.test, preserving selection and order

Scenario: Liquidity is explicitly selected

• WHEN evelyn.liquidity.prod is reached in a valid startup plan
• THEN the Hub loads its runtime configuration, binds the dedicated signer/wallet and Jupiter service to each other, constructs direct Raydium access and registers/starts the liquidity process without inserting a Ticker or status dependency or reordering the plan