Review and approve a plan

A Developer’s approval authorizes one exact plan: isolated implementation, the declared checks, an independent review, and one pull request. It never authorizes merge or deployment.

Who can do this

Holders of the Developer role on the service. A workspace Administrator without that role sees the plan but no decision buttons.

Before the plan exists

While a change is Clarifying or Criteria needed, the Next safe action panel offers Ask AI to draft criteria. The draft turns the brief and thread into editable, measurable criteria; it cannot modify the repository, and only the original requester can confirm it.

Read the plan

When the change shows Plan review, the plan card lists:

• Scope, Affected paths, Declared checks, Assumptions, Risks, and Protected path impact.
• Rollback text.
• Repository base (repository and commit), Policy authority (revision and hash), Base branch, Repository root, and Approval expires.

Check that the affected paths are the ones you expect, that every protected path they touch is declared, that the checks are the right ones from the service policy, and that the base commit is current. A plan expires seven days after it was prepared.

Decide

• Approve exact plan opens a confirmation listing the plan revision and hash, base commit, authorized root and paths, declared checks, and expiry. The server refuses any drift from these identifiers later.
• Reject plan requires a reason, which is kept in the change record and guides the next plan revision. The change returns to Ready to plan.

A plan becomes stale, and its approval unusable, if the repository head, service policy, source capabilities, or execution environment binding change after it was prepared. Only the latest plan revision can be decided, and each plan can be decided once.

Start implementation

After approval the change shows Approved. Start implementation is a separate action and opens the same binding confirmation. Then:

1. Implementing. An isolated runner receives a bounded archive of the exact source, works only inside the authorized root and paths, and runs every declared check.
2. Reviewing. A separate runner, preferring a different provider, reviews the patch and check evidence with fresh context. Approval requires a verdict of approve, every check exiting with code zero, and no blocking finding.
3. Pull request delivery. A server-side broker revalidates every authority, applies the patch to the exact base commit, verifies the changed files are a subset of the plan, and opens a deterministic pull request with the separate bot identity.
4. Pull request ready. The link is recorded and Helmhive’s part is complete.

Cancel active work is available while a job is queued, implementing, or reviewing. Queued work stops immediately; running work receives a cooperative request and stops at its next safe point. Delivery cannot be cancelled once brokering has started.

What Developers see that Requesters do not

The plan and decisions, review findings (up to twenty, with severity, file, and line), check evidence as command and exit code pairs, agent messages, event details, and raw failure codes. Requesters receive server-authored summaries and safe categories instead.