The Pipelines module models AI agent work as observability (not execution). The Pipeline -> PipelineStep -> PipelineJob hierarchy in PostgreSQL lets you track every stage of agent work: from research, through coding, to wrap-up. Job logs are stored as wiki pages, status propagates upward - a failed job pulls its step and pipeline down. The dashboard refreshes every 15 seconds, and is_stale() flags pipelines stuck for more than 6 hours.
Use the same set of skills in both clients. Install the full plugin or select individual skills through MCP with their required instructions and scripts.
Each pipeline has steps (research, coding, wrap-up), each step has jobs. Status propagates upward - failed job -> failed step -> failed pipeline.
Every job has its own wiki page with a full log (content in MinIO). Pages grouped under the 'pipeline-logi' parent, excluded from RAG - they don't pollute search results.
The pipeline list and detail view refresh every 15 seconds via HTMX. Durations are computed on the fly (finished_at - started_at or now() - started_at for active jobs).
is_stale() flags pipelines in running status with no updates for more than 6 hours. Computed at read time, no cron job needed.
The dashboard is read-only - pipelines are created by skills via MCP, not from the UI. AI agents have full control through 9 dedicated MCP tools.
When LLM Wiki is enabled, finishing a pipeline appends an entry to wiki-log. Best-effort - a pipeline MCP error never blocks the agent's work.
The /monolynx:mutation-check skill runs a mutation testing pass under a hard time budget and turns surviving mutants into tracked work: acceptance criteria on a given ticket, or backlog tickets. The run is reported as a mutation-check job in the wrap-up step. Diff mode reports the survivor count, not a percentage - the score is never a gate.
The skill calls create_pipeline via MCP - a ticket_work pipeline automatically gets 3 steps: research, coding, wrap-up.
create_pipeline_job registers a new job in a step (e.g. 'Source code analysis' in the coding step). Status: pending -> running.
append_job_log appends markdown to the job's wiki page. Each call adds another section - the complete history of agent work.
update_pipeline_job(status='success'/'failure') closes the job, sets finished_at, and propagates status up to the step and pipeline.
Pipeline view with step columns and job cards. Statuses, durations, and links to wiki logs - everything in real time.
Agent calls finish_pipeline when done. Final status aggregated from steps if not provided. Optional wiki-log entry when LLM Wiki is enabled.
9 MCP tools for full observability of agent work - creating pipelines, reporting jobs, appending logs, and closing out. All operations are best-effort - a pipeline error never blocks the agent's work.
Available MCP tools
create_pipeline
Create a pipeline (ticket_work: automatic research/coding/wrap-up steps).
create_pipeline_job
Add a job to a step with name, description, and starting status.
update_pipeline_job
Update job status and summary. Propagates upward: job -> step -> pipeline.
append_job_log
Append markdown to the job's wiki page. Creates the page on first call.
finish_pipeline
Close the pipeline with final status (aggregated from steps if not provided).
list_pipelines
List project pipelines with status and type filters plus pagination.
get_pipeline
Full pipeline tree: steps, jobs, timestamps, statuses, and log links.
get_pipeline_job_log
Fetch the full job log as markdown from the linked wiki page.
clean_pipeline_logs
Delete the wiki pages holding pipeline job logs for a sprint (cleanup after close).
Error tracking
Agile project management
URL health checks
Cron job monitoring
Documentation & RAG search
Dependency graph
Work analytics & PDF export
Cross-project billing & attachments
Personal cross-project scheduling
Work from the terminal
Public blog readable by people and AI