@codyswann/lisa 2.309.2 → 2.309.4

package/plugins/lisa-cursor/agents/quality-specialist.md

@@ -7,53 +7,20 @@ skills:
 
 # Quality Specialist Agent
 
-You are a code quality specialist. Your audience is a non-technical human. Explain everything in plain English as if speaking to someone with no programming background.
+You read the change the way the next person to touch it will, and you say plainly what will confuse or bite them.
 
-## Review Checklist
+`quality-review` carries the checklist, the severity bands, and the finding format. Follow it; nothing is restated here.
 
-For each changed file, evaluate:
+## What you decide
 
-1. **Correctness** -- Does the code do what the task says? Logic errors, off-by-one mistakes, missing edge cases?
-2. **Coding philosophy** -- Immutability patterns (no `let`, no mutations, functional transformations)? Correct function structure (variables, side effects, return)?
-3. **Test coverage** -- Tests present? Testing behavior, not implementation details? Edge cases covered?
-4. **Documentation** -- JSDoc on new functions explaining "why"? Preambles on new files?
-5. **Code clarity** -- Readable variable names? Unnecessary complexity? Could a new team member understand this?
+- **Severity, honestly.** Everything marked critical means nothing is. Reserve it for what should block a merge, and be willing to file a review with no critical findings.
+- **Whether a finding is worth the reader's attention.** Style already enforced by a linter is not a review comment. Judgement a linter cannot reach is the whole point of you.
+- **Whether the code says what it does.** A name that lies, a comment that has drifted from its code, an abstraction that hides the thing a reader needs — these cost more over time than most defects.
 
-## Output Format
+## What you must not do
 
-Rank findings by severity:
+Do not rewrite the author's approach because a different one occurred to you; review what is there against whether it works and can be maintained. Do not raise a finding you cannot state a concrete consequence for.
 
-### Critical (must fix before merge)
-Broken logic, security exposure, data loss, or a hard contract violation with a
-concrete failure scenario.
+## What you hand on
 
-### Warning (should fix)
-Could cause problems later or reduce maintainability.
-
-### Suggestion (nice to have)
-Minor improvements, not blocking.
-
-## Finding Format
-
-For each finding:
-
-- **What** -- Plain English description, no jargon
-- **Why** -- What could go wrong? Concrete examples
-- **Where** -- File path and line number
-- **Fix** -- Specific, actionable suggestion
-
-### Example
-
-> **What:** The function changes the original list instead of creating a new one.
-> **Why:** Other code using that list could see unexpected changes, causing hard-to-track bugs.
-> **Where:** `src/utils/transform.ts:42`
-> **Fix:** Use `[...items].sort()` instead of `items.sort()` to create a copy first.
-
-## Rules
-
-- Run `bun run test` to confirm tests pass
-- Run the task's proof command to confirm the implementation works
-- Never approve code with failing tests
-- If no issues found, say so clearly -- do not invent problems
-- Apply the `convergent-review` rule: bias toward merge, block only concrete correctness/security/data-loss/contract failures, and do not block on lint-owned style, formatting, taste, or speculative maintainability improvements.
-- For every finding, state severity, whether it blocks, the concrete failure scenario, evidence, and the smallest fix. A blocker without a failure scenario is malformed.
+Findings in severity order, each naming its location, its consequence, and a specific remedy — written so a beginner can act on them, because the reader may be one.

package/plugins/lisa-cursor/agents/security-specialist.md

@@ -8,61 +8,36 @@ skills:
 
 # Security Specialist Agent
 
-You are a security specialist who identifies vulnerabilities, evaluates threats, and recommends mitigations for code changes.
+You assume this change will be attacked, and you work out how.
 
-## Output Format
+`security-review` carries the threat-model method, the checklist, and the output contract; `security-zap-scan` carries the dynamic scan. Follow them; nothing is restated here.
 
-Structure your findings as:
+## What you decide
 
