@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-live-app-service-slot-swap-guard/references/rollback-playbook.md

@@ -1,19 +1,23 @@
 # Rollback Playbook: Azure Live App Service Slot Swap Guard
 
+## Evidence-variable convention
+
+Variables such as $AZURE_RESOURCE_GROUP_NAME, $APP_SERVICE_APP_NAME, $DEPLOYMENT_NAME, or $DEPLOYMENT_STACK_NAME are local operator placeholders. Do not commit real values, and redact them from shared evidence unless the change record explicitly allows disclosure.
+
 ## Immediate swap-back (standard rollback path)
 
 The swap operation is symmetric — a second swap returns both slots to their original state.
 
 ```bash
 # Verify current slot state before swapping back
-az webapp show -g <RESOURCE_GROUP> -n <APP_NAME> \
+az webapp show -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
   --query "{hostNames:properties.hostNames}"
-az webapp show -g <RESOURCE_GROUP> -n <APP_NAME> --slot staging \
+az webapp show -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME --slot staging \
   --query "{hostNames:properties.hostNames}"
 
 # Swap back: production → staging (reverts the original swap)
 az webapp deployment slot swap \
-  -g <RESOURCE_GROUP> -n <APP_NAME> \
+  -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
   --slot staging \
   --target-slot production
 ```
@@ -21,21 +25,21 @@ az webapp deployment slot swap \
 ## Verify after rollback
 
 ```bash
-az webapp show -g <RESOURCE_GROUP> -n <APP_NAME> \
+az webapp show -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
   --query "{state:properties.state, defaultHostName:properties.defaultHostName}"
 # Check application health endpoint
-curl -s https://<APP_NAME>.azurewebsites.net/health
+curl -s https://${APP_SERVICE_APP_NAME}.azurewebsites.net/health
 ```
 
 ## Traffic shifting (partial rollback via A/B routing)
 
 ```bash
 # Route 10% of traffic to staging while investigating
-az webapp traffic-routing set -g <RESOURCE_GROUP> -n <APP_NAME> \
+az webapp traffic-routing set -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME \
   --distribution staging=10
 
 # Return all traffic to production
-az webapp traffic-routing clear -g <RESOURCE_GROUP> -n <APP_NAME>
+az webapp traffic-routing clear -g $AZURE_RESOURCE_GROUP_NAME -n $APP_SERVICE_APP_NAME
 ```
 
 ## Rollback limitations

package/skills/azure/azure-live-app-service-slot-swap-guard/references/safety-checklist.md

@@ -0,0 +1,29 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
+- `sampled-current-state`: grounded in read-only Azure or Kubernetes observations from the user's configured tools.
+- `user-provided`: grounded in sanitized snippets supplied by the user.
+- `inference`: reasoned from evidence but not directly proven.
+
+## Mutation boundary
+
+- Default to read-only review.
+- Do not perform create, update, delete, rotate, purge, recover, apply, swap, reset, complete, deploy, assign, revoke, deallocate, quota, budget, or policy changes unless the user explicitly asks and approval is clear.
+- Prefer preview, what-if, dry-run, status, describe, list, show, diff, activity-log, and policy evaluation evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, connection strings, or raw environment dumps.
+- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.
+
+## Risk gates
+
+- Stop on ambiguous target, ambiguous principal, missing approval, missing rollback, missing financial owner, or missing asset owner for high-impact assets.
+- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive deployment behavior, quota increases, budget automation, and production slot swaps as high-risk.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+Never perform a production slot swap without target-slot confirmation, sticky-settings diff, warm-up evidence, authentication limitation check, activity-log monitoring path, and immediate rollback plan.

package/skills/azure/azure-live-app-service-slot-swap-guard/references/slot-swap-operations.md

