@codyswann/lisa 2.119.1 → 2.121.0

package/plugins/lisa-copilot/skills/reproduce-bug/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: reproduce-bug
+description: "How to create reliable bug reproduction scenarios. Covers failing tests, minimal scripts, environment verification, and reproduction evidence capture."
+---
+
+# Reproduce Bug
+
+Before investigating root cause, reproduce the issue empirically. A bug that cannot be reproduced cannot be verified as fixed.
+
+## Reproduction Process
+
+### 1. Run the Failing Scenario
+
+- Execute the exact command, test, or request that triggers the bug
+- Capture the complete error output, stack trace, or unexpected behavior
+- Record the exact command used so it can be repeated
+
+### 2. Capture Evidence
+
+- Save the full error output (not just a summary)
+- Note the timestamp and environment details (OS, runtime version, dependency versions)
+- Screenshot or log any visual/UI issues
+- Record the actual behavior vs. the expected behavior
+
+### 3. Investigate Environment Differences (If Cannot Reproduce)
+
+If the issue does not reproduce locally:
+
+- Compare environment configurations (env vars, config files, feature flags)
+- Check runtime versions (Node.js, Python, Java, etc.)
+- Compare dependency versions (`package-lock.json`, `poetry.lock`, etc.)
+- Check data differences (database state, seed data, user roles)
+- Verify network conditions (DNS, proxies, firewalls, VPN)
+- Check for platform-specific behavior (OS, architecture, container vs. host)
+
+### 4. Create a Minimal Reproduction
+
+Create the smallest possible reproduction that triggers the bug:
+
+**Preferred: Failing test**
+- Write a test that exercises the exact code path and asserts the expected behavior
+- The test should fail with the same symptom as the reported bug
+- A failing test is the most reliable reproduction because it runs in CI and prevents regression
+
+**Fallback: Reproduction script**
+- Write a standalone script that triggers the issue
+- Minimize dependencies -- remove anything not needed to reproduce
+- Include setup steps (data seeding, config) in the script itself
+- The script should be runnable by anyone with access to the repo
+
+**Last resort: Manual steps**
+- Document exact click-by-click or command-by-command steps
+- Include prerequisite state (logged-in user, specific data, feature flags)
+- Note any timing-sensitive aspects (race conditions, timeouts)
+
+### 5. Verify Reproduction Is Reliable
+
+- Run the reproduction multiple times to confirm it consistently fails
+- For intermittent bugs, run enough iterations to establish the failure rate
+- If intermittent, note any patterns (timing, load, specific data)
+
+## Output Format
+
+```text
+## Reproduction
+
+### Command/Steps
+The exact command or steps to trigger the bug.
+
+### Actual Behavior
+What happens (error message, wrong output, crash).
+
+### Expected Behavior
+What should happen instead.
+
+### Environment
+- Runtime: [version]
+- OS: [platform]
+- Dependencies: [relevant versions]
+
+### Reproduction Type
+[ ] Failing test: [path to test file]
+[ ] Script: [path to script]
+[ ] Manual steps: [documented above]
+
+### Reliability
+[Always / Intermittent (N/M runs) / Conditional (only when X)]
+```
+
+## Rules
+
+- Never skip reproduction. If you cannot reproduce, report what you tried and what you observed.
+- A failing test is always the preferred reproduction method.
+- Capture complete error output -- do not truncate or summarize.
+- If the bug is environment-specific, document exactly which environment triggers it.
+- Do not begin root cause analysis until you have a reliable reproduction.

