How to request a feature

Post it on the Feature requests board at feedback.tovio.dev, signed in. Requests about the documentation or the getting-started path go on Docs & quickstart instead.

What makes a request actionable

The requests that get built are the ones that describe a problem rather than a solution. The most useful shape is:

• What you were trying to do. The actual task, not the feature you think would solve it.
• What stopped you. Where the current behaviour got in the way.
• What you did instead. Workarounds tell us how much the gap costs you.

A request that names a solution only — "add a --force flag to land" — is hard to evaluate, because the underlying need might be met better another way, or might already be met by something you have not found.

The Surface field is required here too. It is the difference between a request read as "the CLI should do this" and one read as "the VS Code extension should".

Upvote before you post

Search first and upvote an existing request rather than filing a near-duplicate. Duplicates are merged rather than deleted and the votes follow, but merging is a manual step in triage, so adding your vote to the post that already exists is the direct route to being counted. When a merge does happen the votes move to the surviving post and so do you, and you are told which post that is.

Requests that touch a locked decision

Some parts of TOVIO are settled by an architecture decision record — the absence of a staging area, lanes as CRDT refs, canonical serialisation, the crypto tiers. A request that contradicts one of those is not dismissed, but it is answered by a decision record rather than a code change, and that is the slower path. Those requests are tagged needs-adr during triage so they are not mistaken for ordinary work.

Either way you get a written answer. A Not planned always carries the honest reason and the condition that would change it.

Do not report security vulnerabilities here. This board is public and operated by a third-party vendor. Read https://tovio.dev/security and use the private channel it names. Never paste repository contents, file paths, diffs, tokens, keys, or other people's data — describe the behaviour instead.