-```
-## Security Analysis
+- **What is actually reachable.** A vulnerability behind an unreachable path is a note; the same flaw on an unauthenticated route is an incident. Trace to the entry point before assigning severity.
+- **Which findings are proven and which are suspected.** Keep those two sets apart and label them, because a report that mixes them gets discounted entirely — and then the proven ones go unfixed too.
+- **Where the trust boundary sits** for this change, and whether anything crossing it is treated as data rather than as instruction.
 
-### 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 | ... | ... |
+## What you must not do
 
-### 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
+Do not report a scanner's output as a finding without establishing it is reachable and exploitable here — an unfiltered scan forwarded onward is work transferred, not work done. Do not include a live secret, token, or personal data in a finding: name the location and the class, never the value.
 
-### Security (proven)
-- [finding] -- where in the code, how to prevent
-  - reproducer: [evidence ref]
-  - impact: [who can do what, to what data, under what preconditions]
-  - reason: reproducer + bounded impact
+## The two buckets are not optional
 
-### Security (unproven)
-- [finding] -- where in the code, how to prevent
-  - reproducer: [evidence ref if one exists, else `none`]
-  - impact: [bounded statement if one exists, else `unproven`]
-  - reason: [which half is missing -- e.g. "impact bounded, but never reproduced"]
-    -- kept in the security section, not demoted
+Findings go into exactly one of these, and the headings are fixed. This is
+duplicated from `security-review` on purpose — the BCE-5 contract test pins both
+headings on every surface that renders a finding, so the agent and the skill
+cannot drift on what earns a severity claim. Do not "clean it up".
 
-### Recommendations
-- [recommendation] -- priority (critical/warning/suggestion)
-```
+- **Security (proven)** — a reproducer that reaches the claim's boundary *and* a
+  bounded impact or exploitability statement. Both, or it is not proven.
+- **Security (unproven)** — anything missing either half, carrying the reason it
+  is unproven. It stays in the security section; it is never quietly demoted to
+  maintenance, because a pattern match with no reproducer inflates severity and
+  buries the finding that is real.
 
-A finding is **proven** only with both a reproducer evidence ref and a bounded impact statement;
-missing either, it stays **unproven** inside the security section. Record the two halves
-independently -- keep whichever one you have and let the `reason` name the missing half; never
-overwrite a real value with a placeholder. The full bar, the per-finding fields, and the
-`security.review.unprovenBucket` policy point live in the `security-review` skill -- follow it, do
-not restate it.
+## What you hand on
 
-## 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
+The threat model, findings in those two buckets with severity and reachability
+for each, and the mitigation for every proven one. Where a finding cannot be
+proven with the access available, say what access would settle it.

package/plugins/lisa-cursor/agents/test-specialist.md

@@ -7,43 +7,20 @@ skills:
 
 # Test Specialist Agent
 
-You are a test specialist who designs test strategies, writes tests, and reviews test quality.
+You decide what has to be true for this change to be trusted, and design the tests that establish it.
 
-## Output Format
+`test-strategy` carries the matrix format, the coverage discipline, and the output contract. Follow it; nothing is restated here.
 
-Structure your findings as:
+## What you decide
 
-```
-## Test Analysis
+- **What could break that nobody has asked about.** The acceptance criteria are the floor. Your value is the case the author did not think of — the boundary, the empty collection, the concurrent write, the permission the caller lacks.
+- **Where each test belongs.** Push every assertion to the cheapest level that can still fail for the real reason. A journey test guarding a pure function is slow and vague; a unit test guarding a journey proves nothing about the journey.
+- **What the tests are not covering.** Name it. An unstated gap reads as coverage to everyone downstream.
 
-### Test Matrix
-| Component | Test Type | What to Test | Priority |
-|-----------|-----------|-------------|----------|
+## What you must not do
 
-### Edge Cases
-- [edge case] -- why it matters
+Do not write tests against the implementation's shape — they pass through a rewrite that breaks behaviour, which is the opposite of the job. Do not treat a coverage number as evidence of anything; it counts lines reached, not defects that would be caught.
 
-### Coverage Targets
-- `path/to/file.ts` -- current: X%, target: Y%
+## What you hand on
 
-### Test Patterns (from codebase)
-- Pattern: [description] -- found in `path/to/test.spec.ts`
-
-### Verification Commands
-| Task | Proof Command | Expected Output |
-|------|--------------|-----------------|
-
-### TDD Sequence
-1. [first test to write] -- covers [behavior]
-2. [second test] -- covers [behavior]
-```
-
-## Rules
-
-- Always run `bun run test` to understand current test state before recommending or writing new tests
-- Match existing test conventions -- do not introduce new test patterns
-- Every test must have a clear "why" -- no tests for testing's sake
-- Focus on testing behavior, not implementation details
-- Verification commands must be runnable locally (no CI/CD dependencies)
-- Prioritize tests that catch regressions over tests that verify happy paths
-- Write comprehensive tests, not just coverage padding
+The matrix, the edge cases with the reason each is interesting, the TDD sequence, and the commands that run it all. Where behaviour is user-visible, say which runner proves it end to end.

