Plugins

The catalogue

Grouped by the kind of planning it serves. One plugin is in the repository today, and this page lists what exists rather than what is intended.

Product and roadmaps

What a plugin cannot do yet

A plugin extends the data model, so an agent can read and write the fields it adds. It cannot contribute tools of its own, which is what would let an agent be told to recompute a statutory deadline or shift a trade by its lead time and have the domain’s rule applied rather than guessed. Until that seam exists, a domain’s rules live in whoever writes the prompt. It is open work in the repository.

What a plugin is allowed to do

Before a plugin runs, the host reads its manifest: id, name, version, the contract range it was built against, the capabilities it asks for, the views it declares, its configuration schema, and the item metadata keys it owns. All of that is static data, because listing, verifying and version-checking a plugin has to work without executing it.

A manifest that does not validate is refused, loudly, and a declaration has to be covered by a capability — a view needs the view capability, its own data needs the data capability. That is what keeps the capability list meaningful: it is the list somebody installing a plugin is shown, so it may not quietly under-report what the plugin does.

The contract is versioned

The host declares an API version and a plugin declares the range it works with. An incompatible pair is refused with a sentence saying which side is behind. A plugin is an artefact that is not rebuilt when the host changes, so without this the first removed field would fail somewhere in the middle of a render, far from its cause.

The host API is asynchronous and serialisable throughout, even though plugins currently run in the application's own realm where a direct call would be cheaper. That is a deliberate cost: an API shaped around shared objects could not be moved behind an iframe or a worker later without rewriting every plugin.

Writing one

The budget for a plugin is one folder, one registration line, and no change to any core file. If a design needs a core change, that is a finding to report rather than a licence to make one — which is how the extension seam stays honest instead of eroding one exception at a time.

The playbook walks through it end to end →

Frequently asked questions

What is a Zeitlines plugin?

A plugin adds what one kind of planning needs on top of items and groups: its own item fields and, where grouping is not enough, a view of its own. It is switched on per timeline as data rather than as a schema change, and its code is loaded only when a timeline that uses it is opened.

How many plugins ship with Zeitlines?

One: product-roadmap, which adds the pricing matrix, the pricing cards and the item fields derived from that model. A timeline with no plugin enabled is a timeline and a list, which is what most timelines need.

Can a plugin give an agent new abilities?

Not yet. A plugin extends the data model, so an agent can read and write the fields it adds. It cannot yet contribute tools of its own, which is what would let an agent be told to recompute a deadline or shift a trade by its lead time. That seam is open work in the repository.

Does an unused plugin slow the app down?

No. Each plugin is a separate build chunk that is fetched only when a timeline enables it, and it imports its own stylesheet inside that chunk. A build check asserts both halves — that the plugin markers are absent from the entry chunk and present in a lazy one — so the promise is tested rather than trusted.

Can I install a plugin into a running deployment?

Not yet. Today a plugin is registered at build time, which means adding one to a deployment means rebuilding it. Runtime installation is tracked as an open issue in the repository, and the host contract — a static manifest, declared capabilities, a versioned API — was designed for it.