Salamatrix framework gap analysis

Status date: 2026-08-08

Source vision: <https://krtkovo.eu/salamander/framework.html>

This audit compares the framework vision with the implementation in this repository. It distinguishes working code from API placeholders, samples, and catalog metadata. The target is not to reproduce the complete native Plugin SDK in scripting languages. It is the middle extensibility layer described by the vision: persistent lightweight extensions with commands, UI, events, storage, and a shared Salamander object model.

Status labels in the matrix are deliberately requirement-level, rather than commit-level: Implemented means the scoped vision item is covered by working code and a focused test; MVP means the public slice works end-to-end but the vision still calls for a broader surface; Partial means substantial pieces exist but the current slice is not yet a coherent user-facing feature; Missing means there is no implementation of the requested surface yet.

Executive summary

The repository already contains a real Salamatrix foundation, not only a design:

• SALAMATRIX.SPL is a load-on-start Automation Framework provider.
• The core has a process-local, versioned service registry with provider

ownership and short consumer leases.

• Native and Automation callers share the first Salamatrix.UI,

Salamatrix.Commands, Salamatrix.FileOperations, and Salamatrix.Sides services.

• Salamatrix.Runtime is a registered broker with versioned adapter

descriptors, registration, enumeration, and lookup.

• Salamander.UI.progress(...), Salamander.Commands.execute(...), and the

three interactive file-operation wrappers work through the Salamatrix bridge.

• Salamatrix owns the schema-1 extension-package manifest parser and package

root contract; Automation supplies only the compatibility/runtime bridge that discovers entry points and starts workers.

• Salamander.Sides exposes Left, Right, Source, and Target plus safe tab

snapshots, paths, and activation to Automation scripts.

• Salamatrix.Storage and Salamander.Storage provide typed, synchronized,

persistent namespaces isolated by manifest extension id.

• Salamatrix.Extensions now provides an owner-aware lifecycle registry, and

the Salamatrix package manager owns extension roots, recursive manifest discovery, publication and worker lifecycle. Automation no longer publishes manifest packages.

• The Plugin Manager has an enabled Extension Runtimes catalog source and

Salamatrix has a distinct Automation Framework capability flag.

• Manifest extensions carry their package SVG identity icon (plus an optional

dark-mode variant) into the existing Plugin Manager list and toolbar image lists. Every manifest command may override those two SVG assets for its own toolbar button; no separate Extension Manager is introduced.

The repository now covers the scoped first-version middle layer, including the lightweight Viewer and flat FS roles. It is no longer only an MVP/PoC for this scope. The remaining work below is hardening, richer variants, or intentionally out of the v1 boundary rather than a missing basic extension role. In particular:

• Automation keeps the legacy ActiveScript compatibility path, while the

standalone JavaScript/Node, CPython, PowerShell, PHP CLI, and Lua .spl providers use the shared SMX1 worker bootstrap and host-call/UI bindings. Dependency environments, richer values, and long-lived event queues remain.

• JavaScript has both the legacy Windows JScript fallback and an independent

modern Node adapter. Python, PowerShell, and PHP have independent process adapters; bundled interpreters and managed dependency environments remain optional future work.

• The first modern side/tab model is exposed through the native SDK,

Salamatrix, and Automation without raw core pointers. Item snapshots, selection/focus mutation, view settings, tab creation/closing, and change events remain broader follow-up work.

• Modern manifest-backed scripts run through the shared worker bootstrap;

discovery registers the complete batch first, resolves declared extension dependencies in bounded passes, and retries activation after a later runtime/plugin configuration change. One-shot scripts still cannot remain alive after their execution ends. If a required separately installed runtime or manifest dependency is missing, discovery keeps the extension in a visible waiting state and reactivates it after the requirement appears.

• The strict schema-1/schema-2 manifest parser validates package/runtime identity,

minimum runtime version, safe entry points, package-owned and per-command icon/optional iconDark SVG paths, capabilities, an optional event allow-list, typed settings/defaults, dependencies, and multiple command records. Dependency declarations are resolved against the owner-aware extension registry and unresolved packages stay visible as waiting-for-dependency. Package-owned BCP-47 locale resources may localize the extension name, declared command titles, and setting presentation text; settings migrations/files and richer handler lifecycle metadata are still missing.

• Schema 2 adds bounded viewers[] and fileSystems[] contributions. Viewer

masks and optional names are registered through the native Viewer role, so configuration identifies the concrete extension Viewer. The flat salamatrix: FS accepts runtime-provided items and package SVG icons, performs periodic refresh, executes a default item action, builds native context menus, exposes Directory Line breadcrumbs and .., and honors the configured title path mode. Complex transfers and hierarchical FS semantics are outside the deliberately Hyper-V-Machines-level v1 role.

• Persistent workers may register multiple commands. The selected command ID

now follows menu activation through the native host and external runtime bootstrap into Salamander.command_id, so one entry point can dispatch distinct handlers without relying on the first command as a fallback. The selected manifest handler is also exposed as Salamander.command_handler.

• Manifest packages with multiple command records now publish every declared

command into the existing Plugin Manager/menu/toolbar path when their persistent worker activates; handler dispatch remains explicit in the worker via the command context.

• Runtime and manifest commands now carry append-only enabled/visible

state metadata. All five modern workers can update that state through the shared setState host call, and the existing Plugin Manager/menu/toolbar path refreshes without adding a public vtable method.

• Persistent process sessions now publish richer lifecycle diagnostics without

changing the session ABI: cached process id/exit code, explicit host stop, failed nonzero exits, and bounded diagnostic messages are available in the Automation bridge and all five standalone providers.

• The shared native UI service exposes progress, input-box, and a reusable

IDialog/IControl contract for modern workers and native plugins. The native implementation now covers the complete DemoPlug gallery: labels, text boxes, check/radio buttons, combo boxes, ordinary buttons, ListView, TreeView, TabControl, folder/file pickers, group boxes, host static text and hyperlinks, progress bars, arrow/text-arrow/color-arrow buttons, and toolbar headers. Node, Python, PowerShell, PHP, Lua, Automation JScript, and DemoPlug each construct the same 463 x 236 capabilities dialog themselves through Salamatrix.UI and identify their runtime/extension in a Created by group. The package-owned dialog dispatcher is implemented in Salamatrix rather than Automation, including cleanup and change-event delivery. DPI/accessibility polish and migration of legacy Forms wrappers remain.

