Wikis

A wiki is a tree of pages your team reads in Kythene: a handbook, a runbook, a customer-facing knowledgebase. Where a collection is one publish of one piece of work, and a memory is a fact an instance recalls mid-session, a wiki is the thing you send someone to read.

You can have as many as you like in a workspace, each with its own name, its own access and its own tree.

It isn't a third store

A page is a collection underneath, carrying one markdown body. That's not an implementation detail you have to care about, but it's why everything you already know about Kythene keeps working on a page:

• the /c/<id> permalink, versions and full history,
• comments and block-level feedback against a paragraph,
• archiving and deleting, on the usual lifecycle,
• provenance - which person and which instance wrote it.

A wiki's access lives on a tag, which is why a wiki inherits private membership, passwords and share codes for free. You never meet that tag: it's hidden from every tag list, filter and picker, and the tag tools refuse to rename, merge or delete it. Nobody should be able to dismantle a wiki from a screen that never says the word.

Pages and the tree

Every wiki has a home page at its root, and pages hang beneath it, up to six deep. Each page has a slug, and its path is the slugs from the root joined by slashes - onboarding/day-one. That path is how you address the page everywhere: in a URL, in the CLI, in the MCP tools.

A slug only has to be unique among its siblings, not across the whole wiki, so two branches can each hold a setup and neither has to be setup-2.

The wiki's home page has no path at all. It's the page the wiki's own address opens, and in the CLI and the tools you address it by leaving the page argument off.

Draft, published, and what readers see

Every page starts as a draft. A draft is visible only to members who can edit the wiki: not to viewers, not to guests, and not in search or recall. Nothing exists for a reader until you publish it.

Writing to a page doesn't publish it. A live page keeps showing readers the published version until you publish the new one, so you can draft a rewrite in the open without anyone reading half of it.

Going the other way works too. Unpublishing returns a live page to draft and readers lose it. Discarding throws away the unpublished changes and goes back to what's live, keeping the discarded version in the history rather than vanishing it.

When a change needs approval

Turn on a change must be approved before it goes live in the wiki's settings, and publishing takes a second pair of eyes. The author asks for approval (optionally naming a reviewer), and the reviewer either approves - which approves and publishes in one act - or sends it back with a note saying why, which returns it to the author as a draft.

Turning approval off doesn't strand anything: the settings screen tells you how many pages are waiting before you switch it.

Writing a page

Always read the page before you write to it. The read hands back a base_revision, and a write has to carry it. If the page has moved on since you read it, the write is refused and names the newer revision, so you re-read and re-apply rather than silently flattening whoever got there first.

That refusal is the point. Two assistants race on a page exactly as readily as two people do, and the shared-context product is the last place that should resolve by last-write-wins.

A write replaces the body in full - it isn't an append - and takes an optional short note about what changed, which shows on the page's history.

Linking between pages

Pages link to each other with [[double brackets]], the same wikilinks memory uses. [[Day one]] finds a page by title; where a bare title would be ambiguous, write the path - [[onboarding/day-one]] - because the resolver refuses to guess between equally close matches rather than picking one.

Every page shows what links here as well as what it links to. Before you change something, that list is who depends on it.

An unresolved link stays plain text rather than becoming a dead link, and for a guest on a share link a reference only ever points at something already on their page.

Moving and renaming

Move a page under a different parent, rename its slug, or both. Its whole subtree travels with it, and every old path redirects, so tidying the tree never rots a link somebody already sent. The page id never changes either, so anything citing the permalink is unaffected.

Search

Search inside one wiki, or across every wiki you can see. It matches the words on the page, not their meaning, so "pricing" won't find a page that says "fee" - reach for the word whoever wrote it would have used. Titles are weighted above bodies, and results come back with the matching words highlighted in context.

Only published pages are searchable, including for editors. A draft you haven't published won't surface in your own search either, which is deliberate: a result you can open and nobody else can is a trap.

Watching a page

Watch any page and you're told in your inbox when it's published. Watch a page with its subtree and that covers everything beneath it, including pages added later - the right setting for a section you're responsible for rather than a single page.

The page shows how many people are watching before you publish, which is the number worth knowing when the change is a significant one.

Restricting a section

By default everyone in the workspace who can read the wiki can read all of it. To fence off a section - a salary band, a customer's own pages, an unfinished rewrite - restrict a page, and the restriction covers that page and everything under it until a deeper restriction takes over.

You then name who gets in:

• a member of the workspace, or
• one share link's holders, which is how a customer reading from outside is named.

Each gets either read it or read and change it. A restriction only ever widens who can reach a page; it never lifts anyone above their workspace role, so a viewer granted edit still can't write.

A restricted section is absent from the tree for anyone without a grant, and unreachable by URL. One without the other isn't a restriction, it's a hint.

You can't restrict a wiki's root page: that would fence off the whole wiki, which is wiki-level access and belongs on the wiki's own sharing settings where a person can see it. Owners and admins can read a restricted section regardless, for the same oversight reason they can read private content.

Sharing a wiki outside the workspace

This is the one people came for: hand a customer a link and they read your knowledgebase, with no account and no seat.

From the wiki's settings, mint a share link with a label so you can see later who you gave it to and revoke just theirs. Optionally give it an expiry, and a PIN where a forwarded email would matter.

What the holder gets:

• the wiki's home page at the link itself, with no deeper URL needed,
• the contents of everything they're admitted to, and nothing else,
• search within the wiki, which never surfaces a page they can't open,
• a way to tell you something's wrong, against the page they're looking at.

What they don't get: drafts, restricted sections they hold no grant for, page history, state controls, or anyone else's comments. A guest sees only their own notes back - the label on a share link is your bookkeeping ("Acme - Jo"), so showing it to the person holding it would be meaningless, and showing it on somebody else's words would be worse.

The whole share subtree carries noindex, nofollow, so a shared wiki never turns up in a search engine.

Revoking is immediate and server-side. What they told you stays; the way in is gone. See Sharing and guests for the full picture, including tag passwords for a read-only audience with no per-person attribution.

Where pages turn up elsewhere

• The timeline shows published pages alongside published work, and a card opens the page in the wiki rather than the raw collection underneath. Drafts never appear.
• Recall returns published pages to your instances, marked as a page and carrying their path - the path is the context, and a fact recalled without it comes back rootless.
• The collections list does not include pages. A page is read in the wiki, and a flat list of them is neither.

Doing it from an assistant or a script

Everything above is available over MCP and from the CLI. Most wiki content is written by an assistant and read by a person, so the MCP tools are the primary surface rather than an afterthought:

kythe wikis                                   # slug, id, name, published/total
kythe pages handbook                          # the tree, indented
kythe page handbook onboarding/day-one        # the markdown, on stdout
kythe create-page handbook "Day one" --parent onboarding --file day-one.md
kythe page-state handbook onboarding/day-one published

"Put the runbook we just worked out into the platform wiki, under Operations, and publish it."

"What does the handbook say about expenses?"