Nenjim

Implementation status: Journal format version 1, the immutable Java model, internal strict parser, read-only JournalService with a Hub-managed process implementation, passive explicitly refreshed JournalServiceManager, Hub-managed JavaFxRuntimeService, the first central component Registry, and mandatory Hub configuration format 1 are implemented. Contexts, resolution, classloading, discovery, runtime loading/removal, downloading, publishing, synchronization, watching, signatures, permissions, and license filtering remain future work.

One Journal per artifact

A Journal describes exactly one artifact. API, test, and implementation artifacts therefore have independent Journals and chains. Roles such as API or implementation are not stored as a TYPE.

<GROUP>-<MODULE>-<ARTIFACT>
com_r35157_nenjim-hubd-api
com_r35157_nenjim-hubd-api:1.0.3

The three metadata components identify the chain; there is no separate JOURNAL_ID.

Complete immutable snapshots and history

Every Journal revision is a complete worldview of the artifact and all releases known in that revision. It is not a delta and inherits nothing implicitly. A later snapshot may change metadata, add or remove releases, correct release knowledge, alter dependencies or policy, or be a semantic no-op.

The genesis omits PREVIOUS_JOURNAL_DIGEST. Each successor names the SHA-256 digest of the predecessor's exact UTF-8 text, including whitespace and line endings. A chain has one genesis and one head; missing predecessors, forks, cross-artifact links, and non-increasing Journal versions are invalid.

JOURNAL_VERSION is when the worldview was published. PUBLISHED_AT is when an artifact release was published. Both use uuuuMMddHHmmssSSS'Z', but historical knowledge is selected from the Journal chain rather than by filtering the newest snapshot on release publication time.

Metadata and release content

DESCRIPTION is mandatory single-quoted text. INFORMATION_URI is optional single-quoted metadata and must decode to a non-empty absolute URI. Format 1 does not restrict schemes: HTTPS, FTP, IPFS, and other syntactically valid schemes are accepted without opening or interpreting their content.

Every exact major.minor.patch release has a mandatory single-quoted LICENSE, a publication timestamp, non-negative byte size, and one or both supported content identities: sha256 and CIDv1 (cid1). License text is preserved as free text; no vocabulary, compatibility decision, or filtering is applied.

Version expressions

Comma-separated expressions form a union. Boundaries require at least major and minor. Mathematical comparison syntax, incomplete bare exact versions, prereleases, build metadata, empty elements, and reversed or empty ranges are rejected.

Dependencies

Dependencies belong to individual releases and always have an explicit scheme. Format 1 implements only the nenjim: scheme; Maven resolution and unknown schemes are not silently accepted.

