Hot mode

About hot mode

Use hot mode for a change that must land now, or when the loop itself is broken. You, the Principal, edit a task branch live with an agent beside you. There is no sandboxed Developer, no rounds and no controller. Every gate still runs at commit and push, review still happens, and the record still gets a run.

In hot mode the agent acts as the Principal. It edits, commits and pushes with your own login; merge stays yours. There is no credential exception and no confined session. You are accountable for every commit the agent makes. The agent's own local edits are not recorded, as with every agent's local edits.

To walk through it, follow the guide Deploy hot issue now.

How it works

1. 1

   Write the hot Issue

   Write an Issue of kind hot and do its readiness check yourself.

2. 2

   Start

   Run vinaya hot start --issue <n>. It freezes the brief, creates the task branch and worktree, and mints a run identity.

3. 3

   Work

   You or the agent commit and push to the task branch through the ordinary hooks.

4. 4

   Review on demand

   Run vinaya hot review --issue <n> when you want the two reviewers to judge the pull request.

5. 5

   Merge

   Merge through the unchanged merge gate. A push after review voids the verdicts, so review again first.

The hot Issue

A hot Issue is a GitHub Issue of kind hot, labelled vinaya/hot. Its body follows the backlog single-fix profile:

• **Project:**
• one or two ## Objectives
• ## Premises
• ## Surface
• a Boundary with Pinned files:
• ## Test plan
• optionally ## Observed
• the line Readiness: performed by the Principal

Like every Issue, it carries **Parent:**. See Issue kinds.

Start a hot run

vinaya hot start --issue <n>

hot start:

• reads principals from the default branch, and refuses if the default branch cannot be read, if the Issue's author is not a principal, or if it is called through the task-tools MCP server (advisory until authority is fully specified);
• refuses while a live driver lock or a pause record exists for the task;
• freezes the brief, creates task/issue-<n> and its worktree from origin/<parent>, and records the worktree path beside driver.pid.json;
• mints a run identity, emits run_started, and prints export VINAYA_RUN_ID=<id>.

To build the worktree from a branch that is already pushed, use --adopt-branch:

vinaya hot start --adopt-branch <name> --issue <m>

This pushes no reservation and freezes a brief naming that branch. It is how an integration branch gets its review. See Parent and integration branches.

Work

You or the agent commit and push to task/issue-<n> through the ordinary hooks. Three rules always hold:

Review on demand

vinaya hot review --issue <n>

You or the agent run it on demand, from the registered worktree, on the open pull request:

1. 1

   Check the pull request

   Refuses if the body lacks Closes #<n> or the brief hash resolves to null.

2. 2

   Number the attempt

   Numbers the attempt within the hot run.

3. 3

   Stage the inputs

   Stages the candidate inputs with the loop's own functions and takes the turn-confinement snapshot.

4. 4

   Dispatch both reviewers

   Dispatches the code reviewer and the security reviewer in parallel, under the hot run identity.

5. 5

   Build verdicts and manifest

   Builds the verdicts and the review-input manifest with the loop's builders.

6. 6

   Post the verdicts

   Posts both verdicts with effect key hot-<runId>-<attempt>-<role>-verdict and owner hot-review:<task>:<runId>, reads them back to verify the binding, and writes no summary comment.

7. 7

   Finish the report

   Writes the AEG:BEYOND-SURFACE block and runs pr report --push.

Review again after a push

A push after hot review voids the verdicts, because the review gate binds to the head. Review does not run again by itself: the next hot review is attempt n+1, keyed hot-<runId>-<n+1>-….

End

hot review emits run_ended when both verdicts are posted. Merge is yours, through the unchanged merge gate. The review gate needs no loop and accepts a head branch that is not task/issue-<n>.

Run identity

hot start mints one run per hot fix. run_started and run_ended mark a task that has no loop. Each review attempt adds two role_attempt and two effect events. task_status shows the task as hot, with its pull request and last attempt.

Gates

The three new checks read git diff --cached when VINAYA_COMMIT_HOOK=1, and git diff ${BASE_SHA:-origin/main}...HEAD otherwise. See Gates.

Configuration

Hot mode adds no settings. It uses principals from the default branch.

Two questions are still open: whether the protected-path check applies on branches that are not task branches, and whether to fail open or closed when the forge is unreachable.

What gets logged

• run_started and run_ended (new, for a task without a loop).
• Per review attempt, role_attempt and effect events with distinct effect_ids.
• Hooks and CI emit gate events as usual.

See Events.

What's next