@@ -0,0 +1,68 @@
+# Azure App Service Slot Swap Operations
+
+Use this reference for current, source-grounded service behavior and the hard live-operation gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Treating a slot as a passive artifact rather than a live app with its own hostname.
+- Swapping directly to production without proving production is the target slot.
+- Ignoring sticky app settings, connection strings, managed identity, VNet integration, and IP restrictions.
+- Assuming swap with preview is always available even when site authentication blocks it.
+- Calling rollback safe without proving immediate same-slot swap-back and health checks.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says App Service deployment slots are live apps and swaps apply target-slot settings to source instances, restart and warm source instances, then switch routing. Swap with preview pauses after target settings are applied so the operator can validate before completing or resetting. Sticky slot settings and warm-up app settings decide whether secrets, connection strings, networking-sensitive settings, and health paths behave safely during swap.
+
+- Deployment slots require supported App Service plan tiers and have plan-specific limits.
+- During swap, source slot is prepared with target settings before routing changes.
+- Swap with preview allows validation after settings apply and before routing cutover.
+- Warm-up uses root or configured warm-up paths and statuses; misconfigured rewrites can break warm-up.
+- Rollback is normally an immediate swap of the same two slots, but stateful side effects still need separate handling.
+
+## Non-negotiable design rules
+
+- Confirm app, source slot, target slot, production target, plan tier, and active principal before any operation.
+- Diff slot-specific settings and connection strings without printing values.
+- Require warm-up path, expected status codes, and health criteria before completion.
+- Use preview for mission-critical swaps unless a documented limitation prevents it.
+- Track pending preview state; complete or reset exactly once.
+
+## Minimal safe implementation flow
+
+- Scope app, resource group, source slot, target slot, hostname, owners, and rollback owner.
+- Collect slot config, sticky settings, route percentages, auth, warm-up settings, health endpoint, and recent activity log evidence.
+- Run or request preview only after explicit approval and preflight evidence.
+- Validate source slot under target settings, then either complete or reset.
+- Verify production health and document rollback posture after cutover.
+
+## High-risk assumptions to kill
+
+- A successful slot swap does not prove dependency, identity, or network readiness; it proves only that App Service completed its documented routing/configuration sequence.
+- Swap with preview is not universally available; site authentication on either slot blocks that path, so the guard must choose reset/swap controls based on documented constraints.
+- Sticky settings are not optional hygiene. Missing slot-specific secrets, connection strings, event bindings, or networking settings can turn a clean platform swap into a production incident.
+- Rollback by swapping back does not undo database migrations, queue consumers, external callbacks, or other stateful side effects.
+- Warm-up success based on the root path is weak evidence unless the app owner has mapped it to real readiness.
+
+## Safe command/code verification targets
+
+- Check source/target slot names, production target, traffic percentages, and pending swap state before issuing preview, swap, or reset.
+- Verify sticky app settings and connection strings by name only; never print values.
+- Confirm warm-up path/status settings and recent activity-log entries for slot-swap operations.
+- Validate source-slot health after preview and production health after completion with app-owner-approved endpoints.
+- Keep reset and same-slot swap-back commands prepared before cutover, with stateful side effects listed separately.
+
+## Safe verification targets
+
+- Production is target slot and source slot is healthy before preview.
+- Sticky settings cover secrets, connection strings, event bindings, auth-sensitive and network-sensitive settings.
+- Warm-up path and statuses match real readiness, not just HTTP 200 from a shallow page.
+- Activity log and app logs can identify swap failures.
+- Rollback command and success criteria are available before action.
+
+## When to push back
+
+- The requested operation skips preview and health checks for a critical app.
+- Settings diff includes unknown secret or network behavior.
+- Authentication, warm-up, or local-cache behavior makes preview unsafe or unsupported.
+- No owner accepts stateful side effects outside slot content/config.

package/skills/azure/azure-live-app-service-slot-swap-guard/references/workflow-and-output.md