DEPENDS_ON=nenjim:com_r35157_nenjim-hubd-api=[1.0-->
EXCLUDES=nenjim:com_r35157_nenjim-hubd-api=1.0.5:'Known incompatibility'
PREFERRED=nenjim:com_r35157_nenjim-hubd-api=1.0.3:'Built together'

DEPENDS_ON is the hard base set. EXCLUDES removes hard-invalid combinations for that relationship. PREFERRED is a hint and must remain a subset of DEPENDS_ON - EXCLUDES. Repeated rules form unions while each line and description remains inspectable. The Journal layer represents these rules but does not resolve a graph.

Artifact policy

• BLACKLIST is a hard global prohibition.
• DISCOURAGED is a negative hint; a matching release remains selectable.
• RECOMMENDED is a positive hint naming one exact release in the same snapshot.

Overlaps are valid and hard rules win over hints. A future resolver should seek a valid graph containing as many compatible recommendations as possible. The highest valid version is a fallback, not an unconditional rule, so future convergence may move from a higher local version to a lower recommended version.

Strict parsing and immutable model

FORMAT_VERSION=1 must be the first actual entry. Blank lines and comments beginning with # are accepted, while a hash inside single quotes is data. Quoted values support escaped quotes (\') and backslashes (\\). Unknown, malformed, duplicate, misplaced, empty, or semantically inconsistent content fails with source name, one-based line number, and a reason. Validation is complete before service state changes. Returned objects and collections are immutable and defensively copied.

Service, process, ServiceManager, packages, and disk layout

A Service is the public domain API used by applications and other services during ordinary operation. JournalService is a registrable component but remains filesystem-independent and read-only: it exposes current and historical Journal queries without lifecycle, paths, refresh, parser, or mutation operations. Queries become available only after successful Journal process startup.

The Hub constructs one Journal object exposed as both JournalService and NenjimProcess, plus one distinct passive JournalServiceManager. The manager reports the normalized data root and performs explicit refresh; it has no start, stop, service accessor, component identity, or process lifecycle. It delegates through a package-private administration view that ordinary service consumers cannot name or derive.

The Journal process reads UTF-8 runtime files chronologically and validates directory and filename placement. Its complete initial worldview is published only after every runtime file succeeds; failed startup leaves queries unavailable and cannot be retried on the same instance. Later refresh remains explicit, idempotent, and atomic per ingestion. Neither startup nor refresh creates, overwrites, or deletes Journal files.

The package-private JournalServiceImpl keeps exact-text SHA-256 identity, chain state, idempotency, conflicts, forks, and ingestion internal. The public package contains only the two central interfaces; composed models, value types, and exceptions live under .model, .valuetypes, and .exception, while parser, ingestion, chain state, filesystem loading, and the admin boundary live under .impl.ref without leaking through public signatures.

All modern JavaFX applications share one JVM-wide toolkit. When selected, the Hub constructs one JavaFxRuntimeServiceImpl, registers it as nenjim.javafx-runtime.service, starts it through its NenjimProcess view, and injects its lifecycle-free service view into later selected JavaFX applications. Only service startup calls Platform.startup(...); task submission never initializes or retries JavaFX and is rejected until startup succeeds. A headless process plan that omits all JavaFX processes does not construct the runtime or initialize the toolkit.

data/nenjim/journals/
└── <artifact-coordinate>/
    ├── <journal-version>.journal
    └── <journal-version>.journal.example

Only .journal files are runtime input. Version-controlled .journal.example files are documentation and are ignored by the service.

Components and the central Registry

A Nenjim component is a fully constructed building block ready for use. Its consumer decides whether it acts as a service, application, algorithm, or adapter. A service exposes a domain API, while application describes a user-facing or orchestration role. NenjimComponent is therefore a pure marker. Independently, the canonical com.r35157.nenjim.process.NenjimProcess marks an active component that the Hub can start and track; it adds only start() and no common stop, restart, or health operation.

A NenjimComponentId is lower-case lookup metadata owned by one Registry, not a property of the object, an authorization boundary, or an artifact version. One object may have several IDs. Conversely, one registration is indexed under every component interface implemented by that object, so the Registry object's typed service and process views retain reference identity.

NenjimRegistryService is the injected read-only consumer view. It returns immutable, registration-ordered ID snapshots for a component interface and supports lookup by explicit ID plus expected interface. Missing IDs return null; requesting an existing ID through the wrong interface is a caller error. Registration is available only through a package-private administration view behind the passive Registry manager. That manager exposes only registration, is neither a component nor a process, is not registered, and cannot start anything. The internal administration interface must remain package-private so an ordinary service consumer cannot cast the Registry object to a mutation view.

Mandatory NenjimHub.conf format 1

NenjimHubImpl is the global composition and runtime owner. Before any process starts it reads only the readable regular file conf/NenjimHub.conf. The version-controlled conf/NenjimHub.conf.example is a copy-only template: the application never reads, copies, generates, or falls back to it or to a hardcoded startup sequence.

FORMAT_VERSION=1

[AUTO_START]
nenjim.registry.service
nenjim.journal.service

FORMAT_VERSION=1 must be the first actual entry and the one exact [AUTO_START] header must be the next actual entry. Leading and trailing whitespace is ignored. A trimmed line beginning with # is a comment, and # after content begins a trailing comment. Inside the section a comment-only line does not terminate it, while the first whitespace-only line or end of file does. After termination only blank lines and comments are permitted; there is no quoting or escaping for #.

Every active section line is a canonical component ID. The complete list is validated before Registry starts: duplicates, invalid or unknown IDs, passive-only IDs, and IDs the Hub cannot construct as modern processes fail. Registry must occur exactly once first and Journal exactly once second. The known selectable processes are Registry, Journal, Ticker, Jupiter Perps Alarm, both Evelyn services, Production IOU Burner, JavaFX runtime, Mission Control, and Process Manager. The version-controlled template selects only the mandatory Registry and Journal processes; every other process must be added explicitly to the private deployment configuration.

After validation the Hub starts, registers, and records Registry, then eagerly constructs and registers the complete passive graph without activating a process. It next visits every remaining configured ID in exact order, beginning with Journal. Each selected process is constructed only when reached, registered before start(), and recorded only after successful return. An omitted process is therefore neither constructed, registered, started, nor displayed by Process Manager.

[AUTO_START] is the complete manually ordered process dependency closure. The Hub does not infer, insert, recursively construct, or reorder dependencies; JavaFX runtime must precede selected JavaFX applications. Construction, registration, and startup remain fail-fast without rollback. Earlier successful snapshot entries remain truthful after a later failure, and the online point plus blocking wait are reached only after every configured process succeeds.

Ordinary consumers receive the lifecycle-free TickerService view, which exposes only the latest-price query. The same TickerServiceImpl object separately implements NenjimProcess so the Hub owns startup. The implementation starts its configured active PriceSource instances internally and stops those already started if Ticker startup fails; it exposes no general Ticker stop operation.

EvelynIOUBurnerService follows the same separation even though its current domain-service view is empty. It supplies typed Registry and dependency identity without external controls, while the same EvelynIOUBurnerServiceImpl object separately implements NenjimProcess for Hub-owned startup. Neither the service interface nor the implementation exposes an ordinary stop or restart operation.

The Ticker still explicitly selects the Raydium EVE/USDT source ID while the hardcoded source remains a passive, registered component. Process Manager continues to poll immutable ordered snapshots of actual successful startup milestones rather than displaying configured intent or claiming current health.

com.r35157.nenjim.hubd.Main remains only the outer Java bootstrap. It constructs the reference Hub through the public NenjimHub interface and calls start() once. The Hub is neither a component nor a process and is not registered inside its own Registry.

The Registry remains internally open to later registration, but this version has one catalogue and no Context, version resolution, classloader integration, discovery, public runtime loading or registration, removal, persistence, events, ownership tracking, usage counts, permissions, scopes, filtered views, automatic dependency construction, or automatic start-all behavior.

Future Nenjim vision

Contexts, dependency-graph resolution, recursive process construction, automatic selection/reconciliation, runtime upgrade or downgrade, classloaders, artifact downloads, IPFS retrieval, Maven dependencies, signatures, publishing, remote synchronization, filesystem watching, and UI/CLI management are deliberately outside this implementation.