docs(framework): canonize merge-authority policy (hard gate 13 + E2E gate note)
All checks were successful
ci/woodpecker/push/ci Pipeline was successful
ci/woodpecker/pr/ci Pipeline was successful

Coordinated work: post-review merge go-ahead belongs to the active
coordinator/orchestrator session; solo delivery merges without routine
confirmation as before. 'No self-merge' means no UNREVIEWED self-merge.

Previously this policy existed only as per-host local patches to the
preserved ~/.config/mosaic/AGENTS.md (web1 + sb-it-mgr-0-lt rule 38) and
was lost from E2E-DELIVERY.md on every framework sync. Shipping it in
defaults/AGENTS.md + guides/E2E-DELIVERY.md makes it permanent for fresh
installs and upgrades.

Policy: Jason, 2026-06-11.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Hermes Agent
2026-06-11 18:41:59 -05:00
parent aa221bf92e
commit 01b05614ff
2 changed files with 6 additions and 0 deletions

View File

@@ -34,6 +34,7 @@ At session start, additionally:
10. Manual `docker build` / `docker push` for deployment is FORBIDDEN when CI/CD pipelines exist in the repository. CI is the ONLY canonical build path for container images. 10. Manual `docker build` / `docker push` for deployment is FORBIDDEN when CI/CD pipelines exist in the repository. CI is the ONLY canonical build path for container images.
11. Before ANY build or deployment action, you MUST check for existing CI/CD pipeline configuration (`.woodpecker/`, `.woodpecker.yml`, `.github/workflows/`, etc.). If pipelines exist, use them — do not build locally. 11. Before ANY build or deployment action, you MUST check for existing CI/CD pipeline configuration (`.woodpecker/`, `.woodpecker.yml`, `.github/workflows/`, etc.). If pipelines exist, use them — do not build locally.
12. The mandatory intake procedure is NOT conditional on perceived task complexity. A "simple" commit-push-deploy task has the same procedural requirements as a multi-file feature. Skipping intake because a task "seems simple" is the most common framework violation. 12. The mandatory intake procedure is NOT conditional on perceived task complexity. A "simple" commit-push-deploy task has the same procedural requirements as a multi-file feature. Skipping intake because a task "seems simple" is the most common framework violation.
13. **Merge authority (coordinated work):** when a coordinator/orchestrator session is active for the work, the post-review MERGE GO-AHEAD is the coordinator's to give — once code has passed the required review gates, request the coordinator's go-ahead and merge on their confirmation; do NOT wait on the human owner personally. Solo (uncoordinated) delivery keeps the default: merge without routine confirmation per gates 2 and 9. A "No self-merge" note on a PR means no UNREVIEWED self-merge — it does not suspend coordinator-authorized merges. (Policy: Jason, 2026-06-11.)
## Non-Negotiable Operating Rules (condensed — full detail in `guides/E2E-DELIVERY.md`) ## Non-Negotiable Operating Rules (condensed — full detail in `guides/E2E-DELIVERY.md`)

View File

@@ -88,6 +88,11 @@ For implementation work, you MUST run this cycle in order:
### Post-PR Hard Gate (Execute Sequentially, No Exceptions) ### Post-PR Hard Gate (Execute Sequentially, No Exceptions)
> **Merge authority:** if a coordinator/orchestrator session is active for this
> work, obtain the coordinator's merge go-ahead after review passes, then run
> the gate (AGENTS.md hard gate "Merge authority"). Solo delivery proceeds
> without asking.
1. `~/.config/mosaic/tools/git/ci-queue-wait.sh --purpose merge -B main` 1. `~/.config/mosaic/tools/git/ci-queue-wait.sh --purpose merge -B main`
2. `~/.config/mosaic/tools/git/pr-merge.sh -n <PR_NUMBER> -m squash` 2. `~/.config/mosaic/tools/git/pr-merge.sh -n <PR_NUMBER> -m squash`
3. `~/.config/mosaic/tools/git/pr-ci-wait.sh -n <PR_NUMBER>` 3. `~/.config/mosaic/tools/git/pr-ci-wait.sh -n <PR_NUMBER>`