mosaicstack/stack
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases 14 Wiki Activity

docs(framework): canonize merge-authority policy (hard gate 13 + E2E gate note) #537

Merged
jason.woltje merged 1 commits from docs/merge-authority-rule into main 2026-06-11 23:56:21 +00:00
Conversation 0 Commits 1 Files Changed 2 +6
2 changed files with 6 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 01b05614ff - Show all commits

1
packages/mosaic/framework/defaults/AGENTS.md
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`)

5
packages/mosaic/framework/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>`