A board that says where the work really is.

Kanban and scrum boards, drag between columns, sprints that start and close. A board bigger than a page says so rather than quietly showing you the first part of it.

A project can define fields of its own, search by them, colour its board cards by a list’s value, and mark a card with the field that matters.

A project connects its repositories — GitLab or GitHub, and more than one, because a tracker project rarely lives in one. An issue is named by its key — ABC-12 — in the branch name, the merge request’s title or its description, and the request shows on the issue.

A repository that did not answer says so instead of pretending there is nothing there.

An issue can move by itself: to review when its merge request is opened, to «on staging» when a pipeline puts it there, to closed when the release it went out in ships. Nobody has to remember to drag the card.

The ready-made workflow Releases by environment brings a state for each step, three environments and seven rules — switched off. Until you switch one on, nothing moves by itself. You can also write rules of your own.

• A rule moves an issue as whoever switched it on, and the issue’s history names the rule. If that person leaves the project, the rule switches itself off rather than run on nobody’s access.
• It is an ordinary move. If the workflow does not allow it, nothing happens to the issue, and the rule’s journal says why.
• «From» is checked every time. A merge request opened on an issue already in testing does not drag it back.

Three moves stay with a person, because each is a judgement: «I am testing it», «it passed», «staging is fine».

A step in the pipeline, run after the deployment has succeeded, says what went out and where. Kaiku can read the issue keys off the commits since the last deployment to that environment, so the step does not have to list them.

• The issue shows Lies on with every environment it has reached; each opens the pipeline that put it there.
• The board has a Lies on filter.
• An issue on the last environment that is not finished says so for as long as that is true.
• The same deployment reported twice does nothing the second time, so a retried step is safe.

A project keeps its versions with their dates and progress, and an issue may be in several. Release marks a version released; if it still holds unfinished work, the screen asks first: leave it, or move it to a version that is still ahead.

In a search: fixVersion = "2.4.0", fixVersion in releasedVersions(), fixVersion in unreleasedVersions().

Stock and flow are kept apart: what is open now never quietly takes the date range that created-per-day takes. Archived issues are still counted, because a shelf is not a delete — and clearing a board, by hand or on a rule the project sets, loses nothing.

Kaiku answers the REST API of the self-hosted edition of the most widely used corporate tracker: the same paths, request bodies, response shapes, status codes and error format. A tool written for it is pointed at your workspace address with a token, and works. The query language is a subset, on purpose, and the documentation lists what is understood.

We are not affiliated with that vendor, and compatibility is something we work at rather than a guarantee for every tool. If a tool you rely on does not behave, tell us — that is a bug to us.

A company admin imports a project from the cloud version of a popular task manager: issues keep their keys, and their comments, files, custom fields, parents and links come with them. A check runs first and names what will not move — change history, sprints, logged time — before anything is written.

One request gives you the whole project as a zip: structured JSON, readable Markdown, and every attachment. Export keeps working while the workspace is read-only.