Decision gate — a team decision
A production decision gate does not ask “did Claude write the code?” It asks “is the team ready to accept the consequences of this change?” It complements tests, CI, and review, and records who is accountable for the decision.
The usual order is: the author prepares the diff and evidence, local review checks the changes, CI runs deterministic checks, and the team decides GO or HOLD while considering risk, approvals, and the ability to roll back.
| Stage | Outcome |
|---|---|
| Personal readiness | The author checked requirements, the diff, tests, and residual risks |
| Local review | Comments on the actual changes were found or rejected |
| CI / quality gate | Automated checks were confirmed |
| Team decision gate | A team decision of GO or HOLD was recorded with a named approver |
Risk level determines the evidence package
For a small PR, the gate can be part of the PR description or release checklist. A separate file is justified when the decision needs broader traceability or repeated reuse.
| Category | Minimum package |
|---|---|
| Low-risk | A short description, relevant diff, and final decision |
| Review-required | Risk, checks, evidence, required approvals, and decision |
| High-risk | Everything listed above, plus a rollback path, constraints, and named approvers |
Risk classification and permissions have different roles
- risk classification determines process strictness and the required review level;
- permissions technically limit the actions available to Claude or an agent;
- the decision gate records the final human decision about merge or release;
- a database migration, auth path, or other new consequence requires re-classification;
- risk must not be reduced silently or merely because of schedule pressure.
How to record GO or HOLD
- Name the change, affected area, and initial risk category.
- Add local review, CI, and staging-check results when they are required.
- Record approvals, the rollback path, and remaining constraints.
- Check that new consequences do not require re-classification.
- Name the responsible approver and record GO or HOLD.
- If evidence is incomplete, keep the decision at HOLD until the gap is closed.
Example: a gate for a refund change
A refund-flow change has a high-risk profile when it affects money, support roles, or an audit log. Green CI is not enough in that case: regression tests, diff review, a staging smoke check, and approvals from the relevant domain owners are required.
Rollback may include a revert, disabling a feature flag, or restoring the previous handler. Merge should remain on hold until checks are complete and the release owner has recorded the final decision.
Canonical lesson source · JavaRush
Open JavaRush material