Flaclify MMXXVI · № 2
Where this goes · no dates are promised

Five tiers, three done.

First the player reflects what the shell has done, then it drives the shell, then, if ever, a model sits inside the player — and last the whole stack leaves the desk for a device in the pocket. Each tier is a label on the issue tracker and every line below is an issue, so the boxes here follow the tracker and not the other way round. The live list is label:roadmap.

  1. Tier 0

    Files and playlists arrive on their own

    Nothing written into the player's database; the player reads what the shell leaves beside the music.

    Done
    • MPD rescans only the folders flacli filed downloads into.
    • Each synced playlist is stored in MPD under its own name.
    • Bios, wikis and artist pictures kept beside the music are read by the player.
  2. Tier 1

    Flaclify reads flacli state

    Read-only surfaces fed by flacli --compact status, the JSON contract the shell already keeps for agents. Polled only while a job is running.

    Done

    flacli side: a stable status summary for players · one installer for the whole stack

    • Gate every flacli feature on the MPD library being the one flacli files into, and on flacli being on the path with the Nicotine+ bridge reachable.№ 8
    • An incoming indicator: per playlist, the job state and the counts that matter.№ 1
    • Ghost rows in a synced playlist for the tracks it still lacks, greyed, with the reason.№ 2
    • Under an artist's discography, the releases MusicBrainz knows and the library does not.№ 3
  3. Tier 2

    Flaclify drives flacli

    The first write actions from the player into the shell. The shell's rules hold: naming the music is the yes, and Soulseek code stays out of this repository.

    Done

    flacli side: flacli serve, a session D-Bus interface with signals

    • "Get this" on a missing release, and a Get page: search MusicBrainz, tick what is wanted, and flacli fetches it.№ 4
    • Import a playlist from TIDAL, Deezer or YouTube Music: sync in the background, show the totals, queue on the yes.№ 5
    • Review doubtful matches as a dialog, approve or skip per track, with the why the shell computes.№ 6
    • A Requests page: what was asked and not yet landed; a track leaves as it is filed. Never an MPD playlist.
    • A Tidy page: the dry run then Apply on the yes, new arrivals filed, the missing bios, wikis, pictures and covers filled.
    • Transport: spawn the CLI and parse its JSON first; move to D-Bus when polling gets clumsy or Flatpak needs it.№ 7
  4. Tier 3

    An agent inside the player

    Optional, and opened only once Tiers 1 and 2 are in. Claude Code with the flacli plugin, or any MCP client, already is this agent.

    • A chat pane where a model drives flacli from inside Flaclify, with flacli guide as its instructions. First cut in place: a sentence on Ask flacli goes to Claude Code in print mode. A proper pane, and a local model through Ollama, remain.№ 9
  5. Tier 4

    One device

    The stack off the desk: a digital audio player that carries MPD, a Nicotine+ core with the bridge, and flacli. Nothing hosted, nothing bought from anyone, nothing that phones home.

    flacli side: a headless Nicotine+ runtime, aarch64

    • The hardware: an existing player that boots Linux, against a board build with a DAC HAT, a battery and a small touch display. A written comparison and one chosen target.№ 10
    • The device image from one script: MPD, the headless core, flacli serve as a service, the front end on login. The device's storage is the library, synced both ways over the LAN.№ 11
    • Flaclify on the device’s own screen, in a compact layout for a small touch display.№ 12