Odin/src/Idunn

Idunn

Idunn is the keepalive daemon for the Odin swarm.

In plain language: Idunn is the little service whose job is to know which GameCult daemons are supposed to be alive, bring them back after a reboot or crash, watch whether they are still healthy, and raise a clear alarm when a human needs to intervene.

It is named for Idunn, the keeper of the apples that keep the gods young. The job is not glamorous. That is the point. Good infrastructure should make important things boring.

What Idunn Is For

GameCult has many daemons: Odin, Bifrost, VoidBot, Mimir, Heimdall, Eve providers, service workers, renderers, bridges, and local machine helpers. Each one owns its own work, but each one should not have to carry its own private lifecycle machinery.

Idunn centralizes that lifecycle work:

• start known daemons after machine boot;
• ensure deployed daemon artifacts match the desired target revision;
• restart daemons after crashes;
• watch health and freshness signals;
• avoid restarting services when authority is unclear;
• record every deployment/restart request and result as typed state;
• record release targets, deployment artifacts, state migrations, and rollout results as typed state;
• escalate to an operator through Bifrost when human action is needed.

The desired shape is simple:

Odin knows what exists.
Idunn keeps it alive.
Bifrost carries operator/public crossings.
Each daemon owns its own work and health publication.

Who It Helps

Idunn is for anyone running a local GameCult swarm or operating a hosted GameCult machine.

For a developer, Idunn should mean fewer mystery services to restart by hand. For an operator, Idunn should mean health problems become visible, witnessed, and routed to the right place. For daemon authors, Idunn should mean they can publish health, transport profiles, and command boundaries over CultNet RUDP instead of building one more private watchdog.

Current State

Idunn is a Rust daemon inside Odin's Cargo workspace. The live local runtime is one long-lived idunn.exe process that owns the whole Starfire-local swarm: Odin, local adjunct daemons, the Yggdrasil deploy lanes, and the Nightwing display services. Each target declares a daemon-owned health contract and keeps its own interval and deploy/restart authority. Daemon truth comes from typed CultNet/RUDP publication and daemon-owned boundary stores. Shell scripts remain deployment, restart, and manual diagnostic lowerings only; they do not satisfy health. The scheduler and continuity witness now belong to one Rust process instead of a PowerShell-herded pile of one-daemon workers.

scratch/idunn/idunn.keepalive.cc

Run It

From E:\Projects\Odin:

npm run idunn:build
npm run idunn:start -- --daemon demo --rudp-health-bind <idunn-rudp-health-bind>

--rudp-health-bind is explicit. Bare one-daemon Idunn does not open a localhost health ingress.

Install the local Starfire boot watchdog:

.\scripts\install-idunn-startup.ps1

That task starts one idunn.exe swarm supervisor at user logon. The Rust runtime owns the target catalog for Odin, Stonks, Muninn, the enforced Yggdrasil source artifact lanes, and the Nightwing display services. The current Mimir dashboard is observed but not restarted until its restart authority is named.

It also starts idunn-swarm-deployment-coverage, which watches the deployment target catalog in scripts/idunn-deployment-targets.ps1. A repo/service is not allowed to vanish into shrug-space: it is either enforced by Idunn, explicitly blocked with the missing authority named, external-owned, or not a runtime.

To record that a daemon has not published health, run a manual target without a matching idunn.daemon_health RUDP publication:

npm run idunn:start -- --daemon demo --restart-command "echo restart demo"

Idunn writes a non-actuating missing-publication health record and plans from that typed absence. It does not run a local health command to decide daemon truth.

To actually allow restart/deploy actuation after typed health planning decides one is needed:

npm run idunn:start -- --daemon demo --deploy-command "echo deploy demo" --restart-command "echo restart demo" --execute

To keep watching on a resident interval:

npm run idunn:start -- --daemon demo --interval-seconds 30

To run the built-in Starfire-local swarm profile directly:

npm run idunn:start -- --swarm-profile starfire-local --repo-root E:\Projects\Odin --execute

Optional store override:

npm run idunn:start -- --daemon demo --store E:\path\to\idunn.keepalive.cc

What Daemons Should Publish

Idunn should not guess private service truth. A daemon should publish:

• its service id and Verse id;
• where its durable .cc state or witness lives;
• a health or freshness signal;
• the command boundary for deployment or artifact refresh, if one exists;
• the command boundary for restart or recovery, if one exists;
• what operator action is needed when automatic recovery is unsafe.

If that information is missing, Idunn should fail closed and create an operator alarm instead of improvising.

For the repo swarm, deployment ownership begins with catalog coverage. Use:

.\scripts\show-idunn-deployment-targets.ps1
.\scripts\health-idunn-swarm-deployment-coverage.cmd

The enforced targets are Nightwing Gjallar plus the Yggdrasil source artifact lanes whose ops runbooks can produce and verify deployment manifests. Each enforced target must declare upstream remote/branch, rollout strategy, state migration authority, and zero-downtime capability. Idunn deploys the declared upstream main revision, not arbitrary local HEAD. Bifrost is blocked until its production database migration path is coherent; mobile device installs remain blocked at their physical approval boundaries; GitHub Pages remains external-owned.

Typed Records

