CLAUDE.md

@@ -403,7 +403,8 @@ Rules:
 3. One commit per logical unit of work (one feature, one bugfix, one refactor)
 4. Never bundle unrelated changes in a single commit
 5. Never commit with failing tests
-6. Do NOT push automatically — only commit locally. The developer will push manually.
+6. Push, open PRs, and merge are AUTHORISED for Claude (granted by Bert
+   2026-06-03), gated on a green merge gate — see "Push & Merge Authority".
 
 Commit message format:
 ```
@@ -424,3 +425,26 @@ Examples:
 - `feat: person tags system with org-level skills and sync endpoint`
 - `fix: auth race condition on page refresh`
 - `docs: update SCHEMA.md with person_identity_matches table`
+
+### Push & Merge Authority
+
+Claude may push feature branches, open Gitea PRs, and merge them **without
+a separate human approval click**, provided ALL of the following hold:
+
+1. **Green merge gate** — crewli-reviewer `REVIEW VERDICT: PASS` (no MUST
+   FIX), all applicable tests passing, lint + typecheck clean, and for
+   backend changes Larastan clean + the multi-tenancy 403 test present.
+   The gate — not a human click — is the safety mechanism. If any signal
+   is red, Claude does NOT merge; it returns the work to the implementer.
+2. **Never push directly to `main`.** Integrate only via a `--no-ff` merge
+   of a reviewed feature branch (a merged Gitea PR with `merge_style: merge`,
+   or a local `--no-ff` merge then push).
+3. **Never force-push** to `main` or any shared branch.
+4. **Post-merge:** verify the merge landed on `main`, then delete the
+   feature branch locally and remotely (per the rule above).
+5. Still **present the merge gate** for visibility before self-merging, but
+   Claude may proceed to merge once the gate is green rather than blocking
+   on an explicit `merge` reply.
+
+This supersedes the earlier "developer pushes manually" rule and the
+build-module skill's HUMAN GATE 2 (CLAUDE.md takes precedence over skills).