nx_elder_registry.nx

nx_elder_registry.nx -- Elder AI service registry (bits-up). Sovereign service registry for the Stage B Elder AI off-Docker port. Holds the (service_name, port, exec_path, args_blob, healthcheck_url, supervisor_state) tuple per service; the platform-specific launcher (PowerShell on Windows; nx_container on Linux) reads the registry to know what to spawn. V1 mechanics: pure-NishiLang registry with canary-bracketed records. String fields are caller-owned *u8 blobs with byte lengths -- the registry doesn't copy strings, it holds pointers (matches H10 nx_modality_router opacity pattern). Supervisor state per service is a sealed enum mirroring nx_supervisor.nx (HEALTHY / BACKING_OFF / ESCALATING / TERMINATED). Composition path: - register_service(name, port, exec, args, healthcheck_url) once per service at supervisor bootstrap - lookup_by_name(name) at routing time -- caller hashes name to a stable index OR linearly scans (V1 is linear; Elder AI has ~80 services, scan is fine) - lookup_by_port(port) for reverse-lookup (debugging, health-page generation) - mark_state(name, state) when the launcher reports a child crashed / exited / recovered Cardinal honesty: spawning a Win32 process requires CreateProcessW from kernel32.dll. That OS boundary is irreducible -- the substrate cannot fork() on Windows. This file owns ONLY the registry data structure and the supervisor-state bookkeeping. The PowerShell launcher (or future nx_win_spawn primitive) reads the registry's exposed accessors and does the actual CreateProcessW call. Substrate stays bits-up; OS boundary stays thin. genealogy_id: docker_compose_v3_2021 + erlang_otp_supervisor_1996 + cardinal_2026-05-21_elder_ai_windows_native_docker_replacement + cardinal_2026-05-20_bits_up_nishi_not_linux lineage_id: substrate_elder_registry_v1 nx_capability_manifest: