Description
The policy advisor skill and agent are already comprehensive — they query live subscription state, classify findings by 4-tier severity, generate remediation code (ARM JSON + CLI), and produce split reports (dev template fixes + platform subscription actions). The only structural gap is the absence of a blocking gate that prevents deployment when policy violations are found. This mirrors the existing security gate (Stage 2.5) pattern.
What already exists (no changes needed)
- ARM template policy analysis across 7 resource categories
- Live subscription policy queries (
az policy assignment list, management groups)
- Microsoft Learn runtime lookup for current built-in policies
- 4-tier severity classification (Critical/High/Medium/Low) with Audit/Deny effects
- Split report: Part 1 (template fixes) + Part 2 (subscription actions)
- Auto-remediation suggestions with exact ARM JSON snippets
- Policy-as-code generation (
Microsoft.Authorization/policyAssignments)
- Enforcement mode preference in
copilot-instructions.md (Audit default, Deny for production)
- Pipeline integration at Stage 2.85
Scope (what's needed)
- Stage 2.55 Policy Gate — Add a blocking gate step after the policy advisor runs, mirroring the Stage 2.5 security gate pattern:
🟢 POLICY GATE: PASSED — No Critical or High policy violations. Deployment may proceed.
🔴 POLICY GATE: BLOCKED — Critical or High violations found. Deployment blocked until resolved.
- Override mechanism: user types "I accept the policy risk" (logged as
OVERRIDDEN).
- Config toggle — Formalize the existing audit/deny preference in
copilot-instructions.md or .azure/git-ape.yml as a gate mode:
audit (default) — Policy report is generated and shown but does not block deployment.
deny — Policy findings at Critical/High severity block deployment (gate enforced).
- Workflow integration — Add policy analysis summary to
git-ape-plan.yml PR comment alongside security and cost sections.
Acceptance Criteria
Description
The policy advisor skill and agent are already comprehensive — they query live subscription state, classify findings by 4-tier severity, generate remediation code (ARM JSON + CLI), and produce split reports (dev template fixes + platform subscription actions). The only structural gap is the absence of a blocking gate that prevents deployment when policy violations are found. This mirrors the existing security gate (Stage 2.5) pattern.
What already exists (no changes needed)
az policy assignment list, management groups)Microsoft.Authorization/policyAssignments)copilot-instructions.md(Audit default, Deny for production)Scope (what's needed)
🟢 POLICY GATE: PASSED— No Critical or High policy violations. Deployment may proceed.🔴 POLICY GATE: BLOCKED— Critical or High violations found. Deployment blocked until resolved.OVERRIDDEN).copilot-instructions.mdor.azure/git-ape.ymlas a gate mode:audit(default) — Policy report is generated and shown but does not block deployment.deny— Policy findings at Critical/High severity block deployment (gate enforced).git-ape-plan.ymlPR comment alongside security and cost sections.Acceptance Criteria
audit(non-blocking) ordeny(blocking).