The first plugins with a real external dependency (Silk.NET) and the
first that need a display. Both built, both verified by hand against
a real window and a live GL context — not just "compiles."
engine.windowing:
- IEngineWindow, not IWindow — Silk.NET's own windowing type already
owns that name; same lesson as the kernel's World -> GameWorld
rename, applied proactively this time instead of hitting the build
error first. docs/kernel-contract.md's §3 illustrative example
updated to match.
- Exposes the real Silk.NET IWindow directly (IEngineWindow.Native)
rather than re-wrapping it — GL context creation and event pumping
both need it, and hiding it buys nothing yet.
engine.render:
- Minimal: glClear + SwapBuffers against a hardcoded color, no mesh.
Enough to prove M1's actual claim, which has nothing to do with
triangles specifically: edit a plugin, rebuild just it, reload it
while a real window stays open, see the change with no app restart.
- No Contracts assembly — PluginManifest.Contracts is now nullable
rather than forcing an empty assembly into existence just to satisfy
the schema; PluginHost.Load skips the Default-ALC step when absent.
Engine.Host:
- --windowed alongside --headless: pumps window events plus
Stage.Update/Stage.Render each frame instead of a bounded --frames
loop. References Engine.Windowing.Contracts directly (never the
implementation) to know how to drive that loop — same "Contracts
are safe to share" pattern already proven for Sandbox.Echo.Contracts.
- New: typing "r <plugin-id>" + Enter reloads that plugin live. Not a
file watcher (still not built), but real Unload+Load through the
same PluginHost path, against a running window — this is what
actually exercised the hot-reload claim below.
- IServiceRegistry gained TryRequire<T> so Engine.Host can ask "is a
window available" without treating its absence as an error; a
plugin's own Configure()/Shutdown() should keep using Require().
Verified end to end by hand: opened the window, watched it render its
hardcoded color, edited RenderPlugin.cs's ClearColor, rebuilt only
that project, typed "r engine.render" into the running process, and
watched the color change with the same window and GL context still
alive. Also found and documented a real platform gotcha along the
way: on Wayland (unlike X11), a window with no committed buffer isn't
shown at all, not even as a black rectangle — engine.windowing alone
produces an invisible window; engine.render's first Clear+SwapBuffers
is what actually makes it appear. Noted directly on RenderPlugin.
Not covered by automated tests, deliberately: opening a real window
needs a real display, which isn't safe to assume of every environment
this runs in. ServiceRegistry.TryRequire<T> and the null-Contracts
path in PluginHost are unit-tested; the window/render/reload flow is
described here and was checked by hand instead.
README status updated: M1 in progress, not done — engine.input and an
actual drawn triangle (vs. a clear color) are still open.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N1qPfzq8TDCUMFMV3UwV5N
