fix(kickstart): prefer az acr build and safeguards validation in cloudshell

AGENTS.md

@@ -14,8 +14,8 @@ Guides users through deploying an application to AKS Automatic in seven sequenti
 1. **Discover** — Understand the app (language, deps, ports, env vars) and map each service's structure (build context, entry point, existing Dockerfile path)
 2. **Configure Infrastructure** — Create new or select existing Azure resources (RG, AKS, ACR). Cluster creates with `--no-wait` to run in background.
 3. **Design** — Propose target architecture, get approval
-4. **Generate** — Create Dockerfile (reuse existing when present, validate every COPY/ADD path, build & inspect the image), K8s manifests, Bicep, GitHub Actions workflow
-5. **Review** — Validate artifacts against safeguards and security checks, confirm the Dockerfile source→destination map, verify the image builds
+4. **Generate** — Create Dockerfile (reuse existing when present, validate every COPY/ADD path, build remotely with ACR), K8s manifests, Bicep, GitHub Actions workflow
+5. **Review** — Validate artifacts against safeguards and security checks, confirm the Dockerfile source→destination map resolves the entry point, verify the ACR build succeeds
 6. **Pre-Deploy Check** — Verify cluster is ready, ACR attached
 7. **Deploy** — Build (per-service build context + Dockerfile path, never `.`), push, apply with `az` CLI and `kubectl`, then health-check the running app
 

agents/kickstart-reviewer.agent.md

@@ -19,11 +19,13 @@ You review deployment artifacts generated by the Kickstart agent. Your job is to
 ## Review Process
 
 1. Invoke `/kickstart-review` for the full per-artifact checklist (Dockerfile, Kubernetes manifests, Bicep, GitHub Actions) plus dry-run validation (`kubectl apply --dry-run=client`, `az bicep build`).
-2. Invoke `/kickstart-safeguard-checklist` to validate manifests against AKS deployment safeguard rules.
+2. Invoke `/kickstart-safeguard-checklist` to validate manifests against AKS deployment safeguard rules. Report **Part A** (policy-enforced AKS Deployment Safeguards) separately from **Part B** (pod security / best practice), and treat a FAIL on a *mutating* safeguard (A2 requests, A3 spread/anti-affinity, and A6 when generated node-pool configuration is in scope) as a real defect — the cluster will rewrite the object rather than reject it, so it must be fixed in the generated artifact.
 3. Invoke `/kickstart-security-hardening` for security-specific checks (RBAC scope, Key Vault, encryption, network isolation).
 
 Work through every generated artifact against those checklists — do not re-derive the criteria here.
 
 ## Output
 
 Present findings as a checklist with **PASS** ✓, **FAIL** ✗, or **WARN** ⚠ for each item. If any FAIL items exist, list specific fixes needed.
+
+Prefer `az acr build` for images; never require local Docker output or tell the user to install Docker. Verify the entry point by reconciling final-stage `COPY`/`ADD` destinations, `WORKDIR`, and `CMD`/`ENTRYPOINT`; do not inject shell commands into distroless or `scratch` final stages.

agents/kickstart.agent.md

@@ -66,7 +66,7 @@ Handle each starting point (ask via `vscode_askQuestions` only when it wasn't al
     }]
   }
   ```
-  Clone with `run_in_terminal`, then load `/kickstart-samples` for the pre-filled profile and confirm it with the user. **Skip Phase 1's questions** — go straight to **Phase 2 (Configure Infrastructure)**. Do NOT ask the user for app name, port, language, or any discovery questions — but still run the quick structure scan from `/kickstart-samples` to confirm each service's build context, Dockerfile path, and entry point before generating anything.
+  Clone with `run_in_terminal`, then load `/kickstart-samples` for the pre-filled profile and confirm it with the user. **Skip Phase 1's questions** — go straight to **Phase 2 (Configure Infrastructure)**. Do NOT ask the user for app name, port, language, or any discovery questions — but still run the quick structure scan from `/kickstart-samples` to confirm each service's build context, Dockerfile path, and entry point, before generating anything.
 - **Use my current workspace**: Proceed to **Phase 1 (Discover)**.
 
 ## Phases
@@ -85,15 +85,15 @@ Follow `/kickstart-configure-infra`. Do NOT pick subscriptions or run `az aks cr
 Follow `/kickstart-design`. Present architecture summary (container strategy, AKS Automatic, Gateway API, Workload Identity, ACR, monitoring). Get user approval via `vscode_askQuestions`. Run `/kickstart-cluster-status` before transitioning.
 
 ### 4 — Generate