package/plugins/lisa-copilot/skills/research/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: research
+description: "Research a problem space and create a PRD in the configured PRD source. Investigates the codebase, defines user flows, assesses technical feasibility, synthesizes the spec, then creates it in the source (Notion / Confluence / GitHub / Linear per .lisa.config.json `source`) via lisa:prd-source-write — there is no loose document artifact. Vendor-agnostic. Accepts an optional `prd_ready` flag (default false → the PRD is created in the `draft` role; true → created `ready` so lisa:intake auto-claims it) and an optional dedupe `marker`/`dedupe_key` (used when invoked by lisa:project-ideation) so re-runs reference the existing PRD instead of duplicating it."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# Research
+
+Produce a PRD for the problem in `$ARGUMENTS`, then create it in the configured PRD source.
+
+## Inputs
+
+- The problem statement / feature idea (required) — free text, a feasibility card, or a URL.
+- `prd_ready` (optional, default `false`) — `false` creates the PRD in the source's `draft` role for
+  human review; `true` creates it in the `ready` role so `lisa:intake` (PRD side) auto-claims it.
+- `dedupe_key` / `marker` (optional) — a stable dedupe marker (e.g. supplied by
+  `lisa:project-ideation`) embedded in the created PRD so re-runs reference the existing PRD rather
+  than creating a duplicate.
+- `ideation_ledger_payload` (optional, required when invoked by `lisa:project-ideation`) — a
+  structured metadata object to forward unchanged to `lisa:prd-source-write`. It carries the
+  selected marker, automation id/path when available, persona names, persona evidence references,
+  rejected overlap candidates, repo identity, `prd_ready`, selected idea title/key, and expected
+  empirical verification artifact. `research` may use these fields to inform the PRD body, but must
+  not discard, rename, or vendor-render them.
+
+## Orchestration: agent team
+
+If you are NOT already operating inside an agent team (no prior successful team-creation or subagent-delegation tool call in this session, not spawned into a team context), the very first thing you do is establish team orchestration.
+
+Use the team tool for the current runtime:
+
+- Claude: use `TeamCreate`. If `TeamCreate` has not been loaded yet, first use `ToolSearch` with `query: "select:TeamCreate"` to load its schema.
+- Codex: do not call `TeamCreate`; Codex does not expose that Claude tool. Use `tool_search` with a query like `multi-agent tools` to load `multi_agent_v1`, then use `multi_agent_v1.spawn_agent` for teammate delegation. Treat the first successful `spawn_agent` call as establishing team orchestration.
+- Other runtimes: use the current runtime's tool-discovery mechanism to discover and call the appropriate multi-agent/team tool.
+
+If no team creation or subagent delegation tool is available, explicitly state that team orchestration is unavailable in this runtime, continue as the lead agent, and preserve the workflow's review, verification, and task-tracking obligations locally.
+
+Until the team is established, the first Codex teammate has been spawned, or the no-team fallback has been declared, do NOT call any of: `Agent`, `TaskCreate`, `Skill`, MCP tools (Atlassian / Linear / GitHub / Notion), `Read`, `Write`, `Edit`, `Bash`, `Grep`, `Glob`. Gathering context inline as the lead is the exact bypass path that produces ad-hoc work instead of a real team flow.
+
+If you ARE already inside an agent team (e.g., a teammate invoked this skill via the Skill tool), do NOT create a second team — many harnesses reject double-creates — and do NOT collapse the nested flow into a single inline worker. A nested team-first flow must still bring in the specialists it requires by adding them to the existing team, not by doing the work itself:
+
+- **Claude:** teams are flat and only the lead can add named teammates, so do NOT call `Agent` with a `name` from a teammate (the harness rejects it: *"Teammates cannot spawn other teammates — the team roster is flat"*). Send the team lead a message naming the specialist teammate(s) this flow needs, their task assignments, and completion criteria, then coordinate through the shared task list until they finish. An anonymous subagent (`Agent` with `name` omitted) is permitted only for bounded one-shot work whose result returns directly to you — it is not a substitute for the required lifecycle specialists.
+- **Codex:** do NOT call `TeamCreate`. If the lead/root agent is addressable (you were given its id/handle), send it a request to `multi_agent_v1.spawn_agent` the specialist agent(s), including each agent's prompt, ownership, and expected result. If no lead handle exists but `spawn_agent` is available to you, spawn only the bounded specialist agent(s) this flow needs, `wait_agent` for their results, and relay those results upward to the parent/lead.
+
+Treat the first successful lead-spawn request (or, on the Codex fallback, the first specialist spawn) as preserving team orchestration. Never satisfy a team-first lifecycle flow by doing all the work inline.
+
+## Flow
+
+Execute the **Research** flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The rule contains the canonical step sequence (gates, sub-flows, deliverables). This skill does NOT restate flow steps — change them in the rule, propagate everywhere.
+
+## Output
+
+A PRD **created in the configured PRD source** (per the intent-routing rule's Research flow
+definition) containing: context, problem statement, user flows, acceptance criteria, technical
+feasibility notes, open questions, and the "Recommended Tooling for Plan Phase" section. The final
+flow step invokes `lisa:prd-source-write`, which creates the PRD in the configured `source` (Notion
+page in the PRD database, Confluence page under the lifecycle parent, GitHub issue, or Linear
+project) in the `draft` role by default or `ready` when `prd_ready=true`. **The PRD lives in the
+source — there is no loose document artifact.** Before handing the synthesized PRD to
+`lisa:prd-source-write`, record the Research run's direct usage on that artifact through
+`lisa:usage-accounting` so the PRD body carries the canonical `## Lisa Usage` ledger from creation
+time onward. If the runtime does not expose trustworthy usage, the direct entry must still be
+written with `source: unavailable` and nullable token/cost fields rather than silently omitting the
+Research row. If the call includes `ideation_ledger_payload`, pass that object through in the
+`lisa:prd-source-write` spec unchanged alongside `marker`, `dedupe_key`, and `initial_role`; this is
+the vendor-neutral handoff that lets the configured writer render an auditable run ledger without
+`research` bypassing source selection. A `source` must be configured; if it is not, stop and report
+it rather than emitting a document. The Plan flow consumes the created PRD next.

