@codyswann/lisa 2.309.2 → 2.309.4

package/dist/core/upstream-evidence-manifest.js

@@ -187,11 +187,11 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "phaser/merge/.claude/settings.json": "296b8d5e3c197cd4526a99454aee1dc7f5ce9a25a729a957f392b71be3e8cfb6",
     "phaser/merge/.oxlintrc.json": "4ac4bca00bef4b32810f3759a914ab2b8148e6fad3e329417a497e36df9e810c",
     "phaser/package-lisa/package.lisa.json": "2e01b1ec402f6804a54402e22d02d63f1aa96d3f698e171885b0fff6eb25b271",
-    "plugins/src/base/agents/architecture-specialist.md": "5bbe86bd3a7661021f7c8e9c5396fa4c0f3b8a77606e7be868fb9a0e117d424d",
+    "plugins/src/base/agents/architecture-specialist.md": "076feb3a09ef056628bc33242f93278ce6b00f55878984a18a9337d326b5e1d4",
     "plugins/src/base/agents/bug-fixer.md": "e01e5d3678e464385105c9abf90e4b70ae262fd856f1e86b2ebe443dae9e17b1",
     "plugins/src/base/agents/builder.md": "75900b28a384539bba8c54f3c7b2a6ed83786e502093822ed308d324f0461c01",
     "plugins/src/base/agents/confluence-prd-intake.md": "735df81802464abe79fa0f3878ad66dc13a8bf8a8420da28f31392c6e1e3693c",
-    "plugins/src/base/agents/debug-specialist.md": "8d8e3e15bb3cadcf39a9c6becb30d24e0d4ab5926abb123d9c144b824ee8c4aa",
+    "plugins/src/base/agents/debug-specialist.md": "88266c25e03a3dbc110b6da8b6a5f7e47a5c3ba7d3b74b9c5a6fe613768df362",
     "plugins/src/base/agents/git-history-analyzer.md": "8c2b6ae31cec858647675b24425b8148d3f33f3145f5d423336c87bdd9266f78",
     "plugins/src/base/agents/github-agent.md": "05454419d3ea18dbbf45e45e0ca5782a6925c97816c6705eead9fcf597d776bc",
     "plugins/src/base/agents/github-build-intake.md": "5d948d04d39f864bae354c18f56735282e3f37127356e4942f57a10e99c09456",
@@ -205,14 +205,14 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/agents/linear-build-intake.md": "280c0ba1ba359572f28759bd40870a08052b6495342971ae152614c8147ad036",
     "plugins/src/base/agents/linear-prd-intake.md": "28c4ee9f2ebbb4f089dd54bb4633063b48ea8099327a0bf2923825d83c3fe07c",
     "plugins/src/base/agents/notion-prd-intake.md": "53df0fba395b10b17bafe1a82c8c2706e4ec029d2aee8f3a2e7d5afe38d9be98",
-    "plugins/src/base/agents/performance-specialist.md": "2d6c650e16fdb33ba45ba754dde9f62404ea805b5f5157a885f7b31b8a03b267",
+    "plugins/src/base/agents/performance-specialist.md": "39c088eaf9347410988a82310e3a151034cbac28a756b1c7b28bb4c1c32a6a5d",
     "plugins/src/base/agents/pr-mining-specialist.md": "2bf5b933b43ddfbcc9c67f9b98bd68bc6c99ab0c47dca96dcd9e340960df8e55",
-    "plugins/src/base/agents/product-specialist.md": "9c342b1a1c5f8c0eb874db24547fe26d259a97a74e1df5cbc26ffb635025a2e6",
-    "plugins/src/base/agents/quality-specialist.md": "2a1b433fa1be1c8b23c2c83e5f247b851c61e3c253a79caf8a3eb7f326744a22",
-    "plugins/src/base/agents/security-specialist.md": "2d592b4c2666082ef84cae8878be99b9ebd07f75ab77656409beff306f17a6b4",
+    "plugins/src/base/agents/product-specialist.md": "c04cb5abdb077040bfc1a22c142841712473500bd6537853e40c94de25abf94c",
+    "plugins/src/base/agents/quality-specialist.md": "e923aec97457390c6c9c529137a81563a6f452a7d6791ab56b97e40b6e85f039",
+    "plugins/src/base/agents/security-specialist.md": "0952dee7bf1c04f978b0f8125a91425bf639e9b645de1a4b05ad945b9041bea7",
     "plugins/src/base/agents/skill-evaluator.md": "83af6324ed0ee0cd5c4132429e137649c3fd616ef6fa5d4bd95579438d401894",
     "plugins/src/base/agents/spec-conformance-specialist.md": "f589e4d543a617d3c421aa28d6583e1b25e0b18fc83412e6d544a389bdac225c",
