com_r35157_nenjim-hubd-impl_ref/openspec/changes/78-integrate-journal-service-process/specs/nenjim-component-registry/spec.md

MODIFIED Requirements

Requirement: NenjimHub owns composition and runtime startup

NenjimHub SHALL be the global runtime owner and SHALL expose start() throws Exception plus an immutable ordered snapshot of successfully started process IDs. It SHALL be neither a component nor a process and SHALL not register itself. Its only accepted startup attempt SHALL construct the Registry subsystem, start the Registry process first, register it as nenjim.registry.service, construct and register the Journal subsystem as nenjim.journal.service, start Journal second, and continue to the complete hardcoded business component set from issue #76 only after Journal startup succeeds. The Hub SHALL then resolve only the explicitly enabled business IDs through NenjimProcess, start them in dependency-safe order, announce the existing online point, and preserve the existing blocking wait. Registration SHALL never imply startup, and both the Registry and Journal managers SHALL remain distinct passive, unregistered handles retained privately by the Hub.

Scenario: Infrastructure starts before business composition

• WHEN the Hub performs its first startup attempt
• THEN it starts, registers and records Registry first, then registers, starts and records Journal before constructing components in the business graph

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 Journal registration has completed
• THEN the same object is retrievable as both JournalService and NenjimProcess under nenjim.journal.service, while its manager is not registered

Scenario: Required hardcoded bindings are registered

• WHEN Hub composition completes
• THEN Journal and all component IDs and implementation choices enumerated by issue #76 are present exactly as configured, including intentionally inactive components and excluding both service managers

Scenario: Explicit startup subset preserves order

• WHEN Hub startup succeeds through the business-process phase
• THEN successful process order is nenjim.registry.service, nenjim.journal.service, assetaz.ticker.default, evelyn.service.prod, evelyn.service.test, evelyn.iou-burner.prod, and evelyn.mission-control.default

Scenario: Deliberately inactive processes remain inactive

• WHEN Hub startup reaches its online point
• THEN jupiter-perps-alarm.default and the dormant Composer, Process Manager, Test Tool, Soda Task Manager, and Suwimo Client paths have not been started

Scenario: Journal failure is fail-fast

• WHEN Journal process startup throws
• THEN Registry remains the only recorded process, no business component 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: Later startup failure is fail-fast

• WHEN a business process startup throws
• THEN the exception propagates, no later process starts, the Hub neither announces online nor enters its final wait, and no generic rollback or retry is attempted