v1.2.0

Tools

• Host tools: out-of-process applications in any language, described by a tool.toml manifest, with an optional browser UI, an optional supervised background service, versioned APIs, dependencies on other tools, and requested host permissions. See the tool protocol and authoring guide.
• Distinguish independently useful background services from on-demand UI/CLI backends with manifest service.role; show only public UI/SERVICE/CLI interfaces and hide backend lifecycle controls. Add persisted Start with vosu overrides in tool Details, Settings, the dashboard API and vosux --autostart <id> on|off|default; launch eligible services dependencies-first after listeners bind.
• Show usable UI/CLI tools as Ready on their cards, or Working while their native backend starts or runs, rather than exposing idle backend process state. Background-service and error labels, API status values, and Details process status stay unchanged.
• Serve tools on the overlay listener under the reserved /tools/ prefix: UIs at /tools/<id>/, service APIs at /tools/<id>/api/. No overlay can be installed or served as tools. Read routes are open to overlays; writes need a dependent tool's per-launch token or a session minted by the dashboard's Open action. That session lives only in the opened page's memory, never in browser storage overlays can read, so reloading a tool page makes it read-only until it is opened again.
• Supervise services: loopback readiness handshake, health checks, on-demand start and idle stop, crash restart with backoff, dependency-first start, bounded logs, and orderly shutdown; children are killed with vosu on Linux and Windows.
• Respect voluntary status-0 service exits as stopped (exited), without crash counting or automatic restart, including always services; manual start and the next vosu launch can start them again.
• Run a tool from any directory with vosu --tool <directory>; manifests reload live and development services restart when their executable changes.
• User tools in <data dir>/tools/<id>/ require explicit trust on the dashboard. Official tools and their SDK now live separately in vosu-tools; vosu embeds none.
• Add a Python reference tool and a JSON Schema for tool.toml.
• Add Create a tool: a guided isolated-development-to-catalog tutorial, backed by the Python example's live UI, settings, selected-map context, optional read integration, CLI and package builder. Document the consumer's catalog/ZIP format in the protocol and separate the authoring reference from the tutorial.
• Share one 18-LAB design system with tools: /tools/_host/v1/theme.css serves the dashboard's tokens plus documented v- components (app shell with a fixed top bar, panels, buttons, fields, themed select, file picker, toggles, segmented control, tabs, table, stat readout, meter, status dot and badge, help hover, empty state, toast, drawer), with a live reference at /tools/_host/v1/design and rules in the design guide. The bridge applies the dashboard's mode as data-theme and exposes it as vosu.colorScheme.
• Add an optional manifest banner (3:1) beside icon, served at /tools/<id>/_banner and reported as ToolView banner_url; catalog tool and overlay entries may carry HTTPS icon_url and banner_url. Serve icons and banners in every tool status, sandboxed against script.
• Add GET /tools/<id>/_settings and the bridge's vosu.settings() so tool UIs read their effective settings. password settings are write-only from the dashboard (never returned; blank keeps, Clear removes) and never included in that route; only the tool's service reads them through the host API.
• Make the bridge's vosu.subscribe() survive vosu restarts and network drops: it reconnects with capped, jittered exponential backoff, re-sends the subscription, keeps a single socket, stops on unsubscribe, and reports "connecting"/"open"/"closed" through an optional onStatus callback.

Official catalog

