@raishin/vanguard-frontier-agentic 1.2.0 → 1.4.0

package/skills/sigstore/sigstore-cosign-supply-chain-review/references/workflow-and-output.md

@@ -0,0 +1,196 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the scope and collect raw evidence
+
+1. Confirm the review target: a specific container image, a Kyverno ClusterPolicy/Policy, a CI pipeline signing step, or a SLSA level claim.
+2. For image signing evidence, run:
+   ```bash
+   cosign verify \
+     --certificate-identity-regexp "https://github.com/<org>/<repo>/.github/workflows/" \
+     --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
+     <registry>/<image>:<tag>
+   ```
+   A successful exit means a valid keyless signature exists for that identity + issuer pair. An exit code 1 means no matching signature.
+3. For Kyverno admission policy evidence, run:
+   ```bash
+   kubectl get clusterpolicy,policy -A -o yaml | grep -A 30 "verifyImages"
+   ```
+   Collect every `verifyImages` block. Note whether `attestors.entries.keyless.subject` and `attestors.entries.keyless.issuer` are set.
+4. If Cosign policy-controller is in use instead of Kyverno, collect:
+   ```bash
+   kubectl get clusterimagepolicy -o yaml
+   ```
+   Inspect `spec.authorities[].keyless.identities[].issuer` and `.subject` fields.
+
+### Step 2 — Audit the imageVerify / ClusterImagePolicy identity constraints
+
+The most critical control is whether the admission policy constrains **who** signed the image, not just **that** it was signed.
+
+Check each policy rule for:
+
+1. **`issuer`** — the OIDC token issuer (e.g., `https://token.actions.githubusercontent.com` for GitHub Actions). Without this, any OIDC provider's identity can satisfy the check.
+2. **`subject`** — the specific identity within the issuer (e.g., `https://github.com/org/repo/.github/workflows/release.yml@refs/heads/main`). Without this, any identity at that issuer passes.
+3. **`glob` vs exact match** — subject globs like `https://github.com/org/*` allow any workflow in the org to satisfy the check.
+
+Example of a correctly scoped Kyverno imageVerify rule:
+```yaml
+verifyImages:
+  - imageReferences:
+      - "registry.internal.company.com/*"
+    attestors:
+      - entries:
+          - keyless:
+              subject: "https://github.com/org/repo/.github/workflows/release.yml@refs/heads/main"
+              issuer: "https://token.actions.githubusercontent.com"
+              rekor:
+                url: https://rekor.sigstore.dev
+```
+
+Flag as **CRITICAL** if both `subject` and `issuer` are absent — the policy accepts any Sigstore-signed image regardless of signer.
+
+Flag as **HIGH** if `issuer` is set but `subject` is absent — any identity at that issuer passes (e.g., any GitHub Actions workflow anywhere on GitHub).
+
+### Step 3 — Audit `exclude` rules and policy coverage
+
+1. List all `exclude` blocks in every imageVerify policy:
+   ```bash
+   kubectl get clusterpolicy -o yaml | grep -A 10 "exclude"
+   ```
+2. Flag as **HIGH** any exclude that matches:
+   - A broad registry glob (`docker.io/*`, `*`)
+   - A namespace containing workloads with access to sensitive data
+3. Confirm whether ALL namespace-resident Deployments, StatefulSets, DaemonSets, and Jobs are subject to the policy. Kyverno policies with no `matchResources.namespaceSelector` apply cluster-wide — verify this is intentional.
+
+Example of a dangerous broad exclusion:
+```yaml
+exclude:
+  resources:
+    images:
+      - "docker.io/*"   # All Docker Hub images skip verification
+```
+
+### Step 4 — Audit SLSA provenance attestations
+
+1. Check whether a SLSA provenance attestation exists:
+   ```bash
+   cosign verify-attestation \
+     --type slsaprovenance \
+     --certificate-identity-regexp "https://github.com/<org>/<repo>/" \
+     --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
+     <registry>/<image>:<tag>
+   ```
+2. For images claiming SLSA L2+, verify with slsa-verifier:
+   ```bash
+   slsa-verifier verify-image \
+     --source-uri github.com/<org>/<repo> \
+     --source-branch main \
+     <registry>/<image>:<tag>
+   ```
+3. Check whether the build was ephemeral (GitHub Actions or Tekton Chains) — SLSA L3 requires an ephemeral, isolated build environment. Builds on persistent, developer-accessible runners cannot claim L3.
+
+Flag as **HIGH** if SLSA L2 is claimed but `slsa-verifier verify-image` fails or returns no matching attestation.
+
+### Step 5 — Audit SBOM attestations
+
+1. Verify SBOM attestation presence:
+   ```bash
+   cosign verify-attestation \
+     --type spdxjson \
+     --certificate-identity-regexp "https://github.com/<org>/<repo>/" \
+     --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
+     <registry>/<image>:<tag>
+   ```
+2. For CycloneDX SBOM format:
+   ```bash
+   cosign verify-attestation \
+     --type cyclonedx \
+     <image>
+   ```
+3. Check whether the SBOM was generated at build time (accurate) or at image scan time (less reliable — may miss build-time artifacts).
+4. For workloads handling PII or financial data, flag as **MEDIUM** if no SBOM attestation is present — without an SBOM, dependency vulnerability provenance cannot be confirmed.
+
+### Step 6 — Audit Cosign key management (keyless vs key-based)
+
+1. Check CI pipeline signing steps for evidence of keyless OIDC flow:
+   ```yaml
+   # Correct keyless pattern in GitHub Actions
+   - name: Sign image
+     env:
+       COSIGN_EXPERIMENTAL: "1"   # Enables keyless (OIDC Workload Identity)
+     run: |
+       cosign sign --yes ${{ env.IMAGE_REF }}
+   ```
+2. Flag as **HIGH** if the CI pipeline uses `cosign sign --key cosign.key` or references a `COSIGN_PRIVATE_KEY` secret — long-lived key material in CI secrets is a secret sprawl risk.
+3. Verify that keyless signing uses the correct OIDC token source:
+   - GitHub Actions: `id-token: write` permission must be set in the workflow.
+   - Tekton Chains: `CHAINS-GCP-SERVICE-ACCOUNT` or equivalent OIDC binding must be configured.
+
+Example correct GitHub Actions OIDC signing permission:
+```yaml
+permissions:
+  id-token: write
+  contents: read
+  packages: write
+```
+
+Flag as **HIGH** if `id-token: write` is absent from the workflow — keyless signing will silently fail or fall back to anonymous signing.
+
+### Step 7 — Audit Rekor transparency log posture
+
+1. Check whether public Rekor logging is active (default) or disabled:
+   ```bash
+   # Default: public Rekor is used
+   cosign sign --yes <image>
+
+   # Disabled: no transparency log entry created
+   COSIGN_NO_TLOG=1 cosign sign --yes <image>
+   ```
+2. Flag as **MEDIUM** if `COSIGN_NO_TLOG=1` is set without a private Rekor instance configured — disabling transparency logging removes third-party verifiability and auditability.
+3. For images containing internal service references, infrastructure hostnames, or internal artifact paths, flag public Rekor logging as a **MEDIUM** information disclosure risk. These images should use a private Rekor instance.
+4. To verify a signature was logged to Rekor:
+   ```bash
+   cosign verify \
+     --certificate-identity-regexp "<signer>" \
+     --certificate-oidc-issuer "<issuer>" \
+     <image> | jq '.[0].optional.Bundle.Payload.logIndex'
+   ```
+   A non-null `logIndex` confirms the signature is in the public Rekor transparency log.
+
+### Step 8 — Verify admission enforcement is active
+
+1. Confirm Kyverno is installed and the webhook is active:
+   ```bash
+   kubectl get mutatingwebhookconfiguration,validatingwebhookconfiguration | grep kyverno
+   kubectl get pods -n kyverno
+   ```
+2. Confirm imageVerify policy is in `Enforce` mode (not `Audit`):
+   ```bash
+   kubectl get clusterpolicy <policy-name> -o jsonpath='{.spec.validationFailureAction}'
+   ```
+   `Enforce` blocks non-conforming images at admission. `Audit` only logs — images still deploy.
+3. Flag as **HIGH** if imageVerify policy is in `Audit` mode in production — unsigned images are not blocked.
+
+## Output
+
+Return:
+
+- **target**: image reference, ClusterPolicy name, or CI pipeline step, with the evidence source,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **signing identity**: keyless OIDC (Fulcio) vs long-lived key, with the specific issuer and subject,
+- **admission enforcement**: Kyverno imageVerify / policy-controller / none, with policy mode (Enforce/Audit),
+- **identity constraint audit**: issuer and subject present/absent, glob scope, exclude rule coverage,
+- **attestation inventory**: SLSA provenance present/absent, SBOM present/absent, format,
+- **Rekor posture**: public log / private log / disabled, with information disclosure risk if applicable,
+- **risk findings** (with severity: critical / high / medium / low),
+- **safest next actions** with sample policy or workflow YAML,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend disabling imageVerify enforcement in production to unblock a deployment — the correct path is to fix the signing pipeline.
+- Never recommend broad `exclude` rules as a permanent fix for third-party image coverage gaps.
+- Never request or print private Cosign keys, OIDC tokens, registry credentials, or cosign.key file contents.
+- Always confirm admission policy is in `Enforce` mode before concluding that unsigned images are blocked.
+- A Kyverno imageVerify policy in `Audit` mode with no `Enforce` policy provides zero actual enforcement — treat this as a critical gap.

