@raishin/vanguard-frontier-agentic 2.8.0 → 2.10.0

package/skills/azure/azure-ai-foundry-ops-governor/references/official-sources.md

@@ -1,25 +1,29 @@
-# Official Sources
+# Official sources for Azure AI Foundry Ops Governor
 
-## References
+Use this file to ground reviews in Microsoft Learn documentation through the user's configured documentation MCP. Documentation evidence proves Microsoft-published behavior; it does not prove the user's tenant, RBAC, quotas, network routes, deployed resources, or production readiness.
 
-Load only what is needed:
-- Microsoft Foundry architecture
-- Microsoft Foundry rollout planning
-- Foundry RBAC guidance
-- Foundry MCP security best practices
-- Foundry network isolation guidance
-- Foundry quota and monitoring guidance
-- Azure MCP Server tools inventory
+## Primary Microsoft Learn sources
 
-## Official Sources
+| Source | Review implication |
+| --- | --- |
+| [Microsoft Foundry architecture](https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture) | Treat the Foundry resource as the governance/security/network/deployment boundary and projects as team development boundaries. Verify connected resources separately. |
+| [Role-based access control for Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/concepts/rbac-foundry) | Validate scope and role fit. Do not recommend broad Owner/Contributor when Foundry-specific roles or split data/control-plane roles are enough. |
+| [Azure AI security best practices](https://learn.microsoft.com/en-us/azure/security/fundamentals/ai-security-best-practices) | Ground network isolation, least privilege, model governance, secure compute, and monitoring recommendations. |
+| [Configure secure networking for Azure AI platform services](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/platform/networking) | Use for private endpoint and supporting-service network-boundary checks. |
+| [Foundry Model Context Protocol security best practices](https://learn.microsoft.com/en-us/azure/foundry/mcp/security-best-practices) | Use only for Foundry product MCP behavior, identity, RBAC categories, and Conditional Access review. Do not confuse product documentation with evidence about this user's runtime. |
+| [Feature availability across cloud regions](https://learn.microsoft.com/en-us/azure/foundry/reference/region-support) | Confirm model, agent, evaluation, and feature regional support before endorsing a rollout. |
+| [Azure OpenAI quotas and limits](https://learn.microsoft.com/en-us/azure/foundry/openai/quotas-limits) | Treat quota as regional and deployment-dependent; require configured-environment evidence before claiming capacity. |
+| [Agent Service limits, quotas, and regions](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/limits-quotas-regions) | Use for agent-specific limit checks; do not extrapolate from model quota alone. |
 
-- Microsoft Foundry architecture: https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture
-- Role-based access control for Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/concepts/rbac-foundry
-- Microsoft Foundry rollout across my organization: https://learn.microsoft.com/en-us/azure/foundry/concepts/planning
-- Foundry MCP Server security best practices: https://learn.microsoft.com/en-us/azure/foundry/mcp/security-best-practices?view=foundry
-- Configure network isolation for Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/how-to/configure-private-link
-- Configure managed virtual network for Microsoft Foundry projects: https://learn.microsoft.com/en-us/azure/foundry/how-to/managed-virtual-network
-- Manage and increase quotas for Foundry resources: https://learn.microsoft.com/en-us/azure/foundry/how-to/quota
-- Microsoft Foundry Models quotas and limits: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/quotas-limits
-- Monitor model deployments in Microsoft Foundry Models: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/monitor-models
-- Azure MCP Server tools inventory: https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/
+## Source-grounding rules
+
+- Documentation claim: cite the relevant Microsoft Learn source and state it as documented behavior.
+- Current environment claim: require sampled read-only Azure evidence or user-provided sanitized output.
+- Inference: label it as inference and identify the missing proof.
+- Unsupported claim: do not include it. Push back and ask for safe evidence instead.
+
+## Release-note deltas to keep current
+
+- Foundry role names can appear under old or new names during rollout. Prefer role definition IDs when writing automation, and explain the rename instead of treating one label as wrong.
+- Some APIs and UI paths are project-scoped while others remain resource-scoped. Verify scope before recommending automation.
+- Regional availability varies by model, deployment type, agents, evaluations, and quota. A successful design in one region does not prove availability in another.

package/skills/azure/azure-ai-foundry-ops-governor/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist for Azure AI Foundry Ops Governor
+
+## Non-negotiable gates
+
+- Do not ask for keys, connection strings, tokens, tenant identifiers, subscription identifiers, private data, or prompts containing customer data.
+- Prefer Microsoft Entra ID and managed identity. Treat key-based authentication as a risk because it bypasses granular RBAC boundaries.
+- Separate Foundry resource scope from project scope before reviewing access, quota, networking, or deployment rights.
+- Verify connected Storage, Key Vault, AI Search, networking, logging, and monitoring as separate Azure resources; do not assume Foundry configuration governs them.
+- Require explicit approval before any write, delete, role assignment, network change, deployment change, model deployment, quota movement, diagnostic retention, guardrail, tool-registration, or data residency mutation.
+
+## High-risk assumptions to kill
+
+- "Project isolation means dependency isolation." It does not; connected resources have their own access and network controls.
+- "Contributor is fine for developers." Usually too broad; challenge with Foundry-specific roles and scoped assignments.
+- "The model is available because it appears in docs." Docs do not prove regional or tenant quota availability.
+- "Private endpoint on Foundry secures the whole workload." Supporting resources and outbound paths still need verification.
+- "Tool access is harmless because it is just an assistant." Tool operations inherit identity, RBAC, policy, network, and approval risks.
+
+## Evidence labels
+
+- `docs_only`: Microsoft Learn evidence only. Safe for design guidance, not for tenant assertions.
+- `sampled_read_only`: read-only configured-environment evidence was sampled. State exact scope and timestamp in the answer.
+- `user_supplied`: sanitized user evidence was provided. State that it was not independently verified.
+- `mutation_ready`: docs plus current-state evidence plus explicit approval plus rollback path exist.
+
+## Mutation boundaries
+
+Block or escalate when a plan changes RBAC assignments, project membership, network/public access, Key Vault connections, model deployment or deletion, quota allocations, diagnostic retention, guardrails, tool registration, or data residency posture.
+
+## Minimum safe evidence before approval
+
+- Target Foundry resource and project boundary identified without exposing sensitive IDs.
+- Role scope and role definition checked against Microsoft Learn.
+- Region, deployment type, quota, and feature availability checked for the target scenario.
+- Connected resources reviewed for RBAC, network, and secret boundaries.
+- Diagnostics and audit trail destination identified.
+- Rollback or break-glass path documented for each planned change.

package/skills/azure/azure-ai-foundry-ops-governor/references/workflow-and-output.md

@@ -1,96 +1,39 @@
-# Workflow and Output Contract
+# Workflow and output contract for Azure AI Foundry Ops Governor
 
-## Safe Workflow
+## Minimal safe workflow
 
-1. **Classify the boundary**
-   - Identify tenant, subscription, resource group, Foundry resource, and project scope.
-   - Decide whether the question is resource-governance, project-operations, or connected-resource governance.
+1. Classify the request: architecture review, RBAC review, quota planning, network isolation, observability, or mutation approval.
+2. Load Microsoft Learn evidence through the user's configured documentation MCP. Use official sources before drawing conclusions.
+3. Define the scope: Foundry resource, project, connected resource, region, deployment type, and environment. If any are unknown, label the review as partial.
+4. Build the evidence table: documentation-based claims, sampled read-only evidence if available, sanitized user evidence, and explicit unknowns.
+5. Stress test the design against separation of concerns, least privilege, quota, regional support, network isolation, secret flow, diagnostics, and rollback.
+6. Produce a verdict with blockers, safe next actions, and open questions.
+7. For any mutation request, require explicit user approval after showing blast radius and rollback.
 
-2. **Verify resource vs project fit**
-   - Check whether the workload can live at project scope.
-   - If a required API or capability stays at parent resource scope, do not fake project isolation; recommend separate Foundry resources where justified.
-
-3. **Review RBAC and identity model**
-   - Prefer Entra ID and least privilege.
-   - Separate admin, project manager, and project user responsibilities.
-   - Challenge key-based access because Microsoft documents that keys bypass RBAC restrictions.
-
-4. **Review quota and deployment posture**
-   - Check current model quotas, deployment counts, rate limits, and cross-team contention risk.
-   - Distinguish experimentation quota from production quota.
-   - Call out 429 risk, PTU saturation risk, and quota ownership gaps.
-
-5. **Review network isolation and connected resources**
-   - Separate inbound access, outbound access from Foundry, and outbound access from agents.
-   - Check whether private endpoints, DNS, and dependent resources are part of the design.
-   - Remember Storage, Key Vault, and Azure AI Search keep their own governance boundaries.
-
-6. **Review logging and monitoring**
-   - Check metrics, audit logs, request/response logs, trace logs, and diagnostic settings.
-   - Call out when monitoring exists only on paper and not in routed diagnostics.
-
-7. **Gate MCP execution safety**
-   - Read-only discovery first.
-   - Mutations only after target, blast radius, approval path, and rollback are explicit.
-   - Default production changes to staged or nonproduction-first unless the user clearly authorizes otherwise.
-
-8. **Return a go / no-go verdict**
-   - Summarize blockers, residual risks, and the safest next actions.
-
-## Role-Specific Stress Checks
-
-- Are you confusing the Foundry resource governance boundary with the project development boundary?
-- Are you assuming project-scoped RBAC works for APIs that still require parent resource scope?
-- Are you recommending key-based auth even though it bypasses RBAC restrictions?
-- Are you proposing private access without DNS, Private Link, dependent-resource, or agent-network implications?
-- Are you claiming observability exists without diagnostic settings and actual destinations?
-- Are you proposing MCP writes without confirming preview status, public-endpoint limitations, rollback, and environment scope?
-- Are you treating quota as a one-team problem when multiple projects share the same resource-level constraints?
-
-## Output Template
+## Output contract
 
 ```markdown
-# Foundry Operations Governance Review: <scope>
-
 ## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Evidence level: live evidence / documentation-based / sanitized user evidence / inference
-
-## Scope
-- Subscription / resource group:
-- Foundry resource:
-- Project(s):
-- Environment: dev / test / prod
-- Requested action:
+<go | conditional-go | no-go | docs-only advisory>
 
-## Boundary decision
-- Resource-level controls:
-- Project-level controls:
-- Connected resources requiring separate governance:
-- Unsupported or parent-scope-only capabilities:
+## Evidence level
+- Documentation: <sources used>
+- Configured-environment evidence: <sampled / not sampled>
+- User-supplied evidence: <present / absent>
 
 ## Findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
+1. <risk or confirmed control> — Evidence: <docs_only|sampled_read_only|user_supplied|inference>
 
-## Safe execution plan
-1.
-2.
-3.
+## Blockers
+- <missing proof that prevents stronger conclusion>
 
-## Rollout blockers
--
+## Safe next actions
+- <least-privilege, reversible action>
 
 ## Open questions
--
+- <only questions required to reduce risk>
 ```
 
-## Red Flags
+## When to push back
 
-- One Foundry resource is being used as a catch-all for unrelated teams with no cost, quota, or access ownership.
-- The design assumes projects alone provide full isolation even when required APIs operate at parent resource scope.
-- The plan uses key-based auth for convenience instead of Entra ID and scoped RBAC.
-- Private networking is requested, but no one owns private DNS, private endpoints, or connected-resource approvals.
-- Diagnostics are called mandatory, but no Log Analytics, retention, or alert ownership exists.
-- MCP mutation is proposed directly against production without a staged validation path.
+Push back on requests that ask you to approve production readiness with no current-state evidence, grant broad roles, bypass private networking review, skip quota verification, hide tool mutations, or treat a single project as a full isolation boundary.

package/skills/azure/azure-aks-platform-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Operate Azure Kubernetes Service with an adversarial production pos
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.3
+  updated: "2026-06-05"
   category: platform
 ---
 
@@ -32,10 +32,10 @@ Force exact answers on:
 
 Default access posture:
 
-- Prefer Azure MCP read-oriented evidence when the active client exposes useful AKS or related Azure namespaces.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP; use sampled read-oriented Azure evidence when the active client exposes useful AKS or related capabilities.
 - Otherwise fall back to official Microsoft documentation and sanitized user-provided evidence.
 - Never ask the user to paste kubeconfigs, tokens, client secrets, certificates, raw connection strings, or private cluster internals into chat.
-- Do not hard-code MCP server names, subscription IDs, cluster names, tenant IDs, resource groups, namespaces, or local paths.
+- Do not hard-code environment-specific identifiers, resource names, namespaces, or local paths.
 
 ## Trigger Situations
 
@@ -53,7 +53,7 @@ Use this skill when the user asks to:
 
 ## Lean operating rules
 
-- Prefer live Azure or Microsoft evidence first when the active client exposes it; otherwise fall back to official documentation and sanitized user evidence.
+- Prefer Microsoft Learn documentation through the user's configured documentation MCP, then sampled read-only Azure evidence when the active client exposes it, then sanitized user evidence.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, broad scope, destructive changes, and hand-wavy production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -62,7 +62,9 @@ Use this skill when the user asks to:
 
 Load these only when needed:
 
-- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing live Azure evidence, confirming Microsoft MCP capability, or switching to documentation mode.
+- [Operations guide](references/aks-platform-operations.md) — use for service-specific pitfalls, design rules, verification targets, and pushback criteria.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only Azure evidence, or sanitized user evidence.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, and credential boundaries.
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
 - [Official sources](references/official-sources.md) — use when you need the detailed Microsoft documentation list or source notes.
 

package/skills/azure/azure-aks-platform-operator/metadata.json

@@ -14,17 +14,18 @@
   "summary": "Review AKS platform design and operations with a production operator lens across node pools, identity, network policy, scaling, upgrades, rollback safety, and observability readiness.",
   "source_type": "original",
   "official_docs": [
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/",
-    "https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-kubernetes",
     "https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks/baseline-aks",
     "https://learn.microsoft.com/en-us/azure/aks/upgrade-options",
     "https://learn.microsoft.com/en-us/azure/aks/upgrade-conceptual",
     "https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview",
-    "https://learn.microsoft.com/en-us/azure/aks/network-policy-best-practices"
+    "https://learn.microsoft.com/en-us/azure/aks/network-policy-best-practices",
+    "https://learn.microsoft.com/en-us/azure/aks/best-practices-app-cluster-reliability",
+    "https://learn.microsoft.com/en-us/azure/well-architected/service-guides/azure-kubernetes-service",
+    "https://learn.microsoft.com/en-us/azure/architecture/operator-guides/aks/aks-upgrade-practices"
   ],
   "security_notes": "Do not wave through AKS as production ready without explicit upgrade, rollback, workload identity, traffic-control, subnet-capacity, and observability evidence. Treat flat pod networking, static secrets, and untested drain behavior as high-risk.",
-  "last_verified": "2026-04-27",
+  "last_verified": "2026-06-05",
   "path": "skills/azure/azure-aks-platform-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.3"
 }

package/skills/azure/azure-aks-platform-operator/references/aks-platform-operations.md

@@ -0,0 +1,62 @@
+# AKS platform operations
+
+## What people get wrong
+
+- They call AKS production-ready because the cluster exists and nodes are healthy. That ignores ingress, egress, identity, policy, upgrades, subnet capacity, workload health, and recovery.
+- They treat Kubernetes manifests as proof of live posture. Desired state is not current state.
+- They run production upgrades without proving surge capacity, IP availability, PDB behavior, add-on compatibility, or workload drain behavior.
+- They use static credentials in pods instead of workload identity.
+- They enable network policy without a default-deny model, DNS/log exceptions, or engine-specific caveats.
+
+## Officially grounded service shape
+
+Microsoft's AKS baseline architecture frames AKS as a multi-team platform with hub-spoke networking, private endpoints for dependencies, separate system and user node pools, Entra integration, private API options, GitOps-friendly operations, monitoring, and explicit upgrade practices. Microsoft Learn also stresses that Kubernetes evolves quickly and that production updates need testing, maintenance windows, quota, subnet capacity, and rollback strategy.
+
+## Non-negotiable design rules
+
+1. Separate system and user node pools; isolate workload pools when risk, OS, tenancy, or scaling differs.
+2. Plan subnet and pod IP space for scale-out and upgrade surge, not just today's nodes.
+3. Use workload identity or managed identity patterns for Azure access; do not normalize static secrets.
+4. Use network policy intentionally: default deny, specific allows, DNS/logging exceptions, and engine-aware implementation.
+5. Keep image supply chain private and authorized where production reliability or compliance matters.
+6. Test cluster and node upgrades in preproduction before production.
+7. Require telemetry for cluster, nodes, pods, ingress, workloads, and dependencies.
+
+## Minimal safe implementation flow
+
+1. Classify cluster topology and criticality.
+2. Confirm version, node pools, zones, SKU capacity, OS mix, add-ons, and upgrade channel.
+3. Review network: API exposure, ingress, egress, CNI, policy engine, private endpoints, DNS, firewall, and IP capacity.
+4. Review identity: Entra integration for humans; workload identity for pods; least-privilege Azure permissions.
+5. Review workload resilience: replicas, PDBs, probes, requests/limits, autoscaling, affinity, and disruption behavior.
+6. Review operations: GitOps/pipeline flow, monitoring, alerts, backup, incident runbooks, and ownership.
+7. Produce a go/no-go with blockers and reversible remediations.
+
+## High-risk assumptions to kill
+
+- Healthy nodes do not prove workload readiness; probes, PDBs, ingress, egress, dependency access, and rollback behavior still need evidence.
+- An AKS version that is deployable today is not automatically inside the supported window for the intended lifecycle.
+- Cluster autoscaler, upgrade surge, and max-pods settings are unsafe if subnet, pod CIDR, and regional quota headroom are not proven.
+- Network policy is not real isolation without default-deny intent, DNS and telemetry exceptions, and engine-aware validation.
+- GitOps or IaC desired state is not proof of live cluster state unless sampled read-only evidence matches it.
+
+## Safe command/code verification targets
+
+- Inspect IaC for node-pool separation, `maxSurge`, zones, taints, labels, max pods, private API settings, authorized IPs, and maintenance windows.
+- Review manifests for probes, resource requests and limits, PDBs, topology spread, service accounts, and workload identity annotations.
+- Check network policy manifests for explicit namespace/workload selectors, default-deny baselines, DNS allowances, and telemetry egress.
+- Verify pipeline or GitOps configuration includes preproduction promotion, rollback path, and no routine direct `kubectl` production mutation path.
+- Confirm monitoring definitions cover cluster, node, pod, ingress, workload, dependency, 429/throttle-style symptoms, and actionable alerts.
+
+## Safe verification targets
+
+- Kubernetes and node image versions, supported version window, and release notes.
+- Node-pool mode, zones, min/max, surge, max pods, taints, labels, and quotas.
+- Network plugin, policy engine, public/private API, authorized IPs, ingress controller, and egress firewall.
+- Workload identities and federated credentials for Azure resource access.
+- Azure Monitor, Container Insights or managed Prometheus, diagnostic settings, alerts, and SLO dashboards.
+- Backup/recovery or redeploy strategy for cluster state and persistent application data.
+
+## When to push back
+
+Push back on direct production changes, untested automatic upgrades, shared cluster-admin access, public API exposure with no justification, no default-deny policy, subnet plans that ignore surge, or observability claims without metrics and alerts.

package/skills/azure/azure-aks-platform-operator/references/mcp-and-evidence.md

@@ -1,37 +1,27 @@
-# MCP and Evidence Path
+# MCP and evidence path for AKS platform operations
 
-## Official Azure MCP Linkage
+Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscription, RBAC, quotas, deployed resources, or production readiness.
 
-Use official Azure MCP capabilities as configured in the active runtime. Do not assume the server name.
+## Evidence ladder
 
-Relevant namespaces may include:
+1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
+2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
+3. `user_supplied`: sanitized outputs, IaC, diagrams, or metrics provided by the user. Treat as unverified unless independently checked.
+4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.
 
-- `aks` for cluster discovery and cluster configuration evidence,
-- `monitor` for metrics/log signals when available,
-- `applicationinsights` for Application Insights resource discovery only; use `monitor` for most telemetry analysis,
-- `resourcehealth` when platform-health ambiguity exists,
-- `advisor`, `role`, or `policy` only when the question crosses into posture or governance.
+## Rules
 
-Do not invent unsupported AKS mutation flows. Based on current Azure MCP docs, AKS support is clearly cluster-oriented and should be treated primarily as evidence gathering unless the client exposes more.
+- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
+- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, connection strings, private keys, customer data, or raw secrets.
+- If current-state evidence was not sampled, say `not sampled`; do not imply it.
+- If evidence is representative or partial, say so. A sample does not prove broad regional availability or production readiness.
+- Prefer read-only evidence before mutation planning. Stop for approval before write operations.
 
-## Platform-Agnostic Execution
+## Final-answer evidence language
 
-This skill must work in MCP-only, macOS, Linux, and Windows clients.
+Use phrases like:
 
-Prefer:
-
-1. Azure MCP evidence,
-2. official Microsoft Learn and Architecture Center documentation,
-3. sanitized user-provided exports or screenshots,
-4. neutral command or query shapes with `<placeholders>` only when needed.
-
-Do not assume the user runs `kubectl`, Azure CLI, Terraform, Helm, Flux, Argo CD, or GitHub Actions unless they say so.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live Azure evidence beats theory. If live Azure MCP access is unavailable, incomplete, denied, or too risky:
-
-- switch to Microsoft Learn and Azure Architecture Center guidance,
-- ask for sanitized cluster configuration, architecture diagrams, upgrade runbooks, or redacted outputs,
-- label each conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`,
-- do not pretend documentation proves the user’s current cluster state.
+- "Based on Microsoft Learn documentation..."
+- "Configured-environment evidence was not sampled in this review."
+- "The following is an inference from the provided configuration, not proven live state."
+- "This recommendation is mutation-ready only after explicit approval and rollback review."

package/skills/azure/azure-aks-platform-operator/references/official-sources.md

@@ -1,13 +1,29 @@
-# Official Sources
+# Official sources for Azure AKS Platform Operator
 
-## References
+Use Microsoft Learn documentation through the user's configured documentation MCP before making AKS platform claims. Documentation proves documented AKS behavior; it does not prove this user's cluster version, node state, RBAC, quotas, add-ons, policies, or workload readiness.
 
-Load these only when needed:
+## Primary Microsoft Learn sources
 
-- [Azure MCP tools inventory](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/)
-- [Azure Kubernetes Service tools for Azure MCP](https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/tools/azure-kubernetes)
-- [Baseline architecture for an AKS cluster](https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks/baseline-aks)
-- [AKS upgrade options and recommendations](https://learn.microsoft.com/en-us/azure/aks/upgrade-options)
-- [How AKS cluster upgrades work](https://learn.microsoft.com/en-us/azure/aks/upgrade-conceptual)
-- [Microsoft Entra Workload ID for AKS](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview)
-- [AKS network policy best practices](https://learn.microsoft.com/en-us/azure/aks/network-policy-best-practices)
+| Source | Review implication |
+| --- | --- |
+| [Baseline architecture for AKS](https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks/baseline-aks) | Use as the minimum production reference for networking, private API, node pools, image supply chain, identity, GitOps, operations, and upgrade thinking. |
+| [AKS start-here architecture guide](https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks-start-here) | Use to classify baseline, regulated, microservice, and BCDR variants. |
+| [Architecture best practices for AKS](https://learn.microsoft.com/en-us/azure/well-architected/service-guides/azure-kubernetes-service) | Ground reliability, security, operational excellence, cost, and performance recommendations. |
+| [AKS upgrade options](https://learn.microsoft.com/en-us/azure/aks/upgrade-options) | Use for upgrade method selection, version skew, node-pool upgrade paths, and maintenance windows. |
+| [AKS upgrade practices](https://learn.microsoft.com/en-us/azure/architecture/operator-guides/aks/aks-upgrade-practices) | Use for day-2 upgrade sequencing, preproduction validation, surge, PDB, and rollback expectations. |
+| [Workload identity overview](https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview) | Prefer federated workload identity over static secrets for Azure resource access from pods. |
+| [Network policy best practices](https://learn.microsoft.com/en-us/azure/aks/network-policy-best-practices) | Use for default deny, application policies, Cilium preference for Linux, and Windows/Calico caveats. |
+| [Best practices for AKS cluster reliability](https://learn.microsoft.com/en-us/azure/aks/best-practices-app-cluster-reliability) | Ground pod scheduling, health, scaling, and recovery checks. |
+
+## Source-grounding rules
+
+- For architecture: cite Microsoft Learn and label anything cluster-specific as inference unless sampled.
+- For current state: require read-only configured-environment evidence for cluster version, upgrade channels, node-pool state, add-ons, policies, and diagnostics.
+- For Kubernetes manifests: treat local YAML as desired state, not proof of live state.
+- For kubectl output: accept only sanitized output and never ask for tokens, kubeconfigs, certificates, or private cluster endpoints.
+
+## Current review emphasis
+
+- AKS is a day-2 operations commitment, not just a managed control plane.
+- Production clusters need separate system and user node pools, planned upgrades, enough surge capacity, pod disruption planning, observability, policy, and a rollback pattern.
+- Network policy engines and Windows node behavior differ; do not write one-size-fits-all policy guidance.

package/skills/azure/azure-aks-platform-operator/references/safety-checklist.md

@@ -0,0 +1,32 @@
+# Safety checklist for Azure AKS Platform Operator
+
+## Non-negotiable gates
+
+- Never ask for kubeconfig, bearer tokens, client certificates, private endpoint hostnames, cluster-admin credentials, or secret manifests.
+- Do not approve production readiness without evidence for upgrade path, rollback path, node-pool separation, identity, network policy, ingress/egress, diagnostics, and ownership.
+- Treat kubectl-admin access as break-glass, not normal operations. Prefer GitOps or audited pipeline changes for steady-state configuration.
+- Require explicit approval before any write, drain, scale, upgrade, policy, identity, network, or workload mutation.
+- Do not assume AKS Automatic, baseline self-managed AKS, private clusters, Windows node pools, and service-mesh clusters have the same risk profile.
+
+## High-risk assumptions to kill
+
+- "Managed Kubernetes means Microsoft owns day-2 operations." The platform abstracts parts of the control plane, but cluster design and workload operations remain user responsibilities.
+- "The cluster is HA because it has multiple nodes." Node zones, system/user separation, PDBs, replicas, ingress, dependencies, and control-plane SLA matter.
+- "Network policy exists, so east-west traffic is safe." Confirm default deny, DNS/log exceptions, namespace coverage, engine, and Windows behavior.
+- "Autoscaler will save us." Requests/limits, pod disruption, quota, subnet capacity, and initialization time still determine safe scaling.
+- "We can auto-upgrade production." Push back unless preproduction compatibility, maintenance windows, PDBs, quota, and rollback are proven.
+
+## Evidence labels
+
+- `docs_only`: Microsoft Learn-based AKS guidance only.
+- `sampled_read_only`: live or configured-environment evidence was sampled safely. State scope and time.
+- `manifest_review`: repo or user-supplied manifests were reviewed but live state was not proven.
+- `mutation_ready`: current-state evidence, approval, blast radius, and rollback are documented.
+
+## Minimum safe evidence
+
+- Cluster purpose, environment, Kubernetes version, node pools, and operating system mix.
+- Network plugin, policy engine, ingress, egress, private API exposure, and subnet capacity.
+- Identity model for users and workloads.
+- Upgrade channel or manual upgrade process, maintenance window, surge, PDBs, and preproduction validation.
+- Metrics, logs, alerts, backup/recovery, runbooks, and ownership.

package/skills/azure/azure-aks-platform-operator/references/workflow-and-output.md

@@ -1,117 +1,39 @@
-# Workflow and Output Contract
+# Workflow and output contract for Azure AKS Platform Operator
 
-## Safe Workflow
+## Minimal safe workflow
 
-1. **Classify the cluster**
-   - production, preproduction, dev/test, or shared platform,
-   - single-region or multi-region,
-   - public API server or private cluster,
-   - stateless-heavy, stateful, latency-sensitive, regulated, or mixed workload.
-2. **Map ownership**
-   - who owns cluster lifecycle,
-   - who owns workloads,
-   - who owns networking, identity, secrets, and observability,
-   - whether responsibilities are explicit or dangerously fuzzy.
-3. **Check baseline platform shape**
-   - node-pool separation for system versus user workloads,
-   - cluster/network model,
-   - ingress pattern,
-   - IP capacity assumptions,
-   - availability-zone and region posture where relevant.
-4. **Challenge identity and secret assumptions**
-   - workload identity versus legacy credential patterns,
-   - cluster identity and kubelet identity boundaries,
-   - Key Vault or external secret flow,
-   - least-privilege posture and scope.
-5. **Check traffic controls**
-   - network policy presence and intent,
-   - east-west restrictions,
-   - ingress exposure,
-   - egress control assumptions,
-   - private dependency access and DNS implications.
-6. **Check scaling realism**
-   - node autoscaling,
-   - workload HPA/VPA assumptions,
-   - headroom policy,
-   - IP exhaustion risk,
-   - pod density and node sizing assumptions.
-7. **Check upgrade safety**
-   - supported version posture,
-   - in-place versus blue-green strategy,
-   - max surge / max unavailable assumptions,
-   - PDB behavior,
-   - undrainable-node risk,
-   - rollback and validation checkpoints.
-8. **Check observability and operations**
-   - cluster and workload telemetry,
-   - upgrade and failure visibility,
-   - alert quality,
-   - runbooks,
-   - on-call handoff clarity,
-   - recovery drill evidence.
-9. **Return a go / no-go style verdict**
-   - what is credible,
-   - what is fragile,
-   - what is missing,
-   - and what must be validated before any change.
+1. Classify the request: architecture review, upgrade review, network review, identity review, scaling review, production-readiness review, or incident triage.
+2. Ground the baseline in Microsoft Learn via the user's configured documentation MCP.
+3. Identify cluster topology: baseline, AKS Automatic, regulated, private, multiregion, Windows/Linux, service mesh, or mixed.
+4. Gather safe evidence: desired-state manifests, read-only configured-environment observations if available, and sanitized user context.
+5. Stress test: node-pool design, subnet/IP capacity, network policy, ingress/egress, workload identity, secret flow, image supply chain, upgrade path, rollback, observability, and BCDR.
+6. Return a verdict with blockers and safe next actions.
+7. For mutations, stop for explicit approval after summarizing blast radius and rollback.
 
-## Role-Specific Stress Checks
-
-- Reject “AKS is managed so upgrades are easy” as shallow thinking. Managed control plane does not remove node-pool, PDB, IP, or workload-compatibility risk.
-- Reject “we use Kubernetes so we are cloud-native” as meaningless unless operator discipline, upgrade cadence, and observability are proven.
-- If production has no tested rollback path for upgrades, call it out as not operationally ready.
-- If workloads still rely on long-lived secrets where workload identity should be used, flag it.
-- If pod-to-pod traffic is effectively flat and unrestricted, flag the lateral-movement risk.
-- If the cluster subnet is tight and surge or pod density assumptions are hand-wavy, flag IP exhaustion risk.
-- If the platform team cannot explain system versus user node-pool separation, treat that as an operational maturity gap.
-- If the cluster is treated as immutable infrastructure, require a credible replacement-cluster strategy; otherwise require an in-place upgrade strategy.
-
-## Output Template
+## Output contract
 
 ```markdown
-# AKS Platform Review: <scope>
-
 ## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
+<go | conditional-go | no-go | docs-only advisory>
 
-## Cluster context
-- Environment:
-- Region/subscription boundary:
-- Cluster exposure model:
-- Workload profile:
-- Ownership model:
+## Evidence level
+- Documentation: <sources used>
+- Cluster evidence: <sampled_read_only | manifest_review | not sampled>
 
 ## Findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
+1. <finding> — Evidence: <docs_only|sampled_read_only|manifest_review|inference>
 
-## Upgrade and rollback posture
-- Current strategy:
-- Blocking gaps:
-- Validation checkpoints:
-- Rollback path:
+## Upgrade / rollback posture
+- Current proof: <what is known>
+- Gaps: <what is missing>
 
-## Security and identity posture
-- Workload identity:
-- Secret flow:
-- Network policy / ingress / egress:
+## Blockers
+- <production blocker>
 
 ## Safe next actions
-1.
-2.
-3.
-
-## Open questions
--
+- <least-risk action>
 ```
 
-## Red Flags
+## Pushback triggers
 
-- The team wants production AKS guidance but cannot state cluster version, node-pool layout, or upgrade ownership.
-- The design depends on surge upgrades but there is no subnet headroom calculation.
-- The plan assumes Pod Disruption Budgets help, but nobody tested whether they block drains.
-- The platform still depends on static secrets even though Microsoft Entra Workload ID is the safer target model.
-- The answer claims high availability without distinguishing zone resilience, regional failure, and workload replication behavior.
-- The answer recommends AKS by default without testing whether the workload actually needs Kubernetes complexity.
+Reject or downgrade the verdict when the plan skips preproduction upgrades, lacks rollback, uses cluster-admin as normal access, exposes the API publicly without justification, has no network policy/default-deny story, lacks workload identity, or has no health/alert/runbook ownership.