@polderlabs/bizar 10.7.2 → 10.11.0

package/.claude/skills/thinking-pre-mortem/SKILL.md

@@ -1,170 +0,0 @@
----
-name: thinking-pre-mortem
-description: Before committing to a plan or launch, assume it has already failed and reason backward through why — prospective hindsight surfaces risks that "what could go wrong?" misses.
----
-
-# Pre-Mortem Analysis
-
-## Overview
-The pre-mortem, developed by psychologist Gary Klein, uses "prospective hindsight": instead of asking "What could go wrong?", assume the plan HAS failed and reason backward through why. Stating failure as already-happened surfaces concrete risks that forward-looking risk assessment glosses over.
-
-**Core Principle:** It's easier to explain a failure that "already happened" than to predict one. Use that asymmetry productively in a single reasoning pass.
-
-## When to Use
-- Project kickoff (before work begins)
-- Before committing to a major technical decision
-- Sprint planning for high-risk work
-- Before launch or major release
-- When team seems overconfident
-- After a plan is formed but before execution
-
-Decision flow:
-```
-Starting significant work? → yes → Plan looks solid / on track? → yes → PRE-MORTEM ESSENTIAL
-                                                              ↘ no → Pre-mortem still valuable
-                         ↘ no → Standard risk assessment may suffice
-```
-
-## When NOT to Use
-- The work is small, local, and reversible — failure is cheap to undo, so skip the ceremony.
-- You're mid-incident under time pressure — act on the likely cause now (ooda/occams-razor); pre-mortem belongs *before* execution, not during firefighting.
-- You'd only generate generic risks ("requirements unclear", "scope creep") that don't bind to this specific plan — stop if nothing concrete surfaces.
-- The risks are already enforced by automated gates (CI, canary, rollback) — don't re-list what the system already catches.
-
-## Trigger Card
-
-Before committing to a plan or launch where optimism may be hiding risks:
-
-1. **Assume it has already failed** — "It's six months later. The project was a disaster. What happened?"
-2. **List concrete failure reasons** — specific to THIS plan, not generic. Why did it actually fail?
-3. **Mitigate the top 3-5** — for each top failure reason, add a concrete safeguard or change the plan.
-
-Skip if you'd only generate generic risks that don't bind to this specific plan. If risks are already enforced by automated gates (CI, canary, rollback), don't re-list what the system already catches. For a full launch risk review, run the full procedure.
-
-## The Process
-
-### Step 1: Set the Failure Frame
-Adopt the stance that the plan has already failed, stated in past tense:
-> "It is [future date, post-deadline]. This plan didn't just slip — it failed. The launch was rolled back / the migration corrupted data / adoption never happened."
-
-Past tense is what makes this work: you are *explaining* a failure, not *predicting* one.
-
-### Step 2: Generate Failure Reasons (one prospective-hindsight pass)
-Reason through *why* it failed across every angle. Push for breadth, not comfort — aim for 15+ distinct reasons before filtering:
-- **Technical:** wrong architecture, integration/contract breaks, scale limits, data loss
-- **Process:** untested paths, no rollback, deploy timing, missing migration step
-- **Assumptions:** which load-bearing assumption turned out false?
-- **Dependencies/external:** upstream API, vendor, rate limits, config drift
-- Force a second sweep: "What did I, the author of this plan, most want to be true that wasn't?"
-
-Generate the full list first; do not prune or rank while generating (premature filtering anchors on the obvious risks).
-
-### Step 3: Categorize and Prioritize
-Group by theme and assess:
-
-| Category | Risk | Likelihood | Impact | Priority |
-|----------|------|------------|--------|----------|
-| Technical | API integration fails | High | Critical | P0 |
-| Process | Requirements unclear | Medium | High | P1 |
-| People | Key person leaves | Low | Critical | P1 |
-| External | Vendor delays | Medium | Medium | P2 |
-
-### Step 4: Develop Mitigations
-For top risks, define:
-```
-Risk: API integration fails
-Mitigation:
-- Spike on integration first, before depending on it
-- Identify fallback vendor / degrade path
-- Build abstraction layer for swap-ability
-Verification: integration smoke test passes before downstream work begins
-```
-
-### Step 5: Update the Plan
-Incorporate mitigations into the plan:
-- Add spike/investigation tasks ahead of dependent work
-- Build in contingency for the highest P×S risks
-- Add a concrete verification/checkpoint for each top risk
-
-## Pre-Mortem Template
-
-```markdown
-# Pre-Mortem: [Project Name]
-Date: [Date]
-
-## The Scenario
-It is [Future Date]. [Project] has failed. 
-
-## Failure Reasons Identified
-
-### Technical
-- [Reason 1]
-- [Reason 2]
-
-### Process  
-- [Reason 1]
-- [Reason 2]
-
-### People/Team
-- [Reason 1]
-- [Reason 2]
-
-### External/Dependencies
-- [Reason 1]
-- [Reason 2]
-
-## Priority Risks and Mitigations
-
-### P0: [Risk Name]
-- **Description**: [What went wrong]
-- **Mitigation**: [How to prevent]
-- **Owner**: [Who]
-- **Checkpoint**: [When to verify]
-
-### P1: [Risk Name]
-...
-
-## Plan Updates
-- [ ] [Action item from pre-mortem]
-  ...
-```
-
-## Why Pre-Mortems Work
-
-1. **Reframes prediction as explanation**: Explaining an "already-happened" failure is concrete; predicting one stays vague.
-2. **Defeats first-plausible-answer lock-in**: Generating the full failure list before ranking stops anchoring on the obvious risk.
-3. **Surfaces buried assumptions**: Asking "what did the plan need to be true that wasn't?" exposes load-bearing assumptions the forward plan hid.
-4. **Counters optimism**: The forced-failure stance overrides the natural bias toward "this will work."
-
-## Common Failure Categories to Prompt
-
-| Category | Example Failures |
-|----------|-----------------|
-| Requirements | Scope creep, unclear success criteria, missing stakeholder |
-| Technical | Wrong architecture, integration failures, scale issues |
-| Timeline | Underestimation, dependencies delayed, parallel work blocked |
-| Team | Key person unavailable, skill gaps, communication breakdown |
-| External | Vendor issues, regulatory changes, market shift |
-| Process | Insufficient testing, deployment problems, no rollback |
-
-## Execution Tips
-- **Use past tense** consistently ("failed" not "might fail") — it's what triggers the hindsight effect.
-- **Generate before filtering** — collect the full list, then rank; don't prune mid-sweep.
-- **Interrogate the plan's own optimism** — what did the author most want to be true?
-- **Convert to action** — a pre-mortem with no plan change is wasted; each top risk needs a mitigation + verification.
-
-## Verification Checklist
-- [ ] Run before significant work begins (not mid-incident)
-- [ ] Failure frame stated in past tense
-- [ ] 15+ distinct failure reasons generated before ranking
-- [ ] Risks prioritized by likelihood × impact
-- [ ] Top 3-5 risks have explicit mitigations
-- [ ] Each mitigation has a concrete verification/checkpoint
-- [ ] Plan updated to incorporate findings
-
-## Key Questions
-- "The plan failed. Why?"
-- "What was obvious in retrospect that the plan missed?"
-- "What warning signs would have shown up first?"
-- "Which load-bearing assumption turned out to be false?"
-- "What did the plan most need to be true that wasn't?"