• Salamatrix.AI has a provider-neutral contract. The standalone

SalamatrixAI.SPL registers the optional bounded local command provider, owns the interactive chat window, and publishes the localized Ask Salamatrix AI... menu command with a stable fallback caption; Automation remains a shared-service/API consumer and keeps its legacy scripting/runtime role without owning an AI menu or chat flow. The provider exchanges one bounded JSON request/response and enforces the two-minute ceiling; the optional Salamatrix AI Local LLaMA.SPL companion registers a server-free local.bundled provider and launches its separately installed llama.cpp CLI/model assets. The main SalamatrixAI.SPL remains model-free, so users can install only another provider. The Local LLaMA Configuration page launches a pinned downloader for the official CPU x64 llama.cpp release and a selectable Qwen2.5-Coder GGUF model: recommended 1.5B or lightweight English-prompt-only 0.5B. Both downloads retain SHA-256 checks and third-party license files; the binary and models are no longer staged into the plugin package. Its response contract now also permits an explicit canImplement:false plus a validated missingCapabilities list, so unsupported requests can be explained instead of being forced into invented API calls.

Requirement matrix

Persistent runtime shutdown crash regression (2026-08-09)

Two x64 crash reports identified one teardown race, not a manifest schema compatibility failure. One fault returned from a PowerShell worker pump into a freed IRuntimeSession; the other executed a queued main-thread host callback after salamatrix.spl had already been unloaded. Both were enabled by a five-second pump-thread wait followed by session release (and, in Automation, forced thread termination) while the pump could be synchronously blocked in InvokeOnMainThread/SendMessage.

Salamatrix Framework 0.6 and Automation 2.4 now mark the session as stopping before removing its bindings, reject newly arriving host/event/dialog calls, stop the worker, and retain the session and module until the pump has actually returned. When teardown runs on Salamander's UI thread, the shared join helper dispatches only nonqueued synchronous sent messages, avoiding the circular UI-thread/pump-thread wait without consuming posted application work.

A follow-up close-time report from the same build exposed a separate native UI lifetime bug: a long-lived notification popup survived framework release, and USER32 later dispatched WM_WINDOWPOSCHANGING to Salamatrix::UI::NotificationWindowProc at RVA 0x5D5B0 after salamatrix.spl had been unloaded. Salamatrix Framework 0.7 tracks every notification HWND alongside modeless native dialogs, destroys those windows synchronously during CPluginInterface::Release, and unregisters their window class before the module can unload. The PR-running native UI test creates a long-timeout notification and verifies that the shutdown hook leaves no window of that class alive.

Current verification snapshot

The newest implementation commits include d5f7e56d9 (runtime-built Salamatrix.UI capabilities dialogs), 4a380ef3c (editable native FilePicker and standalone worker parity), 89a1d4fbf (isolated process runtime verification), a6a8cedc8 (Plugin Manager settings configuration), 9aa3cbf84 (per-command SVG toolbar artwork), and 6e1711cd8 (dialog FolderPicker). They were compiled into isolated Debug x64 output directories; the user's locally running Salamander process was never started, stopped, or otherwise controlled by this work.

• d5f7e56d9: Node, Python, PowerShell, PHP, Lua, Automation JScript, and

DemoPlug now build the complete capabilities dialog themselves. Salamatrix, Automation, and DemoPlug Release x64 builds passed; all five worker/demo syntax checks passed; and the isolated Python/PowerShell/PHP processruntime_tests.exe run completed with All process runtime tests passed. using only copied standalone provider worker assets. No Salamander process was started or controlled, so live pixel, DPI, dark-mode, and interaction verification remains manual.

The current implementation separates the optional Salamatrix AI Local LLaMA.SPL companion from the model-free SalamatrixAI.SPL. Its configuration downloader is syntax-checked and pins the official llama.cpp CPU x64 archive and both selectable Qwen GGUF models by SHA-256; the plugin build contains only the downloader script, not the binary or model. A live model download was intentionally stopped at the 120-second command limit in this environment; no Salamander process was started or controlled.

• a6a8cedc8: Automation, Salamatrix, the core Salamander executable, and

Extensions native tests passed.

• 9aa3cbf84: strict manifest parser tests and Automation Debug x64 build

passed.

• 6e1711cd8: Salamatrix, Automation, and all four standalone runtime

provider Debug x64 projects passed; runtime-protocol tests passed; Python, PowerShell, PHP, and Node worker syntax checks passed.

• The Python/PowerShell/PHP process-runtime integration executable built, but

its invocation was previously skipped because this environment did not set SALAMATRIX_WORKER_ROOT. That gap is now closed: on 2026-07-26 the build\verification\folder-picker\process-tests\processruntime_tests.exe executable passed with exit code 0 when SALAMATRIX_WORKER_ROOT pointed to the isolated build\verification\process-runtime-worker-root containing only copied Python, PowerShell, and PHP bootstrap files. The run exercised interpreter discovery, one-shot and persistent SMX1 sessions, host calls, typed storage, commands, events, clipboard, file/folder pickers, native dialog controls, shutdown, output capture, and timeout coverage without starting or controlling Salamander.

At the previous pause point all Salamatrix source and documentation changes were committed. The pre-existing worktree-only .gitignore change keeps the two syntax-check artifacts out of source control: src/plugins/automation/runtime/__pycache__/ and src/plugins/pythonruntime/runtime/__pycache__/. They are not source changes and are not staged.

On 2026-07-26, the append-only lifecycle diagnostic contract was verified by an isolated Debug x64 rebuild of the process test, protocol test, and all four standalone provider projects. With SALAMATRIX_WORKER_ROOT set to build\verification\runtime-diagnostics\worker-root, the process-runtime executable passed with exit code 0; its one-shot worker reported running, then exited with exit code 0. The run also exposed stale typed-storage/schema methods in the standalone Python worker, which were brought back to parity before the passing rerun.

The UI slice was verified on 2026-07-26 with an isolated Debug x64 Salamatrix.SPL rebuild and the standalone ui_layout_tests.exe. The test passed picker geometry checks plus 96-to-144 DPI and 144-to-96 DPI scaling checks. No GUI Salamander process was started or controlled.

The current runtime baseline was rebuilt from the current source into build\verification\current-runtime-baseline. Its process-runtime executable passed with SALAMATRIX_WORKER_ROOT explicitly set to an isolated root containing only the Python, PowerShell, and PHP workers copied from their standalone runtime-provider projects. The run returned exit code 0 and no Salamander process was started or controlled.

