Roadmap

The single source of truth for what Iblis intends to build, in what order, and why. Rendered live on https://iblis.meiuxmeiux.com/roadmap. Update through tracked main commits; never duplicate this content into the site.

Granularity rule: each item is a verifiable outcome. If it would not fit in a single pull-request description, split it. Anything past v1.0 is intent, not commitment.

Status words used below:

• built, awaiting acceptance: the code is shipped in the app, but its end-to-end proof on a real Windows 11 GPU machine has not been recorded yet.
• designed: a written plan exists in the repository; no code yet.
• planned: agreed direction, plan still to be written.
• deferred: deliberately parked, with the reason.

Where things stand (2026-09-27)

• Public beta. Shell 0.2.0-alpha.59 (signed auto-updates; carries the alpha.58 song idea + lyrics writing and Local model support, plus the playback pause/seek fix), ACE-Step engine pack 0.1.4, ACE-Step Training pack 0.1.1. The installer, update feed, and /download are synchronized.
• Iblis is open source: the desktop app is GPL-3.0-or-later, the plugin SDK Apache-2.0, first-party plugins MIT, at https://github.com/MeiuxMeiux/Open-Iblis.
• Everything local is free with no account: generation, training, library, playback, analysis, skins, plugins. A product key only unlocks the hosted community services (Styles publishing and downloads, uploads).
• Shipped and in daily use: text-to-music generation with a restart-safe queue, the Library with waveforms and provenance, four built-in BPM/key detectors, live skins with an in-app token editor, signed hot-swappable plugins with rollback, local LoRA training with a community Styles browser, Cloud Providers (bring your own key for song ideas and lyric help), opt-in diagnostics, and the multi-engine registry with a second (fixture) engine.
• Bugs and feature requests: GitHub issues, or the website's feedback form without an account. Every triaged report and its status is on the public board; accepted requests are folded into this file.

What is not built yet

Ordered roughly by when we expect to work on it. Items marked "awaiting acceptance" are gated on a maintainer run on real Windows hardware, not on more code.

1. Acceptance runs that unblock the next steps

• Training end to end (built, awaiting acceptance): train a Style from a folder of your own songs on an 8 GB GPU, upload it, find it in Styles, generate with it, all through the installed app. The run also calibrates the preflight VRAM and time estimates, which are upstream figures today.
• Audible continuity probe for Extend (built, awaiting acceptance): the engine can extend a take (proved by duration); the listen test that decides whether the join is musically acceptable has not been recorded. Extend as a user feature waits on it.
• Multi-engine proof (built, awaiting acceptance): install a second engine from the catalog, pick it in Create, generate, and see the exact engine recorded in the Library.
• Windows code signing (planned): until a certificate is in place, SmartScreen warns about an unknown publisher on first install. Signing also lets the release job publish the source tree hash it built from.

2. Engines

• ACE-Step engine pack 0.1.5 (built, awaiting acceptance): a newer acestep.cpp pin with batched decoding and loader validation, plus the XL Turbo model as an experimental profile. Ships to the catalog after a stability run and an A/B listen against 0.1.4.
• Run without an NVIDIA card (planned): ACE-Step engine packs built for Vulkan (AMD and Intel GPUs) and for CPU only, from the same pinned source. CPU is slow and the picker says how slow, with a measured number.
• macOS (researching): Apple Silicon is plausible for generation through Metal; training is the hard part. A findings note comes before any promise.
• Second real engine, audio.cpp pack (designed): a v2-protocol engine pack around the Apache-2.0 audio.cpp server, first with ACE-Step XL Turbo so it can be compared against the current pack on the same prompts. Zero shell changes expected; new descriptor control kinds would ship as a shell alpha.
• A song model with vocals for the 8 GB tier (planned): the first candidate is an Apache-2.0 model that sings, packaged on audio.cpp after the XL Turbo comparison lands.
• Opt-in high-VRAM quality tier (planned): a larger model on the audio.cpp pack behind an honest 16 GB VRAM gate. Needs a tester with a 16 GB card; it is not accepted on 8 GB hardware.
• Stable Audio as a contract proof (designed): pin, license review, no-Python Windows runtime, and CPU measurements before any UI. It may turn out to be only a test of the engine contract, not a shipping engine.
• Engines load on demand and unload when something else needs the GPU (designed): today every installed engine sidecar starts at launch.
• Native v2 adapter for ACE-Step (designed): ACE currently speaks contract v2 through a compatibility driver; a native adapter retires it.
• Vocal and accompaniment as sibling outputs (planned): for engines that can render them separately, store both against one take.
• Sequential orchestration (designed): one host-owned chain generate -> analyze or split -> repair or extend -> render -> re-analyze with deterministic restart, retry, and cancel at every node, and lineage for every intermediate. No node editor.

3. Create: controlled iterative generation

