Wiki — team knowledge base

The Wiki is a document-oriented knowledge base built into Mockarty: a tree of
markdown pages with full version history, live embeds of your test artefacts,
AI writing assist and one-click import from Confluence or Notion. Documentation
lives next to the tests, mocks and boards it describes.

Open it from the sidebar: Wiki (/ui/wiki).

Pages and the tree

Everything is a page. Pages nest into a tree in the left panel — drag structure
by creating sub-pages, filter by title with the search box at the top.

• Create a root page with the + button, or a child with Sub-page on
  an open page.
• Move / reorganise by creating pages under the right parent; a page can be
  re-parented, and moving a page under its own descendant is rejected.
• Delete removes the page and its whole subtree (it goes to the recycle
  bin along with the rest of your namespace’s deleted items).
• Row menu — right-click a page (or press Shift+F10 on it) for open, add
  sub-page, favorite, move, select, and, for requirement pages, convert / revert.
• Keyboard — arrow keys walk the visible rows, Enter opens the page. The
  tree looks and behaves the same as the boards, mocks and test-case trees.

When you switch namespaces, the selected page from the previous namespace is cleared. Wiki then opens the page you last viewed in the new namespace, if one exists.

Editing

By default you edit inline on the formatted page — headings, bold, lists,
tables and code render live as you type, just like a document. There is no
separate markdown pane to switch between: what you see is what readers get.

• Formatting toolbar — bold, italic, headings, lists, quote, code block,
  link, table and a divider are one click away. Markdown shortcuts also work:
  type ## , - , 1. , > or ``` and the block formats itself.

• Slash menu — on an empty line press / to pick a block (heading, list,
  table, code, quote, divider) without leaving the keyboard.

• Tables — insert a table and a small toolbar lets you add or remove rows
  and columns and toggle the header row; drag a column border to resize it.

• Markdown mode — prefer to write raw markdown? The Inline / Markdown
  button in the edit bar switches to the classic source editor with a side-by-side
  preview. Your choice is remembered. Either way the page is stored as markdown,
  so version history, export and Git sync are identical.

• Insert menu — the + Insert button offers every content type in one
  place: table, checklist, code block, panel, table of contents, Mermaid
  diagram, draw.io diagram, HTML block, a Mockarty board, a dashboard, live
  task / test-case / test-plan tables and a link to another page.

• Page templates — creating a page offers ready-made layouts: meeting
  notes, ADR (decision record), runbook, retro and how-to.

• Ctrl+S saves.

• Every save creates a numbered revision — nothing is ever lost.

• Attachments: drag & drop or paste an image, video or audio file straight
  into the editor, or use the paperclip button. Large files are served directly
  from object storage, so they never slow the app down.

• Voice notes: press the microphone button to record a voice message; it
  is attached and rendered as an inline audio player.

Version history

Press History on any page to open the revisions panel.

• Every save that actually changes the page is a revision, newest first, with
  the author and an optional change note. Re-saving without edits does not
  add a duplicate revision, so the history stays clean.
• Open a revision to view it. Inside the viewer, step through the whole
  history with the ◀ / ▶ arrows, and press Changes to see the diff
  against the previous revision inline — walk the page’s evolution version by
  version without leaving the dialog.
• Restore brings a revision back as the current content. History is
  append-only — a restore is itself a new revision, so you can always go
  forward again.
• Compare any two revisions: tick them and press Compare selected to see
  a line-by-line diff.

If someone else saves the page while you are editing, your save is stopped with
a conflict banner instead of silently overwriting their work. View changes
to compare versions. Load latest asks before discarding your unsaved draft,
then opens the other person’s saved version in the editor. Re-apply your change
there before saving.

If you switch pages or leave Wiki with unsaved edits, Mockarty asks before
discarding the draft. Cancel keeps the editor and its current text open.

Rich content and embeds

Beyond standard markdown, pages support the blocks below. You do not have to
remember the syntax: type / on an empty line in the editor and pick from the
palette — every macro here is in it, alongside headings, lists and tables.
Typing the syntax by hand still works.

• Panels — :::info, :::warning, :::note, :::success … ::: wrap a
  coloured callout box (the body is normal markdown).
• Table of contents — put [[TOC]] on its own line to generate a linked
  list of the page’s headings.