package/skills/terraform/README.md

@@ -0,0 +1,29 @@
+# 🟩 Terraform Skills
+
+<p align="center">
+  <!-- 🖼️ Add a Terraform logo to assets/logos/cloud/terraform/ and update this path -->
+  <span style="font-size:3.5em">🟩</span>
+</p>
+
+This folder contains Terraform-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **1** local Terraform skill:
+
+- `terraform-maestro`
+
+## Portfolio posture
+
+Terraform skills for evidence-backed IaC review, plan safety, and guarded apply workflows across all cloud providers.
+
+These skills are intentionally conservative:
+
+- always review `terraform plan` output before any apply — never apply without a human-reviewed plan
+- assess blast radius: count resource deletions, replacements, and modifications before approving
+- check for missing `prevent_destroy` lifecycle rules on stateful resources (databases, buckets, vaults)
+- verify backend state locking is enabled before any write operation
+- flag remote state outputs consumed by other stacks — changes may break downstream consumers
+- use official Terraform and provider documentation for resource behavior and provider version compatibility
+
+Run `npm run validate` after changing cataloged Terraform skills.

package/skills/terraform/terraform-maestro/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: terraform-maestro
 description: Route Terraform and IaC tasks to the right specialist from the cross-cloud IaC catalog. Use when you do not already know the specific IaC specialist needed. Not for direct Terraform answers; Maestro classifies, dispatches, and synthesizes only. Dispatches single agent for focused tasks, parallel team (max 4) for multi-domain tasks. Never auto-dispatches live-guard agents — requires explicit human confirmation with blast-radius and rollback before routing to any live apply, destroy, or stack mutation.
