A complete tour of what Osnova does today. Screenshots are illustrative; your content and theme will differ.
Everything below is implemented. For things explicitly not yet built, see Roadmap at the end.
Login is delegated to Keycloak (OIDC + PKCE). The login screen follows the chosen language. After login you land on the workspace picker.
Each workspace can expose up to three views, each a filtered presentation of the same Git repository:
- Direct (1:1) — the repository as-is; most permissive.
- Client — Business — a simplified, filtered slice for business stakeholders.
- Client — Technical — the business slice plus ADRs and architecture/infra docs.
Visibility is glob-based and configured per workspace and view. Client views are
fail-closed (nothing shows unless explicitly included), .gitignore/.gitkeep
are respected, and document metadata/frontmatter is hidden by default. Roles
(workspace_maintainer, editor, client_technical, client_business, viewer,
plus the global system_admin) gate every action server-side.
A clean, friendly Markdown reader with GitHub-Flavored Markdown, callouts
([!NOTE], [!TIP], [!IMPORTANT], [!WARNING], [!CAUTION]), Mermaid
diagrams, inline images, downloadable attachments, and copyable heading anchors.
Reference a PDF with image syntax —  — and it renders inline in an
embedded viewer with a download affordance. A plain link [label](file.pdf) stays a
download link.
Every document has a shareable URL (/ws/<slug>/<path>?view=<view>), and every heading
has a copyable anchor — link straight to a clause.
A first-class navigation tree: favorites (starred per user), recently opened,
expand/collapse-all, live filtering, and a ⌘K/Ctrl-K command palette. Plus
full-text search and frontmatter-derived tag filtering.
A dual-mode editor: WYSIWYG (TipTap) with a formatting toolbar, bubble menu, and
task lists — or raw Markdown. The WYSIWYG surface renders in the current preview
style, so editing looks like reading. Images and attachments can be dragged, pasted,
or picked; they're stored in an .attachments/ folder beside the document and
committed to Git. Every save is a commit and push.
Comment inline (anchored to a text selection) or at the document level. Threads
support replies, @mentions (which notify), emoji reactions, and resolve/reopen.
Inline comments leave visible marks in the text and survive edits via fuzzy
re-anchoring.
Lightweight presence shows who else is on the same document right now — avatars in the toolbar, with the activity (viewing / editing / commenting). It's heartbeat-based (no WebSocket dependency) and ephemeral, so it stays accurate without extra infrastructure.
Reviewers with edit rights can mark a comment accepted — a signal that it should be acted on. Accepted comments are exactly what the AI incorporation flow (below) folds into the document, keeping the human in control of what gets applied.
Turn a thread of accepted review comments into clean prose. Claude reads the document and the accepted, open, top-level comments, then proposes an updated version — and you review a current-vs-proposed diff and can hand-edit the result before it's committed and pushed. Nothing changes without your sign-off.
Instead of writing prompts, reviewers pick a skill: a curated, reusable instruction such
as apply verbatim, unify tone, condense, refine language, or restructure. Workspace
admins manage the skill set per workspace (seeded from a shared default pool, then editable),
so each team gets house-style behaviour. The action is gated by both edit and ai-use
permissions, and requires ANTHROPIC_API_KEY to be configured.
Every document can show how it relates to the rest of the repository: a directed graph of
cross-references, laid out in columns by link depth, colour-coded by folder/area and
shaped by doc-type, with a 1–3 degree selector, pan/zoom, hover highlighting, and
click-to-open. The graph is indexed on disk and re-indexed when the repository revision
changes, so it opens fast even on large repos. Client views never surface internal
.ai/context config files in the graph.
Concurrent edits are handled gracefully. Osnova first tries an automatic pull --rebase;
when that succeeds the save just goes through. On a genuine conflict, a guided wizard
presents the conflicting hunks side by side and lets you choose — yours, theirs, or a manual
merge — then commits the resolved file. No raw conflict markers, no lost work.
Edit a document's frontmatter (title/name, doc-type, tags, and other metadata) through a structured Properties panel instead of hand-editing YAML — changes are written back to the file and committed.
A lightweight document review workflow driven from the status pill on each document. Reviewers can:
- Approve the document.
- Reject it, optionally with a comment — the note is posted to the document's comment
thread as a normal comment prefixed with the action (e.g.
❌ Odrzucono: …), so the reason stays visible in the discussion. - Optionally mark it In review — a quiet, non-mandatory marker (no notifications) that signals a review is in progress.
The status pill is colour-coded (approved, stale, rejected, in-review, pending) and detects
when a document has changed since approval, flagging it as stale. All three actions
require the approve permission (client roles + workspace maintainer); editors cannot
approve. The acceptance Reports break documents down across all of these statuses,
including dedicated rejected and in-review buckets.
Legacy
changes_requestedstamps are read transparently asrejected— no migration needed.
Browse every revision of a file, preview it at any commit, view a unified diff with line numbers and add/delete counts, or open per-line blame. You can also restore any past revision — including a file that was deleted — which is written back as a new commit, so nothing is ever truly lost and the history stays linear.
Seven reading styles — Editorial (default), Standard, Reading, Technical, Terminal, Neon, Pastel — independent of the app's light/dark theme. They differ in font, colour, bullet glyphs, spacing, column width, paragraph alignment, and heading alignment.
A bell with an unread badge, a full inbox (filter by type, unread-only, pagination), and an opt-in email digest (daily or weekly) of unread activity, rendered in the recipient's language. An audit log records significant actions (edits, role changes, approvals, deletions) for accountability.
The entire UI is translated and remembered per user; the Keycloak login follows suit
via ui_locales; dates are locale-aware.
System admins can create a workspace through a guided in-app wizard (basics → repo → views → team), or manage everything directly in the PayloadCMS admin panel.
Not yet implemented — deliberately listed here so the docs don't overclaim:
- PlantUML diagrams (Mermaid is supported today) and YouTube embeds.
- Document templates / blueprints.
- Real-time co-editing (CRDT/OT). Live presence ships today; simultaneous character-level co-authoring does not.
- Public read-only share links for non-Keycloak recipients.
Recently shipped (previously on this list): guided merge-conflict resolution, live presence, AI-assisted comment incorporation, the document dependency graph, document properties editing, and one-click restore from history.
See Administration » for managing these features.