-    "plugins/src/base/agents/test-specialist.md": "0e6f7137b8338f76d0302cb7a930f50821b4d66dd197977012f32ab5a0c38061",
+    "plugins/src/base/agents/test-specialist.md": "8f439c725863df84532504a57f64b9e4918acaa242de8c01cb6692553495dbd2",
     "plugins/src/base/agents/tracker-mining-specialist.md": "fef49c3ca8622c83a54d34b3f960471e0f2ad50e6889f691585b0f208180f6bd",
     "plugins/src/base/agents/verification-specialist.md": "32d8a660ba486279fdbb6d0c6665bee36a9703e0cb05e1ab0629b82bc26ebd04",
     "plugins/src/base/commands/agent-ready.md": "b1bc19c90330b9885b44f733e83cc6b44afa9b5e9fd2e9aba99995480e0829e1",
@@ -398,7 +398,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-atlassian-access/scripts/markdown-to-adf.mjs": "538e5a3d91482b9e2a055e133b7c1fcf809be51d4ae72a10776aaeeb8df4832a",
     "plugins/src/base/skills/lisa-attribute-failure/SKILL.md": "5d737b9fda916f02aaf13b208316cd54995d83aa06d27ba5daa19b6ebed6b4d9",
     "plugins/src/base/skills/lisa-automation-status/SKILL.md": "a283afab506d8e52970c6df566b4504a2ed015493cee4de6debe5b62a09782eb",
-    "plugins/src/base/skills/lisa-bug-triage/SKILL.md": "90b0f1388717f81c4e187ab714be01d02a9f41592a4c26487aeb9c26a0959493",
+    "plugins/src/base/skills/lisa-bug-triage/SKILL.md": "bd5bae508a8f344d8b5cb46cfddcb178ff8368ca77936f9e2c63058e05f61af4",
     "plugins/src/base/skills/lisa-codebase-research/SKILL.md": "77dbc2d7e86e5027df486294de315bb539a2ece84bd4b38e47ccc108f8c2875e",
     "plugins/src/base/skills/lisa-codify-verification/SKILL.md": "45cf7e74697fcc0b8769b31c674dbf0b18e19eb1ceab6a77f608b568512def15",
     "plugins/src/base/skills/lisa-confluence-prd-intake/SKILL.md": "a6a099abeb32940d44da7e9a6a62c3519f64efa85294c4b996789fa4fba97461",
@@ -514,12 +514,12 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-quality-review/SKILL.md": "17ba45f4c4b7877c0b0c9a3c1cc1cb9e18c642ead74ff7263698d8034d3241da",
     "plugins/src/base/skills/lisa-queue-status/SKILL.md": "87c6d34d0511d4afd812d1af3fee80fa3b7aa47db8449760b12f2699fedc1d78",
     "plugins/src/base/skills/lisa-repair-intake/SKILL.md": "4f85ac1381631e9f250d9cf3239baba633ae0df9ba1959f8835ed662592e2d77",
-    "plugins/src/base/skills/lisa-reproduce-bug/SKILL.md": "6304c848c64a00be230337d9e40770c3a09aa59c6241733e32060d0cce9a4f9b",
+    "plugins/src/base/skills/lisa-reproduce-bug/SKILL.md": "4d460993fac6021219ca23eee29b1b9afa7c37479dddc662b2fcfaca510edd68",
     "plugins/src/base/skills/lisa-research/SKILL.md": "19de7c5910b117c4b3b1bb7ae42cf9c8b6ff2a376b2e21961526bc7ebde18e85",
     "plugins/src/base/skills/lisa-review-implementation/SKILL.md": "42134253cca50e384f36eaa085c0a1e6b8772e9f3e912a8d1231f1cd69199858",
     "plugins/src/base/skills/lisa-review-local/SKILL.md": "66defe83565ab3633a13e69ce394de64f17f2c2bddbf046bc12c8bbd0ca57f5c",
     "plugins/src/base/skills/lisa-rework-triage/SKILL.md": "3389740fc0f162be0b684625424e716a0a3e4c99c8cdb4317ec82dcfcf7b57c7",
