@polderlabs/bizar 10.7.1 → 10.7.2

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

@@ -0,0 +1,170 @@
+---
+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

@@ -0,0 +1,324 @@
+---
+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

@@ -0,0 +1,142 @@
+---
+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 |