• Install, update, and uninstall official tools from the Tools page's Available section or vosux --install, --update, and --uninstall with an explicit keep/remove-data choice.
• Verify HTTPS destinations, redirects, package SHA-256 and size, ZIP safety, and manifest identity before atomic installation; install dependencies first and restart running services after updates. Surface update badges and job progress.
• Add selected-instance osu_dir and current skin name/folder to the permission-filtered tool host context (lazer folders remain null).
• Add GET /tools/_host/v1/overlays (service or CLI token, context permission): the installed overlays that have an index.html, with id, name, dashboard nickname and alias, metadata author/version/resolution and absolute folder, so tools can load a local overlay. Read-only; settings values are never included.
• Serve the current imported lazer skin through /files/skin/<path> with case-insensitive filename lookup and confined content-addressed storage. Add public /files/skin/ metadata and tool-context availability/built-in identity so tools can explain built-in fallback.
• Add a cached, bounded skin file index to /files/skin/ as entries and truncated, retaining its existing files boolean. Stable entries report size/mtime and lazer entries report size/store hash; built-ins have no entries. Resolve stable skin filenames case-insensitively with exact-path priority and deterministic collisions, including under Wine/Linux.
• Add strong ETags, Last-Modified/no-cache revalidation, bodyless conditional 304s and HEAD support to current skin and beatmap file routes without changing GET bodies or byte-range behaviour.
• Add v2 renderer state: own-gameplay/replay/spectator source, authoritative lazer track rate/running state, fractional mania scroll speed and base scroll time, timing-based note colours, visual toggles and viewport scaling. Expose imported lazer skin families and stable per-map mania speed when readable. Preserve unset random seeds as null instead of exposing uninitialized storage.
• Generate lazer's local configuration enum keys per client version, fixing stale mappings for beatmap skins/colours, scoring display, replay controls and song-select settings. Clear stale replay/spectator flags when entering local play.
• Publish beatmap selection changes to current-file routes and compatibility APIs before notifying selected-field subscribers, even between regular polling ticks. A new subscribed checksum no longer briefly selects the previous map's file.
• Expose lazer's current combo-colour normalisation amount at /settings/visual/comboColourNormalisation using its generated version-specific configuration key; report null on stable.
• Stop slow selected-field subscriptions (ruleset/settings, client, skin folders and beatmap metadata) from forcing both memory readers to 1 kHz. Fast fields request only their producing lane, gameplay-only demand sleeps outside play, and live song-select time can still request the precise clock. Subscriber frame debounce and latest-only delivery are unchanged.
• Keep selected-field reader demand incrementally instead of locking every subscriber on each publication. Share immutable settings graphs across snapshots and copy only changed settings, eliminating repeated allocation and teardown without changing API payloads.
• Manage ordered catalog sources (owner/repo[@tag] or HTTPS catalog URLs) in Settings, with enable/disable, add/remove/reorder and per-source fetch results. Merge tools and overlays across sources; show provenance and shadowed duplicates. Default to 18-lab-dev/vosu-tools and 18-lab-dev/vosulay; only these exact source identities grant automatic tool trust. Overlays remain available through the existing tosu community catalog.
• Move live repository, updater, packaging, and schema links to the 18-LAB organization. At startup, idempotently migrate the two former official source identities and remove the unavailable private overlay source only from untouched old default lists. Customized lists retain their entries, ordering, and enabled flags; a retained former private overlay source is unreachable and can be removed in Settings / Catalog sources.
• License project-authored code under the 18-LAB copyright holder, retaining years, tosu and other third-party notices, and sxlvia's branding/artwork attribution.
• Install/update catalog-source overlays alongside the existing community catalog, retaining settings and offering required tools; keep the existing overlay disclosure and deletion flow. Add vosux --sources; CLI install/update/uninstall remain tool-only.
• Offer vosulay as an optional official tool supervised out-of-process; retain its standalone mode and keep in-game rendering outside the daemon.

Dashboard