The current worktree was audited again after the SalamatrixAI workflow changes: build\verification\worker-root-current was created as an isolated root from the Python, PowerShell, and PHP worker files in this checkout. The existing Debug x64 process-runtime executable from the parent-revision baseline was run with that root in SALAMATRIX_WORKER_ROOT and returned exit code 0. It covered the same host-call, persistent-session, UI, storage, event, picker, AI preview, shutdown, output-capture, and timeout paths; Node was additionally syntax checked with node --check. This validates the current worker assets and SMX1 contract, while a fresh current-source Debug x64 rebuild remains dependent on the unavailable Visual C++/MSBuild toolchain in this environment.

Existing implementation evidence

Core service and plugin integration

• src/plugins/shared/spl_gen.h declares RegisterService,

UnregisterService, QueryService, and the appended owner-aware register/unregister/acquire/release methods. Its appended toolbar contract accepts package-owned SVG paths (normal plus optional dark-mode variant), while the core renders those files through NanoSVG into the shared toolbar image lists. When the optional dark asset is absent, the core derives a dark-friendly bitmap from the normal SVG while preserving alpha and color information.

• src/zip.cpp contains the fixed-size process registry, its critical-section

guard, lease table, unload gate, and condition-variable wait for active consumers.

• src/plugins/shared/spl_base.h defines

FUNCTION_AUTOMATIONFRAMEWORK.

• src/plugins/salamatrix/salamatrix.cpp creates persistent

RuntimeServices, registers the provider, and requests load on startup.

• src/plugins/salamatrixai/ is a separately buildable/installable provider

plugin. It registers local.command plus the optional local.ollama WinHTTP provider under Salamatrix.AI and exposes the shared native chat dialog; it is not a dependency of Automation.

• Automation additionally publishes the optional Salamatrix.ScriptRunner

service. This is the non-privileged bridge used by the AI plugin to execute a saved script through the ordinary extension host dispatcher.

• src/vcxproj/salamand.sln builds Salamatrix as part of the main solution.

Runtime provider packaging boundary

The runtime broker is already a host service rather than an Automation-private API: IRuntimeService::RegisterAdapter and UnregisterAdapter accept adapter objects from any loaded plugin, and runtime descriptors are enumerated through the same service by native callers and workers. The standalone PythonRuntime.SPL, PowerShellRuntime.SPL, PHPRuntime.SPL, and JavaScriptRuntime.SPL projects now own their provider adapters, interpreter discovery, and worker bootstrap. Their standalone Windows projects pass isolated Debug x64 builds, and the worker package gate verifies their bootstrap/export boundary without launching Salamander. Final loading and GUI behavior still require the target machine; Automation retains only its legacy ActiveScript engines and consumes the broker like every other plugin.

Shared services already working

• src/plugins/salamatrix/salamatrix_ui.h adapts the existing Salamander

progress implementation.

• src/plugins/salamatrix/salamatrix_commands.h exposes the small stable

command catalog and interactive rename/copy/move routing.

• src/plugins/salamatrix/salamatrix_sides.h exposes runtime-neutral sides and

panel-tab snapshots over the new core SDK methods.

• src/plugins/salamatrix/salamatrix_storage.h owns validated, synchronized,

typed per-extension storage and its versioned configuration blob.

• src/plugins/salamatrix/salamatrix_events.h owns host event mapping and

unsubscribe-safe callback dispatch.

• The standalone runtime provider projects own bounded out-of-process

CPython, PowerShell, PHP CLI, and Node adapters; Automation retains only transitional source/test implementations while consuming the broker.

• src/plugins/salamatrix/salamatrix_runtime_protocol.h defines the bounded

incremental SMX1 worker framing and its message vocabulary; the Automation bridge now supplies the first host-call dispatcher over that boundary.

• src/plugins/automation/scriptlist.cpp owns the lifecycle callback and the

initial runtime.ready, commands, sides, and string-storage dispatch.

• src/plugins/automation/salamatrixbridge.cpp is a consumer-only bridge.
• src/plugins/automation/salamatrixaut.cpp implements the COM/Automation

wrappers.

• src/plugins/automation/salamander.idl publishes the UI, Commands,

FileOperations, Sides, Events, and isolated Storage namespaces.

Script discovery and manifest parsing

• src/plugins/salamatrix/salamatrix_manifest.cpp contains the strict,

independently tested schema-1 JSON parser and validated package model; Automation consumes its framework header without owning the parser.

• src/plugins/automation/scriptlist.cpp recursively discovers legacy

ActiveScript files, registered runtime-adapter entry points, and valid manifest entry points even when their extension has no COM association.

• The same file resolves manifest runtime id/minimum version through the broker

before execution. Inline Salamatrix.Command* metadata remains supported.

• src/plugins/automation/sample-scripts/Salamatrix Progress Demo/ is the

first manifest-based sample.

Existing legacy Automation value

The new platform should preserve these working capabilities:

• active left/right/source/target panel path, focused item, all items, selected

items, selection manipulation, and panel path changes;

• message/input/error/question/overwrite dialogs, progress and wait windows;
• modal Forms with Label, TextBox, CheckBox, and Button;
• file viewing, path normalization, mask matching, tracing, sleep/cancel;
• basic global persistent values;
• JScript and VBScript, plus third-party IActiveScript engines where

available.

Important implementation risks found by the audit

1. The core service registry still exposes borrowed interface pointers to callers, but provider ownership and short consumer leases now prevent new acquisitions during unload and wait for active calls before removal. The extension lifecycle registry has the same owner-aware callback behavior; unload diagnostics are still minimal. 2. Runtime provider registration is still an explicit plugin-lifetime contract; unload diagnostics and a user-facing dependency view remain. 3. Posted Commands/FileOperations report ok when a command was accepted, not when the modal operation completed successfully. cancel is not observable. 4. The command catalog currently maps both Move and MoveRename to the same native command and contains only three unique operations. 5. The manifest parser retains every validated command and the Automation menu surface iterates all registered runtime command contributions; remaining work is richer independent placement/toolbar metadata rather than dropping additional commands. 6. Discovery and execution now go through runtime adapters. The v1 compatibility callback still keeps old ActiveScript hosting inside Automation; modern process cancellation is currently stop/termination based. 7. Long-lived script callbacks still require richer UI-thread, reentrancy, cancellation, and exception rules; host callbacks now reject new calls during extension deactivation and hold an unload lease while active. 8. A language process must never receive raw C++/COM implementation pointers. Out-of-process adapters need a versioned RPC/value protocol, while in-process adapters need ABI-stable interfaces.

