feat: agent sandbox — Phases 1-9 implementation

.claude/skills/ci:monitoring/SKILL.md

@@ -12,8 +12,8 @@ Monitor running CI pipelines and report results. Creates task items for each CI
 **CI log downloads MUST go to files.** Status checks (`gh pr checks`) are small and OK inline.
 
 ```bash
-export LOG_DIR=/tmp/kagenti/ci/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-ci}"
+mkdir -p "$LOG_DIR"
 
 # When downloading logs after completion:
 gh run view <run-id> --log-failed > $LOG_DIR/ci-run-<run-id>.log 2>&1; echo "EXIT:$?"

.claude/skills/ci:status/SKILL.md

@@ -13,8 +13,8 @@ Check the current CI status for a PR and create task items for any failures.
 `gh run view --log-failed` and artifact downloads MUST redirect:
 
 ```bash
-export LOG_DIR=/tmp/kagenti/ci/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-ci}"
+mkdir -p "$LOG_DIR"
 
 # Small output OK inline:
 gh pr checks <PR-number>

.claude/skills/github:pr-review/SKILL.md

@@ -47,8 +47,8 @@ comments, and posts a GitHub review after user approval.
 PR diffs can be very large. **Always redirect diff output to files and analyze with subagents.**
 
 ```bash
-export LOG_DIR=/tmp/kagenti/review/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-review}"
+mkdir -p "$LOG_DIR"
 ```
 
 Small output OK inline: `gh pr checks`, `gh pr view --json` (metadata only).

.claude/skills/helm:debug/SKILL.md

@@ -10,8 +10,8 @@ description: Debug Helm chart issues - template rendering, value overrides, hook
 **Helm template output can be hundreds of lines.** Always redirect to files:
 
 ```bash
-export LOG_DIR=/tmp/kagenti/helm/${WORKTREE:-$(basename $(git rev-parse --show-toplevel))}
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-helm}"
+mkdir -p "$LOG_DIR"
 
 # Redirect helm template output
 helm template kagenti charts/kagenti -n kagenti-system > $LOG_DIR/rendered.yaml 2>&1 && echo "OK" || echo "FAIL"

.claude/skills/kagenti:deploy/SKILL.md

@@ -12,8 +12,8 @@ This skill guides you through deploying or redeploying the Kagenti Kind cluster
 **Deploy scripts produce hundreds of lines.** Always redirect to files:
 
 ```bash
-export LOG_DIR=/tmp/kagenti/deploy/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-deploy}"
+mkdir -p "$LOG_DIR"
 
 # Pattern: redirect deploy output
 ./.github/scripts/local-setup/kind-full-test.sh ... > $LOG_DIR/deploy.log 2>&1; echo "EXIT:$?"

.claude/skills/kagenti:operator/SKILL.md

@@ -12,8 +12,8 @@ Deploy and manage Kagenti operator, agents, and tools on Kubernetes clusters.
 **Deploy/build commands produce large output.** Always redirect to files:
 
 ```bash
-export LOG_DIR=/tmp/kagenti/deploy/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-deploy}"
+mkdir -p "$LOG_DIR"
 
 # Pattern: redirect build/deploy output
 command > $LOG_DIR/<name>.log 2>&1; echo "EXIT:$?"
@@ -173,14 +173,15 @@ kubectl get crd | grep kagenti
 # All components
 kubectl get components -A
 
-# Agent builds
-kubectl get agentbuilds -A
+# Shipwright builds
+kubectl get builds -A
+kubectl get buildruns -A
 
 # Deployments
 kubectl get deployments -n team1
 ```
 
-### Check Tekton Pipelines
+### Check Shipwright/Tekton Pipelines
 
 ```bash
 # Pipeline runs

.claude/skills/rca/SKILL.md

@@ -37,8 +37,8 @@ the main conversation context.
 
 ```bash
 # Session-scoped log directory