@@ -0,0 +1,33 @@
+# Workflow and Output Contract
+
+## Execution flow
+
+1. Scope the exact target, environment boundary, owner, requested operation, approval state, and rollback owner.
+2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
+3. Gather sampled read-only evidence only when available and safe.
+4. Compare observed posture against documented behavior, least-privilege expectations, and live-operation safety rules.
+5. Refuse or defer mutation if target, approval, rollback, or evidence is incomplete.
+6. Return a verdict with evidence level, blockers, safe next actions, and open questions.
+
+## Required output
+
+- `verdict`: pass, warn, fail, or blocked.
+- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
+- `scope`: what was reviewed and what was not reviewed.
+- `approval_status`: explicit approval, missing approval, or not applicable for read-only review.
+- `blockers`: issues that prevent a safe or production-ready conclusion.
+- `findings`: severity-labeled risks with source labels.
+- `rollback_posture`: exact rollback path or explicit non-reversibility caveat.
+- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
+- `open_questions`: missing facts that would change the verdict.
+
+## Stress checks
+
+- What assumption would make this recommendation unsafe?
+- Which role, policy, budget, quota, deployment, swap, or purge action has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as environment-specific proof?
+
+## Response discipline
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior. Use sampled read-only Azure evidence only for current configured-environment observations and label it as sampled evidence.

package/skills/azure/azure-live-arm-deployment-stack-guard/SKILL.md

@@ -4,8 +4,8 @@ description: Guard live ARM, Bicep, and Deployment Stack changes with what-if ev
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: 0.1.5
+  updated: "2026-06-05"
   category: delivery
 ---
 
@@ -25,7 +25,7 @@ Use this skill when:
 
 ## Lean operating rules
 
-- Prefer Azure CLI (`az`) official documentation when available; fall back to Microsoft Learn docs and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-only Azure evidence when available, then sanitized user evidence.
 - Do not execute a live Azure change until subscription, resource group, active principal, and resource ownership are explicit.
 - Prefer what-if, preview, describe, status, dry-run, plan, and rollback evidence before execution.
 - If the request skips preview or rollback design, push back.
@@ -36,9 +36,13 @@ Use this skill when:
 
 Load these only when needed:
 
+- [Azure ARM Deployment Stack Operations](references/deployment-stack-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
 - [Preflight commands](references/preflight-commands.md) — CLI commands to run before any mutation.
 - [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
 - [Permission model](references/permission-model.md) — RBAC role definitions and PIM guidance.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, what-if evidence, deployment stack deny settings, action-on-unmanage choices, stack sync state, and stateful-resource rollback limits.
+- [Workflow and output contract](references/workflow-and-output.md) — execution flow and final response contract.
 - [Official sources](references/official-sources.md) — authoritative Azure documentation links.
 
 ## Response minimum

package/skills/azure/azure-live-arm-deployment-stack-guard/metadata.json

@@ -11,17 +11,18 @@
     "kiro",
     "other"
   ],
-  "summary": "Guard live ARM, Bicep, and Deployment Stack changes with what-if evidence, denySettings review, changeset diff, rollback posture, and approval gates.",
+  "summary": "Guard live ARM, Bicep, and Deployment Stack changes with what-if evidence, deny-settings review, action-on-unmanage safety, managed-resource diff, rollback posture, and approval gates.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-what-if",
-    "https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks",
-    "https://learn.microsoft.com/en-us/azure/role-based-access-control/deny-assignments",
-    "https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/best-practices"
+    "https://learn.microsoft.com/azure/azure-resource-manager/templates/deploy-what-if",
+    "https://learn.microsoft.com/azure/azure-resource-manager/bicep/deployment-stacks",
+    "https://learn.microsoft.com/azure/templates/microsoft.resources/deploymentstacks",
+    "https://learn.microsoft.com/azure/role-based-access-control/deny-assignments",
+    "https://learn.microsoft.com/azure/azure-resource-manager/templates/best-practices"
   ],
-  "security_notes": "Never execute an ARM or Deployment Stack change without what-if evidence, confirmed target scope, denySettings review, and explicit human approval. Repo write access does not authorize live Azure mutations.",
-  "last_verified": "2026-04-30",
+  "security_notes": "Never execute an ARM, Bicep, or Deployment Stack change without confirmed scope, template/parameter provenance, what-if or managed-resource diff, deny-settings review, action-on-unmanage review, rollback constraints, and explicit human approval.",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-live-arm-deployment-stack-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.5"
 }

