What TOVIO deliberately will not do

Some of the most useful things to know about a tool are the things it has decided not to become. The list below is not a backlog and not a set of gaps: these are written-down decisions, most of them permanent. Where one is a v1 scope call rather than a refusal, it says so. If one of them is what you actually need, TOVIO may be the wrong tool, and it is better to find that out in five minutes than in five weeks.

It will not be transparently wire-compatible with Git

A plain git clone against a TOVIO repository over the Git wire protocol is not a goal. Interop is explicit and named: tovio git import ingests Git history, tovio git bridge exchanges work with a Git remote through conflict-safe namespaces, and tovio git export writes a Git repository back out as a lossy interop view. The reason is structural — a Git client cannot encrypt, so a protected path could only ever cross that wire as plaintext or not at all, and TOVIO chooses not at all.

It will not put policy on a blockchain

Access policy lives in signed policy manifests and the encryption envelope, not on a distributed ledger. That would add an external runtime dependency to a developer tool in exchange for nothing the signatures do not already give you.

It is not a peer swarm — and that part is deferred, not refused

Sync happens between replicas you name and authenticate over TLS. Distribution in TOVIO means every clone is a complete, offline-capable copy, not that anonymous peers serve each other content. Direct peer-to-peer client transport is recorded as out of scope for v1 and deferred rather than ruled out permanently — worth knowing if it is what you were hoping for, because it is one of the few items on this page that a good argument could actually move.

It will not do real-time collaborative editing

Lanes converge using conflict-free replicated data structures, which sometimes leads people to expect Google-Docs-style simultaneous typing. That is explicitly out of scope. The convergence is about references — so two people advancing the same lane never see "diverged history" — not about character-level co-editing of a file.

It will not mount your repository as a filesystem

Operating-system filesystem integration is a non-goal for the core version control system. A proposed optional adapter exists on paper for a separate workspace product; it is neither accepted nor built, and nothing in the core depends on it. What TOVIO does instead for very large repositories is tovio sparse, which materializes only a declared cone of directories.

It will not invent a CI language

TOVIO does not define a pipeline DSL of its own. tovio ci reads the workflow files you already have and classifies how each job would run, and its config-as-code option compiles ordinary JavaScript pipeline definitions down into those same standard workflow files. What it will not do is ask you to learn a TOVIO-only syntax that only TOVIO can run.

It will not pretend to be a GitHub clone

The Git-compatibility facade deliberately does not implement issues, labels, milestones, or GraphQL. A request for one of those is refused honestly rather than answered with a convincing fake, which is the same principle that governs the rest of the system: a surface that cannot be backed by a real native referent says so.

There will not be a hosted graphical client from the project

A first-party local desktop application is in scope and being built. A hosted, browser-based IDE operated by the project is not.

Why say any of this out loud

Because the alternative is a roadmap that silently absorbs every request and delivers none of them. A non-goal is reversible in principle — it takes a written, reviewed decision to change one — but it is not a hint, and no amount of demand converts it on its own. If one of these is a blocker for you, say so on the feature-request board; the case for reversing a decision is exactly the kind of thing that board is for.