Protect a lane

Lane protection turns conventions into gates a Forge enforces. It is configured in the repository's policy manifest, not on the Forge, so the rules travel with the repository and are the same everywhere it is served.

tovio policy protect main --require-review --min-approvals 2 --required-checks ci/build,ci/testtovio policy protect 'release/**' --require-review --reviewers 'role=security'tovio policy protect main --remove

Each call replaces the protection for that exact pattern rather than adding to it, so give every requirement in one command. Running it again with only --required-checks would drop the review requirement you set the first time.

Every protection also carries a conflict-free requirement: a protected lane never adopts a commit that still holds unresolved conflicts.

Path-scoped change control

Protection is lane-scoped. The path-scoped equivalent applies on any lane, which is how you protect a file rather than a branch:

tovio policy change-control 'SECURITY.md' --min-approvals 2 --reviewers 'role=security'tovio policy change-control 'crates/**/crypto*' --reviewer did:key:z... --required-checks ci/audit

A direct push touching such a path is refused and the author routed to a proposal — TVO-FORGE-080. Development on a personal namespace is not gated; only the land onto a served lane is.

Only the owner can change policy

Writing policy on a clone whose pinned owner root is someone else refuses with TVO-PERM-007, rather than writing something every peer would drop. After editing, the owner re-attests and publishes:

tovio policy sign

An unattested manifest is refused by every serving edge and every peer as TVO-SYNC-008, and so is one whose version would move backwards — which is what stops an old signed manifest being replayed to weaken policy.

What a Forge is actually serving

tovio forge policy show --remote <host:port>

An open read of the served manifest: its version, the path-to-policy declarations, and the protected lanes. Worth checking when a land is refused and you expected it not to be.

The one unique to TOVIO

Protected-path review coverage. If a land newly introduces a protected path that no approving reviewer is cleared to read, it is blocked (TVO-FORGE-011). Nobody can rubber-stamp a change to a secret they could not see.

Everything is decided server-side

Approval counts, the eligible-reviewer set, required checks, and the reviewed base are all computed by the Forge from the served manifest and roster — never from a client-supplied field. Change-control rules can also require approvals from someone other than the author, and reviewer rosters are repository-authoritative rather than set per proposal.

Refusal codes