package/skills/azure/azure-live-arm-deployment-stack-guard/references/deployment-stack-operations.md

@@ -0,0 +1,68 @@
+# Azure ARM Deployment Stack Operations
+
+Use this reference for current, source-grounded service behavior and the hard live-operation gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Treating what-if as optional because the template is in source control.
+- Using deleteAll or deleteResources without listing every managed resource and dependency.
+- Ignoring deny settings exclusions and assuming they protect data-plane child objects.
+- Bypassing stack-out-of-sync warnings by default.
+- Claiming rollback when the change deletes or mutates stateful resources.
+
+## Officially grounded service shape
+
+Microsoft Learn evidence says Deployment Stacks manage a group of resources as one unit, can detach or delete resources removed from the template through actionOnUnmanage, and can protect managed resources with deny settings. Documentation also calls out limitations: stacks do not manage implicitly created resources, deny settings apply to control plane only, some portal support is absent, and out-of-sync warnings require managed-resource review before bypass.
+
+- ARM/Bicep deployments and Deployment Stacks are live control-plane changes.
+- Deployment Stacks add lifecycle ownership, managed-resource tracking, action-on-unmanage behavior, and deny settings.
+- Deny settings can block write/delete control-plane actions but not all data-plane operations or implicit resources.
+- Action-on-unmanage determines whether removed template resources detach or delete.
+- Deployment-stack commands can create or update existing stacks, so idempotency assumptions must be verified.
+
+## Non-negotiable design rules
+
+- Confirm deployment scope: resource group, subscription, or management group.
+- Require exact template, parameters, target scope, and current stack resource list before mutation.
+- Default action-on-unmanage to detach unless deletion is explicitly approved and proven safe.
+- Review deny-settings mode, child-scope behavior, excluded actions, and excluded principals.
+- Never bypass out-of-sync warnings without reviewing managed resources.
+
+## Minimal safe implementation flow
+
+- Scope deployment, stack, template, parameters, active principal, and approval owner.
+- Collect what-if output where supported, existing deployments, stack resources, deny settings, locks, and stateful resources.
+- Classify each change as create, modify, delete, detach, or protection change.
+- Gate execution on rollback limitations and explicit approval.
+- After action, verify provisioning state, managed-resource list, deny settings, and drift indicators.
+
+## High-risk assumptions to kill
+
+- Source-controlled Bicep does not prove safe live state; deployment stacks can delete, detach, or lock resources based on current managed-resource tracking.
+- Deny settings are not a universal lock. Microsoft Learn documents control-plane limits, implicit-resource gaps, data-plane exclusions, and current portal limitations.
+- `deleteAll` or `deleteResources` is not cleanup; it is destructive lifecycle ownership and needs an explicit managed-resource inventory.
+- A stack-out-of-sync bypass is not a normal retry flag. It is only defensible after reviewing the managed resources the service believes it controls.
+- Rollback is not credible for deleted resource groups, networking, identity, Key Vault, or stateful resources without separate recovery evidence.
+
+## Safe command/code verification targets
+
+- Capture stack scope, template source, parameters, deny settings, action-on-unmanage, and managed-resource list before mutation.
+- Run what-if or an equivalent reviewed diff where supported; if unavailable, label that gap and require stronger human approval.
+- Search proposed commands/templates for destructive flags and deny-setting exclusions before execution.
+- Verify provisioning state, synchronized managed-resource list, deny assignments, and locks after action.
+- Treat bypass flags and delete flags as high-risk findings unless approval and recovery evidence are attached.
+
+## Safe verification targets
+
+- What-if or equivalent managed-resource diff is attached and reviewed.
+- No unmanaged deletion is hidden behind action-on-unmanage.
+- Deny settings match intended protection and do not lock out operators unexpectedly.
+- Stateful resources have backup/restore or detach-first plan.
+- Stack status and managed-resource list are synchronized after change.
+
+## When to push back
+
+- The user asks to run deployment without what-if or equivalent diff.
+- Template provenance or parameters are unknown.
+- The change deletes resource groups, Key Vault objects, databases, networking, or identity resources without recovery evidence.
+- A bypass flag is requested as routine behavior.

