VIXENTIO

VIXENTIO / Documentation

Reviews and Publish

Versioned reviews with named reviewers, then Accept and a Publish step to a GitHub pull request.

Nothing an agent does reaches your repository on its own. A change goes through three separate decisions, each made by a person: the team approves a version, the result's owner accepts it, and someone starts the Publish step that pushes a branch and opens a pull request.

Review a version

When a run has a result, it becomes a version in the work's review: Version 1, Version 2 and so on, each with its after pictures at the project's widths, the before pictures to compare, and the project's checks. If guidance changes the result, a new version is added and the earlier ones stay as they were.

  1. Choose Request Reviewers… to name who should look. Naming someone is a request, not a requirement.
  2. Reviewers sign off as Design, Product or Technical. Technical review is required whenever the agent changed code.
  3. A reviewer chooses Approve… or Request Changes…, and can pin a comment to a spot on a picture.

A version is Verified once it's approved on passing checks with every required sign-off. If a newer version arrives, any earlier approval no longer counts.

Accept

The person whose run produced the result accepts it on their Mac, after looking at the change. Accepting is what opens the Publish step. Before that, Undo removes the change from the project folder, and only Vixentio's own part of it.

Publish to GitHub

After Accept, the Publish panel appears.

  1. Vixentio commits only the task's own change to a new branch named vixentio/…, without moving your checkout, your current branch or anything you haven't committed.
  2. It pushes that branch and opens a pull request with your own git and GitHub CLI sign-in. Vixentio never stores those credentials.
  3. Choose Open Pull Request. To merge too, turn on Also merge the pull request when its checks pass (off by default) and choose Publish and Merge. A merge happens only once the checks pass, and never with an administrator override.

When the team reviews the work, only the Verified version can be published, and Vixentio checks that again just before the push.

Whether each git step asks first depends on the permission mode: see Git writes by mode.

Undo after publishing

Revert adds a revert commit and publishes it as its own pull request, like any other change. Undo in This Folder still removes the change from your local folder without touching git.

In a cloud workspace

A cloud run publishes the same way from its own workspace once its starter chooses Publish When Ready: a branch of its own and, when the team reviews the work, only once the version is approved. It never merges. See Cloud workspaces.