package/.claude/skills/thinking-probabilistic/SKILL.md

@@ -1,324 +0,0 @@
----
-name: thinking-probabilistic
-description: Use when stating a forecast, estimate, or risk. Anchor on the base rate, give a confidence range instead of a point, and update the number when new evidence arrives.
----
-
-# Probabilistic Thinking
-
-## Overview
-
-Probabilistic thinking, informed by Philip Tetlock's "Superforecasting," treats a forecast as a probability and a range rather than a single confident number. Three moves do almost all the work: **anchor on the base rate**, **express the estimate as a range** (not a point), and **update the number** when new evidence arrives.
-
-**Core Principle:** Start from how often similar things happen, state your estimate as a range with a confidence level, and move the number — explicitly — when the evidence moves.
-
-> **Stateless-agent note.** Across a single task you have no persistent prediction log, so there is no "track my calibration over months" step here. The leverage is in the *act* of estimating: base rate, range, update. Apply the calibration *attitude* (assume you're overconfident; widen the range) without pretending to keep a cross-session scorecard you don't have.
-
-## When to Use
-
-- Stating a timeline or effort estimate
-- Assessing the risk of an action (migration, deploy, change)
-- Predicting an outcome (will this fix work? will this launch hit the target?)
-- Evaluating an uncertain technical choice
-- Any time you're about to give a confident single number you can't actually be sure of
-
-Decision flow:
-
-```
-About to state a forecast/estimate/risk?
-  → Outcome genuinely uncertain? → yes → BASE RATE, then a RANGE (not a point)
-  → New evidence since last estimate? → yes → UPDATE THE NUMBER
-  → Can you just look it up / measure it? → yes → DO THAT INSTEAD
-```
-
-## When NOT to Use
-
-- **The quantity is knowable.** If you can measure it, query it, or look it up, do that — don't dress a checkable fact as a probability.
-- **A single piece of evidence updates a single prior.** That's the narrower mechanics of `thinking-bayesian`; use it for the explicit prior × likelihood-ratio update.
-- **The decision doesn't depend on the number.** If you'd act the same across the plausible range, skip the estimate and act.
-- **You'd be inventing the base rate.** If there's no real reference class, say the estimate is a guess rather than manufacturing false precision.
-
-## Core Concepts
-
-### Probability as Confidence
-
-Convert vague language to numbers:
-
-| Vague Statement | Probability Range |
-|-----------------|-------------------|
-| "Certain" | 99%+ |
-| "Almost certain" | 90-99% |
-| "Very likely" | 80-90% |
-| "Likely" / "Probable" | 65-80% |
-| "Better than even" | 55-65% |
-| "Toss-up" | 45-55% |
-| "Unlikely" | 20-35% |
-| "Very unlikely" | 10-20% |
-| "Almost impossible" | 1-10% |
-| "Impossible" | <1% |
-
-### Confidence Intervals
-
-Express estimates as ranges, not points:
-
-```
-BAD: "The project will take 6 weeks"
-GOOD: "I'm 80% confident the project will take 4-8 weeks"
-BETTER: "50% confidence: 5-7 weeks; 90% confidence: 3-10 weeks"
-```
-
-### Base Rates
-
-Start with how often similar things happen:
-
-```
-Question: Will this feature launch on time?
-Base rate: What % of similar features launched on time? ~40%
-Adjustment: This team is experienced (+10%), scope is clear (+10%)
-Estimate: ~60% probability of on-time launch
-```
-
-## The Probabilistic Process
-
-### Step 1: Express Initial Probability
-
-State your belief as a number:
-
-```markdown
-## Prediction: Will we hit Q2 revenue target?
-
-Initial estimate: 65%
-Reasoning:
-- Last 4 quarters: Hit 3/4 targets (75% base rate)
-- Current pipeline: Slightly below historical (-10%)
-- New product launching: Uncertain impact
-```
-
-### Step 2: Identify Key Uncertainties
-
-What could change the probability?
-
-```markdown
-Key uncertainties:
-1. Will Enterprise deal close? (+15% if yes)
-2. Will new product cannibalize existing? (-10% if significant)
-3. Will competitor launch disrupt? (-20% if aggressive)
-```
-
-### Step 3: Create Probability Tree
-
-For complex predictions, branch scenarios:
-
-```
-Project success: ?
-├── Technical risk resolves well (60%)
-│   ├── Team stays intact (80%) → 0.60 × 0.80 = 48% → SUCCESS
-│   └── Key person leaves (20%) → 0.60 × 0.20 × 0.50 = 6% → PARTIAL
-├── Technical risk causes delays (30%)
-│   ├── Scope reduced (60%) → 0.30 × 0.60 × 0.70 = 12.6% → SUCCESS
-│   └── Scope maintained (40%) → 0.30 × 0.40 = 12% → FAILURE
-└── Technical risk blocks project (10%) → 10% → FAILURE
-
-P(Success) = 48% + 12.6% = 60.6% ≈ 60%
-```
-
-### Step 4: Update with New Information
-
-When new evidence arrives, update:
-
-```markdown
-Original estimate: 65% hit revenue target
-
-New information: Enterprise deal delayed to Q3
-Impact: -15% (was +15% if closed, now neutral)
-Updated estimate: 50%
-
-New information: Competitor launch was weak
-Impact: +10% (was -20% if aggressive)
-Updated estimate: 60%
-```
-
-### Step 5: State the Estimate So It Can Be Checked
-
-Make the forecast falsifiable within the task itself: a clear claim, a timeframe, and the range. This lets the *user or a later observation* verify it — you don't carry a personal scorecard across sessions, but a sharply-stated prediction can still be proven right or wrong.
-
-```markdown
-Prediction: "80% confident the migration completes with <5 min downtime,
-            range 1-15 min downtime." (Checkable against the actual run.)
-```
-
-## Calibration Techniques
-
-> These are sanity checks you apply *now*, within the task — not a longitudinal tracking exercise.
-
-### The Equivalent Bet Test
-
-"Would I bet at these odds?"
-
-```
-Prediction: 80% confident project finishes on time
-Equivalent: Would I bet $4 to win $1?
-If that feels wrong, adjust the probability.
-```
-
-### The Outside View
-
-Always check base rates:
-
-```
-Inside view: "Our team is great, we'll definitely finish on time"
-Outside view: "What % of similar projects finished on time?"
-
-Inside tends toward overconfidence
-Outside provides calibration anchor
-```
-
-### The Pre-Mortem Adjustment
-
-Imagine failure, then adjust:
-
-```
-Initial estimate: 85% success
-After pre-mortem: Identified 5 failure modes I hadn't considered
-Adjusted estimate: 70%
-```
-
-### The Confidence Interval Check
-
-Are your intervals too narrow?
-
-```
-Test: Of your 90% confidence intervals, do 90% contain the actual?
-Common finding: Only 60-70% do
-Fix: Widen intervals by 50%
-```
-
-## Application Examples
-
-### Project Estimation
-
-```markdown
-## Project: Payment System Rewrite
-
-Timeline estimate:
-- 50% confidence: 8-12 weeks
-- 80% confidence: 6-16 weeks
-- 95% confidence: 4-24 weeks
-
-Key variables:
-- API complexity: High uncertainty (+/- 3 weeks)
-- Team availability: Medium uncertainty (+/- 2 weeks)
-- Integration testing: High uncertainty (+/- 4 weeks)
-
-Commitment: "We're 80% confident we'll deliver in Q2"
-```
-
-### Risk Assessment
-
-```markdown
-## Risk: Database migration causes extended downtime
-
-Probability assessment:
-- Base rate for similar migrations: 20% have issues
-- Our preparation level: Above average (-5%)
-- Complexity of our schema: Above average (+5%)
-- Rollback plan quality: Strong (-5%)
-
-Estimate: 15% probability of extended downtime
-
-Mitigation value:
-- If issue occurs: 4 hours downtime × $10K/hour = $40K
-- Expected loss: 15% × $40K = $6K
-- Mitigation cost: $3K for additional testing
-- Decision: Mitigation worth it (ROI positive)
-```
-
-### Technical Decision
-
-```markdown
-## Decision: Adopt new framework
-
-Success probability factors:
-| Factor | Probability | Weight |
-|--------|-------------|--------|
-| Team learns quickly | 70% | 0.3 |
-| Framework matures | 80% | 0.2 |
-| Performance meets needs | 60% | 0.3 |
-| Integration works | 75% | 0.2 |
-
-Combined probability (simplified):
-0.70 × 0.80 × 0.60 × 0.75 = 25% (if all must succeed)
-OR weighted average: 70% (if partial success acceptable)
-
-Decision: High uncertainty suggests pilot first
-```
-
-## Probabilistic Thinking Template
-
-```markdown
-# Probabilistic Assessment: [Prediction]
-
-## Prediction
-[Clear, falsifiable statement with timeframe]
-
-## Initial Probability
-Estimate: [X]%
-Base rate: [Similar events: Y%]
-Adjustment rationale: [Why different from base rate]
-
-## Confidence Interval
-- 50% CI: [Range]
-- 80% CI: [Range]
-- 95% CI: [Range]
-
-## Key Uncertainties
-| Uncertainty | If positive | If negative |
-|-------------|-------------|-------------|
-| [Factor 1] | +X% | -Y% |
-| [Factor 2] | +X% | -Y% |
-
-## Updates (within this task)
-| New information | Old P | New P |
-|-----------------|-------|-------|
-| | | |
-
-## Checkable Outcome
-[The specific observation that will prove this forecast right or wrong]
-```
-
-## Verification Checklist
-
-- [ ] Expressed prediction as specific probability
-- [ ] Checked base rate for similar events
-- [ ] Created appropriate confidence intervals
-- [ ] Identified key uncertainties and their impacts
-- [ ] Stated the prediction so it's checkable (claim + timeframe + range)
-- [ ] Applied equivalent bet test for sanity check
-- [ ] Willing to update the number when new information arrives
-
-## Key Questions
-
-- "What probability would I assign to this?"
-- "What's the base rate for similar things?"
-- "What would change my estimate up or down?"
-- "Am I being overconfident? (Usually yes — widen the range)"
-- "Have I given a range, or am I hiding uncertainty behind a single number?"
-- "Would I bet at these odds?"
-
-## Tetlock's Superforecaster Traits
-
-1. **Update often:** Change the number when evidence changes
-2. **Granular probabilities:** Use 65% not "likely"
-3. **Outside view:** Start with base rates
-4. **Seek disconfirming evidence:** Look for reasons you're wrong
-5. **Ranges, not points:** Express confidence as an interval, and widen it
-6. **Intellectual humility:** Assume you're often wrong
-
-## Tetlock's Wisdom
-
-"The fox knows many things, but the hedgehog knows one big thing."
-
-Superforecasters are foxes—they integrate many perspectives, update frequently, and avoid ideological certainty. They're not smarter; they're more calibrated.
-
-"Beliefs are hypotheses to be tested, not treasures to be protected."
-
-Your predictions should change as evidence changes. Holding steady when you should update is a calibration failure.

package/.claude/skills/thinking-red-team/SKILL.md

@@ -1,142 +0,0 @@
----
-name: thinking-red-team
-description: Use when reviewing code, auth, or APIs for security vulnerabilities — adopt an attacker mindset, enumerate the attack surface, report only findings with a concrete reproducible attack path.
----
-
-# Red Team Thinking
-
-## Overview
-
-Red teaming is **adversarial security review**: deliberately attacking a system you control to find vulnerabilities before an attacker does. This skill is scoped to security/code vulnerability detection — it is NOT for plan stress-testing or decision challenge (use `thinking-pre-mortem` or `thinking-steel-manning` for those).
-
-**The anti-fabrication gate is the most important rule:** every reported finding MUST include a concrete, reproducible attack path — entry point → exact steps → realized impact. If you cannot describe how the attack actually executes against *this* code/config, it is not a finding. Drop it. A short report of real, demonstrable vulnerabilities beats a long list of speculation.
-
-**Core Principle:** Attack yourself before others do. But only report what you can actually break.
-
-## When to Use
-
-- Security review of code, authentication, authorization, APIs, or infrastructure you control
-- Pre-launch security hardening of a system that handles auth, data, or money
-- Evaluating whether a specific vulnerability class (injection, XSS, auth bypass, etc.) is present in your code
-
-Decision flow:
-
-```
-Reviewing a system for security?
-  → Can you demonstrate an attack path? → No → Don't report it
-  → Is the finding reproducible against this code/config? → No → Drop it
-  → Is this plan stress-testing or decision challenge? → Yes → Use thinking-pre-mortem or thinking-steel-manning
-  → No → RED TEAM IT
-```
-
-## When NOT to Use
-
-- **Speculative claims without a reproducible attack path.** This is the anti-fabrication gate. "Best practice says X" or "this could theoretically be vulnerable" is not a finding. State the entry point, exact steps, and realized impact — or drop it.
-- **Plan, strategy, or decision stress-testing.** For "how could this plan fail," use `thinking-pre-mortem`. For "what's the strongest case against this decision," use `thinking-steel-manning`.
-- **Architecture review without security focus.** For architecture resilience, use `thinking-systems` or `thinking-pre-mortem`.
-- **Running scanners replaces thinking.** Where you can actually run a SAST tool, fuzzer, or PoC, do that. This skill structures the adversarial thinking; it doesn't replace automated verification.
-- **Padding the report to look thorough.** A short list of real vulnerabilities beats a long list of theoretical ones. Resist the incentive to add "informational" or "best-practice" items.
-
-## Procedure
-
-### Step 1: Define the Target and Scope
-
-```markdown
-Target: [System/component under review]
-Scope: [What to attack — be specific]
-Out of scope: [What to skip]
-Goal: [What constitutes a successful attack — e.g., unauthorized access, data exfiltration, privilege escalation]
-```
-
-### Step 2: Adopt the Adversary Mindset
-
-Identify who would attack this system and what they want:
-
-```markdown
-Adversary profiles:
-- External attacker (no access): targets public endpoints, auth bypass, injection
-- Authenticated user (basic access): targets privilege escalation, IDOR, business logic
-- Insider (elevated access): targets data exfiltration, audit bypass
-
-For each profile, ask: "If I wanted to cause maximum damage with their access level, how would I?"
-```
-
-### Step 3: Enumerate the Attack Surface
-
-Map every entry point and trust boundary:
-
-| Surface | Exposure | Trust Boundary |
-|---------|----------|----------------|
-| Login form | Public internet | Anonymous → Authenticated |
-| API /graphql | Public (with key) | Authenticated → Application |
-| Password reset flow | Public | Anonymous → Account owner |
-| Admin panel | Internal network | Authenticated → Admin |
-| File upload endpoint | Authenticated | User data → Server storage |
-
-### Step 4: Execute Attack Scenarios
-
-For each attack surface, attempt to break the system:
-
-```markdown
-Attack: Credential stuffing against login
-Steps:
-1. Obtain breach database of known credentials
-2. Script requests against /login with varied credentials
-3. Observe rate limiting, account lockout, timing differences
-Findings:
-- Rate limiting: 10 req/min per IP (bypassable via distribution)
-- Account lockout: none
-- Timing: response time reveals valid vs invalid usernames ← VULNERABILITY
-```
-
-For each attack scenario, record: the entry point, exact steps taken, observed behavior, and whether a vulnerability was found.
-
-### Step 5: Attempt Defense Bypass
-
-For each defense encountered, try to bypass it:
-
-| Defense | Bypass Attempt | Result |
-|---------|---------------|--------|
-| IP-based rate limiting | Distribute requests across IPs | BYPASSED |
-| Input validation | Unicode normalization attacks | RESISTED |
-| Session timeout | Replay expired token with modified timestamp | BYPASSED |
-
-### Step 6: Document Findings — With the Anti-Fabrication Gate
-
-For EVERY finding, fill out:
-
-```markdown
-Finding: [Title]
-Severity: Critical / High / Medium / Low
-Attack path (REQUIRED):
-  Entry point: [URL, endpoint, parameter, file]
-  Steps: [1. Send X, 2. Observe Y, 3. Escalate to Z]
-  Realized impact: [What the attacker actually achieves — data access, privilege, DoS]
-Remediation: [Concrete fix]
-```
-
-**If you cannot fill out the attack path completely, drop the finding.** Do not report "Missing HttpOnly flag" as a standalone finding without demonstrating session token theft. Do not report "No rate limiting" without demonstrating a viable brute-force attack.
-
-## Output Contract
-
-A completed Red Team report produces:
-
-1. **Target and Scope** — what was reviewed and what was excluded
-2. **Attack Surface Map** — entry points with exposure levels and trust boundaries
-3. **Attack Scenarios Executed** — each scenario with steps, observations, and outcome
-4. **Findings Report** — each with severity AND a concrete, reproducible attack path (entry point → steps → impact)
-5. **Defense Bypass Results** — which defenses held and which were circumvented
-6. **Remediation Recommendations** — prioritized by severity with concrete fixes
-
-Findings without a complete attack path are excluded from the report. A report with zero findings is acceptable if no reproducible vulnerabilities were discovered.
-
-## Anti-Patterns
-
-| Anti-Pattern | Symptom | Correction |
-|---|---|---|
-| **Speculative claims** | Findings that say "could be vulnerable" or "best practice says" without a demonstrated attack path | Drop them; only report what you can actually break |
-| **Padding the report** | Adding "informational" or "best-practice" items to look thorough | A short report of real vulns beats a long list of theory |
-| **Non-security red-teaming** | Using this skill for plan stress-testing or decision challenge | Use `thinking-pre-mortem` (plans) or `thinking-steel-manning` (decisions) |
-| **Skipping the adversary model** | Attacking without defining who the attacker is and what access they have | Define the adversary profile first; attacks make sense only in context |
-| **Missing the attack path** | Reporting a vulnerability without showing how to reach it | Every finding needs: entry point → steps → impact |
-| **Scanner-as-substitute** | Running a SAST tool and reporting its output without adversarial thinking | The tool finds patterns; red-teaming finds exploitable paths |