milens 0.6.3 → 0.6.5

package/.agents/skills/milens-plan/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: milens-plan
+description: Implementation Planning — research codebase, analyze impact, plan tests, and produce a structured implementation plan
+---
+
+# milens-plan — Implementation Planning
+
+Research the codebase end-to-end before writing code: understand structure, trace execution, assess blast radius, plan tests, and produce a structured plan following the ECC Planner specification.
+
+## Tools Required
+
+| Tool | Purpose |
+|---|---|
+| `mcp_milens_codebase_summary` | High-level project overview (languages, file count, domain count) |
+| `mcp_milens_domains` | Module clusters showing logical groupings |
+| `mcp_milens_routes` | API endpoints inventory with handler mappings |
+| `mcp_milens_smart_context` | Intent-aware symbol analysis (edit intent) |
+| `mcp_milens_edit_check` | Pre-edit safety: callers, export status, re-export chains, warnings |
+| `mcp_milens_trace` | Execution flow from entrypoints to target |
+| `mcp_milens_impact` | Blast radius: what breaks if target changes |
+| `mcp_milens_test_plan` | Mock strategy + test scenarios for a symbol |
+| `mcp_milens_test_coverage_gaps` | Related untested symbols |
+
+> **CRITICAL:** All milens MCP tool calls MUST include the `repo` parameter set to the **absolute path of the workspace root**.
+
+## Workflow
+
+### Step 1: Project Overview
+
+Understand the codebase at a high level.
+
+```
+mcp_milens_codebase_summary({repo: "<workspaceRoot>"})
+```
+
+Captures: languages, file counts, total symbols, top-level domains, entry points.
+
+### Step 2: Domain Structure
+
+Map module clusters to understand logical groupings.
+
+```
+mcp_milens_domains({repo: "<workspaceRoot>"})
+```
+
+Shows which files form cohesive modules based on the dependency graph. Helps identify:
+- Where the target code lives
+- Which domains interact with it
+- Natural boundaries for the change
+
+### Step 3: API Surface (optional)
+
+If the project is a web service, inventory the endpoints.
+
+```
+mcp_milens_routes({repo: "<workspaceRoot>"})
+```
+
+Useful when the change touches:
+- Route handlers
+- Middleware
+- Request/response types
+- Authentication/authorization
+
+### Step 4: Target Analysis
+
+Zoom in on the specific symbol to change.
+
+```
+mcp_milens_smart_context({name: "<symbolName>", intent: "edit", repo: "<workspaceRoot>"})
+```
+
+The `edit` intent returns: callers, export status, and immediate blast radius — only what matters for editing.
+
+### Step 5: Pre-Edit Safety Check
+
+Run `edit_check` for pre-edit warnings.
+
+```
+mcp_milens_edit_check({name: "<symbolName>", repo: "<workspaceRoot>"})
+```
+
+This returns:
+- **Callers** — who calls this symbol
+- **Export status** — whether it's public API
+- **Re-export chains** — barrel file re-exports that extend blast radius
+- **Warnings** — breaking change risks, high fan-in, etc.
+
+### Step 6: Execution Flow
+
+Trace how the target gets called at runtime.
+
+```
+mcp_milens_trace({name: "<symbolName>", direction: "to", repo: "<workspaceRoot>"})
+```
+
+Shows the call chains from entrypoints down to this symbol. Critical for understanding:
+- What triggers this code
+- What data flows into it
+- What side effects it may have
+
+### Step 7: Blast Radius
+
+Assess the full impact of the proposed change.
+
+```
+mcp_milens_impact({target: "<symbolName>", depth: 3, repo: "<workspaceRoot>"})
+```
+
+Shows all symbols that break if the target changes, up to the specified depth.
+- If depth-1 dependents > 5: **STOP and warn** before proceeding
+- If depth-3 dependents > 20: **consider a facade or adapter pattern**
+
+### Step 8: Test Strategy
+
+Plan the testing approach.
+
+```
+mcp_milens_test_plan({name: "<symbolName>", repo: "<workspaceRoot>"})
+```
+
+Covers:
+- Mock strategy (what to isolate)
+- Test scenarios (happy path, edge cases, error handling)
+- Affected test files
+
+### Step 9: Coverage Gaps (optional)
+
+Check for related symbols that lack test coverage.
+
+```
+mcp_milens_test_coverage_gaps({repo: "<workspaceRoot>", limit: 10})
+```
+
+If neighboring symbols are untested, consider adding tests as part of the change.
+
+### Step 10: Produce Implementation Plan
+
+Consolidate all findings into a structured plan:
+
+1. **Executive Summary** — what changes, why, at what risk level
+2. **Codebase Context** — domains, routes, and structure (from Steps 1-3)
+3. **Symbol Analysis** — target details, callers, execution flow (from Steps 4-6)
+4. **Impact Assessment** — blast radius, breaking change risks, dependents map (from Step 7)
+5. **Test Strategy** — test plan, mock strategy, coverage gaps (from Steps 8-9)
+6. **Implementation Steps** — ordered, actionable steps with file paths
+7. **Risk Mitigation** — rollback plan, feature flags, phased deployment options
+
+## Example Session
+
+### Input
+
+```
+"plan a change to add rate limiting to the login handler"
+```
+
+### Tool Calls
+
+**Step 1:**
+```
+mcp_milens_codebase_summary({repo: "/home/user/project"})
+```
+
+**Output:** TypeScript project, 120 files, 850 symbols, 5 domains (auth, routes, db, utils, config).
+
+**Step 2:**
+```
+mcp_milens_domains({repo: "/home/user/project"})
+```
+
+**Output:** `auth` domain contains login handler, token manager, session store.
+
+**Step 4:**
+```
+mcp_milens_smart_context({name: "loginHandler", intent: "edit", repo: "/home/user/project"})
+```
+
+**Output:** 3 callers (Express route, rate limiter middleware, integration test), no re-exports.
+
+**Step 5:**
+```
+mcp_milens_edit_check({name: "loginHandler", repo: "/home/user/project"})
+```
+
+**Output:** 3 callers, exported, no re-export chains, **WARNING: exported function — changing signature is a breaking change.**
+
+**Step 6:**
+```
+mcp_milens_trace({name: "loginHandler", direction: "to", repo: "/home/user/project"})
+```
+
+**Output:** Chain: `Express router → authMiddleware → loginHandler → tokenService.sign()`
+
+**Step 7:**
+```
+mcp_milens_impact({target: "loginHandler", depth: 3, repo: "/home/user/project"})
+```
+
+**Output:** Depth-1: 3 dependents (route, integration test, auth docs). Depth-2: 8 dependents. Depth-3: 14 dependents. **No STOP threshold breached.**
+
+**Step 8:**
+```
+mcp_milens_test_plan({name: "loginHandler", repo: "/home/user/project"})
+```
+
+**Output:** Mock `tokenService`, `userStore`. 4 test scenarios: valid login, invalid password, rate limit exceeded, database failure.
+
+**Step 10 — Plan produced** (see plan format above).
+
+## Best Practices
+
+1. **Never skip impact analysis.** Even a "small" change can ripple through re-export chains. `impact` catches what intuition misses.
+2. **Use `edit` intent for `smart_context`** when planning edits — it omits irrelevant detail and focuses on callers and blast radius.
+3. **Stop at depth-3 for impact.** Deeper assessment rarely changes the implementation strategy but adds noise.
+4. **Trace before planning.** Understanding the execution path prevents "add rate limiter after JWT decode" mistakes where ordering matters.
+5. **Write the plan before the code.** The structured plan from Step 10 is the deliverable. Implementation follows the plan — not the other way around.
+
+## Quality Gate
+
+| Criteria | Pass | Fail |
+|---|---|---|
+| Codebase overview | All 3 overview tools succeed (summary, domains, routes) | Any tool fails or returns empty |
+| Target analysis | `smart_context` + `edit_check` both run | Either tool skipped for the target symbol |
+| Impact assessment | `impact` at depth 3 completed, dependents counted | Impact not run or depth < 3 |
+| Blast radius check | < 5 depth-1 dependents OR user warned and confirmed | > 5 depth-1 dependents without user confirmation |
+| Test plan | `test_plan` covers happy path, edge cases, and errors | Less than 3 scenarios in the plan |
+| Implementation plan | All 7 sections of the plan filled | Missing sections or incomplete analysis |

