diff --git a/skills/coding-standards/SKILL.md b/skills/coding-standards/SKILL.md index ed02409..5ac714b 100644 --- a/skills/coding-standards/SKILL.md +++ b/skills/coding-standards/SKILL.md @@ -3,8 +3,9 @@ name: coding-standards description: > Engineering quality bar for GroomBook code: priority ordering of correctness vs. clarity vs. maintainability vs. performance vs. elegance, PR and test - requirements, no-hardcoded-values rules, branch discipline, and the no-self- - merge contract. + requirements, no-hardcoded-values rules, branch discipline, the no-self- + merge contract, and the uat→main merge-gate policy (CTO Gitea Approve + reserved for novel auth, infra/prod-affecting, and risk-flagged merges). --- # Coding Standards @@ -57,6 +58,23 @@ All releases use CalVer (`YYYY.MMDD.PATCH`, e.g. `2026.0504.0`). No SemVer, no c Push to `git.farh.net` only. Never Docker Hub for first-party images. +## uat→main merge-gate policy + +The **CTO Gitea Approve click is not the default gate** on `uat → main` PRs. Once the four pre-gates — **QA**, **UAT deploy**, **UAT regression**, and **security review** — are all green, the engineer self-merges. A CTO Gitea Approve click is required only for PRs in one of the three categories below. + +### Categories that require CTO Gitea Approve + +1. **Novel auth / session paths** — login, OIDC, OOBE, session middleware, token issuance, password reset, MFA, or any new auth provider integration. Routine changes to auth-gated UI (button styling, error messages, form layout, copy edits) are **not** in this category. +2. **Infra / prod-affecting merges** — deploys, infra manifests, secrets, GitOps overlays, CI/CD pipelines, `main` branch protection, production routing/ingress, or any change that mutates prod state. **All Phase 5 infra overlay PRs (`groombook/infra`) require CTO Gitea Approve** without exception. +3. **Risk-flagged merges** — any PR that carries the `risk:cto-approve` label, or where the CTO or CEO has explicitly requested CTO sign-off in the PR or issue thread. + +The engineer who opened the PR classifies it against the three categories above (escalating to the CTO via comment if the call is unclear), then: + +* **In a category** → request a CTO Gitea Approve click. The engineer merges once the CTO has approved. +* **Outside all three categories** → no CTO click needed. The engineer merges once the four pre-gates are green. + +The pre-gates (QA, UAT deploy, UAT regression, security) do **not** change. This rule only removes the CTO Gitea Approve click from the default `uat → main` path for routine PRs that already pass every pre-gate. + ## When uncertain If a code-quality call isn't covered above and you can't decide cleanly, escalate to the CTO via comment rather than guessing. diff --git a/skills/sdlc/SKILL.md b/skills/sdlc/SKILL.md index b5976b3..9dc376a 100644 --- a/skills/sdlc/SKILL.md +++ b/skills/sdlc/SKILL.md @@ -26,7 +26,7 @@ Three long-lived branches map to the three deployment environments: |--------|-------------|-----------|-----------| | `dev` | Dev | Engineer | CI passes | | `uat` | UAT | Engineer | QA code review approval | -| `main` | Production | Engineer | UAT validation & CTO code review | +| `main` | Production | Engineer | UAT validation, security review, and the `coding-standards` uat→main merge-gate policy | **Engineers always target `dev` first** — never `uat` or `main` directly. - Feature branches: `/`. @@ -70,11 +70,14 @@ tea pr create --base dev --title "..." --body "... cc @cpfarhood" 1. **Engineer** opens a PR from `uat` to `main`. 2. **CI** fail → back to **Engineer** (return to Phase 1). -3. **CI** pass → **CTO** performs code review. -4. **CTO** rejected → back to **Engineer** (return to Phase 1). -5. **CTO** approved → **Engineer** merges PR. -6. **CI** fail → back to **Engineer** (return to Phase 1). -7. **CI** pass → Begin Phase 5. +3. **CI** pass → **Engineer** classifies the PR against the `coding-standards` **uat→main merge-gate policy**: + * **In a category that requires CTO Gitea Approve** (novel auth / session paths, infra / prod-affecting merges, `risk:cto-approve` label or explicit CTO/CEO sign-off request) → Engineer pings the CTO for a Gitea Approve click. + * **CTO** rejected → back to **Engineer** (return to Phase 1). + * **CTO** approved → continue to step 4. + * **Outside all three categories** → no CTO click needed; jump to step 4 once the four pre-gates (QA, UAT deploy, UAT regression, security) are green. +4. **Engineer** merges the PR. +5. **CI** fail → back to **Engineer** (return to Phase 1). +6. **CI** pass → Begin Phase 5. ### Phase 5 — Production Deployment