• Redesign every page as a calm app shell in the 18-LAB system with Workstation (dark) and Drafting (light) modes, embedded Barlow and IBM Plex Mono fonts, and a restyled diagnostics report. Text, controls and dialogs use the tool design system's sizes (16 px root, 14 px body, 32 px controls); headings, labels and buttons are sentence case, booleans are switches, and the wordmark, tabs and header buttons share one baseline with the current tab's underline on the header rule. Sheet labels, card numbers, crop marks and the title-block footer are gone; the affiliation notice, version and source live in Settings › About.
• Add a Tools page with status, dependencies, permissions, API routes, storage, logs, lifecycle and trust actions, and tool settings that reuse the overlay settings editor. Cards stay compact (icon, name, version, status and primary actions, with a short banner strip); description, facts, routes and maintenance actions open in a Details drawer.
• Show tool and catalog-overlay icons and banners on installed and Available cards, falling back to initials; list each interface (UI, Service, CLI) as its own chip; give cards in a row equal heights with their actions aligned at the bottom. The Tools page's Available section lists only tools that are not installed or have an update; Update and Uninstall for installed tools are on the card and in Details, with permissions, routes and the command under "Developer details". A disabled tool's card leads with Enable. Catalog failures read as one line with Retry and per-source details.
• Make overlay previews transparent in both modes. Each installed preview frame takes the colour scheme its overlay declares, because browsers paint an opaque backdrop behind an embedded page whose scheme differs from its frame's. Available previews sit on the neutral sheet colour.
• Keep the "About community overlays" link under the search field after the notice is dismissed.
• Edit tool settings from the tool's card in the same dialog overlays use; tools without settings.json show no Settings action.
• Give installed overlays a dashboard nickname and a short URL alias (/acc/ redirecting to the overlay's folder) from the card's ⋯ menu; aliases are validated against vosu's routes, folders, and other aliases and persist in overlay-names.json.
• Use the width of large screens on Settings: a sticky section rail and runtime groups in two columns from 1440 px (three from 2400 px).
• One unreadable overlay folder (a bad metadata.txt or settings schema) is an error card with Open folder and Delete instead of emptying the Overlays page; a folder vosu cannot list at all shows its own error, never the empty state. The Overlays page renders from local files without waiting for the catalog; update badges and Update buttons come from the last catalog fetch.
• Network changes: after Apply the dashboard lands on the new address with a bar under the header, Keep focused, Revert now and the seconds left; a revert, timed or chosen, is reported on the page. Settings rows show "Saved" or the error beside the field, and an absolute overlays folder that does not exist is rejected. The Settings save state shares the title row with the search field (and moves into the pinned header's status strip once the title row is scrolled away, never over content): empty at rest, a brief "Saved" or "Network settings kept" that fades, and "Unsaved changes" or errors while they apply, including network fields waiting for Apply.
• Keyboard and screen readers: every checkbox and switch shows a focus ring; cards have one Tab stop per action (pin, menu, URL) with arrow keys between cards; Enlarge, Open in browser and Copy resolution are menu items; focus moves to a sensible place after deleting or reordering; only short summaries are announced; errors stay until dismissed. Destructive confirmations use a danger button, and dialogs with unsaved input ask before discarding it.
• The enlarged preview scales small overlays up to fill the dialog; the connected chip no longer counts the dashboard's own previews (their pages tag the WebSockets they open, since browsers send no Referer on a handshake); every search matches all of its words; the Available page lists catalog-source overlays (official first, with a source badge) above the community catalog in the same card and filters both; the update notice can be put off with "Later" and stays one click away in the status strip; pages that don't exist show a styled 404 page with a link back to the dashboard on both listeners, while scripts and API clients still get the plain Not Found body.
• An invalid settings.schema.toml error names the file and the setting at fault. Switching or managing a settings profile and removing a command row ask before discarding unsaved edits. Installed cards offer Update once (no repeated badge), and the version the update offers is named as soon as the catalog arrives.

Brand

• vosu is now an 18-LAB product. The signal V keeps its shape in 18-LAB colours (amber or blueprint line, signal-coloured node) with the 1.x monoline wordmark and an 18-LAB endorsement; light and dark README banners and a 1280×640 social preview are new. The mark is used across the dashboard header, diagnostics report, favicon, Windows executable and tray icon, Linux tray and packages, with pixel-fitted 16 and 24 px versions. Rules are in branding.
• Linux packages install hicolor icons from 16 to 512 px plus the scalable icon, and the tray offers 16–64 px pixmaps instead of one scaled 64 px image. The rasters are committed (rendered by scripts/render-brand.py), so packaging no longer needs ImageMagick. Packages name 18-LAB as vendor.

Known limitations

• Live osu!lazer on Windows was not exercised for this release: lazer itself would not start on the Windows test machine (a native crash before vosu was involved). Windows lazer support passed its native tests against recorded memory, but reading a running lazer client, lazer's current-skin files, the tools' lazer features and vosulay inside lazer were verified only on Linux.

Code signing policy

SignPath signing is not active yet, so this release's Windows executable is unsigned. See the code signing policy.

Privacy policy · Security and installation disclosure