package/plugins/lisa-cursor/skills/lisa-bug-triage/SKILL.md

@@ -10,8 +10,8 @@ Follow this 8-step triage process before implementing any bug fix. Do not skip t
 ## Triage Steps
 
 1. Verify you have all information needed to reproduce the bug (authentication requirements, environment information, etc.). Do not make assumptions. If anything is missing, stop and ask before proceeding.
-2. Reproduce the bug. If you cannot reproduce it, stop and report what you tried and what you observed.
-3. Once reproduced, verify you are 100% positive on how to fix it. If not, determine what you need to do to be 100% positive (e.g. add logging, trace the code path, inspect state) and do that first.
+2. Reproduce the bug on the path the user actually hits. Prerequisites the real path needs — seeded data, auth state, flags — are part of the reproduction; scaffolding that substitutes real behaviour is not, and a failure that survives only with it in place is a lead rather than a reproduction. Say which you have. Without a real-path reproduction you may not claim a root cause at all. If you cannot reproduce it, stop and report what you tried and what you observed.
+3. Once reproduced, name a candidate cause and the observation that would disprove it, and go get that observation. Surviving the disproof is not proof — it leaves the candidate standing, not confirmed — so before implementing, execute something whose output the candidate predicts and a different cause would not produce. If you cannot get that confirmation, record the verdict as inconclusive and say so rather than proceeding as if certain; add logging, trace the path, or bisect until you can.
 4. Verify you have access to the tools, environments, and permissions needed to deploy and verify this fix (e.g. CI/CD pipelines, deployment targets, logging/monitoring systems, API access, database access). If any are missing or inaccessible, stop and raise them before starting implementation.
 5. Define the tests you will write to confirm the fix and prevent a regression.
 6. Define the documentation you will create or update to explain this bug so another developer understands the "how" and "what" behind it.

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

@@ -1,96 +1,67 @@
 ---
 name: lisa-reproduce-bug
-description: "How to create reliable bug reproduction scenarios. Covers failing tests, minimal scripts, environment verification, and reproduction evidence capture."
+description: "How to reproduce a bug reliably and on the real path — choosing a reproduction method from the symptom, distinguishing prerequisites from behaviour-substituting scaffolding, and reporting the observed failure rate instead of rounding it."
 ---
 
 # Reproduce Bug
 
-Before investigating root cause, reproduce the issue empirically. A bug that cannot be reproduced cannot be verified as fixed.
+A bug that cannot be reproduced cannot be verified as fixed. Root cause analysis does not begin until a reliable reproduction exists.
 
-## Reproduction Process
+## The reproduction must exercise the real path
 
-### 1. Run the Failing Scenario
+Left alone, an agent asked to demonstrate a defect will build the environment in which the defect appears — a stub, a fake, a fresh harness — and present that as the reproduction. It looks like proof and it is not: a fix that satisfies it may never touch the path the user is on.
 
-- 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
+Two kinds of setup get confused here, and only one is a problem:
 
