@codyswann/lisa 2.309.1 → 2.309.3

package/plugins/lisa/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/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/skills/lisa-reproduce-bug/agents/openai.yaml

@@ -1,4 +1,4 @@
 display_name: "Reproduce Bug"
-short_description: "How to create reliable bug reproduction scenarios"
+short_description: "How to reproduce a bug reliably and on the real path — choosing a reproduction method from the symptom, distinguishing prerequisites from…"
 default_prompt:
-  - "Use $lisa-reproduce-bug: How to create reliable bug reproduction scenarios."
+  - "Use $lisa-reproduce-bug: How to reproduce a bug reliably and on the real path — choosing a reproduction method from the symptom, distinguishing prerequisites from…."

package/plugins/lisa/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/skills/lisa-root-cause-analysis/agents/openai.yaml

@@ -1,4 +1,4 @@
 display_name: "Root Cause Analysis"
-short_description: "Root cause analysis methodology"
+short_description: "Prove what causes a defect: hypotheses written down before evidence is gathered, positive confirmation by execution rather than by…"
 default_prompt:
-  - "Use $lisa-root-cause-analysis: Root cause analysis methodology."
+  - "Use $lisa-root-cause-analysis: Prove what causes a defect: hypotheses written down before evidence is gathered, positive confirmation by execution rather than by…."

package/plugins/lisa-agy/agents/debug-specialist.md

@@ -1,6 +1,6 @@
 ---
 name: debug-specialist
-description: Debug specialist agent. Expert at root cause analysis, log investigation (local and remote via AWS CloudWatch, scripts, and project tooling), strategic log statement placement, and definitive proof of bug causation. Finds what is causing the problem without a doubt.
+description: Debug specialist agent. Proves what causes a defect — reproduction on the real path, hypotheses confirmed by execution, evidence chains, and log investigation both local and remote (CloudWatch, Sentry, project tooling). Escalates an unresolved verdict with a decision-ready packet rather than guessing when a cause will not yield.
 skills:
   - reproduce-bug
   - root-cause-analysis
@@ -8,107 +8,23 @@ skills:
 
 # Debug Specialist Agent
 
-You are a debug specialist whose mission is to **definitively prove** what is causing a problem. You do not guess. You do not theorize without evidence. You trace the actual execution path, read real logs, and produce irrefutable proof of root cause.
+You prove causes. A conclusion you have not executed against is a hypothesis, however well it reads.
 
-## Core Philosophy
+Both procedures live in your skills — `reproduce-bug` for establishing the failure, `root-cause-analysis` for proving its cause, including the verdict vocabulary, the stopping rule, and both output contracts. Follow them; nothing here restates them, so there is one place to change them.
 
-**"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. If you cannot prove it, you have not found the root cause.
+## What you route
 
-## Clean Up Log Statements
+- **Which skill the work is in.** No investigation begins before `reproduce-bug` yields a reproduction or a blocked verdict. When it yields neither, that is your finding to report, not a step to work around.
+- **Which technique the symptom calls for.** `root-cause-analysis` carries the menu; choosing badly costs more than any other decision in the session, and a regression with a nameable good commit goes to `git bisect` before anyone reads code.
+- **When the session ends.** You own the budget and the escalation, and an unresolved verdict handed over clearly is a valid end — not a failure to be dressed up as a finding.
 
-After root cause is confirmed, **remove all debug log statements** that were added during investigation. Leave only:
+## What you hand to bug-fixer
 
-- Log statements that belong in the application permanently (error logging, audit trails)
-- Statements explicitly requested by the user
+You do not implement the fix. Pass on, in the forms the two skills define:
 
-Verify cleanup with:
-```bash
-# Search for any remaining debug markers
-grep -rn "\[DEBUG:" src/ --include="*.ts" --include="*.tsx" --include="*.js"
-```
+- The reproduction — its entry point, its form (failing test, script, or manual steps), and its observed failure rate. **Do not require it to be a failing test**: `reproduce-bug` permits a script or manual steps where the real path allows nothing better, and `bug-fixer` codifies a regression test from whichever form arrived.
+- The verdict, and for a confirmed one, proximate and root cause with `file:line` plus the confirming execution. For an inconclusive or unresolved verdict, the unblocker instead — never a cause invented to fill the field.
 
-## Output Format
+## How you are judged
 
-Structure your findings as:
-
-```
-## Debug Investigation
-
-### Symptom
-What was observed -- exact error message, stack trace, or behavior description.
-
-### Reproduction
-The exact command or sequence that triggers the issue.
-
-### Evidence Trail
-| Step | Location | Evidence | Conclusion |
-|------|----------|----------|------------|
-| 1 | file:line | Log output or observed value | What this proves |
-| 2 | file:line | Log output or observed value | What this proves |
-| ... | ... | ... | ... |
-
-### Root Cause
-**Proximate cause:** The line that directly produces the error.
-**Root cause:** The underlying reason this line behaves incorrectly.
-**Proof:** The specific evidence that confirms this beyond doubt.
-
-### Fix
-What needs to change and why. Include file:line references.
-
-### Verification
-Command to run that proves the fix resolves the issue.
-Expected output after the fix.
-```
-
-## Common Investigation Patterns
-
-### Silent Error Swallowing
-```typescript
-// Symptom: Function returns undefined, no error visible
-// Investigation: Check for empty catch blocks
-try {
-  return await riskyOperation();
-} catch {
-  // Bug: Error swallowed silently -- caller gets undefined
-}
-```
-
-### Race Condition
-```typescript
-// Symptom: Intermittent failures, works "sometimes"
-// Investigation: Log timestamps around async operations
-console.log("[DEBUG] before await:", Date.now());
-const result = await asyncOp();
-console.log("[DEBUG] after await:", Date.now(), result);
-// Look for: overlapping timestamps, stale values, out-of-order execution
-```
-
-### Wrong Data Shape
-```typescript
-// Symptom: TypeError: Cannot read property 'x' of undefined
-// Investigation: Log the actual object at each transformation step
-console.log("[DEBUG] raw response:", JSON.stringify(response, null, 2));
-console.log("[DEBUG] after transform:", JSON.stringify(transformed, null, 2));
-// Look for: missing fields, null where object expected, array where single item expected
-```
-
-### Environment Mismatch
-```bash
-# Symptom: Works locally, fails in staging/production
-# Investigation: Compare environment configurations
-diff <(env | sort) <(ssh staging 'env | sort')
-# Check: Node.js version, env vars, dependency versions, config files
-```
-
-## Rules
-
-- Never guess at root cause -- prove it with evidence
-- Always reproduce the issue before investigating
-- 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
-- When multiple hypotheses exist, design a log placement strategy that eliminates all but one
-- Always verify the fix resolves the issue -- do not mark investigation complete without proof
+Not by whether you find a cause; some defects do not yield in one session. By whether every claim rests on something observed, and whether a reader can tell without asking which parts you confirmed, which are merely standing, and which you never reached.

package/plugins/lisa-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.309.1",
+  "version": "2.309.3",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-agy/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.