-    "plugins/src/base/skills/lisa-root-cause-analysis/SKILL.md": "2b1cb5bac2be7e8bb6b852efb0bd499cbcdca6299c342a54e0c8d872821c7364",
+    "plugins/src/base/skills/lisa-root-cause-analysis/SKILL.md": "3fa14217ca36b238ebb8203d18f10eaaf98a3647f949cdada6cb9f56ddf9ed50",
     "plugins/src/base/skills/lisa-security-review/SKILL.md": "5a980eaf5efc4fcce66e75521ec5b1eda143a5b0d36e7157234a705dac94e3f5",
     "plugins/src/base/skills/lisa-security-zap-scan/SKILL.md": "a5189442dbf970cc49fd089ab03c386c8a205b856e09501f6ad1966321e7e4b5",
     "plugins/src/base/skills/lisa-sentry-access/SKILL.md": "ecaf49b42bbf399781a3ebd0b1595e5a8ac44422537832e0442b2f184da0c83c",

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.8"
   },
   "name": "@codyswann/lisa",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

package/plugins/lisa/.codex-plugin/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/.codex-plugin/skills/lisa-reproduce-bug/SKILL.md

@@ -1,96 +1,67 @@
 ---
 name: lisa-reproduce-bug
-description: "How to create reliable bug…"
+description: "How to reproduce a bug reliably…"
 ---
 
 # 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/.codex-plugin/skills/lisa-reproduce-bug/agents/openai.yaml

@@ -1,4 +1,4 @@
 display_name: "Reproduce Bug"
-short_description: "How to create reliable bug…"
+short_description: "How to reproduce a bug reliably…"
 default_prompt:
-  - "Use $lisa-reproduce-bug: How to create reliable bug…."
+  - "Use $lisa-reproduce-bug: How to reproduce a bug reliably…."

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

@@ -1,155 +1,135 @@
 ---
 name: lisa-root-cause-analysis
-description: "Root cause analysis methodology"
+description: "Prove what causes a defect…"
 ---
 
 # 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/.codex-plugin/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…"
 default_prompt:
-  - "Use $lisa-root-cause-analysis: Root cause analysis methodology."
+  - "Use $lisa-root-cause-analysis: Prove what causes a defect…."

package/plugins/lisa/agents/architecture-specialist.md

@@ -9,39 +9,20 @@ skills:
 
 # Architecture Specialist Agent
 
-You are a technical architecture specialist who designs implementation approaches and evaluates structural impact of code changes.
+You work out how this change should be built before anyone writes it, and you say what it will disturb.
 
-## Output Format
+`codebase-research` carries the investigation method, `task-decomposition` the breakdown, `epic-triage` the larger-than-one-change case, and each carries its own output contract. Follow them; nothing is restated here.
 
-Structure your findings as:
+## What you decide
 
-```
-## Architecture Analysis
+- **What already exists.** The most valuable thing you produce is often "this is already solved in `<file>`" — reuse beats design, and nobody else in the flow is looking for it.
+- **What this change touches that nobody mentioned.** Callers, migrations, cached shapes, public interfaces, downstream consumers. Ripple effects are your specific responsibility because they are invisible from inside the ticket.
+- **Whether the work is one change or several**, and if several, the order in which they can land while keeping the system working at every step.
 
-### Files to Create
-- `path/to/file.ts` -- purpose
+## What you must not do
 
-### Files to Modify
-- `path/to/file.ts:L42-L68` -- what changes and why
+Do not design past the requirement. An abstraction added for a need nobody has stated is a cost with no benefit, and it will be maintained by someone who does not know why it exists. Do not assert behaviour from a file or function name — open it.
 
-### Dependency Graph
-- [file A] → [file B] → [file C] (modification order)
+## What you hand on
 
-### Design Decisions
-| Decision | Choice | Rationale |
-|----------|--------|-----------|
-
-### Reusable Code
-- `path/to/util.ts:functionName` -- how it applies
-
-### Risks
-- [risk description] -- [mitigation]
-```
-
-## Rules
-
-- Always read files before recommending changes to them
-- Follow existing patterns in the codebase -- do not introduce new architectural patterns unless explicitly required
-- Include file:line references for all recommendations
-- Flag breaking changes explicitly
-- Keep the modification surface area as small as possible
+Files to create and modify, the dependency order, the design decisions with their reasoning and the alternatives rejected, reusable code found, and the risks worth watching during implementation.