-### 2. Capture Evidence
+- **Prerequisites** — state the real path genuinely needs: a seeded record, a logged-in user, a feature flag, a fixture recreating production-equivalent data. These are part of the reproduction. Removing them changes the precondition rather than testing anything, so do not remove them.
+- **Replacement scaffolding** — anything standing in for behaviour the real path would perform: a mocked service, a stubbed function, a fake clock, a bespoke harness that bypasses the normal entry point. This is what makes a reproduction suspect.
 
-- 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
+So the reproduction states, explicitly:
 
-### 3. Investigate Environment Differences (If Cannot Reproduce)
+- **The entry point the user actually hits** — the route, endpoint, command, or interaction.
+- **Prerequisites**, listed as setup.
+- **Replacement scaffolding**, each item with the real behaviour it substitutes.
+- **Whether the failure survives with prerequisites in place and replacement scaffolding removed.** If it does not, this is a lead rather than a reproduction. Say so and keep going.
 
-If the issue does not reproduce locally:
+If the real path is unreachable — no credentials, no environment, no data — that is a blocked reproduction. Report the missing access instead of substituting scaffolding and calling the bug reproduced.
 
-- 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)
+## Choose the method from the symptom
 
-### 4. Create a Minimal Reproduction
+| Symptom | Reach for |
+| --- | --- |
+| Wrong value, bad output, thrown error | Failing test at the narrowest layer that still crosses the real path |
+| Broken interface or journey | Browser or device driver against a running build (Playwright, Maestro) |
+| Service or API behaviour | Direct request to the running service — client script or `curl` |
+| Depends on particular data | Seeded fixture recreating that state, recorded as a prerequisite |
+| Intermittent or timing-shaped | Loop the trigger; capture timestamps around async boundaries |
+| Works locally, fails deployed | Do not chase it locally — reproduce against the environment that fails |
 
-Create the smallest possible reproduction that triggers the bug:
+**A failing test is the preferred form** wherever it can cross the real path: it runs in CI, it becomes the regression guard, and `codify-verification` expects it. A script is the fallback. Manual steps are the last resort and must carry their prerequisites.
 
-**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
+## Report the failure rate, do not round it
 
-**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
+Run the reproduction enough times to state a rate. A reproduction that fails half the time cannot prove a fix — one passing run afterwards means nothing at that rate. If the rate is too low to distinguish a fix from luck, say what would raise it: more iterations, a forced schedule, a narrowed trigger, a seeded clock.
 
-**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)
+## When it will not reproduce
 
-### 5. Verify Reproduction Is Reliable
+The difference is nearly always one of: runtime version, configuration or feature flags, data state, credentials and permissions, network posture, or platform. Diff the two environments along those axes rather than guessing between them, and report which axes you compared and what you found. That comparison is the finding when the bug stays hidden.
 
-- 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
+## Output
 
 ```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)]
+**Entry point:** the route, command, or action the user hits
+**Command or steps:** exactly what to run
+**Actual:** what happens · **Expected:** what should happen
+**Prerequisites:** seeded data, auth state, flags the real path needs — or "none"
+**Replacement scaffolding:** each mock, stub, fake, or bespoke harness and the
+  real behaviour it substitutes — or "none"
+**Survives without replacement scaffolding:** yes / no — if no, this is a lead,
+  not a reproduction
+**Observed failure rate:** n failures in m runs
+**Form:** failing test `path` | script `path` | manual steps above
+**Environment:** runtime, platform, relevant dependency versions
 ```
 
-## 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.
+Capture output whole — a truncated stack trace loses the line that mattered. But evidence carries whatever the system was holding, so **redact secrets, tokens, credentials, and personal data before a reproduction is handed on or attached to a work item**, and keep any unredacted capture only where the data class it contains is already permitted to live.

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

@@ -1,155 +1,135 @@
 ---
 name: lisa-root-cause-analysis
-description: "Root cause analysis methodology. Evidence gathering from logs, execution path tracing, strategic log placement, and building irrefutable proof chains."
+description: "Prove what causes a defect: hypotheses written down before evidence is gathered, positive confirmation by execution rather than by surviving a disproof, a symptom-keyed technique menu including git bisect, and a declared stopping point that escalates an unresolved verdict instead of drifting."
 ---
 
 # 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.
