Work with changes

This walkthrough is for people who hold a Requester or Developer role on one or more services. Your workspace administrator handles workspace-wide settings and access.

Find your services

Open Services. You see only the services you are assigned to, each with your role badges. A service page has five tabs: Overview, Requests & changes, Activity, Environments, and Policy. The Your access card on the Overview tab lists exactly what you can do here.

If a service you expect is missing, ask an administrator for a service role. Hiding a page is not the same as denying an operation: the server checks every permission independently.

As a Requester

1. From a service page or from Changes, choose Request a change.
2. Pick the service, give the request a short Title, and describe the Desired outcome in plain language. Focus on what should be possible; details come later.
3. Open the change and use Confirm success criteria to write or edit measurable outcomes, one per line. You can do this immediately, or after a clarification thread. Only the original requester can confirm them.
4. Once criteria are confirmed, choose Prepare implementation plan. Planning binds an exact plan that a Developer decides on.

Your change page keeps your brief, criteria, and clarification thread visible, and shows safe lifecycle and pull-request state. Model output, plans, review findings, commands, and raw errors are restricted to Developers. Full guide: Request a change.

As a Developer

1. When a change shows Plan review, open it. The plan card lists scope, affected paths, declared checks, assumptions, risks, protected-path impact, rollback, the repository base commit, the policy revision, and when the approval expires.
2. Choose Approve exact plan or Reject plan with a reason. Approval binds one plan hash; any drift in the repository, policy, or environment makes it stale.
3. Choose Start implementation as a separate action. Isolated runners implement, run the declared checks, and independently review the change. Delivery stops at a pull request.

Full guide: Review and approve a plan.

When something fails

The change page names the failure and offers the one safe next action. Helmhive never retries a repository write on its own. See Recover a failed change.