-export LOG_DIR=/tmp/kagenti/rca/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-rca}"
+mkdir -p "$LOG_DIR"
 ```
 
 **Rules:**
@@ -109,10 +109,21 @@ After RCA is complete, switch to TDD for fix iteration: ◄──┘┘ │
 > Before routing to `rca:kind`, run `kind get clusters` — if a cluster exists from another session,
 > route to `rca:ci` instead or ask the user.
 
+## CVE Awareness
+
+All RCA variants include a CVE check before publishing findings. If the root
+cause involves a dependency issue, `cve:scan` runs automatically to check for
+known CVEs. If found, `cve:brainstorm` blocks public disclosure until the CVE
+is properly reported through the project's security channels.
+
+See `cve:scan` and `cve:brainstorm` for details.
+
 ## Related Skills
 
 - `tdd:ci` - Fix iteration after RCA (CI-driven)
 - `tdd:hypershift` - Fix iteration with live cluster
 - `tdd:kind` - Fix iteration on Kind
 - `k8s:logs` - Query and analyze component logs
 - `k8s:pods` - Debug pod issues
+- `cve:scan` - CVE scanning gate
+- `cve:brainstorm` - CVE disclosure planning

.claude/skills/rca:ci/SKILL.md

@@ -14,8 +14,9 @@ can dump thousands of lines into context. ALL CI log analysis MUST happen in sub
 
 ```bash
 # Session-scoped log directory
-export LOG_DIR=/tmp/kagenti/rca/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+# Works in both Claude Code (local) and sandbox agent (container)
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-rca}"
+mkdir -p "$LOG_DIR"
 ```
 
 **Rules:**
@@ -175,6 +176,28 @@ grep -i "oom\|memory\|evict\|limit" logs/*.txt
 [How to prevent recurrence]
 ```
 
+### CVE Check Before Publishing Findings
+
+**Before posting RCA findings to any public destination** (issue comment, PR comment, etc.):
+
+If the root cause involves a dependency bug, unexpected behavior, or version issue:
+
+1. Invoke `cve:scan` to check if this is a known CVE
+2. If a CVE is found → invoke `cve:brainstorm` **BEFORE** documenting findings publicly
+3. Rewrite RCA documentation to use neutral language (no CVE IDs, no vulnerability descriptions)
+4. Report the CVE through proper channels (see `cve:brainstorm`)
+
+Example neutral RCA wording:
+```
+Root Cause: Incompatibility with <package> <version>.
+Fix: Bump to <version> which resolves the behavior.
+```
+
+NOT:
+```
+Root Cause: CVE-2026-XXXXX in <package> allows remote code execution.
+```
+
 ## Escalation to rca:hypershift
 
 Escalate when:
@@ -201,3 +224,5 @@ rca:ci inconclusive? → Create cluster → rca:hypershift
 - `rca:hypershift` - RCA with live cluster access
 - `tdd:ci` - Fix iteration after RCA
 - `superpowers:systematic-debugging` - General debugging approach
+- `cve:scan` - CVE scanning (check if root cause is a known CVE)
+- `cve:brainstorm` - Disclosure planning (if CVE found during RCA)

.claude/skills/rca:kind/SKILL.md

@@ -12,8 +12,8 @@ Root cause analysis workflow for failures on local Kind clusters.
 **All diagnostic commands MUST redirect output to files.**
 
 ```bash
-export LOG_DIR=/tmp/kagenti/rca/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-rca}"
+mkdir -p "$LOG_DIR"
 ```
 
 **Rules:**
@@ -112,6 +112,16 @@ After fixing, re-run the specific failing test:
 uv run pytest kagenti/tests/e2e/ -v -k "test_name" > $LOG_DIR/retest.log 2>&1; echo "EXIT:$?"
 ```
 
+### CVE Check Before Publishing Findings
+
+**Before posting RCA findings to any public destination:**
+
+If the root cause involves a dependency bug or version issue:
+
+1. Invoke `cve:scan` to check if this is a known CVE
+2. If a CVE is found → invoke `cve:brainstorm` BEFORE documenting publicly
+3. Use neutral language in all public documentation
+
 ## Kind-Specific Issues
 
 | Issue | Cause | Fix |
@@ -135,3 +145,5 @@ If the issue can't be reproduced locally, escalate:
 - `kind:cluster` - Create/destroy Kind clusters
 - `k8s:pods` - Debug pod issues
 - `kagenti:ui-debug` - Debug UI issues (502, API, proxy)
+- `cve:scan` - CVE scanning (check if root cause is a known CVE)
+- `cve:brainstorm` - Disclosure planning (if CVE found during RCA)

.claude/skills/tdd/SKILL.md

@@ -320,8 +320,8 @@ and being re-read on every subsequent turn.
 
 ```bash
 # Session-scoped log directory — ALWAYS set before running commands