• Extend (designed, gated on the audible probe): a Library action on engine-generated takes to continue a track before or after by N seconds. The derivative records its parent, the operation, and a reproducible request; the original stays immutable.
• Edit and remix (designed): region inpainting over the waveform, and remix with a strength slider. Each is its own slice with its own Windows listen gate.
• Imported-audio conditioning (designed): use your own recording as the source for Extend or remix, with an explicit rights acknowledgement. Source audio never leaves the machine.
• Reusable creation presets (planned): named prompt, lyrics, settings, and style selections with provenance and local export and import.
• Stems, lego, and complete task types (deferred): they need the base non-turbo model, which is a VRAM and model-pack question before any UI.
• Section replacement, two-reference blending, and voice features (deferred): each needs its own model, rights review, and listen gate.
• Local taste ranker (designed): a small on-device preference model that orders takes by what you have liked before. It never trains on anyone else's choices.
• Blending two Styles at once (deferred): the pinned engine loads one adapter at a time; the UI says so rather than pretending.

4. Library and analysis

• BPM and key lifecycle (planned): detected values show on rows, in search, in the sort menu, as badges in the player and track detail, and a track with no detection gets an Analyze button (alpha.57). Still to do: filters, consented backfill for tracks made before alpha.37, re-analysis after a provider change, carrying the labels into Training datasets, and picking a commercially clear default detector after a native comparison on a rights-cleared corpus.
• Derived-file store (designed): processor protocol v2 with staged promotion, retry, recovery, cancel, and delete for every artifact a processor produces (stems, covers, spectral data), with path and media validation.
• Frequency-coloured waveforms (designed): a bounded spectral sidecar and low, mid, high skin tokens. Today's amplitude peaks cannot do this.
• Cover art (designed): a signed image-generation plugin, validated image intake owned by the Library, editable cover prompt, retry and cancel, and manual cover replacement. Local by default; a cloud cover action is a separately disclosed Cloud Providers capability.
• Stem splitting (built, awaiting acceptance): track detail splits a track into vocals, drums, bass, and other (or six stems) with a signed, Windows-native Demucs processor, three model choices, cancellable jobs, per-stem hashes and provenance, BPM and key measured on each stem, synced solo and mute, reveal, drag-out, and export (shell alpha.57). The three processor packs reach Plugins after a GPU stability run on Windows. Opt-in automatic post-generation splitting only after cost and stability are measured.
• Pluggable waveform visualizer (planned): the first visualizer that ships as a plugin rather than shell code. Split-stereo, spectrogram, and oscilloscope styles are product direction, not commitments.
• Plugin UI slots (planned): the Library and other views reserve slot names in the SDK today; nothing loads a plugin's panel into them yet.
• Non-destructive trim, normalize, and master (designed): each as a processor that writes a derived file and leaves the original untouched.
• Library as a workspace (planned): favorites, tags, playlists, bulk selection and actions, saved filters, nested and reorderable folders after a keyboard usability pass, a lineage and takes view (original, derivatives, selected take, notes), a non-destructive archive with restore, and local projects that group tracks, stems, notes, and export settings.

5. Training and Styles

• Training primer in the app (planned): what you provide, what each stage does, what to expect on 8 GB, and how to read progress.
• Structured stage progress (planned): current stage, work done and remaining when known, elapsed time, blocked state, and calm failure and retry guidance for both Training and Generation, instead of a generic wait.
• First-class Training and Generation lock (planned): both views name the active owner, say what is blocked and why, and link to the running job.
• Training-time captions (planned): an audio-understanding model writes captions for training clips once the pack's caption format is fixed.
• Training pack 0.1.2 (built, awaiting release): carries the trainer's stricter adapter-file validation; the multi-gigabyte pack should be assembled and published by the release pipeline rather than by hand.
• Training data-correctness pass (designed): vocal versus instrumental labelling, skipping stems for Groove-only runs, Texture and Groove as separate community downloads, a versioned adapter descriptor, and structured adapter provenance.
• Dataset-size guidance (planned): warn below eight or above fifty tracks before a run starts.
• Per-engine Styles (designed): Style folders and training recipes per engine, and a "Train for this engine" entry once a second engine ships.
• Preview clips for Styles (planned): short locally rendered examples so you can hear a Style before generating with it.

6. Plugins, SDK, and skins

• Plugin and skin scaffolding (planned): just plugin-new and just skin-new are stubs today; they should produce a manifest, folder layout, and tests that pass the SDK validator.
• Four more built-in skins (planned): pink and purple in dark and light, a neon-green terminal skin, and one more with real personality. Before that, an audit of the skin token contract against every control added since the first four skins.
• Community-authored skins (deferred): opening skin authoring waits until the token vocabulary covers every element type that will exist, so a skin made today does not break when a new control ships.
• Visual-system sweep (planned): icons on every main view and section header, semantic icon and colour variants on status badges, keyboard focus and contrast pass on Library and Styles controls, narrow-window layout.
• Deliberate cloud actions (designed): key management shipped; no content request exists yet. Song ideas and lyrics first, then manual cover generation. Every billable request names the provider and model, shows price information, needs an explicit confirmation, and records only redacted local provenance.
• Plugin SDK on npm (planned, after the repository is public): the @iblis/plugin-sdk package with its generated reference.
• Relicensed catalog plugins (built, awaiting release): the OpenRouter and ImageRouter adapters and the Nord skin are MIT in source; the catalog publish ships with engine pack 0.1.5.

