Roadmap

Roadmap

Work is organised as packages in docs/execution/work-packages.adoc. This is the summary; that file is authoritative.

Built

• The engine. Metadata round-tripping, hierarchy, backlinks, diagnostics, deterministic sidebar generation.
• The store. Atomic writes, path validation, stale-write guard, sidebar regenerated inside every mutation.
• Out-of-clone app state and the draft store.
• The reader. Zero-JavaScript three-pane explorer with search and diagnostics.
• The editor. Source editing with preview, page create and delete, explicit Save and Save-draft, two-layer stale guard.
• The git engine and sync layer. One store mutation becomes one atomic logical commit.
• A GitHub mirror, read-only.
• The writer lock. One clone has at most one BerryWiki writer at a time — an OS advisory lock held by serve for its lifetime, and by a CLI mutation for its duration. The kernel releases it however the process exits, so there is no stale lock to reclaim.
• Attachments, tags and per-page history in the reader.
• Backup and restore as CLI commands: a git bundle of committed history plus drafts and the operation journal.
• CherryTree .ctd import, dry-run and apply.
• Subtree move. Moving a page moves its whole subtree: the store cascades every descendant filename, rewrites inbound links and regenerates the sidebar, and sync lands the lot as one commit that never half-applies. Preview is a pure dry run that writes nothing; Move re-plans against the live graph before applying, so a stale preview can never be applied.
• Conflict classification. Once you have started a merge, BerryWiki reads the git index — not the marker-laced working tree — and classifies each clash: sidebar, body, metadata, added-both, deleted-by-either, or opaque. Every clash is shown with all three sides: ancestor, ours, theirs. A merge whose only clash is the generated _Sidebar.md can be concluded in place by regenerating it. Page bodies and metadata are never merged or unioned on your behalf — that is a deliberate limit, not a missing feature.
• Accessibility as a gate. Fourteen structural rules run over every rendered route in the test suite: heading order, landmarks, a skip link, accessible names, and text alternatives wherever colour or shape alone would carry meaning. Writing the gate found a rendered route that two separate green "every route" tests had both missed.

Next

• Zim import — the second importer, and the one that actually tests whether the neutral model is a contract rather than one command's internals.
• The live GitHub spikes — see Compatibility and Limits. Until these run, the compatibility report stays a hypothesis list. This is the honest gap in the project: every GitHub Wiki behaviour BerryWiki relies on is reasoned from documentation and has not been tested against a real wiki.
• The accessibility walkthrough. The structural gate above is enforced on every route. The manual half — driving the reader and editor with a screen reader — is written up and has never been run. It needs a human at a browser with NVDA, and no screen-reader claim is made until it has been.

Later

Packaging, and the SPARK proof work on the invariants.

Deliberately parked

A richer client-side experience — inline autocomplete, drag-and-drop reordering, live preview — was gated on whether generated client script may ever ship. ADR-0007 ruled that question on 2026-09-03: it may, generated only, and only behind a manifest recording each artefact's sources, pinned toolchain, reproduced hash and permitted routes.

It stays parked all the same. Nothing has been built against the ruling, the no-<script> test is unchanged, and the manifest gate has to exist before any of it can start.