-export LOG_DIR=/tmp/kagenti/tdd/$WORKTREE   # or $(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-tdd}"
+mkdir -p "$LOG_DIR"
 ```
 
 **Rules:**
@@ -342,10 +342,11 @@ All three flows eventually enter this loop:
 3. test:review — verify test quality (no silent skips, assertive)
 4. test:run-kind or test:run-hypershift — execute tests (output to $LOG_DIR)
 5. Track progress — compare test results with previous run
-6. git:commit — commit with proper format
-7. git:rebase — rebase onto upstream/main
-8. Push → ci:monitoring — wait for CI results
-9. CI passes? → Handle reviews (Flow 2 Step 4). CI fails? → Back to step 1.
+6. cve:scan — scan for CVEs before pushing (BLOCKS if found)
+7. git:commit — commit with proper format
+8. git:rebase — rebase onto upstream/main
+9. Push → ci:monitoring — wait for CI results
+10. CI passes? → Handle reviews (Flow 2 Step 4). CI fails? → Back to step 1.
 ```
 
 ## Commit Policy
@@ -394,5 +395,6 @@ Commit 3: 11 pass, 2 fail ← good, +1 passing
 - `git:commit` - Commit with proper format
 - `git:rebase` - Rebase before pushing
 - `git:worktree` - Create isolated worktrees
-- `git:commit` - Commit format and conventions
 - `repo:pr` - PR creation conventions
+- `cve:scan` - CVE scanning gate
+- `cve:brainstorm` - CVE disclosure planning

.claude/skills/tdd:ci/SKILL.md