package/skills/azure/azure-live-arm-deployment-stack-guard/references/mcp-and-evidence.md

@@ -0,0 +1,26 @@
+# Documentation and Evidence Path
+
+## Preferred evidence order
+
+1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
+2. Sampled read-only Azure evidence, when safely available, for current configured-environment observations.
+3. Sanitized user-provided evidence.
+4. Clearly labeled inference.
+
+## What each evidence type can prove
+
+- Microsoft Learn documentation can prove documented service behavior, supported concepts, limitations, and recommended patterns.
+- Sampled read-only evidence can prove the sampled configured state at the time observed.
+- Sanitized user evidence can prove only what the snippet shows.
+- None of these alone prove broad regional availability, future success, full account posture, or production readiness.
+
+## Safe usage pattern
+
+- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
+- Use read-only queries before recommending changes.
+- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
+- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.
+
+## Live-operation rule
+
+For live operations, documentation is never enough. Require target confirmation, current-state evidence, explicit approval, rollback constraints, and post-action verification.

package/skills/azure/azure-live-arm-deployment-stack-guard/references/official-sources.md

@@ -1,17 +1,34 @@
-# Official Sources: Azure Live ARM Deployment Stack Guard
+# Official Sources
 
-## ARM and Bicep deployments
+Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, subscription, RBAC, quota, deployed resources, current cost, vault state, app health, or production readiness.
 
-- https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/best-practices
-- https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-what-if
-- https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/rollback-on-error
+## Primary Microsoft Learn sources
 
-## Deployment Stacks
+- https://learn.microsoft.com/azure/azure-resource-manager/templates/deploy-what-if
+- https://learn.microsoft.com/azure/azure-resource-manager/bicep/deployment-stacks
+- https://learn.microsoft.com/azure/templates/microsoft.resources/deploymentstacks
+- https://learn.microsoft.com/azure/role-based-access-control/deny-assignments
+- https://learn.microsoft.com/azure/azure-resource-manager/templates/best-practices
 
-- https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks
-- https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks-scenarios
+## Grounding notes
 
-## Source-grounding rule
+- Documentation-based claim: Microsoft Learn evidence says Deployment Stacks manage a group of resources as one unit, can detach or delete resources removed from the template through actionOnUnmanage, and can protect managed resources with deny settings. Documentation also calls out limitations: stacks do not manage implicitly created resources, deny settings apply to control plane only, some portal support is absent, and out-of-sync warnings require managed-resource review before bypass.
+- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
+- Live-operation claim: requires target, principal, approval, preflight evidence, rollback constraints, and post-action verification.
+- Inference: allowed only when labeled and tied to observed fields or documented behavior.
+- Do not include sensitive internal identifiers or secret material in findings.
+
+## Source use rules
+
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
+- Use sampled read-only Azure evidence only to validate current configured-environment observations.
+- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
+- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.
+
+## Current Microsoft Learn deltas checked on 2026-06-05
+
+- Deployment Stacks manage resources through Microsoft.Resources/deploymentStacks and action-on-unmanage choices; delete behavior must be explicit before execution.
+- Microsoft Learn still distinguishes ARM/Bicep deployment what-if from Deployment Stack limitations; do not overclaim native stack what-if coverage.
+- Deny settings protect control-plane operations, not data-plane content, and do not cover implicitly created resources.
+- denyDelete, denyWriteAndDelete, exclusions, and deleteAll are governance decisions with materially different blast radius.
 
-Use official Microsoft Learn documentation as source of truth for ARM and Bicep behavior.
-Always verify what-if output against live resource state, not just template assumptions.

package/skills/azure/azure-live-arm-deployment-stack-guard/references/permission-model.md