package/plugins/lisa-copilot/skills/review-local/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: review-local
+description: This skill should be used when performing a code review on local changes on the current branch compared to the main branch. It uses multiple parallel agents to check for bugs, CLAUDE.md compliance, git history context, previous PR comments, and code comment adherence, then scores and filters findings by confidence level.
+disable-model-invocation: false
+---
+
+Provide a code review for the local changes on the current branch compared to the main branch.
+
+To do this, follow these steps precisely:
+
+1. Use a Haiku agent to check the current git state:
+   - Run `git branch --show-current` to get the current branch name
+   - Run `git log main..HEAD --oneline` to see commits on this branch
+   - Run `git diff main...HEAD --stat` to see changed files
+   - If the current branch IS main, or there are no commits/changes compared to main, do not proceed.
+2. Use another Haiku agent to give you a list of file paths to (but not the contents of) any relevant CLAUDE.md files from the codebase: the root CLAUDE.md file (if one exists), as well as any CLAUDE.md files in the directories whose files were modified on this branch
+3. Use a Haiku agent to analyze the branch changes:
+   - Run `git log main..HEAD --format="%s%n%b"` to get commit messages
+   - Run `git diff main...HEAD` to get the full diff
+   - Return a summary of the changes
+4. Then, launch 5 parallel Sonnet agents to independently code review the change. The agents should do the following, then return a list of issues and the reason each issue was flagged (eg. CLAUDE.md adherence, bug, historical git context, etc.):
+   a. Agent #1: Audit the changes to make sure they comply with the CLAUDE.md. Note that CLAUDE.md is guidance for Claude as it writes code, so not all instructions will be applicable during code review.
+   b. Agent #2: Read the file changes (via `git diff main...HEAD`), then do a shallow scan for obvious bugs. Avoid reading extra context beyond the changes, focusing just on the changes themselves. Focus on large bugs, and avoid small issues and nitpicks. Ignore likely false positives.
+   c. Agent #3: Read the git blame and history of the code modified, to identify any bugs in light of that historical context
+   d. Agent #4: Read previous pull requests that touched these files, and check for any comments on those pull requests that may also apply to the current changes.
+   e. Agent #5: Read code comments in the modified files, and make sure the changes comply with any guidance in the comments.
+5. For each issue found in #4, launch a parallel Haiku agent that takes the diff, issue description, and list of CLAUDE.md files (from step 2), and returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim):
+   a. 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
+   b. 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md.
+   c. 50: Moderately confident. The agent was able to verify this is a real issue, but it might be a nitpick or not happen very often in practice. Relative to the rest of the changes, it's not very important.
+   d. 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md.
+   e. 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
+6. Filter out any issues with a score less than 80.
+7. Write the review to claude-review.md. When writing your review, keep in mind to:
+   a. Keep your output brief
+   b. Avoid emojis
+   c. Reference relevant files and line numbers
+8. Briefly summarize claude-review.md as direct output to the user
+
+Examples of false positives, for steps 4 and 5:
+
+- Pre-existing issues
+- Something that looks like a bug but is not actually a bug
+- Pedantic nitpicks that a senior engineer wouldn't call out
+- Issues that a linter, typechecker, or compiler would catch (eg. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself -- it is safe to assume that they will be run separately as part of CI.
+- General code quality issues (eg. lack of test coverage, general security issues, poor documentation), unless explicitly required in CLAUDE.md
+- Issues that are called out in CLAUDE.md, but explicitly silenced in the code (eg. due to a lint ignore comment)
+- Changes in functionality that are likely intentional or are directly related to the broader change
+- Real issues, but on lines that were not modified in the current branch
+
+Notes:
+
+- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
+- Use git commands to analyze local changes (not `gh` commands for remote PRs)
+- Make a todo list first
+- You must cite each bug with file path and line number (eg. if referring to a CLAUDE.md, you must reference it)
+- For your final output, follow the following format precisely (assuming for this example that you found 3 issues):
+
+---
+
+### Code review for branch `<branch-name>`
+
+Reviewed X commits with changes to Y files.
+
+Found 3 issues:
+
+1. **<brief description of bug>** (CLAUDE.md says "<...>")
+   - File: `path/to/file.ts:L10-L15`
+
+2. **<brief description of bug>** (some/other/CLAUDE.md says "<...>")
+   - File: `path/to/other-file.ts:L25-L30`
+
+3. **<brief description of bug>** (bug due to <reasoning>)
+   - File: `path/to/another-file.ts:L5-L8`
+
+---
+
+- Or, if you found no issues:
+
+---
+
+### Code review for branch `<branch-name>`
+
+Reviewed X commits with changes to Y files.
+
+No issues found. Checked for bugs and CLAUDE.md compliance.
+
+---

package/plugins/lisa-copilot/skills/root-cause-analysis/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: root-cause-analysis
+description: "Root cause analysis methodology. Evidence gathering from logs, execution path tracing, strategic log placement, and building irrefutable proof chains."
+---
+
+# Root Cause Analysis
+
+Definitively prove what is causing a problem. Do not guess. Do not theorize without evidence. Trace the actual execution path, read real logs, and produce irrefutable proof of root cause.
+
+**Core principle: "Show me the proof."** Every conclusion must be backed by concrete evidence -- a log line, a stack trace, a reproducible sequence, or a failing test.
+
+## Phase 1: Gather Evidence from Logs
+
+### Local Logs
+
+- Search application logs in the project directory (`logs/`, `tmp/`, stdout/stderr output)
+- Run tests with verbose logging enabled to capture execution flow
+- Check framework-specific log locations (e.g., `.next/`, `dist/`, build output)
+
+### Remote Logs (AWS CloudWatch, etc.)
+
+- Discover existing scripts and tools in the project for tailing logs:
+  - Check `package.json` scripts for log-related commands
+  - Search for shell scripts: `scripts/*log*`, `scripts/*tail*`, `scripts/*watch*`
+  - Look for AWS CLI wrappers, CloudWatch log group configurations
+  - Check for `.env` files referencing log groups or log streams
+- Use discovered tools first before falling back to raw CLI commands
+- When using AWS CLI directly:
+  ```bash
+  # Discover available log groups
+  aws logs describe-log-groups --query 'logGroups[].logGroupName' --output text
+
+  # Tail recent logs with filter
+  aws logs filter-log-events \
+    --log-group-name "/aws/lambda/function-name" \
+    --start-time $(date -d '30 minutes ago' +%s000) \
+    --filter-pattern "ERROR" \
+    --query 'events[].message' --output text
+
+  # Follow live logs
+  aws logs tail "/aws/lambda/function-name" --follow --since 10m
+  ```
+
+## Phase 2: Trace the Execution Path
+
+- Start from the error and work backward through the call stack
+- Read every function in the chain -- do not skip intermediate code
+- Identify the exact line where behavior diverges from expectation
+- Map the data flow: what value was expected vs. what value was actually present
+
+## Phase 3: Strategic Log Placement
+
+When existing logs are insufficient, add targeted log statements to prove or disprove hypotheses.
+
+### Log Statement Guidelines
+
+- **Be surgical** -- add the minimum number of log statements needed to confirm the root cause
+- **Include context** -- log the actual values, not just "reached here"
+- **Use structured format** -- make logs easy to find and parse
+
+```typescript
+// Bad: Vague, unhelpful
+console.log("here");
+console.log("data:", data);
+
+// Good: Precise, searchable, includes context
+console.log("[DEBUG:issue-123] processOrder entry", {
+  orderId: order.id,
+  status: order.status,
+  itemCount: order.items.length,
+  timestamp: new Date().toISOString(),
+});
+```
+
+### Placement Strategy
+
+| Placement | Purpose |
+|-----------|---------|
+| Function entry | Confirm the function is called and with what arguments |
+| Before conditional branches | Verify which branch is taken and why |
+| Before/after async operations | Detect timing issues, race conditions, failed awaits |
+| Before/after data transformations | Catch where data becomes corrupted or unexpected |
+| Error handlers and catch blocks | Ensure errors are not silently swallowed |
+
+### Hypothesis Elimination
+
+When multiple hypotheses exist, design a log placement strategy that eliminates all but one. Each log statement should be placed to confirm or rule out a specific hypothesis.
+
+## Phase 4: Prove the Root Cause
+
+Build an evidence chain that is irrefutable:
+
+1. **The symptom** -- what the user observes (error message, wrong output, crash)
+2. **The proximate cause** -- the line of code that directly produces the symptom
+3. **The root cause** -- the underlying reason the proximate cause occurs
+4. **The proof** -- log output, test result, or reproduction steps that confirm each link
+
+### Evidence Chain Format
+
+```text
+Symptom: [exact error message or behavior]
+    |
+    v
+Proximate cause: [file:line] -- [the line that directly produces the error]
+    |
+    v
+Root cause: [file:line] -- [the underlying reason]
+    |
+    v
+Proof: [log output / test result / reproduction that confirms the chain]
+```
+
+## Phase 5: Clean Up
+
+After root cause is confirmed, **remove all debug log statements** added during investigation. Leave only:
+
+- Log statements that belong in the application permanently (error logging, audit trails)
+- Statements explicitly requested by the user
+
+Verify cleanup:
+```bash
+# Search for any remaining debug markers
+grep -rn "\[DEBUG:" src/ --include="*.ts" --include="*.tsx" --include="*.js"
+```
+
+## Output Format
+
+```text
+## Root Cause Analysis
+
+### Evidence Trail
+| Step | Location | Evidence | Conclusion |
+|------|----------|----------|------------|
+| 1 | file:line | Log output or observed value | What this proves |
+| 2 | file:line | Log output or observed value | What this proves |
+
+### Root Cause
+**Proximate cause:** The line that directly produces the error.
+**Root cause:** The underlying reason this line behaves incorrectly.
+**Proof:** The specific evidence that confirms this beyond doubt.
+
+### Recommended Fix
+What needs to change and why. Include file:line references.
+```
+
+## Rules
+
+- Never guess at root cause -- prove it with evidence
+- Read the actual code in the execution path -- do not rely on function names or comments to infer behavior
+- When adding debug logs, use a consistent prefix (e.g., `[DEBUG:issue-name]`) so they are easy to find and clean up
+- Remove all temporary debug log statements after investigation is complete
+- If remote log access is unavailable, report what logs would be needed and from where
+- Prefer project-specific tooling and scripts over raw CLI commands for log access
+- If the root cause is in a third-party dependency, identify the exact version and known issue
+- Always verify the fix resolves the issue -- do not mark investigation complete without proof

package/plugins/lisa-copilot/skills/security-review/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: security-review
+description: "Security review methodology. STRIDE threat modeling, OWASP Top 10 vulnerability checks, auth/validation/secrets handling review, and mitigation recommendations."
+---
+
+# Security Review
+
+Identify vulnerabilities, evaluate threats, and recommend mitigations for code changes.
+
+## Analysis Process
+
+1. **Read affected files** -- understand current security posture of the code being changed
+2. **STRIDE analysis** -- evaluate Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege risks
+3. **Check input validation** -- are user inputs sanitized at system boundaries?
+4. **Check secrets handling** -- are credentials, tokens, or API keys exposed in code, logs, or error messages?
+5. **Check auth/authz** -- are access controls properly enforced for new endpoints or features?
+6. **Review dependencies** -- do new dependencies introduce known vulnerabilities?
+
+## Output Format
+
+Structure findings as:
+
+```
+## Security Analysis
+
+### Threat Model (STRIDE)
+| Threat | Applies? | Description | Mitigation |
+|--------|----------|-------------|------------|
+| Spoofing | Yes/No | ... | ... |
+| Tampering | Yes/No | ... | ... |
+| Repudiation | Yes/No | ... | ... |
+| Info Disclosure | Yes/No | ... | ... |
+| Denial of Service | Yes/No | ... | ... |
+| Elevation of Privilege | Yes/No | ... | ... |
+
+### Security Checklist
+- [ ] Input validation at system boundaries
+- [ ] No secrets in code or logs
+- [ ] Auth/authz enforced on new endpoints
+- [ ] No SQL/NoSQL injection vectors
+- [ ] No XSS vectors in user-facing output
+- [ ] Dependencies free of known CVEs
+
+### Vulnerabilities Found
+- [vulnerability] -- where in the code, how to prevent
+
+### Recommendations
+- [recommendation] -- priority (critical/warning/suggestion)
+```
+
+## Rules
+
+- Focus on the specific changes proposed, not a full security audit of the entire codebase
+- Flag only real risks -- do not invent hypothetical threats for internal tooling with no user input
+- Prioritize OWASP Top 10 vulnerabilities
+- If the changes are purely internal (config, refactoring, docs), report "No security concerns" and explain why
+- Always check `.gitleaksignore` patterns to understand what secrets scanning is already in place

package/plugins/lisa-copilot/skills/security-zap-scan/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: security-zap-scan
+description: "Run an OWASP ZAP baseline security scan locally using Docker. Checks for the ZAP baseline script, executes the scan, and summarizes findings by risk level with remediation recommendations."
+allowed-tools: ["Bash", "Read"]
+---
+
+# OWASP ZAP Baseline Security Scan
+
+Run a ZAP baseline security scan against the local application.
+
+## Workflow
+
+1. **Check prerequisites**:
+   - Verify Docker is installed and running: `docker info`
+   - Check if `scripts/zap-baseline.sh` exists in the project
+
+2. **Execute scan**:
+   - If the script exists, run: `bash scripts/zap-baseline.sh`
+   - If the script does not exist, inform the user that this project does not have a ZAP baseline scan configured
+
+3. **Analyze results**:
+   - After the scan completes, read `zap-report.html` (or `zap-report.md` for text)
+   - Summarize findings:
+     - Total number of alerts by risk level (High, Medium, Low, Informational)
+     - List each Medium+ finding with its rule ID, name, and recommended fix
+     - Categorize findings as "infrastructure-level" (fix at CDN/proxy) vs "application-level" (fix in code)
+
+4. **Handle failures**:
+   - If the scan failed, explain what failed and suggest concrete remediation steps
+
+## Execution
+
+Run the scan now.