public sealed class AssetEditorsModuleDoc 37 § P7's panel, registered — the half of that phase that was built and unreachable.
Remarks
P7 shipped a view, a model, six tests and no way to open any of it. AgentDebuggerView was never handed to Shell.RegisterPanel, AgentDebugModel was constructed only by this assembly's own tests, and docs/overview.md recorded the whole row as "none of it is reachable". Every exit criterion of that phase was met as a test, which is exactly the shape of defect a test suite cannot see: nothing was broken, and nobody could use it.
⚠ Here rather than in the editor's application, because the view is in this assembly and this module already exists to be its last mile. The four AI asset editors are registered by StandardEditors and reached from the application; the debugger has no document and no extension, so a factory registry has no seat for it. A module that already owns a PluginContext does — and AddPanel unregisters it again on unload, which Shell.RegisterPanel would not.
⚠ The model is a field and the view is not. A panel's factory runs again every time it is reopened, so a model built inside the lambda would throw away the breakpoints and the selected agent every time somebody closed the tab. The view is the opposite: it belongs to the panel that built it, and Closed drops it so a stale control is never refreshed.
⚠ Live needs an AiSystem and the editor does not have one. Refresh photographs a system in this process, and nothing in the editor owns one. So the panel looks for one in PluginServices and shows an empty model when there is none, which is the honest reading of doc 20's first bar: a verb that is not implemented is visibly not implemented rather than absent. A host that does step agents — a game embedding the editor — publishes its system with Services.Add(system) and the panel goes live with no further wiring.
⚠ This used to add "there is no play mode that steps agents", and that is false. PlayModeController steps a real EngineLoop, and IPlaySystems is the declared seam for adding a system that needs a service the loop cannot invent — PlayPhysics is the worked example. What stops a PlayAi contribution is lifetime rather than scheduling: an AiSystem created on Play dies on Stop, and PluginServices has no removal, which is precisely why PlayPhysics calls session.Provide instead. Nothing here can see a play session. #470 carries that decision.
⚠ And the service that decision asks for mostly exists already, which narrows it. #470 proposes inventing "an IActivePlaySession-shaped service published once and long-lived, whose Current is null between sessions" — PlayModeController.Session is public, is exactly that, and is set on Play and nulled on Stop. What is missing is only that EditorApplication.PlayMode is internal and the controller is not in PluginServices; the precedent for publishing it is ShownScene, which is a contract over a moving answer for the same reason. So option 1 is a publish rather than a design.
⚠ What is genuinely undecided is the producer, and that is not scheduling either. An AiSystem takes an AgentActionRegistry and a BlackboardLayout, and a project's actions are registered by that project's own OnInitialise — which the editor does not run. A PlayAi handing the system an empty registry would put agents in the debugger whose every action is missing, which teaches an author something false. Publishing the seam before that is answered would add a second empty place for these panels to look.
Fields and properties (4)
public const string AgentDebuggerPanelIdWhat the agent debugger is registered as.
public const string ModuleIdWhat the host activates it under, and what a plugin depending on it names.
public const string ModuleNameWhat a plugin-management panel calls it.
public const string InputDebugPanelIdWhat the input debug panel is registered as.
Methods (2)
public bool Follow(UiElement view)Points a freshly-opened AI asset editor at the debugger's model.
public void Activate(PluginContext context)Adds everything the plugin contributes.
Used by (5)
- AgentDebuggerPanelTestsVixen.Editor.App.Tests
- AgentFollowWiringTestsVixen.Editor.App.Tests
- EditorApplicationVixen.Editor.App
- EditorModulesVixen.Editor.Host
- InputDebugPanelTestsVixen.Editor.App.Tests