package/.agents/skills/milens-refactor-clean/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: milens-refactor-clean
+description: Safe Refactoring with Blast Radius Check — find dead code, verify impact, remove safely, and verify test coverage
+---
+
+# milens-refactor-clean — Safe Refactoring with Blast Radius Check
+
+Identify dead or unwanted code, verify it's truly unused via context and text search, assess blast radius, remove safely, and confirm only expected files changed.
+
+## Tools Required
+
+| Tool | Purpose |
+|---|---|
+| `mcp_milens_find_dead_code` | Find exported symbols with zero incoming references |
+| `mcp_milens_context` | Verify a symbol is truly unused (incoming refs check) |
+| `mcp_milens_impact` | Blast radius assessment before removal |
+| `mcp_milens_grep` | Text search for symbol name in configs, templates, docs |
+| `mcp_milens_detect_changes` | Post-refactor verification of changed files |
+| `mcp_milens_test_impact` | Identify affected test files to run |
+
+> **CRITICAL:** All milens MCP tool calls MUST include the `repo` parameter set to the **absolute path of the workspace root**.
+
+## Workflow
+
+### Step 1: Find Candidates
+
+Identify exported symbols with zero incoming code references.
+
+```
+mcp_milens_find_dead_code({repo: "<workspaceRoot>", limit: 30})
+```
+
+The output lists symbols that the static analysis graph shows as unreferenced. These are removal candidates.
+
+**Important caveats:**
+- Symbols used only via reflection, `eval`, or dynamic imports won't show references
+- Side-effect-only imports (e.g., `import "./init"`) may look unused
+- Config-based routing (React Router, NestJS decorators) may not resolve to references
+
+### Step 2: Verify Truly Unused
+
+For each candidate, run context to confirm zero incoming references.
+
+```
+mcp_milens_context({name: "<symbolName>", repo: "<workspaceRoot>"})
+```
+
+Look at the **incoming references** count:
+- **0 incoming refs** — likely safe to remove
+- **1+ incoming refs** — the symbol is used via paths the dead code detector missed; do NOT remove without further investigation
+
+### Step 3: Check Text References
+
+Even if context shows 0 code references, the symbol may appear in non-code files.
+
+```
+mcp_milens_grep({pattern: "<symbolName>", repo: "<workspaceRoot>"})
+```
+
+Check for matches in:
+- **Config files** — `.json`, `.yaml`, `.toml`, `.env`
+- **Template files** — `.html`, `.vue`, `.jsx`, `.tsx` (usage in markup)
+- **Documentation** — `*.md`, `*.mdx`
+- **Route definitions** — string-based routing (Express, FastAPI)
+- **Package scripts** — `package.json` scripts referencing the symbol
+
+### Step 4: Assess Blast Radius
+
+Before deleting, understand what removing the symbol would affect (even if nothing references it now — for safety).
+
+```
+mcp_milens_impact({target: "<symbolName>", depth: 3, repo: "<workspaceRoot>"})
+```
+
+Check:
+- **Depth-1 dependents** — should be 0 for true dead code
+- **Transitive dependents** — if > 0, something references this indirectly
+
+### Step 5: Remove the Code
+
+After verification, remove:
+1. The symbol itself (function, class, interface, etc.)
+2. Its imports if they're now unused
+3. Related tests (now orphaned)
+
+### Step 6: Verify Change Scope
+
+Confirm only expected files changed.
+
+```
+mcp_milens_detect_changes({repo: "<workspaceRoot>"})
+```
+
+Check that:
+- Only the files you intended to modify appear
+- No config files, lockfiles, or unrelated modules changed
+- No accidental deletions
+
+### Step 7: Run Affected Tests
+
+Identify and run tests impacted by the removal.
+
+```
+mcp_milens_test_impact({repo: "<workspaceRoot>"})
+```
+
+This lists test files that reference the removed code or its dependents. Run all affected tests to ensure nothing is broken.
+
+## Example Session
+
+### Input
+
+```
+"remove unused utility functions from the helpers module"
+```
+
+### Tool Calls
+
+**Step 1 — Find candidates:**
+```
+mcp_milens_find_dead_code({repo: "/home/user/project", limit: 30})
+```
+
+**Output:**
+```
+1. formatDateLegacy    [function]  src/utils/helpers.ts:45
+2. unusedValidator     [function]  src/utils/helpers.ts:78
+3. OldUserType         [interface] src/types/legacy.ts:12
+4. debugLog            [function]  src/utils/helpers.ts:102
+```
+
+**Step 2 — Verify context for each:**
+```
+mcp_milens_context({name: "formatDateLegacy", repo: "/home/user/project"})
+```
+
+**Output:** 0 incoming refs, 1 outgoing dep (calls `toISOString`). Safe to remove.
+
+```
+mcp_milens_context({name: "unusedValidator", repo: "/home/user/project"})
+```
+
+**Output:** 0 incoming refs. Safe to remove.
+
+```
+mcp_milens_context({name: "debugLog", repo: "/home/user/project"})
+```
+
+**Output:** 3 incoming refs — used in `server.ts`, `logger.ts`, `middleware.ts`. NOT dead code — skip.
+
+**Step 3 — Text search for remaining candidates:**
+```
+mcp_milens_grep({pattern: "formatDateLegacy", repo: "/home/user/project"})
+```
+
+**Output:** 1 match in `docs/migration-guide.md` — documentation reference only, still safe to remove with a docs update.
+
+```
+mcp_milens_grep({pattern: "OldUserType", repo: "/home/user/project"})
+```
+
+**Output:** 0 matches across all files. Fully dead.
+
+**Step 4 — Impact check:**
+```
+mcp_milens_impact({target: "formatDateLegacy", depth: 3, repo: "/home/user/project"})
+```
+
+**Output:** Depth-1: 0 dependents. No blast radius.
+
+**Step 5 — Remove `formatDateLegacy` and `OldUserType`** in file editor
+
+**Step 6 — Verify scope:**
+```
+mcp_milens_detect_changes({repo: "/home/user/project"})
+```
+
+**Output:**
+```
+Changed files:
+  src/utils/helpers.ts    [modified] — expected
+  src/types/legacy.ts     [modified] — expected
+  docs/migration-guide.md [modified] — expected (updated reference)
+```
+
+**Step 7 — Test impact:**
+```
+mcp_milens_test_impact({repo: "/home/user/project"})
+```
+
+**Output:** 2 affected test files — `src/__tests__/helpers.test.ts`, `src/__tests__/types.test.ts`. Both pass after updating.
+
+## Best Practices
+
+1. **Context beats dead-code detection.** A symbol tagged as "dead" by the detector may still be used via dynamic patterns. Always verify with `context` before deleting.
+2. **Grep is the backstop.** `context` only catches code-level references. `grep` catches template usage, string-based routing, config files, and docs. Never skip Step 3.
+3. **Remove in small batches.** Delete 1-3 symbols per commit. Large-scale deletion makes `detect_changes` harder to verify and `git bisect` harder to use.
+4. **Update docs proactively.** If `grep` finds documentation references, update or remove them in the same commit. Stale docs referencing deleted symbols are worse than no docs.
+5. **Test impact is not optional.** Removing code can break tests that import the symbol directly. Run `test_impact` and fix before committing.
+
+## Quality Gate
+
+| Criteria | Pass | Fail |
+|---|---|---|
+| Dead code identified | `find_dead_code` returns candidates | Tool fails or returns empty (with large codebase) |
+| Verification complete | `context` + `grep` run for every candidate marked for removal | Any candidate removed without both checks |
+| Blast radius safe | All removed symbols have 0 depth-1 dependents | Any symbol with dependents removed without justification |
+| Change scope clean | `detect_changes` shows only expected files | Unexpected files in the diff |
+| Tests pass | All `test_impact` files pass | Any affected test file fails |