7. Installer, updates, and releases

• First-run "good defaults" flow (designed): a one-screen setup that probes the GPU, recommends the engine pack, and gets a new user from installer to first song without decisions they cannot take back. Today Create offers the engine install; the guided path around it is not built. An Advanced Setup path (paths, engine choice, optional plugins, skin preview) and a short tour under Settings are designed alongside it.
• Install updates on next launch (built, held): switched on after the Electron 44 releases have soaked on Windows for a while.
• Diagnostics phase B (designed): crash capture, log rotation, and a daily size cap on what an opted-in install can send. Still off by default.
• Verifiable builds (planned): publish the exported source tree hash with each release so anyone can match an official version to a public commit. Signed release files and build attestations follow once the repository is public; reproducible installer bytes are longer-term.
• Privacy statement shipped inside the installer (planned): the website's privacy page, bundled and shown in Settings.

8. Website and community services

• Public feedback board (shipped 2026-09-25): triaged reports appear on /board with a status and a public note, any report can be checked by its reference, and reporters who leave an address can opt in to one email per status change.
• Public repository housekeeping (planned): branch protection, required checks, secret scanning, and the contributor sync from public pull requests into releases are exercised for the first time with real outside contributions. An outside review of the exported code and a short legal review of the trademark and license notices are on the same list.
• Roadmap fed from triage (designed): accepted feedback and issues update this page without a hand edit.
• Plugin submission on the website (deferred): until there are outside plugins to submit, proposals go through GitHub issues.
• Hosted services hardening (ongoing): a handful of low and medium findings from the 2026-09-24 pre-open-source audit remain open, none of them user-facing. They are worked through in order between feature sessions and noted in the changelog as they close.

9. v1.0.0 exit criteria

• The first-run flow above is shipped.
• Extend, cover art, and stem splitting each pass their Windows gate.
• The privacy statement ships inside the installer.
• Windows code signing is in place.
• The maintainer has generated fifty or more tracks across five or more genres and is satisfied with the result.

10. Beyond v1.0 (intent, not commitment)

• Arrangement timeline over stems: clip placement, fades, gain, mute and solo, a BPM grid, take lanes, autosaved versions, undo and redo, with rendering as a supervised processor plugin.
• Export presets for full mix, selected range, individual stems, and a portable project bundle. MIDI only once a transcription provider has measured accuracy and clear redistribution terms.
• Node-based builder as an optional plugin.
• File-explorer plugin, DAW drag-and-drop, sample-pack pipeline, and an auto-mastering chain, each after the artifact and project paths make them useful.
• Share-link plugin, and a credit or cloud-boost system, deliberately last.
• Operator-panel extras: an upload interface for catalog assets and a secrets vault.

Shipped so far

Each phase's design and acceptance record lives in the linked document.

• Phase 0, foundation. Repository, charter, this site.
• Phase 1, shell skeleton. Electron plus Svelte 5 app with Mica chrome, custom titlebar, and self-update from the release feed.
• Phase 2, plugin host. Ed25519-signed catalog, SHA-256-verified downloads, versioned plugin folders with atomic pointer and instant rollback, sidecar supervision with hot swap.
• Phase 3, ACE-Step engine. Native CUDA engine pack; the host-stability investigation and its fix are in docs/feature/engine-stability.md.
• Phase 4, Library foundation. Atomic library store, folders, prompts, app-wide playback, byte-correct WAV serving, waveform peaks, provenance, the serial generation queue with pause, reorder, cancel, and restart recovery, blind A/B comparison, and automatic BPM/key analysis with four license-labeled detectors (alpha.37). Remaining work is in section 4 above; the plan is docs/phase-4-plan.md.
• Phase 6, skins. Token contract, four built-in skins, live picker, the in-app token editor with per-skin overrides, .iblis-skin export and import, and skins as signed plugins.
• Phase 7, Training and community Styles. Local stems, tagging, dataset build, and LoRA training through an opt-in signed pack; resumable upload; the Styles section with a community browser; the Create style picker. Plan: docs/training/00-overview.md. Acceptance run pending, see section 1.
• Phase 8, product keys and operator panel. Hardware-bound short-lived leases for the hosted services, a passkey-secured operator panel, and end-to-end observable licensing events. Design: docs/admin/00-overview.md.
• Engine v2 platform, slices 4A to 4D. Neutral engine-provider interface with the ACE dialect in a compatibility driver, strict contract-v2 parsers with hostile fixtures, a fixture engine in the catalog, and capability-driven Create controls rendered from each engine's signed descriptor. Packet: docs/planning/2026-07-21-audio-platform/.
• Cloud Providers. Bring-your-own-key adapters for song ideas and lyric help, with capability disclosure before any use.
• Open source (2026-09-24). Electron 44 security baseline, no shared secrets in the app, free local use with no key, the public export with its scrub and secret gates, the feedback form, and the Source page.