The project wiki

Your team's markdown files, readable and editable on every device — and still just files in your repo.

Teams write things down: the architecture, the runbooks, the decisions, the answers new joiners ask for. Peractor gives those notes a home on every device — a phone, a browser, the Mac, the desktop app.

It does not give them a database of its own. The files are the wiki — by default, files in your repository — and everything Peractor holds is a copy, and every copy is throwaway.

That one rule buys a lot. A page is diffed, blamed, branched, and reviewed like the code it describes. A page edited in your editor is just edited — nothing has to be told and there is no direction of sync to get wrong. And the agent working your next run already has the page, because it cloned the repository.

A project with no repository of its own works the same way: Peractor keeps its files (see Projects without a repository), and its wiki just saves.

A wiki folder can also be kept outside the repository — in Peractor's storage, or a bucket or repository of your organization's (see Where files are kept). Its pages read, save and merge as they do in the repository, but the folder has no branches, and a run's workspace doesn't hold it yet.

Turn it on

The wiki is off until someone with Manage project turns it on, in Settings → General. You choose:

• One or more folders in the repository — prefilled with docs/. Every markdown file under them is a page. One folder is marked the default, so a new page knows where to go.
• A branch — prefilled with the repository's default branch. A project can point the wiki at a wiki branch instead, with the trade-off that those pages are not visible to somebody browsing the repository on GitHub.

A project without a wiki has no Wiki screen at all, rather than an empty one.

Reading

Every device holds the whole wiki as text, so it opens instantly and searches with no connection at all. Pages render as markdown, with headings, code blocks, tables, links between pages, and images from the repository.

On a phone, the Wiki tab takes the Triggers slot in the bar while the wiki is on. Triggers is still a row in Settings, where it was before it had a tab.

Editing, and one button

Keep an edit with Save or the checkmark. With a keyboard, ⌘S on Mac or Ctrl+S saves the active editor too. Save writes the page to this device’s working copy. If automatic commits are enabled for the wiki, it also commits the change; otherwise the pending list holds it until you commit.

On Mac and iPad, Wiki pages and Markdown files use the main reader header to switch between Preview, Side by side where there is room, and Edit source. On iPhone and Android phones the same modes are a bar in words directly under the header. In Side by side, drag the line between the source and the preview to resize them, or double-click it to split them evenly again. Preview includes unsaved edits. Save from the status bar or with ⌘S keeps the current view; closing an edited tab offers Save, Don’t Save, and Cancel.

On Mac and iPad, opening another file while a tab has unsaved changes opens the file in a new tab and keeps your edited tab. Its dot stays until you save. Closing an edited tab still asks before discarding.

Full-screen document and slide presentations use floating native controls: Liquid Glass on Apple and Material controls on Android. Use the arrow buttons to navigate, the screen icon to blank the display, and the keyboard icon for shortcuts. The close icon returns to the editor.

Document previews have Zoom in and Zoom out controls. Click the percentage between them for Fit and fixed zoom presets. Presentations use this same status-bar menu, with no separate canvas picker. On Mac and iPad, ⌘+ and ⌘− also zoom the active document tab.

A file’s size appears in its status bar. The Wiki tree shows file names and icons without size labels.

Opening a file such as a script from Wiki uses the same editor and file actions as Code. You can edit and save it there, and opening the same file through Code uses the same draft. Images, PDFs and office documents use Code’s shared previews. File edits follow Code’s save and commit settings.

New folder creates an empty folder, without adding an Overview page or opening an editor. It is kept on this device and branch between visits. Use Add to inside it to create its first page; the folder reaches the repository when a file inside it is committed.

A pending list shows what this device has changed — each page marked new, edited, or deleted, each with a way to throw the change away. One button commits all of them in a single commit, with a message field carrying a sensible default. Straight to the branch, no pull request: a wiki edit is not a code change and should not wait on a reviewer.

The words are the ordinary ones. "Not committed yet" over the list, "Commit 3 files" on the button, "Discard" on a row.

Two people editing one page

Your device knows which version of a page you started from, so a commit is a three-way merge — the version you started from, the version in the repository now, and your edit.

• Different parts of the page changed: it merges and commits, and nobody is told anything. This is the common case and it should be invisible. Two people editing two paragraphs merge silently.
• The same lines changed: you are shown both versions and pick or edit. Only here. Two people editing neighbouring lines of one list will see this — it is what git means by a conflict, and it is what every git user already lives with.

Two things worth knowing

• Runs already have it. Nothing is staged into a run — the clone contains the wiki because the wiki is the repository. When the wiki is on, the project's guidelines gain a line naming the folders, so an agent knows where the knowledge is before it starts guessing.
• Triggers can ignore it. A developer editing docs/ would otherwise fire every repository trigger in the project. Triggers take an ignore list beside their path filter — useful well beyond the wiki, for generated files, changelogs, and lockfiles. Peractor's own wiki commits are already skipped.

Where the repository is not reachable

What the wiki is not

• No pull request per edit — straight to the branch.
• No drafts that follow you between devices. A working copy is per machine.
• No rich-text editor. Markdown, with a preview.
• No permissions of its own. Reading the wiki takes View files and committing to it Edit files, wherever the page is: a folder or a page can be closed to some people as any file can (Private projects & access), and then it isn't in their wiki at all. Manage access… in a folder's or a page's menu opens its settings.
• Adding new images from a phone is not in the first version. Reading a page that references one works.