Recommended implementation order

Phase 0: make the foundation safe

1. Route extension discovery and execution through the existing Salamatrix.Runtime broker. Implemented. 2. Add provider ownership/leases, diagnostics, and lifecycle rules to runtime and core services. Provider ownership and short leases are implemented; richer diagnostics remain. 3. Replace the manifest text scanner with a real parser and validate a versioned schema.

Phase 1: complete the useful common object model

1. Publish Salamatrix.Sides with Left, Right, Source, and Target. Implemented. 2. Add side and tab snapshots/handles: path, active tab, tabs, focused/selected items, view mode, tree visibility, detached state. Implemented for tab identity, enumeration, path, activation, active/source/target/locked/ detached state, side path changes, refresh, selection mutation, and focus; item/view details remain. 3. Add clipboard and panel refresh. 4. Expand stable Commands and implement synchronous, programmatic file operations. 5. Add isolated per-extension storage. Implemented for typed key/value persistence; settings schemas, quotas, migrations, and uninstall policy remain.

Phase 2: make extensions persistent

1. Extension instances and lifecycle: discover, load, activate, deactivate, unload. The owner-aware Salamatrix.Extensions registry and persistent IRuntimeSession activation seam are implemented; host dispatch and worker bindings remain. 2. Command contribution service independent of menu/toolbar/hotkey placement. 3. Event service with a small first set: startup/shutdown, active side/tab, path, selection, tab create/close. Implemented for host lifecycle, settings/configuration/colors, panel swap, active-panel events, successful shared-Sides path/selection/tab/refresh operations, and core path/selection/tab notifications; persistent instance queues now use bounded worker-session frames. File-operation and window lifecycle hooks remain. 4. Package state in the existing Plugin Manager.

Phase 3: runtimes

1. Keep current Automation as the legacy-wsh compatibility adapter. 2. Add a modern bundled JavaScript adapter as the default lightweight runtime. 3. Add PowerShell and CPython adapters as separate runtime components. 4. Add PHP only after the common out-of-process protocol is proven; it should reuse the same protocol rather than introduce a fourth binding architecture. 5. Run the same runtime contract suite against every adapter.

An out-of-process JSON-RPC-style transport is the safest common denominator for CPython, PowerShell, and PHP. The host owns all Salamander objects and returns serializable handles/snapshots; runtimes send typed API requests. A bundled JavaScript engine may be in-process for size and speed but should implement the same logical contract.

Phase 4: shared UI

The native dialog/control surface, explicit layout, collection binding, pickers, validation/events, and the complete DemoPlug control gallery are now implemented through one framework-owned service. The five worker runtimes, Automation JScript, and native DemoPlug independently exercise that surface; the old Automation Forms classes remain compatibility wrappers rather than the owner of modern dialogs. Continue with automated dark-mode/DPI interaction, full UI Automation roles and screen-reader testing, virtualized collections, richer notifications, reentrancy rules, and localization guidance for extension-authored text. See doc/salamatrix-ui.md for the current contract and examples.

Phase 5: AI assistant

Start only after the common API is useful without AI:

1. Generate a machine-readable API schema from the real contracts. 2. Define a provider-neutral model interface and structured result containing title, description, required capabilities, estimated effects, and script. 3. Implement Ask -> Preview -> Validate -> Run -> Save. 4. Add static validation and a repair loop against the exact installed API version. 5. Add an external local provider first, then an optional bundled local backend. 6. Treat the AI as a script author with no privileged control path.

First implementation slice

The first code slice following this audit is implemented:

• publish Salamatrix.Runtime as a real service;
• allow runtime adapters to register versioned runtime ids and file/language

metadata;

• make Automation advertise its legacy Active Scripting adapter through that

broker;

• expose runtime availability in diagnostics;
• make registration failure transactional.

The second code slice is also implemented:

• replace raw scalar scanning with a strict schema-1 UTF-8 JSON parser;
• validate runtime/minimum version, safe entry points, capabilities, and the

complete commands array;

• discover manifest entry points independently of ActiveScript associations;
• route manifest execution through a structured runtime-adapter request/result;
• execute existing JScript/VBScript compatibility engines through the broker;
• add a standalone manifest parser test target and invalid-manifest fixtures.

The third code slice is also implemented:

• append versioned tab snapshot and activation methods to the native plugin SDK

and raise the SDK requirement to 105;

• assign every live panel tab an opaque 64-bit lifetime id;
• publish Salamatrix.Sides with Left/Right/Source/Target resolution, tab

snapshots, paths, activation, and active-tab path changes;

• expose the service to scripts as Salamander.Sides, Side, and Tab

Automation objects;

• represent ids as decimal strings and revalidate each operation by id so stale

script objects fail safely;

• compile the main executable, Salamatrix, and Automation in Debug x64, Debug

Win32, and Release x64.

The fourth code slice is also implemented:

• publish Salamatrix.Storage as a transactionally registered service;
• isolate namespaces by the validated manifest extension id instead of asking

scripts to invent collision-resistant prefixes;

• support UTF-8 strings, signed 64-bit integers, booleans, delete, and clear

through a synchronized runtime-neutral contract;

• persist one bounded, versioned, fully validated configuration blob through

the plugin registry abstraction;

• expose Salamander.Storage.has/get/set/remove/clear only to manifest

extensions and preserve the old global API for loose-script compatibility;

• add /W4 /WX tests for isolation, validation, types, mutation, save/load

round-trip, unchanged saves, and corrupt data.

The fifth code slice is also implemented:

• publish Salamatrix.Events with lifecycle, settings/configuration, colors,

panel-swap, and active-panel event kinds;

• map the existing Salamander plugin Event callback into copied,

runtime-neutral payloads containing panel/tab/path context;

• dispatch matching callbacks outside the registry lock so self-unsubscribe and

reentrant subscription are safe;

• expose Salamander.Events.subscribe/unsubscribe with decimal opaque ids and

automatic cleanup when the one-shot Automation root is released;

• add /W4 /WX tests for event delivery, self-unsubscribe, capacity, and invalid

payload/kind handling.

The sixth code slice is also implemented:

• publish Salamatrix.Extensions as a bounded, owner-aware lifecycle registry;
• track explicit discovered/activating/active/deactivating/inactive/failed

states and invoke lifecycle callbacks outside the registry lock;

• register valid manifest-backed Automation scripts at load/refresh and remove

them before their CScriptInfo owners are deleted;

• retain and stop a persistent IRuntimeSession from the owning script during

activate/deactivate and destruction;

• add /W4 /WX tests for registration, duplicate-owner rules, lifecycle state

transitions, validation, and owner cleanup.

This slice intentionally stops before host API dispatch. The registry and session are the stable seam for the next runtime-host work.

The seventh code slice is now implemented:

• extend the runtime request/result contract with working-directory, timeout,

process/exit, and bounded output fields;

• register optional out-of-process Python.CPython, PowerShell, and PHP.CLI

adapters from Automation using explicit environment overrides or PATH;

• execute entries through non-shell CreateProcessW, drain stdout/stderr,

terminate timed-out children, and surface structured failure/exit results;

• document the remaining persistent worker/RPC boundary instead of treating a

one-shot CLI process as a full Salamander-aware runtime.

The transport foundation is covered by a standalone /W4 /WX test for partial frames, round trips, malformed ids, newline rejection, and the 1 MiB limit.

The eighth code slice is now implemented:

• add IRuntimeSession and optional IRuntimeAdapter::StartPersistent();
• implement bidirectional persistent process sessions with bounded frame reads,

CRLF-tolerant worker output, safe stop/Release cleanup, and timeout-aware liveness checks;

• connect manifest lifecycle activation/deactivation to session ownership;
• start and join a bounded host pump thread so worker frames are processed in

normal plugin operation;

• verify a Python echo worker end to end through SMX1 frames.

This does not pretend that modern Python or PowerShell support is complete. It creates the contract those adapters need and removes the current architectural assumption that every script file must map directly to an IActiveScript COM CLSID.

The ninth code slice is now implemented:

• add a host-dispatch callback to the persistent runtime request;
• bind runtime.ready, salamander.commands.execute,

salamander.sides.activeTab, and string salamander.storage.get/set calls;

• bind event subscribe/unsubscribe and push matching event frames, plus a

parented message-box call;

• ship language-specific bootstrap scripts that expose the same Salamander

object model and route calls/events over SMX1;

• add bounded JSON string-member extraction tests and verify the Automation

plugin plus the Python worker round trip.

The tenth code slice is now implemented:

• add stable toolbar contribution keys to the appended native toolbar ABI;
• persist extension toolbar placement in the existing toolbar configuration,

while retaining automatic defaults for older configurations;

• resolve persisted entries by manifest/plugin identity rather than transient

process-local command ids;

• derive a dark-mode bitmap from the normal extension SVG when an extension

does not ship a separate iconDark asset.

• keep icon rendering and placement shared between native plugins and all

runtime-backed extensions.

The eleventh code slice is now implemented:

• connect the AI service to the live runtime broker;
• publish versions of all native Salamatrix service contracts in the machine-

readable API description;

• publish the current runtime adapter inventory (id, language, extensions,

version, and availability) for prompt construction;

• cover the generated metadata with the runtime protocol test target.

The twelfth code slice is now implemented:

• let the native command, file-operation, UI, sides, events, storage,

extensions, and runtime services publish compact schema fragments next to their actual contracts;

• aggregate those fragments into the AI service's machine-readable schema;
• validate the resulting nativeContracts JSON object in the runtime protocol

tests.

The thirteenth code slice is now implemented:

• add a common AI response validator for capabilities, estimated effects,

runtime identity, and undeclared external/network operations;

• expose the validator and a bounded GenerateWithRepair loop through the

provider-neutral AI ABI, preserving compatibility defaults for older services;

• use the same repair-aware generation path in the standalone Salamatrix AI

chat and both Automation AI consumers;

• cover valid, unsupported-capability, and unsafe-script responses in the

runtime protocol tests.

The fourteenth code slice is now implemented:

• extend schema-1 manifests with an optional events declaration;
• validate event names and reject duplicates during strict manifest parsing;
• enforce the declared allow-list at the persistent worker host boundary while

preserving unrestricted event subscriptions for legacy manifests and generated one-shot AI scripts;

• cover declared, absent, unknown, and duplicate event declarations in the

manifest parser tests.

The fifteenth code slice is now implemented:

• represent an unavailable requested runtime with the ABI-safe

ExtensionFlagRuntimeUnavailable flag and ExtensionStateWaitingForRuntime;

• have Automation check the shared runtime broker for the adapter and minimum

version while publishing manifest extensions;

• keep waiting extensions visible in the existing Plugin Manager and annotate

their runtime/function status without offering an install flow;

• make activation a safe no-op while the dependency is absent, then clear the

waiting state and activate through the existing same-owner refresh when the standalone runtime plugin registers;

• cover registration, blocked activation, and reactivation in the extension

lifecycle test.

The sixteenth code slice is now implemented:

• retain the selected runtime command ID in the Automation execution context;
• pass that ID through the Python, PowerShell, PHP, and Node worker bootstrap

command lines for both the Automation compatibility broker and standalone runtime providers;

• expose it consistently as Salamander.command_id (with JavaScript's

camel-case alias commandId as well);

• publish the field in the AI/API description so generated extensions can

dispatch manifest or dynamically registered handlers explicitly;

• cover the end-to-end Python one-shot path and re-run all worker syntax and

provider Debug builds.

The seventeenth code slice is now implemented:

• retain all validated manifest command records (up to the native runtime

command limit) instead of applying only the first record;

• publish each declared command with its own plugin/context/toolbar placement

and requires event masks when the persistent extension activates;

• keep the manifest command surface stable across worker teardown and restore

its default command metadata on the next activation;

• allow the worker to add or remove dynamic commands alongside manifest-owned

commands without losing the package identity;

• preserve the selected command context for all of these entries through the

existing Salamander.command_id worker field.

The eighteenth code slice is now implemented:

• extend the versioned runtime request with an optional CommandHandler field;
• resolve the selected manifest command's declared handler by command ID;
• pass that handler through the Automation broker and all four standalone

worker providers using the bounded --command-handler/-CommandHandler bootstrap argument;

