SpikeForge Dashboard gives the experiment a desktop home

Capsize Games released SpikeForge Dashboard 0.2.5 and 0.2.6, a React and TypeScript desktop interface for experiments built with the SpikeForge spiking-neural-network toolkit. The releases focused on packaging, adding a desktop bundle, smoke checks and a release checklist so the shipped archive is verified alongside the source tree. The dashboard is positioned as a visual surface for viewing a run, its loaded data and the configuration that produced it, not a replacement for Python.

SpikeForge Dashboard https://github.com/Capsize-Games/spikeforge-dashboard is the desktop interface for experiments made with the SpikeForge spiking-neural-network toolkit. Its desktop builds moved through 0.2.5 and 0.2.6 after a run of smaller releases that established the packaging path. The dashboard exists for the part of the work that is awkward in a terminal: looking at an experiment, checking what was loaded, and keeping the result close to the configuration that produced it. It is a React and TypeScript dashboard packaged as a desktop application and backed by the SpikeForge packages. The app is not a replacement for Python. It is a visual surface for the same experiment. The release work focused on the boundary between source code and the thing a user downloads. The build now has a package path, a desktop bundle, smoke checks and a small release checklist. The source tree can be green while the archive has the wrong files, the wrong path or a missing licence. The packaged archive is part of the test target. The source is public in the SpikeForge Dashboard repository https://github.com/Capsize-Games/spikeforge-dashboard . The project site is spikeforge.net https://spikeforge.net/ , and the desktop build is available through Capsize Games on itch.io https://capsizegames.itch.io/spikeforge-desktop . I wanted the app to feel like a place for the experiment rather than a launcher with a screenshot attached. That means the current run, the loaded data and the path back to the source should stay near each other. It also means the release archive gets opened and checked as an archive, not only built as a side effect of the CI job. Install the desktop build and open one of the small examples from the core toolkit. Keep the experiment short, then compare the training and test views. If the result is worth keeping, move the configuration into the repository or the model hub instead of leaving it inside a screenshot. This is the pattern I want from the desktop projects: a finished surface, a public download and a clear route back to the code. The next release can improve the surface without hiding how the experiment works. The broader four-week release story https://capsize.online/devlog/2026/09/20/four-weeks-of-building-in-public/ covers the other software, games and sites that moved at the same time.