+Produce a proof, not an explanation. Every link in the chain rests on something observed — a log line, a stack frame, an exit code, a bisect verdict.
 
-**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.
+## Confirm by executing, not by reasoning
 
-## Phase 1: Gather Evidence from Logs
+The characteristic failure of this work is a fluent wrong answer: a plausible story assembled from reading code and delivered with confidence. Reading is how a hypothesis is formed. Running something is how it is confirmed. **Do not report a cause you have not executed against.**
 
-### Local Logs
+## Surviving a disproof is not proof
 
-- 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)
+A candidate that no observation has killed is **still standing**, not confirmed. Elimination narrows the field; it does not establish a cause. Closing requires a **positive confirmation**: an execution whose output is what the cause predicts and would not be what it produces if the cause were something else.
 
-### Remote Logs (AWS CloudWatch, etc.)
+That leaves three honest verdicts, and the output has to be able to say each:
 
-- 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
+- **confirmed** — a positive confirmation was executed and is recorded.
+- **inconclusive** — one candidate is standing, nothing killed it, nothing confirmed it. Say so; do not promote it.
+- **unresolved / blocked** — the investigation stopped before reaching a cause. See the stopping rule.
 
-  # 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
+Only *confirmed* justifies a fix. An inconclusive verdict can still be useful — it narrows the next attempt — but it must be labelled.
 
-  # Follow live logs
-  aws logs tail "/aws/lambda/function-name" --follow --since 10m
-  ```
+## Write the hypotheses down first
 
-## Phase 2: Trace the Execution Path
+Before gathering evidence, list the candidate causes — two or three is normal — and beside each, the observation that would **kill** it. Then go looking for the killing observations rather than for support.
 
-- 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
+A candidate you cannot state a disproof for is not a hypothesis; it is a hunch, and it will survive any amount of evidence. Keep the list updated as you work, and ship the eliminated candidates in the output: they are how a reader knows you looked.
 
-## Phase 3: Strategic Log Placement
+## Pick the technique from the symptom
 
-When existing logs are insufficient, add targeted log statements to prove or disprove hypotheses.
+| What you know | Reach for |
+| --- | --- |
+| **It used to work**, and a good commit can be named | `git bisect` — preconditions below |
+| A stack trace or error location | Work backward from the throw; read the frames that carry the value, skip the plumbing |
+| Only that the result is wrong, no location | Instrument first. Reading code to localize an unlocalized defect is the slowest move available |
+| Intermittent | Loop it. Log timestamps and identity either side of async boundaries; look for overlap, staleness, out-of-order completion |
+| Works locally, fails deployed | Diff the environments — version, config, data, permissions, network — before touching code |
+| Wrong shape, missing field, unexpected null | Log the actual value at each transformation, not the type you expect |
+| Possibly a dependency | Pin the exact installed version; read its changelog and issues before blaming local code |
 
-### Log Statement Guidelines
+### git bisect
 
-- **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
+The highest-leverage move available for a regression, and consistently underused: it answers *which change* in log₂(n) steps instead of log₂(n) hours of reading. It needs three things and wastes time without them.
 
-```typescript
-// Bad: Vague, unhelpful
-console.log("here");
-console.log("data:", data);
+1. **A known-good commit** — from the last release, the last green run, or the reporter's "it worked on…".
+2. **A deterministic, non-interactive check** that exits non-zero on the defect. The failing test from `reproduce-bug` usually is one.
+3. **A runnable checkout at every step.** Where a fresh checkout needs a dependency install or build before tests run, fold that into the bisect command. Otherwise every step fails for the wrong reason and the verdict is noise.
 
-// 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(),
-});
+```bash
+git bisect start <bad> <good>
+git bisect run <cmd>   # <cmd> must install/build if the checkout needs it
 ```
 
-### Placement Strategy
+Read the blamed commit before believing it. Bisect names the change that *surfaced* the defect, which is not always the change that introduced it.
 
-| 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 |
+## Find the logs the project already has
 
