- conforms_to::[[Observation Form Contract]]
- has_epistemic_status::[[Empirical Observation]]
- in_practice_domain::[[eOS Continuum]]
- authored_by::[[Christopher Allen]]
- has_lifecycle::[[Seed Stage]]↗
- has_curation::[[Working Draft]]↗
Nine Fix Rounds Landed on One Live Composite Instance Without Restart or State Loss
Claim
During the development of eOS-kernellib PR #129 (2026-07-20), one running DGD instance absorbed nine rounds of interactive fixes -- spanning the demo page, the HTTP handler, the SSE broker, the inventory daemon, and the System-tier identity facade -- entirely by recompile in place, while a human tester drove the browser demo against it. No round restarted the process. Registered identities, minted agents, live bearer sessions, persisted items, audit entries, and held-open server-sent-event streams survived every daemon replacement; the tester's walk continued across all nine rounds without re-registering. One round demonstrated the safety half of the property: a daemon draft that could not compile was refused at the console and the running master kept serving its old program until corrected source compiled -- the instance is never in a broken in-between state.
Grounds
This is an Empirical Observation: direct observation of the 2026-07-20 development session, with the artifacts in public git history.
Setup: the composite browser demo (eOS-kernellib examples/composite-app/) deployed per its README browser-path recipe on a macOS development host -- DGD with the lpc-ext crypto module, native TLS on the labeled https port, a human tester in Safari. The instance booted once and ran through the whole session.
The nine rounds and their mechanisms (each a commit on the branch merged as PR #129, 24b978d through fc74f70 plus the page rounds before them):
- Page-only rounds (banner and heartbeat placement, chat-style log, entry triad, recovery-kit fixes): deployed by copying the edited file into the served tree. Because
sys/demo.creads the page per request and sendsCache-Control: no-store, a plain browser reload was the entire deployment. - Daemon rounds, via the admin console's
compileverb (the hot-fix surface documented in eOS-kernellibdocs/admin-console.md):streamdgained the server-pushed heartbeat topic;handlerandinventorydgained the capability-gated report;authdandhandlergained passkey self-service;identitydandauthdhad wire-visible refusal strings renamed. Eachcompilereplaced the running master in place; the drive-verbs transcripts show every reload passing.
State-intact evidence: after the inventoryd replacement, the new report code read back the item and audit counts created before the replacement (items and audit entries minted early in the tester's walk). The tester's identities and sessions continued authenticating across the identityd and authd replacements. The audit stream's server heartbeat, held open on one connection, was observed at tick #70 mid-session -- a connection whose lifetime spanned multiple daemon replacements.
The refused round: an inventoryd draft referenced a function defined later in the file (LPC resolves calls textually); the console compile refused it with the compile error and the running daemon kept serving the old program. The corrected source (PR #129 commit c7497ea) then compiled in place. The failure mode was refusal, not partial replacement.
Limits: one operator, one instance, one development host. Variable-layout preservation was exercised in the additive direction only (new variables initialized nil; existing state retained). The in-flight-request-finishes-with-old-logic half of the hot-reload claim was not directly probed -- the same caveat the single-file demonstration carries.
What Would Revise It
- A reproduction in the same shapes -- additive daemon recompile on a live instance -- that loses daemon state, drops held-open connections, or leaves a partially-replaced program would downgrade the claim.
- Divergent behavior on the Linux production-shape runtime (the same tree under Lima or a hosted boot) would narrow the claim to the development host.
- A demonstrated case where a refused compile nevertheless disturbed the running master would remove the safety half of the claim.
- Direct probing of concurrent in-flight requests across a recompile would either complete the property or bound it; until then that half rests on the platform's documentation, not this observation.
Sources
- https://github.com/eOSContinuum/eOS-kernellib/pull/129 -- the merged PR whose development session is this observation's evidence; the branch commits
24b978d..fc74f70are the per-round artifacts, andc7497earecords the refused compile.
Relations
-
informs_downstream::[[Hot Reload Is a Runtime Operation, Not a Deployment Event]]
- The Conviction's strongest project evidence to date: nine consecutive runtime recompiles on composed, stateful, System-tier daemons under live interactive load, plus the refused-compile safety behavior -- the Conviction's claim exercised as a working practice rather than a single demonstration.
-
contrasts_with::[[Recompiling an LPC File Over HTTP Updates the Next HTTP Response Without DGD Restart]]
- The sibling proves the mechanism at minimal scale: one throwaway file, one route, sequential curls, MVA-era. This observation proves the same property at composition scale -- an identity layer, persistent daemons, held-open streams, a human mid-walk -- and adds the refusal half the minimal probe could not reach.