+allowed-tools: Agent Skill Read Grep Glob
 metadata:
   author: "github: Raishin"
   version: "0.1.0"
+  updated: "2026-05-05"
+  category: ai
 ---
 
 # Terraform Maestro — Routing Skill

package/skills/velero/velero-backup-restore-guard/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: velero-backup-restore-guard
+description: Use this skill when guarding Velero backup schedule changes, restore operations, BackupStorageLocation mutations, or volume snapshot configuration. Trigger on any request to run a velero restore, delete a Schedule, change a BSL default, or modify backup retention.
+allowed-tools: Read Grep Glob WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: resilience
+---
+
+# Velero Backup/Restore Guard
+
+## Purpose
+
+Guard live Velero operations — restore execution, schedule deletion, BackupStorageLocation changes, and volume snapshot configuration — against data loss, scope creep, and missing rollback posture. A Velero restore is destructive: it overlays resources onto the cluster. Every guarded operation requires confirmed cluster context, explicit scope, current state capture, and explicit platform-team sign-off before any mutation executes.
+
+## Lean operating rules
+
+- Confirm cluster context (`kubectl config current-context`) and target namespace before any Velero operation — ambiguous context is a hard stop.
+- Capture current state of the target Backup, Schedule, or BSL (`velero backup describe <name> --details`, `kubectl get schedule <name> -o yaml`) before every write — Velero has no built-in undo.
+- For restore operations: require `includedNamespaces` to be explicitly scoped; a cluster-wide restore (`includedNamespaces: []`) requires explicit platform-team sign-off.
+- Recommend `velero restore create --dry-run` before every non-emergency restore; treat missing dry-run as a hard stop in non-emergency scenarios.
+- Block deleting a Schedule that is the only backup for a production namespace unless an alternative backup source is confirmed.
+- Block changing a BSL `default: true` without confirming no in-progress backups and reviewing the impact on all dependent Schedules.
+- Check pre-backup hook coverage on stateful workloads (PostgreSQL, MySQL, Kafka) — missing quiesce hooks mean inconsistent backups.
+- Label all claims as live evidence, documentation-based, or inference.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md)
+- [Safety checklist](references/safety-checklist.md)
+
+## Response minimum
+
+- Confirmed cluster context and target scope
+- Current state of the Backup/Schedule/BSL (evidence level)
+- Hard-stop assessment (is this a blocked operation?)
+- Explicit platform-team sign-off status
+- Recommended dry-run or safe-path command
+- Rollback posture
+- Post-operation verification steps

