@codyswann/lisa 2.309.2 → 2.309.3

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.309.2",
+  "version": "2.309.3",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/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/src/base/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/src/base/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.