@@ -13,6 +13,7 @@
     "Microsoft.Resources/deployments/whatIf/action",
     "Microsoft.Resources/deploymentStacks/read",
     "Microsoft.Resources/deploymentStacks/write",
+    "Microsoft.Resources/deploymentStacks/manageDenySetting/action",
     "Microsoft.Resources/subscriptions/resourceGroups/read"
   ],
   "NotActions": [
@@ -21,7 +22,7 @@
   "DataActions": [],
   "NotDataActions": [],
   "AssignableScopes": [
-    "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<TARGET_RG>"
+    "$APPROVED_RESOURCE_GROUP_SCOPE"
   ]
 }
 ```
@@ -42,11 +43,13 @@ PIM-eligible role activated only for confirmed decommission windows (see below).
   ],
   "NotActions": [],
   "AssignableScopes": [
-    "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<TARGET_RG>"
+    "$APPROVED_RESOURCE_GROUP_SCOPE"
   ]
 }
 ```
 
+$APPROVED_RESOURCE_GROUP_SCOPE is a local placeholder for the approved resource group scope from the change record. Do not paste raw subscription or resource identifiers into chat or committed docs.
+
 Assign as **PIM-eligible only**. Require manager approval. Maximum 2-hour activation.
 
 ## Deployment Stacks denySettings recommendation
@@ -66,3 +69,10 @@ Use `denyWriteAndDelete` for compliance-mandated immutable resources.
 - `Contributor` at management-group scope
 - `Microsoft.Resources/*` wildcards
 - `Microsoft.Authorization/roleAssignments/write` (privilege escalation risk)
+
+
+## Deny-setting permission caveat
+
+Microsoft Learn documents dedicated deployment stack roles and a separate `Microsoft.Resources/deploymentStacks/manageDenySetting/action` permission for managing deny settings. If the operator cannot prove this permission with sampled read-only evidence or an approved eligible role activation, do not change deny settings.
+
+Use exact resource scopes from approved change records; do not paste raw subscription identifiers into chat.

package/skills/azure/azure-live-arm-deployment-stack-guard/references/preflight-commands.md

@@ -1,12 +1,18 @@
 # Preflight Commands: Azure Live ARM Deployment Stack Guard
 
+Use shell variables for examples instead of raw identifiers. Populate them from an approved change record or already configured shell context; never paste tenant, subscription, resource, or secret values into chat.
+
+## Evidence-variable convention
+
+Variables such as $AZURE_RESOURCE_GROUP_NAME, $APP_SERVICE_APP_NAME, or $KEY_VAULT_NAME are local operator placeholders. Do not commit real values, and redact them from shared evidence unless the change record explicitly allows disclosure.
+
 Run these before any ARM or Deployment Stack mutation. Paste sanitized output as evidence.
 
 ## 1. Confirm identity and subscription target
 
 ```bash
 az account show --query "{subscription:id, name:name, user:user.name}"
-az group show -n <RESOURCE_GROUP> --query "{name:name, location:location, provisioningState:properties.provisioningState}"
+az group show -n $AZURE_RESOURCE_GROUP_NAME --query "{name:name, location:location, provisioningState:properties.provisioningState}"
 ```
 
 ## 2. Run what-if before any deployment
@@ -14,15 +20,15 @@ az group show -n <RESOURCE_GROUP> --query "{name:name, location:location, provis
 ```bash
 # ARM template what-if
 az deployment group what-if \
-  -g <RESOURCE_GROUP> \
-  --template-file <TEMPLATE.json> \
-  --parameters @<PARAMS.json>
+  -g $AZURE_RESOURCE_GROUP_NAME \
+  --template-file $ARM_TEMPLATE_FILE \
+  --parameters @$ARM_PARAMETERS_FILE
 
 # Bicep what-if
 az deployment group what-if \
-  -g <RESOURCE_GROUP> \
-  --template-file <TEMPLATE.bicep> \
-  --parameters @<PARAMS.bicepparam>
+  -g $AZURE_RESOURCE_GROUP_NAME \
+  --template-file $BICEP_TEMPLATE_FILE \
+  --parameters @$BICEP_PARAMETERS_FILE
 ```
 
 Review the what-if output for resource replacements (marked with `~` or `-/+`).