-Follow `/kickstart-generate`. Produce Dockerfile (reuse an existing one when present), K8s manifests (`k8s/`), Bicep (`infra/`), GitHub Actions workflow — driven by the structure map, with every `COPY`/`ADD` path validated against the build context. Use actual resource names from Phase 2. Pin image tags — never `:latest`. Build and inspect each image (confirm the entry point landed) before exiting. Run `/kickstart-cluster-status` before transitioning.
+Follow `/kickstart-generate`. Produce Dockerfile (reuse an existing one when present), K8s manifests (`k8s/`), Bicep (`infra/`), GitHub Actions workflow — driven by the structure map, with every `COPY`/`ADD` path validated against the build context. Use actual resource names from Phase 2. Pin image tags — never `:latest`. Emit manifests that already satisfy the mutating AKS Deployment Safeguards (CPU/memory **requests**, `topologySpreadConstraints` or pod anti-affinity, unique per-service Service selectors, probes, CSI `storageClassName`, no `kubernetes.azure.com/*` labels) and omit `CriticalAddonsOnly` tolerations from app workloads as a best practice. Preflight ACR build permissions, then build each image with `az acr build` and validate the final-stage source→destination map resolves the entry point. Run `/kickstart-cluster-status` before transitioning.
 
 ### 5 — Review
-Follow `/kickstart-review`. Show the Dockerfile source→destination map for confirmation and verify the image builds with the entry point present, then run `/kickstart-safeguard-checklist` validation. Present pass/fail/warn checklist. Fix failures before proceeding. Run `/kickstart-cluster-status` before transitioning.
+Follow `/kickstart-review`. Show the Dockerfile source→destination map for confirmation and verify the image builds via `az acr build` with its final-stage paths resolving the entry point — then run `/kickstart-safeguard-checklist` validation. Present pass/fail/warn checklist. Fix failures before proceeding. Run `/kickstart-cluster-status` before transitioning.
 
 ### 6 — Pre-Deploy Check
 Follow `/kickstart-handoff` — it carries the full strict-order playbook: cluster readiness (6a), metadata detection (6b), ACR attachment verification (6c — idempotent; the registry is usually already attached during cluster setup), kubelogin (6d), and the consolidated permission probes (6e–6g) via the bundled `aks.checkDeploymentPermissions` command. Escalate through `/kickstart-pim-activation` whenever a role assignment returns 403. Confirm readiness with the user via `vscode_askQuestions` before deploying.
 
 ### 7 — Deploy