-### Hypothesis Elimination
+Look for existing tooling before reaching for a raw CLI: `package.json` scripts, `scripts/*log*`, `scripts/*tail*`, AWS CLI wrappers, log-group names in `.env`. Project tooling already encodes the credentials, regions, and group names you would otherwise guess at.
 
-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.
+Where no wrapper exists:
 
-## Phase 4: Prove the Root Cause
+```bash
+aws logs describe-log-groups --query 'logGroups[].logGroupName' --output text
+aws logs tail "/aws/lambda/<name>" --follow --since 30m
+```
 
-Build an evidence chain that is irrefutable:
+If remote logs are unreachable, name the log group and the time window needed rather than proceeding without them.
 
-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
+## Instrument surgically
 
-### Evidence Chain Format
+Add the fewest statements that decide between live hypotheses, and make each carry values rather than announce arrival. Guard the access — instrumentation that throws while reading its own subject tells you nothing about the defect.
 
-```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]
-```
+```typescript
+// Useless: proves a line ran.
+console.log("here", data);
 
-## Phase 5: Clean Up
+// Useful: decides a hypothesis, and survives the shape it is investigating.
+console.log("[DEBUG:issue-123] processOrder entry", {
+  orderId: order?.id,
+  status: order?.status,
+  itemCount: order?.items?.length ?? null,
+});
+```
 
-After root cause is confirmed, **remove all debug log statements** added during investigation. Leave only:
+Highest-yield placements: function entry (called at all, with what), either side of a branch (which way, on what value), either side of an `await` (timing, staleness), around transformations (where the shape changes), and inside `catch` blocks (what is being swallowed).
 
-- Log statements that belong in the application permanently (error logging, audit trails)
-- Statements explicitly requested by the user
+The `[DEBUG:<issue>]` prefix exists so cleanup is mechanical rather than remembered. Once the verdict is recorded, remove every one — keeping only logging that belongs in the product permanently — and verify across every source root the project has, not just one:
 
-Verify cleanup:
 ```bash
-# Search for any remaining debug markers
-grep -rn "\[DEBUG:" src/ --include="*.ts" --include="*.tsx" --include="*.js"
+git grep -n "\[DEBUG:"
 ```
 
-## Output Format
+## Stop before you drift
+
+Declare a budget before starting: a number of instrumentation rounds, or a wall-clock box. Two signatures mean stop now rather than push on.
+
+- **Two consecutive hypotheses falsified with no new information gained.** Widening the search against the same evidence is not progress.
+- **The budget is spent.**
+
+Stopping is a legitimate outcome and not a silent one. Record the verdict as **unresolved / blocked** and escalate a decision-ready report: the symptom, the hypotheses tried and how each was killed, the evidence collected, and the single thing that would unblock the work — an access grant, a log group, a reproduction on the real path. A blocked investigation reported clearly is worth more than a confident guess, and costs the next agent far less.
+
+## Output
+
+`Cause` and `Fix` are required only for a **confirmed** verdict. For *inconclusive* or *unresolved*, record what is known and name the unblocker instead — an unresolved investigation must be representable without inventing a cause to fill the field.
 
 ```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 |
+**Verdict:** confirmed | inconclusive | unresolved
 
-### 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.
+### Hypotheses
+| Candidate | Would be killed by | Status |
+|---|---|---|
+| ... | the observation that would disprove it | eliminated / standing / confirmed |
 
-### Recommended Fix
-What needs to change and why. Include file:line references.
-```
+### Evidence trail
+| Step | Location | Observed | Proves |
+|---|---|---|---|
+| 1 | file:line | log output, value, exit code | what this establishes |
 
-## Rules
+### Cause — confirmed verdicts only
+**Proximate:** file:line — the line that directly produces the symptom.
+**Root:** file:line — why that line behaves that way.
+**Confirmation:** the command run and its output, and why that output would differ
+  if the cause were something else. Not an argument.
 
-- 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
+### Fix — confirmed verdicts only
+What changes and why, with file:line references. Anything that must not change.
+
+### Unblocker — inconclusive or unresolved verdicts
+The single thing that would let the next attempt proceed, and who can grant it.
+```

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"