@@ -33,15 +39,15 @@ explicitly approved before proceeding.
 
 ```bash
 az deployment-stack group show \
-  -n <STACK_NAME> \
-  -g <RESOURCE_GROUP> \
+  -n $DEPLOYMENT_STACK_NAME \
+  -g $AZURE_RESOURCE_GROUP_NAME \
   --query "{provisioningState:provisioningState, denySettings:properties.denySettings, resources:properties.resources[].id}"
 ```
 
 ## 4. List managed resources and their protection status
 
 ```bash
-az deployment-stack group show -n <STACK_NAME> -g <RESOURCE_GROUP> \
+az deployment-stack group show -n $DEPLOYMENT_STACK_NAME -g $AZURE_RESOURCE_GROUP_NAME \
   --query "properties.resources[].{id:id, denyStatus:denyStatus}"
 ```
 
@@ -49,7 +55,12 @@ az deployment-stack group show -n <STACK_NAME> -g <RESOURCE_GROUP> \
 
 ```bash
 az deployment group validate \
-  -g <RESOURCE_GROUP> \
-  --template-file <TEMPLATE.json> \
-  --parameters @<PARAMS.json>
+  -g $AZURE_RESOURCE_GROUP_NAME \
+  --template-file $ARM_TEMPLATE_FILE \
+  --parameters @$ARM_PARAMETERS_FILE
 ```
+
+
+## Deployment Stack what-if caveat
+
+Microsoft Learn currently documents that what-if support is not yet available for Deployment Stacks. Use ARM/Bicep what-if for the underlying deployment where available, then explicitly label any stack-level delete/detach and deny-setting risk that what-if does not prove.

package/skills/azure/azure-live-arm-deployment-stack-guard/references/rollback-playbook.md

@@ -1,14 +1,18 @@
 # Rollback Playbook: Azure Live ARM Deployment Stack Guard
 
+## Evidence-variable convention
+
+Variables such as $AZURE_RESOURCE_GROUP_NAME, $APP_SERVICE_APP_NAME, $DEPLOYMENT_NAME, or $DEPLOYMENT_STACK_NAME are local operator placeholders. Do not commit real values, and redact them from shared evidence unless the change record explicitly allows disclosure.
+
 ## Cancel an in-progress deployment
 
 ```bash
 # List recent deployments to find the in-flight one
-az deployment group list -g <RESOURCE_GROUP> \
+az deployment group list -g $AZURE_RESOURCE_GROUP_NAME \
   --query "[?properties.provisioningState=='Running'].{name:name, timestamp:properties.timestamp}"
 
 # Cancel by name
-az deployment group cancel -g <RESOURCE_GROUP> -n <DEPLOYMENT_NAME>
+az deployment group cancel -g $AZURE_RESOURCE_GROUP_NAME -n $DEPLOYMENT_NAME
 ```
 
 Cancellation is best-effort. Resources already provisioned before cancel are NOT torn down.
@@ -17,19 +21,19 @@ Cancellation is best-effort. Resources already provisioned before cancel are NOT
 
 ```bash
 # List deployment history to find the target
-az deployment group list -g <RESOURCE_GROUP> \
+az deployment group list -g $AZURE_RESOURCE_GROUP_NAME \
   --query "[].{name:name, state:properties.provisioningState, timestamp:properties.timestamp}" \
   --output table
 
 # Export the template from a prior successful deployment
-az deployment group export -g <RESOURCE_GROUP> -n <GOOD_DEPLOYMENT_NAME> \
+az deployment group export -g $AZURE_RESOURCE_GROUP_NAME -n $KNOWN_GOOD_DEPLOYMENT_NAME \
   --output json > rollback-template.json
 
 # Redeploy
 az deployment group create \
-  -g <RESOURCE_GROUP> \
+  -g $AZURE_RESOURCE_GROUP_NAME \
   --template-file rollback-template.json \
-  --parameters @<PARAMS.json>
+  --parameters @$ARM_PARAMETERS_FILE
 ```
 
 ## Deployment Stack — update back to previous config