package/.agents/skills/milens-security-review/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: milens-security-review
+description: Security Audit — scan for secrets, hidden unicode, dangerous patterns, data leaks, and produce a security report
+---
+
+# milens-security-review — Security Audit
+
+Scan the codebase for security vulnerabilities: exposed secrets, hidden unicode (Trojan Source), dangerous code patterns, data leakage, and unexpected file changes.
+
+## Tools Required
+
+| Tool | Purpose |
+|---|---|
+| `mcp_milens_review_pr` | Initial risk assessment of changed files and symbols |
+| `mcp_milens_grep` | Pattern search for secrets, unicode, dangerous calls, data leaks |
+| `mcp_milens_review_symbol` | Deep-dive risk analysis on high-risk symbols |
+| `mcp_milens_detect_changes` | Verify only expected files changed |
+
+> **CRITICAL:** All milens MCP tool calls MUST include the `repo` parameter set to the **absolute path of the workspace root**.
+
+## Workflow
+
+### Step 1: Initial Risk Assessment
+
+Start with a PR-level overview to identify high-risk areas.
+
+```
+mcp_milens_review_pr({repo: "<workspaceRoot>"})
+```
+
+Focus on:
+- **New files** — highest risk for secrets or vulnerabilities
+- **Modified config files** — `.env`, `config.*`, settings files
+- **Auth/routing files** — middleware, guards, session handlers
+- **CRITICAL-rated symbols** — these get deep-dived in Step 6
+
+### Step 2: Secret Detection
+
+Search for hardcoded secrets and credentials.
+
+```
+mcp_milens_grep({pattern: "password|secret|api_key|token|private_key|AUTH_TOKEN", scope: "code", repo: "<workspaceRoot>"})
+```
+
+Key patterns to flag:
+- **Assignments to secrets** — `const apiKey = "sk-..."` (critical)
+- **Config values** — `password: "admin123"` (high)
+- **Variable names only** — `const apiKey = process.env.KEY` (low — already env-var'd)
+- **Test fixtures** — `const testPassword = "..."` (verify it's not a real password)
+
+### Step 3: Hidden Unicode Detection (Trojan Source)
+
+Search for invisible and bidirectional Unicode characters used in supply-chain attacks.
+
+```
+mcp_milens_grep({pattern: "[\\u200B\\u200C\\u200D\\u2060\\uFEFF\\u202A-\\u202E]", scope: "code", isRegex: true, repo: "<workspaceRoot>"})
+```
+
+These characters can:
+- Make code look like one thing but compile as another
+- Hide backdoors in copy-pasted code
+- Exploit bidirectional text in string literals and comments
+
+**Any match is a CRITICAL finding** — flag for immediate removal.
+
+### Step 4: Dangerous Code Patterns
+
+Search for patterns that enable code injection or arbitrary execution.
+
+```
+mcp_milens_grep({pattern: "eval\\(|exec\\(|child_process|Function\\(", scope: "code", isRegex: true, repo: "<workspaceRoot>"})
+```
+
+Severity guidance:
+- `eval()` / `exec()` with user input — **CRITICAL**
+- `child_process.exec()` with dynamic arguments — **CRITICAL**
+- `new Function()` — **HIGH** (eval equivalent)
+- `child_process.spawn()` with fixed arguments — **LOW** (safer than exec)
+
+### Step 5: Data Leak Detection
+
+Find logging statements that may expose sensitive data.
+
+```
+mcp_milens_grep({pattern: "console\\.(log|debug|info)\\(", scope: "code", isRegex: true, repo: "<workspaceRoot>"})
+```
+
+Flag any `console.log` that logs:
+- User data (emails, names, PII)
+- Tokens, passwords, keys
+- Request bodies or headers
+- Database query results with user data
+
+### Step 6: Deep-Dive on Critical Symbols
+
+For any symbol flagged as CRITICAL in Step 1, run a deep-dive.
+
+```
+mcp_milens_review_symbol({name: "<symbolName>", repo: "<workspaceRoot>"})
+```
+
+This provides:
+- **Role** — what the symbol does (auth, routing, data access)
+- **Heat** — how frequently it changes (volatile code = higher risk)
+- **Dependents** — blast radius if compromised
+- **Test status** — whether its behavior is verified
+
+### Step 7: Verify Change Scope
+
+Confirm that only expected files were modified.
+
+```
+mcp_milens_detect_changes({repo: "<workspaceRoot>"})
+```
+
+This catches:
+- Unintended file modifications (config drift)
+- Stray files included in the commit
+- Missing or extra changes vs. expectations
+
+### Step 8: Produce Security Audit Report
+
+Consolidate into a structured report:
+
+1. **Executive Summary** — overall risk level, critical findings count
+2. **Secret Scan Results** — each match with file, line, severity, and remediation
+3. **Unicode Scan Results** — each match (any match is critical)
+4. **Dangerous Patterns** — each `eval`/`exec`/`Function` usage with justification
+5. **Data Leak Findings** — each `console.log` that logs sensitive data
+6. **Symbol Risk Deep-Dives** — per CRITICAL symbol from Step 6
+7. **Change Scope Verification** — expected vs. actual changed files
+8. **Remediation Plan** — ordered by severity, with specific fix recommendations
+9. **Verdict** — PASSED / NEEDS REMEDIATION / BLOCKED
+
+## Example Session
+
+### Input
+
+```
+"run a security audit before the release"
+```
+
+### Tool Calls
+
+**Step 1 — PR overview:**
+```
+mcp_milens_review_pr({repo: "/home/user/project"})
+```
+
+**Output:** 8 changed files, 2 CRITICAL symbols (`authHandler`, `paymentProcessor`).
+
+**Step 2 — Secret detection:**
+```
+mcp_milens_grep({pattern: "password|secret|api_key|token|private_key|AUTH_TOKEN", scope: "code", repo: "/home/user/project"})
+```
+
+**Output:**
+```
+src/config.ts:12    apiKey: "sk-prod-abc123..."     ← CRITICAL: hardcoded API key
+src/auth/login.ts:34 const password = req.body.pass   ← LOW: variable assignment
+src/__tests__/helpers.ts:8  const testToken = "test"  ← OK: test fixture
+```
+
+**Step 3 — Unicode scan:**
+```
+mcp_milens_grep({pattern: "[\\u200B\\u200C\\u200D\\u2060\\uFEFF\\u202A-\\u202E]", scope: "code", isRegex: true, repo: "/home/user/project"})
+```
+
+**Output:** 0 matches. Clean.
+
+**Step 4 — Dangerous patterns:**
+```
+mcp_milens_grep({pattern: "eval\\(|exec\\(|child_process|Function\\(", scope: "code", isRegex: true, repo: "/home/user/project"})
+```
+
+**Output:**
+```
+src/scripts/migrate.ts:22  exec(`pg_dump ${dbName}`)  ← CRITICAL: dynamic args
+```
+
+**Step 5 — Data leak:**
+```
+mcp_milens_grep({pattern: "console\\.(log|debug|info)\\(", scope: "code", isRegex: true, repo: "/home/user/project"})
+```
+
+**Output:**
+```
+src/auth/login.ts:28  console.log("User login:", email)  ← HIGH: logs PII
+```
+
+**Step 6 — Deep-dive:**
+```
+mcp_milens_review_symbol({name: "authHandler", repo: "/home/user/project"})
+```
+
+**Output:** Core auth entry point, 23 dependents, 0 tests — very high risk.
+
+**Step 7 — Verify scope:**
+```
+mcp_milens_detect_changes({repo: "/home/user/project"})
+```
+
+**Output:** 8 files changed — matches expectations.
+
+**Step 8 — Report produced** (see report format above). Verdict: **NEEDS REMEDIATION** (1 critical secret, 1 critical dangerous pattern, 1 high data leak).
+
+## Best Practices
+
+1. **Don't assume variable names are safe.** `const password = process.env.DB_PASS` is fine; `const password = "admin123"` is not. Read the value, not just the name.
+2. **Unicode scan is non-negotiable.** Trojan Source attacks are invisible to human reviewers. Even a single zero-width character match is a blocking finding.
+3. **Test fixtures get a pass — but verify.** `const testApiKey = "test-key"` is acceptable, but `const testApiKey = "sk-live-..."` is a leaked production key.
+4. **Dynamic exec/Function is almost always wrong.** If `exec()` takes user-controlled input, it's remote code execution. The only acceptable pattern is fully-hardcoded command strings.
+5. **Detect changes verifies the boundary.** If `detect_changes` shows files you didn't touch, something went wrong — config drift, lockfile churn, or accidental staging.
+
+## Quality Gate
+
+| Criteria | Pass | Fail |
+|---|---|---|
+| Secret scan | No hardcoded secrets found outside test fixtures | Any production secret in code |
+| Unicode scan | Zero matches | Any hidden unicode character found |
+| Dangerous patterns | No `eval`/`exec` with dynamic input | Any dynamic `exec()` or `Function()` call |
+| Data leak | No PII/credentials in `console.log` | Sensitive data logged to console |
+| Change scope | `detect_changes` matches expectations | Unexpected files in the diff |
+| All scans completed | All 7 steps executed | Any tool call skipped or failed |