Added config editor in front end

docs/FORKING_RENDER_CADENCE_BASE.md

@@ -6,7 +6,7 @@ This note captures the fork-readiness review for using this repository as a base
 
 The repository is clean enough for an internal fork, but it needs a small hygiene pass before it becomes a comfortable long-lived base repo.
 
-The important architecture is already in place: render cadence, video input/output, frame exchange, readback, preview, control, and shader build work are mostly separated by role. The main replacement point is the render-thread draw path in `src/render/thread/RenderThread.cpp`, where cadence, input upload, readback, and frame publication wrap the actual GPU rendering call.
+The important architecture is already in place: render cadence, video input/output, frame exchange, readback, preview, control, and shader build work are mostly separated by role. The main replacement point is the render-content adapter in `src/render/RuntimeShaderRenderContent.*`, where the current shader-package renderer decides what to draw into the framebuffer handed to it by `RenderThread`.
 
 For a new repo, keep the cadence and frame handoff machinery, then replace or narrow the runtime shader rendering layer.
 
@@ -34,22 +34,22 @@ These are most likely to change when the fork renders something other than shade
 - `runtime/templates/shader_wrapper.slang.in`: only needed for the current Slang package pipeline.
 - Shader-specific UI affordances in `ui`, if the new renderer has a different control model.
 
-The cleanest first fork step is to preserve `RenderThread`'s cadence/readback shell and introduce a narrow render-content interface behind the draw call. Then the new repo can swap the implementation without touching video I/O scheduling.
+The first fork step is now in place: `RenderThread` preserves the cadence/readback shell and calls a narrow render-content interface behind the draw call. A new repo can swap that implementation without touching video I/O scheduling.
 
 ## Current Swap Point
 
-The current draw decision happens inside the readback queue call in `src/render/thread/RenderThread.cpp`:
+The render cadence loop now calls `IRenderContent` inside the readback queue call in `src/render/thread/RenderThread.cpp`:
 
 ```cpp
-if (runtimeRenderScene.HasLayers())
-	runtimeRenderScene.RenderFrame(index, mConfig.width, mConfig.height, videoInputTexture);
-else if (videoInputTexture != 0)
-	renderer.RenderTexture(videoInputTexture);
-else
-	renderer.RenderFrame(index);
+renderContent.RenderFrame(RenderContentFrame{
+	index,
+	mConfig.width,
+	mConfig.height,
+	videoInputTexture
+});
 ```
 
-That is the practical boundary for a fork:
+The default implementation is `RuntimeShaderRenderContent`, which owns the existing runtime shader scene plus simple fallback renderer. That is the practical boundary for a fork:
 
 - keep the tick clock, input upload, readback queueing, and `SystemFrameExchange` publication around it
 - replace what draws into the current GL framebuffer
@@ -84,9 +84,9 @@ The generated Visual Studio `RUN_TESTS` target did not build missing test execut
 ## Recommended Fork Sequence
 
 1. Make the hygiene fixes above in this repo or immediately after the fork.
-2. Add a small render-content abstraction behind the `RenderThread` draw call.
-3. Port the existing runtime shader renderer behind that abstraction as the baseline implementation.
-4. Add the new renderer beside it.
+2. Keep `IRenderContent` as the boundary behind the `RenderThread` draw call.
+3. Keep `RuntimeShaderRenderContent` as the baseline implementation until the fork's renderer exists.
+4. Add the new renderer beside it or replace the default adapter.
 5. Verify that video output still consumes completed frames and never requests rendering directly.
 6. Only then remove shader package pieces that the new repo no longer needs.