The workflow engine

Making a podcast is a sequence of activities, and Podlibre models that sequence rather than presenting a drawer of tools. This is the part of the application the project description calls the core system.

Activities

An activity is one thing a podcaster does.

Field	Meaning
id	Stable identifier. Keys its strings and its completion marks, so it never changes once released.
scope	application, show, or episode — which level of the work it belongs to.
phase	Which group it sits in, so a long workflow stays readable.
provides	Which plugin serves it. An activity with none is still shown, greyed.
complete	A test answering has this been done? from the data itself.

Completion is derived, never stored as a flag. A flag can lie: a file is deleted, an edit is undone, a show is copied from another machine. Asking the data is slower and always true. A user may still mark a step done by hand, for the activities that leave no trace.

Workflows

A workflow is an ordered list of activity ids with a name. Podlibre ships several — a full one that follows the project description's diagram, and a short one for a podcaster who records clean and publishes fast. The user edits them, and each show remembers which it uses.

Plugins contribute

A plugin declares activities in its manifest. An activity whose id matches one Podlibre ships replaces it, which is how a third party takes over a step — serving transcribe with a different engine, say — rather than adding a competing entry beside it.

Commands and the palette

Every action in Podlibre is a command: an id, a title, the scope it makes sense in, and what it does. Menus, keyboard shortcuts and the command palette are three views of one registry, so a plugin that adds a command gets all three at once, and nothing is reachable by one route and not another.

The palette searches commands first, then episodes by title across every show, ranked with recency. With a local model enabled, the typed text can be sent to it as a question instead.