package/skills/velero/velero-backup-restore-guard/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "velero-backup-restore-guard",
+  "name": "Velero Backup/Restore Guard",
+  "type": "skill",
+  "provider": "velero",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Live-guard skill for Velero backup schedules, restore operations, BackupStorageLocation changes, and volume snapshots — requiring explicit platform-team sign-off before any mutation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://velero.io/docs/latest/",
+    "https://velero.io/docs/latest/restore-reference/",
+    "https://velero.io/docs/latest/backup-reference/",
+    "https://velero.io/docs/latest/locations/",
+    "https://velero.io/docs/latest/hooks/"
+  ],
+  "security_notes": "Velero restore with existingResourcePolicy:update can overwrite live RBAC resources, Secrets, and ServiceAccounts — equivalent to a partial cluster wipe. BSL credentials with write-only access prevent listing/deleting old backups, causing runaway storage costs. Never proceed with cluster-wide restores without explicit platform-team sign-off.",
+  "last_verified": "2026-05-02",
+  "path": "skills/velero/velero-backup-restore-guard",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/velero/velero-backup-restore-guard/references/safety-checklist.md

@@ -0,0 +1,40 @@
+# Safety Checklist
+
+## Pre-Restore Checklist (10 items)
+
+Before executing any `velero restore create` command, confirm all 10 items. A single unchecked item is a HARD STOP unless the approver explicitly overrides with written justification.
+
+- [ ] **1. Cluster context confirmed** — `kubectl config current-context` output has been shown and matches the intended target cluster. Do not assume the current context is correct.
+- [ ] **2. Namespace scope is explicit** — `includedNamespaces` lists one or more specific namespaces. Empty list (`[]`) = cluster-wide restore = requires explicit platform-team sign-off with ticket reference.
+- [ ] **3. Backup timestamp verified** — the backup name and creation timestamp have been confirmed as the correct recovery point. Do not restore from an older backup if a closer-in-time backup exists and is healthy.
+- [ ] **4. Backup phase is Completed** — `velero backup describe <name>` shows `Phase: Completed`. Do not restore from a `PartiallyFailed` or `Failed` backup without explicit acknowledgment of the incomplete scope.
+- [ ] **5. Dry-run executed and reviewed** — `velero restore create --dry-run` output has been reviewed for unexpected resource counts, namespace scope, and PV restore entries. (Exception: active P0 incident with explicit platform-team override.)
+- [ ] **6. existingResourcePolicy reviewed** — if `existingResourcePolicy: update` is used, the approver understands this will overwrite live Secrets, ConfigMaps, RBAC objects, and ServiceAccounts in the target namespace.
+- [ ] **7. PV restore posture confirmed** — `restorePVs: true/false` intent is explicit. If false, stateful applications will start with empty persistent volumes.
+- [ ] **8. Current state captured** — target namespace resources have been exported (`kubectl get all,cm,secret,pvc -n <ns> -o yaml > pre-restore-state.yaml`) as a rollback artifact.
+- [ ] **9. Explicit platform-team sign-off obtained** — approver name, role, and ticket/incident reference are documented. Not implied — must be explicit.
+- [ ] **10. Post-restore verification plan exists** — the team knows which pods, endpoints, and data checks confirm successful restore before closing the incident.
+
+---
+
+## Pre-Schedule-Delete Checklist (5 items)
+
+Before executing `velero schedule delete <name>` or removing a Schedule manifest:
+
+- [ ] **1. Alternative backup source confirmed** — the namespaces covered by this Schedule are also covered by another Schedule or a manual backup strategy. Deleting the only backup Schedule for a production namespace is a HARD STOP.
+- [ ] **2. Existing backups will not be deleted** — deleting a Schedule does not delete existing Backups by default. Confirm this is the intended behavior; if cascade-delete is intended, explicitly document which backups will be removed.
+- [ ] **3. No in-progress backup from this schedule** — `velero backup get | grep InProgress` shows no active backup from this Schedule. Deleting a Schedule mid-backup can leave a partial backup with no retention management.
+- [ ] **4. Dependent restore references reviewed** — no existing Restore objects reference backups created by this Schedule in a pending or future recovery plan.
+- [ ] **5. Platform-team sign-off obtained** — explicit written approval with ticket reference. A Schedule deletion is irreversible (re-creation restores future backups but not the deleted Schedule's backup history lineage).
+
+---
+
+## Post-Restore Verification (5 items)
+
+After a restore completes (`velero restore describe <name>` shows `Phase: Completed`):
+
+- [ ] **1. Pod health confirmed** — all Deployments and StatefulSets in the restored namespace reach `Ready` state within the expected startup window. Check: `kubectl get pods -n <ns> -w`.
+- [ ] **2. PVC binding confirmed** — all PersistentVolumeClaims are in `Bound` status. Unbound PVCs indicate snapshot restore failure or storage class mismatch. Check: `kubectl get pvc -n <ns>`.
+- [ ] **3. Application data sampling** — spot-check application-level data integrity (e.g., query a database, verify a file, check an API endpoint). Pod running does not guarantee data consistency.
+- [ ] **4. Service endpoints reachable** — Services and Ingress rules are routing traffic correctly. Check: `kubectl get svc,ingress -n <ns>` and a live probe to the application endpoint.
+- [ ] **5. Restore warnings reviewed** — `velero restore logs <name>` has been scanned for warnings. Warnings about skipped resources, unresolved PV references, or hook failures must be triaged before marking the restore complete.

package/skills/velero/velero-backup-restore-guard/references/workflow-and-output.md

@@ -0,0 +1,202 @@
+# Workflow and Output Contract
+
+## Pre-Operation Workflow
+
+### Step 1 — Confirm cluster context
+
+```bash
+kubectl config current-context
+kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
+```
+
+Never proceed if context is ambiguous, stale, or unconfirmed. This is a HARD STOP.
+
+### Step 2 — Inventory the target
+
+For restore operations:
+```bash
+velero backup get
+velero backup describe <backup-name> --details
+velero backup logs <backup-name>
+```
+
+For schedule review:
+```bash
+velero schedule get
+kubectl get schedule <schedule-name> -n velero -o yaml
+```
+
+For BSL review:
+```bash
+velero backup-location get
+kubectl get backupstoragelocation -n velero -o yaml
+```
+
+For volume snapshot locations:
+```bash
+velero snapshot-location get
+kubectl get volumesnapshotlocation -n velero -o yaml
+```
+
+### Step 3 — Capture current state
+
+Before any mutation, export the current state as a rollback artifact:
+
+```bash
+# Backup the Schedule
+kubectl get schedule <schedule-name> -n velero -o yaml > schedule-backup-$(date +%Y%m%d%H%M%S).yaml
+
+# Backup the BSL
+kubectl get backupstoragelocation <bsl-name> -n velero -o yaml > bsl-backup-$(date +%Y%m%d%H%M%S).yaml
+```
+
+### Step 4 — Scope assessment for restores
+
+Review the proposed Restore manifest or CLI flags:
+
+```yaml
+apiVersion: velero.io/v1
+kind: Restore
+metadata:
+  name: myapp-restore-20260502
+  namespace: velero
+spec:
+  backupName: myapp-backup-20260501
+  includedNamespaces:
+    - myapp-production        # MUST be explicitly scoped; [] = cluster-wide = HARD STOP
+  excludedResources:
+    - nodes
+    - events
+    - events.events.k8s.io
+    - backups.velero.io
+    - restores.velero.io
+    - resticrepositories.velero.io
+  existingResourcePolicy: none  # "update" overwrites live resources — requires sign-off
+  restorePVs: true
+```
+
+### Step 5 — Dry-run (mandatory in non-emergency scenarios)
+
+```bash
+velero restore create myapp-restore-dryrun \
+  --from-backup myapp-backup-20260501 \
+  --include-namespaces myapp-production \
+  --dry-run -o yaml
+```
+
+Review the dry-run output for:
+- Unexpected resource counts (compare against last-known production state)
+- Resources that would be overwritten if `existingResourcePolicy: update`
+- Missing PV restore entries
+
+### Step 6 — Sign-off gate
+
+Document sign-off clearly before proceeding. Required fields:
+- Approver name and role
+- Ticket or incident reference
+- Recovery point objective confirmation (is this the correct backup timestamp?)
+- Cluster context and namespace scope confirmation
+
+### Step 7 — Execute restore
+
+```bash
+velero restore create myapp-restore-20260502 \
+  --from-backup myapp-backup-20260501 \
+  --include-namespaces myapp-production \
+  --existing-resource-policy none
+```
+
+### Step 8 — Monitor restore progress
+
+```bash
+velero restore describe myapp-restore-20260502 --details
+velero restore logs myapp-restore-20260502
+kubectl get pods -n myapp-production -w
+```
+
+---
+
+## Backup Schedule Review Workflow
+
+### Reviewing schedule cadence against RPO
+
+```bash
+kubectl get schedule -n velero -o custom-columns=\
+NAME:.metadata.name,\
+CRON:.spec.schedule,\
+TTL:.spec.template.ttl,\
+LOCATION:.spec.template.storageLocation,\
+NAMESPACES:.spec.template.includedNamespaces
+```
+
+Validation checklist:
+- `spec.schedule` cron expression matches RPO requirement (e.g., hourly = `0 * * * *`)
+- `spec.template.ttl` is not shorter than the retention SLA (default `720h` = 30d)
+- `spec.template.includedNamespaces` does not omit stateful production namespaces
+- `spec.template.storageLocation` references a BSL in the same region as the cluster for DR validity
+- `spec.template.volumeSnapshotLocations` is set if PVs need snapshot coverage
+
+### Reviewing hook coverage on stateful workloads
+
+```yaml
+# Example pre-backup hook to quiesce PostgreSQL
+metadata:
+  annotations:
+    pre.hook.backup.velero.io/command: '["/bin/bash", "-c", "psql -U postgres -c CHECKPOINT;"]'
+    pre.hook.backup.velero.io/container: postgres
+    pre.hook.backup.velero.io/on-error: Fail
+    pre.hook.backup.velero.io/timeout: 30s
+    post.hook.backup.velero.io/command: '["/bin/bash", "-c", "echo backup complete"]'
+    post.hook.backup.velero.io/container: postgres
+```
+
+Missing hooks on StatefulSets running PostgreSQL, MySQL, MongoDB, or Kafka = inconsistent backup. Flag as HIGH.
+
+---
+
+## BackupStorageLocation Change Workflow
+
+Before changing a BSL:
+
+```bash
+# List all active backups and their storage location
+velero backup get -o yaml | grep -E 'storageLocation|name:'
+
+# Check for in-progress backups
+velero backup get | grep InProgress
+
+# Check which schedules reference this BSL
+kubectl get schedule -n velero -o json | jq '.items[] | select(.spec.template.storageLocation == "<bsl-name>") | .metadata.name'
+```
+
+BSL credential review (IRSA/Workload Identity):
+```bash
+kubectl get backupstoragelocation <bsl-name> -n velero -o jsonpath='{.spec.credential}'
+```
+
+Expected: `credential.secretRef` using IRSA annotations. Flag if IAM user static credentials are used.
+
+---
+
+## Volume Snapshot TTL vs Backup TTL Alignment
+
+```bash
+velero backup describe <backup-name> --details | grep -A5 "Volume Snapshots"
+```
+
+Verify: volume snapshot TTL >= backup TTL. If backup TTL is 30d but snapshot TTL is 7d, restore from snapshot after day 7 will fail silently (snapshot gone, backup metadata present).
+
+---
+
+## Output Format
+
+Return:
+
+1. **Target and scope** — backup name, namespace scope, cluster context, BSL, timestamp
+2. **Hard-stop assessment** — is this operation blocked? List exact rule triggered.
+3. **Evidence level** — live evidence, documentation-based, or inference
+4. **Approval status** — confirmed sign-off or pending
+5. **Recommended command** — dry-run first, then execute
+6. **Rollback posture** — saved state file, re-apply command
+7. **Verification steps** — post-restore pod health, resource counts, PV binding status
+8. **Open risks** — hook coverage gaps, snapshot TTL mismatches, BSL credential posture