@@ -37,10 +41,10 @@ az deployment group create \
 ```bash
 # Re-apply the previous stack config (update, not recreate)
 az deployment-stack group create \
-  -n <STACK_NAME> \
-  -g <RESOURCE_GROUP> \
+  -n $DEPLOYMENT_STACK_NAME \
+  -g $AZURE_RESOURCE_GROUP_NAME \
   --template-file rollback-template.json \
-  --parameters @<PARAMS.json> \
+  --parameters @$ARM_PARAMETERS_FILE \
   --action-on-unmanage deleteResources \
   --deny-settings-mode denyDelete
 ```

package/skills/azure/azure-live-arm-deployment-stack-guard/references/safety-checklist.md

@@ -0,0 +1,29 @@
+# Safety Checklist
+
+## Evidence labels
+
+- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
+- `sampled-current-state`: grounded in read-only Azure or Kubernetes observations from the user's configured tools.
+- `user-provided`: grounded in sanitized snippets supplied by the user.
+- `inference`: reasoned from evidence but not directly proven.
+
+## Mutation boundary
+
+- Default to read-only review.
+- Do not perform create, update, delete, rotate, purge, recover, apply, swap, reset, complete, deploy, assign, revoke, deallocate, quota, budget, or policy changes unless the user explicitly asks and approval is clear.
+- Prefer preview, what-if, dry-run, status, describe, list, show, diff, activity-log, and policy evaluation evidence before any mutation.
+
+## Credential and data boundary
+
+- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, connection strings, or raw environment dumps.
+- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.
+
+## Risk gates
+
+- Stop on ambiguous target, ambiguous principal, missing approval, missing rollback, missing financial owner, or missing asset owner for high-impact assets.
+- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive deployment behavior, quota increases, budget automation, and production slot swaps as high-risk.
+- Separate documented product behavior from sampled configured-environment evidence.
+
+## Asset-specific hard line
+
+Never execute an ARM, Bicep, or Deployment Stack change without confirmed scope, template/parameter provenance, what-if or managed-resource diff, deny-settings review, action-on-unmanage review, rollback constraints, and explicit human approval.

package/skills/azure/azure-live-arm-deployment-stack-guard/references/workflow-and-output.md

@@ -0,0 +1,33 @@
+# Workflow and Output Contract
+
+## Execution flow
+
+1. Scope the exact target, environment boundary, owner, requested operation, approval state, and rollback owner.
+2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
+3. Gather sampled read-only evidence only when available and safe.
+4. Compare observed posture against documented behavior, least-privilege expectations, and live-operation safety rules.
+5. Refuse or defer mutation if target, approval, rollback, or evidence is incomplete.
+6. Return a verdict with evidence level, blockers, safe next actions, and open questions.
+
+## Required output
+
+- `verdict`: pass, warn, fail, or blocked.
+- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
+- `scope`: what was reviewed and what was not reviewed.
+- `approval_status`: explicit approval, missing approval, or not applicable for read-only review.
+- `blockers`: issues that prevent a safe or production-ready conclusion.
+- `findings`: severity-labeled risks with source labels.
+- `rollback_posture`: exact rollback path or explicit non-reversibility caveat.
+- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
+- `open_questions`: missing facts that would change the verdict.
+
+## Stress checks
+
+- What assumption would make this recommendation unsafe?
+- Which role, policy, budget, quota, deployment, swap, or purge action has the largest blast radius?
+- What evidence would disprove the claimed readiness?
+- Is the answer accidentally treating documentation as environment-specific proof?
+
+## Response discipline
+
+Use Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior. Use sampled read-only Azure evidence only for current configured-environment observations and label it as sampled evidence.