• expose the value consistently as Salamander.command_handler (plus

JavaScript's camel-case alias) and cover the Python one-shot path in the process-runtime integration test.

The nineteenth code slice is now implemented:

• retain an optional handler name on every native runtime command record;
• extend Salamander.commands.register(...) in Python, PowerShell, PHP, and

JavaScript with the common optional handler argument;

• persist dynamic handler names through native command activation and expose

the selected value through the same Salamander.command_handler field;

• publish the handler field in the live AI/API command schema and verify the

worker-to-host registration payload in the Python bootstrap integration test.

The twentieth code slice is now implemented:

• add the ABI-safe fileChanged event kind without extending the events vtable;
• forward Salamander core AcceptChangeOnPathNotification callbacks through

Salamatrix with the UTF-8 affected path and recursive-scope flag;

• expose the event consistently to modern workers, Automation, manifest event

allow-lists, and the live AI/API schema;

• cover subscription acceptance and path/scope delivery in the native Events

test suite.

The twenty-first code slice is now implemented:

• add the append-only UI 1.1 notification contract and native timed popup;
• expose Salamander.ui.notify(message, title, timeout) consistently to

Python, PowerShell, PHP, JavaScript, native Automation adapters, and the live AI/API schema;

• keep notification calls non-modal and bounded (default five seconds,

maximum ten minutes) while allowing click-to-dismiss;

• cover the worker-to-host notification call in the Python bootstrap test.

The twenty-second code slice is now implemented:

• validate an optional manifest dependencies array (bounded, identifier-only,

case-insensitive unique ids) and retain it with the discovered script;

• register the complete manifest batch before activation, resolve dependency

chains in bounded passes, and represent unresolved dependencies with the ABI-safe waitingForDependency state/flag;

• make activation a safe no-op while a dependency is absent and surface the

reason in the existing Plugin Manager alongside runtime-unavailable status;

• cover dependency parsing, blocked activation, and same-owner reactivation in

the manifest and Extensions test suites.

The twenty-third code slice is now implemented:

• append the Extensions 1.1 disabled state and SetExtensionDisabled API

without changing the existing descriptor layout;

• persist the manifest extension's enabled choice in its isolated

salamatrix.enabled Storage key, where no key remains backwards-compatible as enabled;

• make Plugin Manager Deactivate stop the worker first, then persist and show

disabled; Activate clears that state and starts the ordinary lifecycle;

• cover disabled registration, safe no-op activation, re-enable, and

re-disable transitions in the Extensions lifecycle test.

The twenty-fourth code slice is now implemented:

• append the ABI-safe Extensions 1.2 settings-schema contract with bounded

string/integer/boolean setting records, without changing the descriptor layout;

• publish manifest setting declarations from Automation after each successful

extension registration;

• use the shared Salamatrix.UI dialog/control API from Plugin Manager's

Configure action to edit typed per-extension values (with a deliberate 24-setting fixed-layout limit);

• cover schema registration, retrieval, duplicate rejection, and the

Extensions 1.2 service build alongside Automation, Salamatrix, and core Salamander Debug x64 builds.

The twenty-fifth code slice is now implemented:

• allow every manifest commands[] record to declare a package-contained SVG

icon and optional dark-mode iconDark asset;

• validate the command artwork with the same safe-relative-path and SVG-only

rules as package artwork, resolve it during discovery, and prefer it for its specific toolbar button;

• preserve package artwork as the compatibility fallback and retain core dark

icon generation when no valid dark asset is supplied;

• cover valid and invalid command artwork through the strict manifest parser

test and build Automation Debug x64.

The twenty-sixth code slice is now implemented:

• add a native FolderPicker control to Salamatrix.UI dialogs; it opens the

standard folder browser, returns its selected UTF-8 path through IControl, and raises the standard control-change event;

• expose it to every modern worker facade as Python add_folder_picker,

PowerShell AddFolderPicker, PHP addFolderPicker, and Node addFolderPicker, with the raw runtime protocol kind folderpicker also accepted;

• include the control in the runtime and AI API schemas so the local script

helper can generate it;

• build Salamatrix and Automation Debug x64, run the API protocol test, and

syntax-check all four runtime worker implementations. The process-runtime integration run was completed later with an explicit isolated SALAMATRIX_WORKER_ROOT; its result is recorded in the twenty-seventh slice below.

The twenty-seventh code slice is now implemented:

• add the append-only filepicker control kind to the shared native dialog;

its edit control keeps a UTF-8 path value while the adjacent browse button opens the wide Win32 file dialog with heap-backed path storage rather than a new MAX_PATH dependency;

• expose add_file_picker/AddFilePicker/addFilePicker in the Python,

PowerShell, PHP, and Node workers and publish the control in the runtime and AI API schemas;

• extend the host mapping and the cross-runtime process test to cover the new

control for Python, PowerShell, and PHP;

• fix typed-storage/schema drift in the standalone PowerShell and PHP worker

assets, which the isolated provider-root test exposed after the first attempt;

• rebuild Salamatrix, Automation, all four standalone provider projects, the

runtime protocol test, and the process-runtime test into build\verification\editable-file-picker; the protocol test and the process-runtime test both passed, with the latter returning exit code 0 under an explicit isolated SALAMATRIX_WORKER_ROOT.

The twenty-eighth code slice is now implemented:

• extend manifest setting declarations with validated label, description,

group, order, width, and multiline metadata while keeping the storage key stable;

• allow selected package locale resources to translate setting presentation

text in addition to extension names and command titles;

• append presentation fields to ExtensionSettingInfo, but accept and return

the legacy 1.2 prefix by honoring caller StructSize, preserving the existing ABI and service vtable;

• publish the metadata through storage.schema() and the existing Plugin

Manager's Configure dialog, including localized labels/groups and bounded multiline/width layout;

• cover parser validation, localized settings, the new registry fields, and

legacy setting-schema callers. The isolated parser/registry tests and Automation plus Salamatrix Debug x64 builds passed under build\verification\manifest-settings; no Salamander process was started or controlled.

The twenty-ninth code slice is now implemented:

• add initial enabled/visible state to manifest and runtime command

metadata while keeping the public service/vtable prefixes unchanged;

• expose setState/set_state/SetState/setState through the common worker

facades, apply the state in Automation's existing menu and toolbar path, and trigger the normal Plugin Manager/menu refresh;

• cover manifest state parsing, the runtime API schema, and state changes from

Python, PowerShell, and PHP in the isolated process-runtime test;

• build Automation, Salamatrix, all four standalone provider projects, and the

focused tests into build\verification\command-state. The explicit SALAMATRIX_WORKER_ROOT process run, all worker syntax checks, and the parser/protocol tests passed; no Salamander process was started or controlled.

The thirtieth code slice is now implemented:

• complete the append-only IRuntimeSession::GetDiagnostic implementation in

the Automation process bridge and all four standalone runtime providers;

• preserve cached process id and exit code after handle teardown, distinguish

running, explicit host stop, clean exit, and nonzero failed exit, and expose bounded diagnostic text without changing any public vtable prefix;

• extend the process-runtime test with running/stopped/process-id assertions

and a deterministic nonzero-exit failure fixture;

• build Automation, the process-runtime test, and all four standalone

providers into build\verification\runtime-lifecycle. The explicit SALAMATRIX_WORKER_ROOT run passed with exit code 0; no Salamander process was started or controlled.

The thirty-first code slice is now implemented:

• append filter and save file-picker options to the shared native control

contract without changing existing enum values, vtable prefixes, or control layout prefixes; save selects the native GetSaveFileNameW path and filter uses the UTF-8 pipe-separated Win32 filter format;

• keep the SMX1 wire contract flat (kind, text, filter, and save) and

preserve positional compatibility in the Python and Node helpers by placing the new optional values after the existing layout argument;

• update the Automation host mapping, all four standalone worker assets, the

runtime/AI schema fragments, and the Python/PowerShell/PHP process bootstrap assertions for both option values;

• rebuild Salamatrix, Automation, all four standalone providers, and the

focused tests into build\verification\file-picker-options; UI layout, runtime protocol, worker syntax, and explicit SALAMATRIX_WORKER_ROOT process-runtime tests passed with exit code 0. No Salamander process was started or controlled.

The thirty-second code slice is now implemented:

• append tabCreated, tabClosed, tabReordered, windowDetached, and

windowAttached as event kinds 16–20 without changing the existing event enum prefix, service vtable, or V1 EventPayload prefix;

• infer lifecycle transitions from per-side heap-backed tab snapshots on

PLUGINEVENT_TABCHANGED, establish an explicit baseline for empty sides, and publish inferred lifecycle events before the legacy tabChanged;

• bridge changedTabId, tabIndex, and previousTabIndex into Automation's SMX1

JSON event frame while retaining safe defaults for older V1 payloads;

• extend the existing Plugin Manager manifest event allow-list and the

Salamatrix/AI event schemas, with deterministic native, manifest, and schema tests;

• build the focused tests, Automation, Salamatrix, and all four standalone

providers into build\verification\tab-lifecycle; all passed, as did the explicit worker-root process-runtime run and all four worker syntax checks. No Salamander process was started or controlled.

The thirty-third code slice is implemented and verified:

• a deterministic Python bootstrap scenario verifies the fixed host/worker tab

mutation contract: createTab returns a decimal string tab id and closeTab, reorderTab, moveTab, and setDetached return their exact response shapes; each dispatcher path is counted once;

• the published Sides schema advertises version 1.3 and all five append-only

mutation methods;

• core, Automation host, Salamatrix, events, runtime protocol, process-runtime,

extension-manifest, and all four standalone provider projects pass isolated Debug x64 verification under build\verification\tab-object-model;

• all four worker syntax checks pass. The process-runtime test passed with an

explicit provider worker root in SALAMATRIX_WORKER_ROOT; no Salamander process was started or controlled.

The thirty-fourth code slice is implemented and verified:

• classify Salamatrix Framework, JavaScript/Python/PowerShell/PHP runtime

providers, and SalamatrixAI by stable registry-key prefixes with display-name fallbacks, preserving the ordinary Automation Framework label for unrelated plugins;

• expose SalamatrixAI's Menu Extension capability in the existing Plugin

Manager and publish a localized command that opens the local-model chat;

• make SalamatrixAI shutdown unload-safe when Salamatrix Framework unloads

first by querying the current SALAMATRIX_SERVICE_AI record and checking pointer identity before provider unregistration, then clearing all borrowed service pointers;

• add a deterministic source-contract regression script and rebuild both the

Salamatrix core and SalamatrixAI into build\verification\regressions;

• the regression script, core Debug x64 build, and SalamatrixAI Debug x64 build

passed. No Salamander process was started or controlled.

The thirty-fifth code slice is implemented and verified:

• extend schema-1 manifests with bounded settingsVersion and

settingsMigrations metadata for typed string/integer/boolean rename and remove operations, with strict conflict, bounds, reserved-key, and complete chain validation;

• apply migrations through an internal host helper before settings defaults,

persist the reserved salamatrix.settings.version, preserve existing destinations, support retries after partial failures, and never downgrade a higher stored version; no public SDK vtable or struct layout changes;

• wire the helper into Automation's manifest discovery and add a standalone

migration test executable covering typed values, chains, no-op removals, destination preservation, retry behavior, and version stamping;

• rebuild the manifest parser tests, migration tests, and Automation Debug x64

plugin into isolated build\verification\manifest-migrations-current, build\verification\settings-migrations-current, and build\verification\automation-migrations-current outputs; all passed.

The thirty-sixth code slice is implemented and verified:

• add standalone, non-GUI assertions for Salamatrix.UI accessibility metadata:

default ControlOptions values remain null, explicit UTF-8 values are retained, and the append-only IControl default accessors return empty strings for older control implementations;

• rebuild and run the UI layout/DPI test executable in isolated

build\verification\ui-accessibility-final2 output; all assertions passed;

• rebuild Salamatrix.SPL itself in isolated

build\verification\salamatrix-accessibility-final2 output after fixing the helper's private-implementation scope; the Debug x64 build passed.

The thirty-seventh code slice is implemented and verified:

• add ABI-safe GetKeyCount/GetKeyAt storage enumeration with typed UTF-8

key metadata and the salamander.storage.keys host method;

• add storage.keys()/Storage.Keys()/storage->keys()/Storage.keys() to

the Python, PowerShell, PHP, and Node worker facades;

• add direct storage unit coverage and persistent Python/PowerShell/PHP

bootstrap assertions for string, boolean, and integer key types;

• rebuild storage, Automation, and process-runtime tests in isolated

build\verification\storage-enumeration-final, build\verification\storage-enumeration-automation-final, and build\verification\storage-keys-process-teststests outputs; all passed;

• rerun the process-runtime executable with explicit

SALAMATRIX_WORKER_ROOT=build\verification\storage-keys-worker-root; all process runtime tests passed without starting Salamander.

The previous storage-table note that listed key enumeration as missing is superseded by this thirty-seventh slice. Remaining storage gaps are settings files, quotas, transactional batches, and uninstall retention/deletion policy.

The thirty-eighth code slice is implemented and verified:

• remove Automation's CmdAskAssistant menu command, enablement path, and

interactive generation/preview/run/save/package flow, so Automation remains the independent legacy JS/VBScript and shared runtime-client plugin;

• remove the Automation-only AI menu localization and helper implementation

while preserving the Salamatrix.AI bridge/API used by runtime scripts and the Salamatrix.ScriptRunner compatibility service;

• keep the standalone SalamatrixAI.SPL menu extension as the sole native

owner of the localized chat-opening command;

• extend the source-contract regression test to assert that Automation no

longer publishes or dispatches an AI menu command while the standalone AI command still calls ShowChat;

• rebuild the affected Debug x64 projects and run the regression test in an

isolated verification output; no Salamander process was started or controlled.

The thirty-ninth code slice is implemented and verified:

• make the standalone SalamatrixAI.SPL menu caption explicitly

Ask Salamatrix AI... in its own resource and use the same text as a bounded fallback when localized resource lookup returns NULL or empty;

• strengthen the source-contract regression test to validate the standalone

resource text, fallback, BuildMenu command insertion, and the existing ExecuteMenuItem to ShowChat path;

• rebuild SalamatrixAI.SPL Debug x64 into

build\verification\ask-ai-menu-ai-final2 and rerun the regression test; no Salamander process was started or controlled.

The fortieth code slice is implemented and verified:

• synchronize the shared Salamatrix native UI with Salamander's explicit

Windows Dark Mode (experimental) configuration and current scheme colors at provider startup and when WM_SETTINGCHANGE/WM_THEMECHANGED arrives;

• apply the existing win32-darkmodelib path to Salamatrix dialog trees,

controls, title bars, and Unicode message boxes without changing any public SDK/vtable prefix;

• give SalamatrixAI the shared src/res/sal_r.ico artwork, conventional

versinfo.rh2/versinfo.rc2 metadata, and the common project homepage; apply the same homepage to all four independent runtime .SPL providers;

• add source-contract coverage and third-party attribution, then build the

Salamatrix Framework, SalamatrixAI, and all four runtime providers into isolated build\verification\ai-darkmode-* and build\verification\metadata-* outputs. The source regression test and all six Debug x64 builds passed; no Salamander process was started or controlled.

The forty-first code slice is implemented and verified:

• audit commit 4a2bca820dcd238abc3855f900d4a92ab37acc9f and restore the

removed AI assistant workflow in the standalone SalamatrixAI.SPL plugin: panel context, localized prompts/status text, temporary script creation, bounded repair/refinement, clipboard preview, save/run actions, and runtime extension-package export;

• keep Automation independent as the legacy JavaScript/VBScript plugin and

shared runtime client: its removed AI command, resources, helpers, and dispatch path remain absent while its Salamatrix.AI and Salamatrix.ScriptRunner compatibility services remain available;

• add the append-only IScriptRunner::RefreshExtensions method so the AI

package export requests a refresh through the shared service and the existing Plugin Manager can discover the package without a new Extension Manager or runtime installer;

• add source-contract coverage for the complete migration and rebuild both

affected Debug x64 projects into isolated build\verification\ai-restored-logic-final and build\verification\automation-restored-logic-final outputs. The source regression test and both builds passed; no Salamander process was started or controlled.

The forty-second code slice is implemented and verified:

• diagnose the shutdown crash from ACE187E9236B11B2-AS50SAM0.13X64-260726-101224.TXT:

a runtime provider called UnregisterAdapter through a stale borrowed Salamatrix.Runtime broker after the Framework provider had already been unloaded;

• add an unload guard to all four standalone runtime providers. Each provider

queries the current SALAMATRIX_SERVICE_RUNTIME, compares it with the registration's original service pointer, and only then calls Unregister(). If the service is gone or replaced, it clears local registration state without dereferencing the stale broker;

• extend the source-contract regression test for JavaScript, Python,

PowerShell, and PHP and rebuild all four Debug x64 .SPL providers into isolated build\verification\shutdown-guard-* outputs. The regression test and all four builds passed; no Salamander process was started or controlled.

The forty-third code slice is implemented and verified:

• make salamatrix_runtime.h self-contained for its dark-mode API calls by

including the shared darkmode.h declarations directly;

• preserve projects that define USE_DARKMODELIB=1 and provide a fallback of

0 for consumers that only use the header and do not inherit Salamatrix's precompiled header;

• rebuild the demoplug Debug x64 plugin into isolated

build\verification\demoplug-darkmode-header; compilation and linking passed. No Salamander process was started or controlled.

The forty-fourth code slice is implemented and verified:

• wire SalamatrixAI's existing IDI_PLUGINICON resource to numeric ID 1030,

load it during CPluginInterface::Connect, and publish it through the normal Plugin Manager icon-list callbacks;

• keep the shared src/res/sal_r.ico icon for Salamatrix Framework and

SalamatrixAI only; remove it from the JavaScript, Python, PowerShell, and PHP runtime resource scripts so those providers retain the default Plugin Manager icon;

• extend the source-contract test for numeric icon identity, AI icon-list

registration, and default runtime icon scope; rebuild SalamatrixAI and all four runtimes into isolated build\verification\icon-scope-* outputs. The test and all five builds passed; no Salamander process was started or controlled.

The forty-fifth code slice is implemented and verified:

• initialize SalamanderGUI from CSalamanderPluginEntryAbstract in

SalamatrixAI.SPL before the normal Plugin Manager connect lifecycle; the existing Connect() icon-list registration can therefore publish src/res/sal_r.ico instead of silently taking the null-GUI path;

• make the standalone AI dynamic menu command use the public

MENU_SKILLLEVEL_ALL contract and report CmdOpenAssistant as enabled even while the optional Salamatrix Framework services are still being resolved; execution retains lazy service lookup and the existing user-facing fallback when the Framework is unavailable, so Plugin Manager keyboard shortcuts dispatch the same command as the menu item;

• extend the source-contract regression test for entry GUI initialization,

all-skill-level menu insertion, and enabled command state; rebuild the SalamatrixAI.SPL Debug x64 artifact in isolated build\verification\ai-menu-icon-fix output. The regression test and build passed; no Salamander process was started or controlled.