• idunn.desired_daemon.v1
• idunn.daemon_health.v1
• idunn.keepalive_decision.v1
• idunn.deployment_request.v1
• idunn.deployment_result.v1
• idunn.release_target.v1
• idunn.deployment_artifact.v1
• idunn.state_migration_plan.v1
• idunn.state_migration_result.v1
• idunn.rollout_plan.v1
• idunn.rollout_result.v1
• idunn.restart_request.v1
• idunn.restart_result.v1
• idunn.operator_alarm.v1
• idunn.daemon_surgery_plan.v1
• idunn.daemon_transport_profile.v1
• idunn.command_boundary.v1
• idunn.runtime_transport_check.v1
• idunn.rudp_health_ingress.v1

Idunn publishes one idunn.daemon_surgery_plan.v1 record per swarm target when the swarm starts. Those records make the CultNet/RUDP migration queue explicit: owner, objective, current mechanism, intended authority, cut line, steps, blockers, severity, and status.

It also publishes one idunn.daemon_transport_profile.v1 and one idunn.command_boundary.v1 per target. The desired daemon record links to both. The transport profile names cultnet.transport.rudp.v0 as the target and marks daemon publication and daemon-owned witness stores as the health substrate. The command boundary names restart, deploy, health, and alarm authority separately; health authority belongs to daemon-published RUDP state.

At startup Idunn also publishes idunn.runtime_transport_check.v1, currently a loopback CultNet hello over cultnet.transport.rudp.v0. That proves Idunn's Rust body can use the RUDP substrate before it asks the rest of the swarm to walk through the same door.

For deploy-enforced targets, startup also publishes idunn.release_target.v1, idunn.deployment_artifact.v1, idunn.state_migration_plan.v1, and idunn.rollout_plan.v1. During deployment, Idunn runs any declared daemon-owned migration command before the deploy command; a failed migration stops the rollout and raises an operator alarm. Zero downtime is recorded only when the target declares a real in-place, blue/green, or rolling strategy; otherwise Idunn says restart-required and verifies that path honestly.

Deploy scripts are Idunn actuators. Agents should configure the target catalog, release target, command boundary, migration command, and daemon publication surface, then let Idunn run the rollout. Direct script execution without IDUNN_ACTUATOR=1 fails on purpose; the little hand reaching for the deploy button has been removed from the machine.

scripts/start-idunn-local.ps1 launches the local swarm with --rudp-health-bind 0.0.0.0:17870 so host-local and explicitly configured peers can publish to the configured Idunn health endpoint. It accepts raw idunn.daemon_health document puts on the canonical CNR0 RUDP schema channel and writes them into the keepalive store. That is daemon-owned health publication, not restart/deploy authority. On Windows, UDP reset reports from closed one-shot publishers are treated as nonfatal ingress noise so one accepted health frame cannot kill the listener.

When a fresh daemon-published RUDP health record exists for a target, Idunn uses that record for keepalive planning. The record must match the daemon id, health contract, RUDP transport, and freshness window. If it is absent or stale, Idunn publishes a missing-publication observation and raises/plans from that typed absence instead of running a local health probe.

The active transport cut is no longer "make the daemons speak RUDP at all." Nightwing Gjallar now consumes Odin's accepted surface:gamecult.network.status snapshot over CultNet/RUDP, so every active Starfire-local daemon target now publishes daemon-owned RUDP health plus typed boundary state. The remaining debt is deleting bridge-only lowerings and xenos-boundary ingestion shims without letting them reclaim ownership. Odin still owes removal of hashed-store/C# witness shims once direct interoperable witness publication is ready.

Muninn media uses a codec-owned prediction model, not a custom visual-delta codec. The canonical LAN profile is muninn.rudp.low_latency_h264_lan.v1: NVENC H.264 owns inter-frame prediction, motion search, residuals, keyframe production, and the actual lossy visual encoding; CultNet/RUDP owns bounded delivery of typed video access units, audio packets, receiver feedback, retransmit pressure, expiry, and keyframe requests. Late media is dropped when it misses the fixed latency budget. Optical flow, foveation, ROI maps, or stochastic patch experiments may become future Muninn profiles only after this hardware-codec RUDP path is measured and proven insufficient.

Raven Muninn task actions are also an explicit ops invariant: Task Scheduler must execute wscript.exe //B //Nologo hidden launcher actions directly for GameCult-Muninn, GameCult-Muninn-Activate, and GameCult-Muninn-VideoProof, never raw .cmd wrappers, and the hidden VBS layer must call .ps1 launchers directly instead of cmdPath trampolines. Those three live Raven tasks have been repaired and verified. The repair actuator now uploads its Raven PowerShell body with sftp and runs a tiny cleanup wrapper, so the hidden-task repair does not hit Windows command-line limits before it can run. The long-running Muninn serve bodies on Raven, Nightwing, and Starfire now also carry their own --idunn-rudp-health, --idunn-daemon, and --idunn-health-contract arguments, and live Idunn accepts those daemon-owned health records directly instead of relying on one-shot health commands for the truth.

From here on out, the work is not "teach another daemon to speak." It is "delete the witness masks and keep ownership where it belongs."

Rust no longer gets to claim the transport is imaginary: vendor/cultnet-rs includes the canonical CNR0 cultnet.transport.rudp.v0 session path for acknowledged CultNet messages over UDP. That is substrate only. Idunn still marks daemon profiles as migration-required until each daemon actually publishes health and command boundary records through that path.

Boundaries

Idunn is not Odin. It does not decide which Verses exist.

Idunn is not Bifrost. It does not own public crossings, Discord delivery, owner DMs, or governance transport.

Idunn is not Eve. It does not own presentation.

Idunn is the keeper of continuity. If a daemon should be alive, Idunn should know that, check it, help it recover, and leave a witness trail sharp enough that nobody has to guess what happened.