The documentation lives next to the work.

A project comes with exactly one wiki space, keyed like the project. There is nothing to set up and no second set of permissions to keep in step: whoever may see the project may read its pages, whoever may change it may edit them.

Pages are written in Markdown — headings, lists, tables, code, links to other pages and to issues, pictures, and formulas in $…$. A page can be narrowed further: who may read it and who may edit it.

Tie a page to an issue and the link shows on both: the issue lists the pages that document it, the page lists the issues it is about. Both ends are filtered through the reader’s own access, so a link never shows something the reader may not see.

A page can also carry a live list of issues — by a query, or simply the issues linked to that page. The list is asked when the page is read, with the reader’s access: it never shows a key closed months ago as open, and a long one says how many it left out rather than stopping silently.

The history shows each version with what changed against the one before, folded down to the changed lines. Restoring an old version saves it as a new one — the record of what happened is never rewound.

Search looks in titles, text and labels — and in the words inside diagrams attached as SVG. The name of a service on an architecture drawing is found like any other word, instead of being a picture nobody can search.

• A page goes out as a Word document or a PDF, for somebody who is not in the workspace.
• A page can be read translated into your language, on demand. A page with restricted access is not sent to a model at all.

Kaiku’s own MCP server searches, reads, writes and links pages as well as issues, so an agent that closed an issue can update the page about it in the same run. The wiki also speaks the REST API of the widely used corporate wiki, and tools written for it work unchanged.