Review, approve or request changes

tovio review <change_id>

Renders the change's diff against its base. Clear paths diff normally; a protected path you can decrypt shows its decrypted diff; a protected path you cannot decrypt shows a locked marker and a coarse change indicator, never the plaintext or anything derived from it. It ends with a coverage summary.

tovio review <change_id> --approve --proposal prop:<id> --remote <host:port>tovio review <change_id> --request-changes --proposal prop:<id> --remote <host:port>

With a decision flag it renders the review locally first, then submits. The rules are strict on purpose:

• --approve and --request-changes are mutually exclusive.
• A decision needs both --proposal and --remote. Missing either is a clear usage error, not a silently-dropped submission.
• --proposal or --remote without a decision flag is also refused, rather than being ignored.
• The reviewer is your signing identity. It is never a field you can set.

--cert defaults to .tovio/relay-cert.der. A Forge that refuses or cannot apply the decision surfaces as TVO-OP-011.

The rule that surprises people

You cannot approve what you cannot read. If a land would newly introduce a protected path and no approving reviewer is a recipient for it, the land is blocked — TVO-FORGE-011.

This is deliberate. An approval from someone who saw a redaction where the secret changed is not a review. The fix is to have someone cleared for that path review it, not to work around the gate.

Two details matter. Coverage is computed over the whole-tree diff from the pinned base to the pinned commit, so a protected path introduced by a stacked ancestor is caught even when your own change looks benign. And it is computed server-side from the Forge's own objects, served manifest, and roster — the coverage summary your CLI prints is advisory display, and the gate ignores it entirely.

Staleness

If the lane advances under a review, landing is refused as TVO-FORGE-013. The coverage was computed against a base that has moved, so the proposal must be re-pinned onto the new tip and re-reviewed. It is a guard against approving one state and landing another.

Eligibility, not just headcount

For an encrypted path, eligibility and read coverage are conjoined: an eligible approver must also be a recipient.

Seeing the state you are reviewing against

tovio forge proposal list --target main --remote <host:port>tovio forge check list --proposal prop:<id> --remote <host:port>