@@ -15,6 +15,7 @@ description: CI-driven TDD workflow - commit, local checks, push, wait for CI, i
 - [Phase 1: Brainstorm](#phase-1-brainstorm-new-features)
 - [Phase 2: Commit](#phase-2-commit)
 - [Phase 3: Local Checks](#phase-3-local-checks)
+- [Phase 3.5: CVE Gate](#phase-35-cve-gate)
 - [Phase 4: Push to PR](#phase-4-push-to-pr)
 - [Phase 5: Wait for CI](#phase-5-wait-for-ci)
 - [Phase 6: Analyze Failures](#phase-6-analyze-failures)
@@ -33,8 +34,8 @@ Iterative development workflow using CI as the test environment. Commit changes,
 
 ```bash
 # Session-scoped log directory — use worktree name to avoid collisions
-export LOG_DIR=/tmp/kagenti/tdd/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-tdd}"
+mkdir -p "$LOG_DIR"
 ```
 
 ### Key Patterns
@@ -94,7 +95,10 @@ flowchart TD
     P1 --> P2["Phase 2: Commit"]:::git
     P2 --> P3["Phase 3: Local Checks"]:::test
     P3 -->|Checks fail| P2
-    P3 -->|Checks pass| P4["Phase 4: Push to PR"]:::git
+    P3 -->|Checks pass| P3B["Phase 3.5: CVE Gate"]:::cve
+    P3B -->|Clean| P4["Phase 4: Push to PR"]:::git
+    P3B -->|CVE found| CVE_HOLD["cve:brainstorm (BLOCKS push)"]:::cve
+    CVE_HOLD -->|Resolved| P4
     P4 --> P5["Phase 5: Wait for CI"]:::ci
     P5 --> RESULT{"CI Result?"}
 
@@ -119,6 +123,7 @@ flowchart TD
     classDef hypershift fill:#3F51B5,stroke:#333,color:white
     classDef ci fill:#2196F3,stroke:#333,color:white
     classDef test fill:#9C27B0,stroke:#333,color:white
+    classDef cve fill:#D32F2F,stroke:#333,color:white
 ```
 
 > Follow this diagram as the workflow.
@@ -328,6 +333,19 @@ uv run pytest kagenti/tests/ -v --ignore=kagenti/tests/e2e > $LOG_DIR/unit-tests
 
 **Fix any failures before pushing.** On failure, use `Task(subagent_type='Explore')` to read the log file.
 
+## Phase 3.5: CVE Gate
+
+**MANDATORY before pushing.** Scan dependencies for known CVEs before any public output.
+
+Invoke `cve:scan` on the working tree:
+
+1. If `cve:scan` returns clean → proceed to Phase 4
+2. If `cve:scan` finds HIGH/CRITICAL CVEs → `cve:brainstorm` activates a CVE hold
+   - **Do NOT proceed to Phase 4** until the hold is resolved
+   - The hold blocks `gh pr create`, `gh pr comment`, `gh issue create/comment`
+   - Silent fixes (dependency bumps with neutral commit messages) are allowed
+   - See `cve:brainstorm` for resolution steps
+
 ## Phase 4: Push to PR
 
 ```bash
@@ -472,7 +490,7 @@ After **3+ failed CI iterations**, consider switching to `tdd:hypershift` for re
 
 ```bash
 # Check if cluster exists for current worktree
-WORKTREE=$(basename $(git rev-parse --show-toplevel))
+WORKTREE=$(basename "${WORKSPACE_DIR:-$(pwd)}")
 ls ~/clusters/hcp/kagenti-hypershift-custom-*/auth/kubeconfig 2>/dev/null
 ```
 
@@ -598,3 +616,5 @@ This is optional but recommended for tracking development effort.
 - `git:commit` - Commit format and conventions
 - `git:rebase` - Rebase onto upstream main
 - `session:post` - Post session analytics to PR
+- `cve:scan` - CVE scanning gate (Phase 3.5)
+- `cve:brainstorm` - CVE disclosure planning (if CVEs found)

.claude/skills/tdd:kind/SKILL.md

@@ -40,8 +40,11 @@ flowchart TD
     GUARD -->|Cluster exists, mine| REUSE["Reuse existing cluster"]:::k8s
     GUARD -->|Cluster exists, not mine| STOP([Stop - another session owns it])
 
-    CREATE --> ITER
-    REUSE --> ITER
+    CREATE --> CVEGATE["CVE Gate: cve:scan"]:::cve
+    REUSE --> CVEGATE
+    CVEGATE -->|Clean| ITER
+    CVEGATE -->|CVE found| CVE_HOLD["cve:brainstorm"]:::cve
+    CVE_HOLD -->|Resolved| ITER
 
     ITER{"Iteration level?"}
     ITER -->|Level 1| L1["Test only (fastest)"]:::test
@@ -70,10 +73,24 @@ flowchart TD
     classDef hypershift fill:#3F51B5,stroke:#333,color:white
     classDef ci fill:#2196F3,stroke:#333,color:white
     classDef test fill:#9C27B0,stroke:#333,color:white
+    classDef cve fill:#D32F2F,stroke:#333,color:white
 ```
 
 > Follow this diagram as the workflow.
 
+## CVE Gate (Pre-Deploy)
+
+**MANDATORY before deploying to Kind cluster.**
+
+Invoke `cve:scan` on the working tree before the first deployment:
+
+1. If `cve:scan` returns clean → proceed to iteration selection
+2. If `cve:scan` finds HIGH/CRITICAL CVEs → `cve:brainstorm` activates a CVE hold
+   - Silent fixes (dependency bumps) are allowed
+   - Deployment proceeds only after hold is resolved
+
+This gate runs once per session, not on every iteration.
+
 ## Key Principle
 
 **Match CI exactly**: Kind tests must use the same packages as CI to avoid version mismatches. CI uses `pip install` (gets latest versions), local uses `uv` (locked versions). Always verify package versions match.
@@ -84,8 +101,8 @@ flowchart TD
 
 ```bash
 # Session-scoped log directory — use worktree name to avoid collisions
-export LOG_DIR=/tmp/kagenti/tdd/$(basename $(git rev-parse --show-toplevel))
-mkdir -p $LOG_DIR
+export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/kagenti-tdd}"
+mkdir -p "$LOG_DIR"
 ```
 
 ### Log Analysis Rule
@@ -255,3 +272,5 @@ This is optional but recommended for tracking development effort.
 - `test:review` - Review test quality
 - `git:commit` - Commit format
 - `session:post` - Post session analytics to PR
+- `cve:scan` - CVE scanning gate (pre-deploy)
+- `cve:brainstorm` - CVE disclosure planning (if CVEs found)