Components

The task pipeline

Keeps an external task service in step with the vault's task ledger. The vault is the truth; the service is a mirror.

The pipeline exists to answer one question: where does a task live when you are not in a session?

The vault’s task ledger is a file. A file is excellent at being the record and poor at being reachable from a phone on a train. So a second surface is needed — and the moment a second surface exists, the question is which of the two is right when they disagree.

The vault is the truth. The service is a mirror.

The ledger is the source. The external service holds a copy of it, and the copy is allowed to be behind. It is never allowed to be the thing that is consulted when the two differ.

This is not a preference. It follows from what each one can hold: the ledger sits beside the meeting note that produced the task, in a folder that also carries the project’s configuration and its history. A task service holds a title and a date. Reconciling toward the poorer representation loses the part that made the task meaningful.

Which is why only one of the pipeline’s scripts reaches the external service at all. The rest read and write inside the vault and never leave it. A component whose network surface is one file out of several is a component whose failure modes are small.

What it reads and writes

The contract declares this, and the table below is rendered from it rather than described here — the same rule the framework applies to itself.

Naming the service

The contract says an external task service, and it is right to: the pipeline does not care which one, and a reader running a different tracker is not running a different design.

This page names Todoist because a reader cannot evaluate a mirror without knowing what is being mirrored, and because naming it costs nothing — it is a commercial product anyone can look up. The rule this site follows is that a thing is named when a reader could go and get it, and left generic when it exists only on one person’s machines.

This part is not published

The pipeline is a set of local scripts and they are not in a public repository. The role is described here because the manual describes the whole system, not only the parts a reader can install.

Two consequences worth stating plainly. The pattern transfers even though the code does not: a ledger in the vault, one script that mirrors outward, and a rule about which side wins. And the credential stays where the script is — the dashboard that marks a task finished does so by writing in the ledger, not by calling the service, and therefore holds no API key of its own.

From ecosystem.yaml, contract 41 · core-skills 1.89.4 · read at build 2026-10-08