• Diagrams — a fenced ```mermaid block renders as a Mermaid diagram
  (flowcharts, sequence, C4 context, and more).
• Whiteboards — !board:<board-id> embeds one of your boards: a live
  preview with an Open board link and a Draw here button that opens the
  canvas right inside the page. Use Insert → Board for a picker with search
  and your folder structure, or New empty board to create a blank board and
  drop it in ready to draw on.
• Frames — !iframe:<url> embeds a live page right in your document: an
  external status page, a self-hosted tool, or a same-origin page such as the
  built-in API reference (!iframe:/swagger/...). The page loads in an
  isolated frame in the reader’s browser, so it is always current — no
  copy-paste. The editor toolbar’s Insert HTML dialog has a URL field that
  inserts this for you. Administrators can restrict which hosts are allowed
  to embed by setting MOCKARTY_WIKI_IFRAME_ALLOWLIST to a comma-separated
  host list — or to none to forbid external embeds entirely (same-origin
  pages keep working).
• draw.io diagrams — Insert → draw.io opens a full diagram editor in a
  dialog; press Save there and the finished diagram lands in your page as
  an image. The file keeps its source, so you can re-edit it in any draw.io
  later. The editor is an external draw.io service: your administrator
  connects it by setting MOCKARTY_DRAWIO_URL to a self-hosted draw.io (or
  the public editor when the server has internet access). Until then the
  menu item is shown muted with a setup hint.
• HTML blocks — Insert → HTML accepts arbitrary HTML (with scripts) and
  renders it in an isolated frame on the page: interactive widgets,
  visualisations, custom forms. The block cannot touch the rest of the app.
• Dashboards — !dashboard:<id> embeds a live widget-dashboard panel.
• Live task tables — !tasks:<filter> renders a live table of tracker
  issues matching the filter; !tasks:source=jira <query> pulls from a Jira
  integration configured in Settings. !cases:<filter> and !plans:<filter>
  do the same for test cases and test plans.
• Page variables — {{page.title}}, {{page.version}}, {{page.author}},
  {{page.updated}}, {{date}} are substituted when the page is viewed.

Stay in the loop: watch, mentions, reactions

• Watch (the bell button on a page) subscribes you to it: every change
  notifies you in the app bell, by email and in your connected channels.
• Mention a teammate by typing @login in the page text — they are
  notified on save.
• Reactions — leave a quick emoji under the title; click again to remove.
• Labels — tag pages (the + next to the title) and filter the tree by
  label with the chips above it.
• Favourites and recents — bookmark pages you use daily; both lists sit at
  the top of the tree.
• Space home — a page with the slug home becomes the landing page of the
  space: it opens first when someone visits the Wiki.

Who can see a page: access restrictions

By default every member of the namespace can read and edit a page. To narrow
that down, open Restrictions in the page menu — it has two fields, “Can
view” and “Can edit” (logins or emails, comma-separated).

The rule that is easy to misread: the page becomes private as soon as
EITHER field is filled in. An empty field does not mean “everyone is allowed” —
it means “nobody was added here”.

So if you want “everyone reads, the team edits”, list the readers under “Can
view” as well — otherwise the page disappears from everyone else’s tree. The
dialog warns you about this as you type.

Edit access implies view access, so there is no need to repeat editors in the
view field. The page author and admins always keep access — you cannot lock
yourself out.

A restricted page disappears completely: it is absent from the tree, from
search, from the export and from a direct link (the answer is the same as for a
page that does not exist, so its existence never leaks). Child pages are hidden
together with their parent.

Requirements

Any wiki page can become a requirement — a spec you want to track, without
leaving the Wiki. A requirement is a normal page (same tree, same editor, same
version history and access rules) with a bit of extra metadata: a short key
(REQ-1, REQ-2, …), a type (functional or non-functional) and a free-form
status (draft by default).

There are three ways to make one:

• From the page menu — open the ⋮ actions menu on any page in the tree (or
  right-click it) and choose Convert to requirement. Pick the type and
  confirm; the page keeps everything it had and gains a REQ-N key.
• Drag and drop — drag a page (or a whole multi-selection) onto the
  Requirements drop-zone above the tree. The same type picker opens with a
  Move button, and every dropped page becomes a requirement in one step.
• From an agent — the wiki_page_convert tool tags a page as a requirement
  or reverts it, so an AI assistant can turn a spec page into a tracked
  requirement on its own.

A requirement shows a coloured REQ-N chip next to its title in the tree and a
type · status badge at the top of the page. To turn it back into a plain page,
use Convert to page in the same menu — the key is dropped and the page stays
exactly as it was.

Focus on requirements. Above the tree, a All / Requirements switch scopes
the tree: pick Requirements to see only requirements, with the folders that
lead to them kept so the structure stays intact — everything else is hidden. The
Requirements drop-zone doubles as the switch (click it to focus, drop a page
on it to convert) and shows how many requirements the space holds.

Traceability — is it actually tested? Open a requirement and its
Traceability panel shows the test cases that verify it, each with its latest
run result, and a single verdict:

• Verified — at least one covering case passed and none are red.
• Failing — a covering case failed (a red case wins over passing ones, so you
  never see a green verdict while a known test is failing).
• Not run / No cases — covered but never executed, or nothing linked yet.

Press Link case to search your test cases and attach the ones that prove the
requirement (the same link the test-case editor’s Documentation section makes —
it shows on both sides). For a requirement with sub-requirements, the panel also
rolls the whole subtree into one verdict, so a parent reads Verified only when
it and everything under it is verified.

The panel’s Tasks / issues section connects the requirement to tracker
tasks and bugs — press Link task, search, and attach. The Boards /
diagrams section links the page to whiteboards the same way — press Link
board, search, and attach. Documentation, requirements, tasks, test cases and
boards all link to each other, so from a requirement you see the tasks, cases and
boards behind it, and from a task you can jump back to the requirements and specs
that reference it.

This isn’t limited to requirements: on any wiki page, the Connections
button in the toolbar opens the same panel, so a plain runbook or design doc can
link the test cases, tasks and boards that relate to it too.

Connected to your tests

• The Links button shows everything connected to the page: where it is
  mentioned across the wiki, and which test cases and test plans cover
  it. The reverse links are made from the case editor / plan form — the
  “Documentation” section there links a case or plan to its spec page.
• Discussions open on any page from the side dock; you can also link a
  Telegram group chat to a page’s discussion — the bot keeps the recent
  chat history and /summarize posts a digest of the conversation into the
  discussion, so decisions made in the messenger are not lost.
• Comments live at the bottom of every page — the same conversation the
  discussion shows, rendered as a Confluence-style comment log. The composer
  supports Markdown with a formatting toolbar, pasted images and files,
  @-mentions with autocomplete (the mentioned person gets a bell
  notification with a link to the page), and replies: answer a comment and it
  shows a quoted line of the original, while its author is notified that you
  replied. Meeting recordings posted from a call appear as a card with a
  built-in player; when transcription is available, the transcript follows as
  its own comment.

Export and sync

• PDF — print any page to PDF from the browser (the page renders in a
  clean print layout).
• Space ZIP — the export button in the tree header downloads the whole
  space as a ZIP of markdown files, preserving the tree.
• Git sync — connect a repository in Settings and pages sync to markdown
  files in git: edit in the app or in your editor, both directions work.

AI writing assist

When a language model is configured, three buttons help you write:

• Summarize (view mode) — produces a short abstract of the page.
• Improve (edit mode) — rewrites the current text for clarity while keeping
  its meaning, code blocks and structure; you confirm before it replaces your
  draft.
• Draft (edit mode) — generates a fresh page body from a short prompt and
  appends it to the editor.

Nothing is saved automatically — the AI result lands in the editor and you
decide what to keep. If no model is configured the buttons return a clear
“not available” message.

Search

Wiki pages are part of the platform’s global search: results match the page
title and its content. The AI agent can search the wiki too, so it can find
and reference the right page when answering.

Import from Confluence, Notion or markdown

Press Import in the tree header to bring an existing knowledge base in:

• Confluence — a space HTML export ZIP;
• Notion — a “Markdown & CSV” export ZIP;
• Markdown — any ZIP of .md/.markdown files in a folder tree.

The folder structure becomes the page tree. Pages are created under the page you
have open (or at the root); nothing existing is overwritten. The importer is
bounded against oversized archives.

Confluence macros survive the move. The importer translates Confluence
macros into the native blocks above instead of flattening them to plain text:
info/note/warning/tip panels become ::: panels (titles preserved in bold),
code blocks keep their language and indentation as fenced code, a table of
contents becomes [[TOC]], expand sections become collapsible blocks, status
lozenges become bold [TAG] markers, and Jira issue keys stay readable as
inline code. Links and bold/italic text are preserved as markdown. A macro the
importer does not recognise keeps its readable text and is marked with an HTML
comment naming the original macro, so you can find and rework those spots —
nothing is dropped silently.

Enabling the Wiki

The Wiki ships inside the Processing & Communications module — the same per-namespace switch as the rest
of that family enables it. Until enabled, its API answers with a
self-explanatory error that points at the setting.