Plugins give each plan its own language
A plugin adds the fields, views, stored data and tools a planning domain needs. It is enabled per timeline, so the catalogue can grow without turning the core into one large planning suite.
Shipped plugins
Four plugins are included in the repository today. Each page names its current capabilities and limits.
Product and roadmaps
Projects and delivery
Construction
In the repositorySequences trades by the wait each one owes the next, shifts a dependent chain when work moves, and reports the fixed dates that chain runs into.
Sprints
In the repositoryRun sprints on the same plan that carries the roadmap: every sprint has a goal, a window and a capacity, the work is entered once, and a burndown that says where its numbers come from. Your dates keep meaning what they say, and an agent can fill a sprint, hand unfinished work on and report where one stands.
Lifecycle and obsolescence
What plugins can contribute
- Item fields owned by the plugin.
- Focused views rendered from the same timeline records.
- Plugin data stored with the timeline.
- Tools that apply domain rules for an agent.
A versioned contract
Every plugin declares its identity, compatible host range and required capabilities. The host validates that manifest before loading the plugin. Unused built-in plugins stay in separate build chunks and load only for timelines that enable them.
Build on the platform
The authoring reference defines the external artifact and host API. The playbook covers domain research, implementation and publication. Current runtime limits are recorded in the repository with the contract.