User-impacting review policy

User-impacting review policy

Status: Review policy for changes that touch users, tenants, or operational reliability.

This document distinguishes review layers and defines which changes require which level of review before merge.

Review layers

Layer	Owned by	Replaces
Rubber-duck / self-review	Implementer	Does NOT replace independent human review
Independent human review	CODEOWNERS / designated reviewer	N/A
Automated gates	CI (go vet, go test, go build)	Proves covered invariants only
Repository-enforced approvals	Forgejo branch protection	Configured separately by admins

The implementer’s rubber-duck pass and automated gates do not replace independent human review for user-impacting PRs.

Risk classification

Every PR must be classified against these risk labels. Apply every matching label.

Label	Covers	Required evidence
risk:security	Auth, encryption, credential storage, API access control, tenant isolation, secret handling	Manual audit of credential flow in the diff. Verify no plaintext tokens in logs.
risk:ops	CI/deploy, scheduled jobs, hosting, runtime fallback, database migrations, rollback paths	Migration tested against local DB. Rollback plan documented.
risk:data	Data model changes, schema migrations, data export/import, backward compatibility	Forward-compatible migration. Backward-compatible read path.

If none apply, check N/A with a one-line explanation.

Review routing

Risk label	Review required
risk:security	Mandatory independent human review. Do not auto-merge.
risk:ops + migration	Independent human review. Verify migration in staging.
risk:ops no migration	Rubber-duck review sufficient. Auto-merge allowed.
risk:data	Independent human review. Test migration locally.
None	Rubber-duck review sufficient. Auto-merge allowed.

User-impacting paths

These paths are always considered user-impacting and require independent human review regardless of other risk labels:

1. Credential changes — any change to how tenant forge tokens are stored, encrypted, rotated, or accessed.
2. API surface changes — adding, removing, or changing API endpoints, request/response shapes, or authentication.
3. Database migrations — adding/removing columns, tables, or indexes.
4. Tenant isolation — changes that affect how tenants are separated or how one tenant’s data could leak to another.
5. Merge queue behavior — changes to the engine, staging, bisect, or status reporting logic.
6. Security controls — rate limiting, auth, input validation, error handling that affects security posture.

Enforcement

• Repository-enforced approvals should be configured via Forgejo branch protection rules for main.
• Code owners should be configured in a CODEOWNERS file.
• The risk:security path must never be auto-merged. It must be explicitly approved by a designated reviewer.
• Automated gates (go vet, go test, go build) are always required but are only one layer of review.