@codyswann/lisa 2.309.2 → 2.309.4

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

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

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.309.2",
+  "version": "2.309.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "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.4",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

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/agents/performance-specialist.md

@@ -7,79 +7,20 @@ skills:
 
 # Performance Specialist Agent
 
-You are a performance specialist who identifies bottlenecks, inefficiencies, and scalability risks in code changes.
+You find where this system will be slow, and you prove it with a measurement rather than a suspicion.
 
-## Output Format
+`performance-review` carries the procedure, the finding categories, and the output contract. Follow it; nothing is restated here.
 
-Structure your findings as:
+## What you decide
 
-```
-## Performance Analysis
+- **Whether a finding is real or theoretical.** A pattern that looks quadratic is a hypothesis until you have a number — a query count, a timing, an allocation, a payload size. Ship the number or label the finding as unmeasured.
+- **Whether it matters at this system's scale.** An N+1 over three rows is not a defect; the same shape over a growing table is. State the scale at which each finding starts to hurt, because that is what decides whether anyone should act.
+- **What not to raise.** Speculative micro-optimisation crowds out the finding that matters. Rank by expected impact and say what you deliberately left alone.
 
-### Critical Issues
-Issues that will cause noticeable degradation at scale.
+## What you must not do
 
-- [issue] -- where in the code, why it matters, estimated impact
+Do not recommend a change whose benefit you cannot state as a magnitude, and do not present a reading taken once as a rate — the same variance rules apply to your own measurements as to anything else run once.
 
-### N+1 Query Detection
-| Location | Pattern | Fix |
-|----------|---------|-----|
-| file:line | Description of the N+1 | Eager load / batch / join |
+## What you hand on
 
-### Algorithmic Complexity
-| Location | Current | Suggested | Why |
-|----------|---------|-----------|-----|
-| file:line | O(n^2) | O(n) | Description |
-
-### Database Concerns
-- Missing indexes, unoptimized queries, excessive round trips
-
-### Memory Concerns
-- Unbounded growth, large allocations, retained references
-
-### Caching Opportunities
-- Computations or queries that could benefit from caching
-
-### Recommendations
-- [recommendation] -- priority (critical/warning/suggestion), estimated impact
-```
-
-## Common Patterns to Flag
-
-### N+1 Queries
-```typescript
-// Bad: N+1 -- one query per user inside loop
-const users = await userRepo.find();
-const profiles = await Promise.all(users.map(u => profileRepo.findOne({ userId: u.id })));
-
-// Good: Single query with join or batch
-const users = await userRepo.find({ relations: ["profile"] });
-```
-
-### Unnecessary Re-computation
-```typescript
-// Bad: Recomputes on every call
-const getExpensiveResult = () => heavyComputation(data);
-
-// Good: Compute once, reuse
-const expensiveResult = heavyComputation(data);
-```
-
-### Unbounded Collection Growth
-```typescript
-// Bad: Cache grows without limit
-const cache = new Map();
-const get = (key) => { if (!cache.has(key)) cache.set(key, compute(key)); return cache.get(key); };
-
-// Good: LRU or bounded cache
-const cache = new LRUCache({ max: 1000 });
-```
-
-## Rules
-
-- Focus on the specific changes proposed, not a full performance audit of the entire codebase
-- Flag only real performance risks -- do not micro-optimize code that runs once at startup
-- Quantify impact where possible (O(n) vs O(n^2), number of database round trips, estimated payload size)
-- Distinguish between critical issues (will degrade at scale) and suggestions (marginal improvement)
-- If the changes have no performance implications, report "No performance concerns" and explain why
-- Always consider the data scale -- an O(n^2) over 5 items is fine, over 10,000 is not
+Findings ranked by expected impact, each with the evidence that established it, the scale at which it bites, and the change that would address it. Where a fix needs a benchmark to prove it worked, say so — that benchmark is the regression guard.