-Follow `/kickstart-deploy` — build & push to ACR (using each service's build context and Dockerfile path from the structure map, never `.`), get credentials, apply manifests, then verify and health-check the running app (hit its endpoint, compare expected vs actual — not just pod readiness), executed step by step via `run_in_terminal` with confirmation between each and error classification on failure.
+Follow `/kickstart-deploy` — prefer building and pushing with server-side `az acr build`, using each service's build context and Dockerfile path from the structure map (never `.`); get credentials, apply manifests, then verify and health-check the running app (hit its endpoint, compare expected vs actual — not just pod readiness), executed step by step via `run_in_terminal` with confirmation between each and error classification on failure.
 
 Once the app is running, offer to commit the generated artifacts (Dockerfile, `k8s/`, `infra/`, workflow). If the user wants to commit or open a PR, follow `/kickstart-github-pr-conventions` for branch naming, Conventional Commits, and PR structure.

kickstart-guide.md

@@ -74,8 +74,8 @@ The main agent follows seven phases in strict order. Each phase has a dedicated
 | 1. Discover | `/kickstart-discover` | Collect app name, language, framework, deps, port, env vars, Dockerfile/CI status; map each service's build context, entry point, and existing Dockerfile path | Enough info to propose architecture + structure mapped |
 | 2. Configure | `/kickstart-configure-infra` | Create new or select existing Azure resources (RG, AKS cluster, ACR). Cluster creates with `--no-wait` | Resources selected/creating |
 | 3. Design | `/kickstart-design` | Propose AKS Automatic architecture, get user approval | User approves |
-| 4. Generate | `/kickstart-generate` | Create Dockerfile (reuse existing, validate COPY/ADD paths, build & inspect image), K8s manifests, Bicep, GHA workflow | All files written + image builds |
-| 5. Review | `/kickstart-review` | Confirm Dockerfile source→destination map, verify image builds, validate artifacts against safeguards + security | All checks pass |
+| 4. Generate | `/kickstart-generate` | Create Dockerfile (reuse existing, validate COPY/ADD paths, build remotely with ACR), K8s manifests, Bicep, GHA workflow | All files written + ACR build succeeds |
+| 5. Review | `/kickstart-review` | Confirm Dockerfile source→destination map resolves the entry point, verify ACR build, validate artifacts against safeguards + security | All checks pass |
 | 6. Pre-Deploy | `/kickstart-handoff` | Verify cluster ready, ACR attached, final summary | Cluster provisioned, user confirms |
 | 7. Deploy | `/kickstart-deploy` | Build (per-service context + Dockerfile path), push, apply with `az` and `kubectl`, health-check endpoint | App running + endpoint verified |
 

skills/kickstart-deploy/SKILL.md

@@ -11,12 +11,16 @@ Deploy using Azure CLI and `kubectl`. Execute each step via `run_in_terminal`, c
 ## Steps
 
 1. **Build and push**: `az acr build --registry <acr> --image <image>:<tag> -f <dockerfilePath> <buildContext>`
+   Prefer `az acr build` over `docker build` + `docker push`. It runs on ACR's remote task builders, avoids a local Docker daemon dependency, and keeps the pushed digest and deployed image on one build path.
    Use the build context and Dockerfile path from the structure map — never assume repo root (`.`). For monorepos, build each service from its own context. Tag with a version (e.g. v1.0.0), never `:latest`.
+   Requires the ACR build and push permissions verified in Generate and Pre-Deploy. Make sure `.dockerignore` excludes bulk because the whole context is uploaded on each build.
+   Third-party images the app depends on (Redis, Postgres, RabbitMQ) can't be `az acr build`-ed — bring them in with `az acr import --name <acr> --source docker.io/library/<img>:<tag> --image <img>:<tag>`.
 
 2. **Get credentials**: `az aks get-credentials --resource-group <rg> --name <cluster> --overwrite-existing`
    kubelogin handles AAD auth automatically (verified in Pre-Deploy Check). Never use `--admin`.
 
-3. **Apply manifests**: `kubectl apply -f k8s/`
+3. **Apply manifests**: preview with `kubectl apply --dry-run=server -f k8s/`, then `kubectl apply -f k8s/`.
+   Expect mutation: AKS Automatic's Deployment Safeguards rewrite on admission — missing CPU/memory requests get defaults and missing spread rules get anti-affinity/topology constraints. If Phase 4 generated compliant manifests these are no-ops; if `kubectl get -o yaml` differs from your file, inspect the safeguard mutation before treating it as a bug.
 
 4. **Verify**: `kubectl get pods -n <namespace>` and `kubectl get services -n <namespace>`
    If pods not Ready, run `kubectl describe pod <name>` and `kubectl logs <name>` to diagnose.
@@ -33,6 +37,7 @@ Classify failures:
 - **config** — missing or invalid configuration (subscription, RG, cluster, ACR, manifest)
 - **dependency** — missing CLI tool, extension, or container image
 - **cluster** — pod CrashLoopBackOff, ImagePullBackOff, scheduling, quota
+- **safeguard** — admission rejected by a Deployment Safeguard (e.g. `:latest` tag, non-CSI StorageClass, duplicate Service selector, AKS-reserved label, node edit). Fix the manifest to satisfy the rule; never disable the policy.
 
 Provide specific `az` or `kubectl` fix commands. Offer retry via `vscode_askQuestions`.
 

skills/kickstart-discover/SKILL.md

@@ -26,6 +26,12 @@ Never assume a flat repo. Apps often live in nested or monorepo layouts (`src/<s
 
 Use `codebase`/`search` to confirm each path actually exists — do not infer it from the language alone. Surface this map to the user and let them correct it before proceeding.
 
+## Build environment
+
+Prefer **`az acr build`** for container images. It builds on ACR's remote task builders, avoids depending on a local Docker daemon, and uses the same build-and-push path in every environment.
+
+`az acr build` needs the Phase 2 ACR to exist and the caller to hold the required ACR build and push permissions. Keep `.dockerignore` tight because the whole build context uploads on every build.
+
 ## What to collect
 
 - App name
@@ -43,4 +49,4 @@ Use `codebase`/`search` to confirm each path actually exists — do not infer it
 - When the answer is open-ended (app name), use `allowFreeformInput: true`.
 
 ## Exit Criteria
-You know the app name, language, framework, port, key deps, env vars, CI status, and a confirmed per-service structure map (build context + entry point + existing Dockerfile path) for every deployable service. Announce: "Discovery complete — moving to Configure Infrastructure."
+You know the app name, language, framework, port, key deps, env vars, CI status, a confirmed per-service structure map (build context + entry point + existing Dockerfile path) for every deployable service. Announce: "Discovery complete — moving to Configure Infrastructure."