devflow-kit 3.11.0 → 3.12.1

package/src/assets/skills/go/SKILL.md

@@ -12,7 +12,7 @@ activation:
 
 # Go Patterns
 
-Reference for Go-specific patterns, idioms, and best practices. Full bibliography: `references/sources.md`.
+Full bibliography: `references/sources.md`.
 
 ## Iron Law
 
@@ -22,126 +22,37 @@ Reference for Go-specific patterns, idioms, and best practices. Full bibliograph
 > return must be checked, wrapped with context, or explicitly documented as intentionally
 > ignored with `_ = fn()`. "Errors are values. Values can be programmed." — Rob Pike [5]
 
-## When This Skill Activates
+## Error Handling
 
-Working with Go codebases — error handling, interfaces, goroutines, channels, packages.
+- Wrap with context, `return fmt.Errorf("finding user %s: %w", id, err)`, not a bare `return err`: the caller loses context.
+- Declare sentinel errors (`var ErrNotFound = errors.New("not found")`) and match them with `errors.Is`.
+- Never discard an error with `val, _ := fn()`: check it, wrap it, or ignore it on purpose with `_ = fn()`.
+- No `panic` or `log.Fatal` in library code.
 
----
-
-## Error Handling [5][6]
-
-```go
-// BAD: return err  — caller loses context
-// GOOD: return fmt.Errorf("reading config %s: %w", path, err)
-
-var ErrNotFound = errors.New("not found")
-
-func FindUser(id string) (*User, error) {
-    u, err := db.Get(id)
-    if err != nil {
-        return nil, fmt.Errorf("finding user %s: %w", id, err)
-    }
-    if u == nil { return nil, ErrNotFound }
-    return u, nil
-}
-// Caller: if errors.Is(err, ErrNotFound) { ... }
-```
-
----
-
-## Interface Design [7][14]
+## Interface Design
 
-```go
-// "The bigger the interface, the weaker the abstraction" — Rob Pike [7]
-// BAD: func NewService(repo *PostgresRepo) *Service
-// GOOD: func NewService(repo Repository) *Service — accept interfaces [14]
+- Accept interfaces: `NewService(repo Repository)`, not `NewService(repo *PostgresRepo)`.
+- Define an interface at the consumer when it is used, not at the producer before use.
+- Keep interfaces small (1-3 methods) and compose them (`ReadWriter` embeds `Reader` and `Writer`).
 
-// Small interfaces compose cleanly [1]
-type Reader interface { Read(p []byte) (n int, err error) }
-type Writer interface { Write(p []byte) (n int, err error) }
-type ReadWriter interface { Reader; Writer }
-```
-
----
-
-## Concurrency [9][10][13]
-
-CSP (Hoare [9]): "Do not communicate by sharing memory; share memory by communicating." [10]
-
-```go
-// Context cancellation with errgroup [16][22]
-func Process(ctx context.Context, items []Item) error {
-    g, ctx := errgroup.WithContext(ctx)
-    for _, item := range items {
-        g.Go(func() error { return processItem(ctx, item) })
-    }
-    return g.Wait()
-}
-
-// Channel direction prevents misuse at compile time [1][8]
-func producer(ch chan<- int) { ch <- 42 }
-func consumer(ch <-chan int) { v := <-ch; _ = v }
-```
-
----
+## Concurrency
 
-## Package Design [15][17]
+- Do not communicate by sharing memory; share memory by communicating.
+- Pass `context.Context` as the first parameter.
+- Give every goroutine a clear lifecycle and cancellation, for example `errgroup.WithContext`. A bare `go fn()` leaks.
+- Specify channel direction in signatures: `chan<- int`, `<-chan int`.
 
-```go
-// BAD: models/, controllers/, services/
-// GOOD: user/, order/, payment/  — organize by domain [15]
+## Package Design and Zero Values
 
-func (s *Service) validate(u *User) error { ... }   // unexported — internal only
-func (s *Service) CreateUser(ctx context.Context, req CreateUserReq) (*User, error) { ... }
-```
-
----
-
-## Zero Values [1]
-
-```go
-var mu sync.Mutex; var buf bytes.Buffer  // Ready to use — no init needed
-
-type Config struct {
-    Timeout time.Duration // zero = no timeout
-    Retries int           // zero = no retries
-}
-```
-
----
-
-## Anti-Patterns
-
-| Pattern | Violation | Source |
-|---------|-----------|--------|
-| Ignoring error | `val, _ := fn()` | [5][2] |
-| Naked return | `return` in named returns | [2][4] |
-| init() abuse | Complex `init()` with side effects | [1][12] |
-| Interface pollution | Interface defined before use | [14][7] |
-| Goroutine leak | `go fn()` without lifecycle | [13][16] |
-| Panic in library | `panic(err)` in non-main code | [1][4] |
-
----
+- Organize packages by domain (`user/`, `order/`), not by type (`models/`, `controllers/`). Keep internals unexported.
+- Make zero values ready to use (`sync.Mutex`, `bytes.Buffer`; a zero `Timeout` means no timeout).
+- No naked `return` in functions with named returns.
+- No complex `init()` with side effects.
 
 ## Extended References
 
-- `references/sources.md` — Full bibliography (25 sources)
-- `references/violations.md` — Violations with citations [5][6][7][12][13]
-- `references/patterns.md` — Extended patterns with citations [1][3][11][18][19]
+- `references/sources.md` — Full bibliography
+- `references/violations.md` — Violations with citations
+- `references/patterns.md` — Extended patterns with citations
 - `references/detection.md` — Grep patterns for automated detection
-- `references/concurrency.md` — CSP-grounded concurrency patterns [9][10][13][22]
-
----
-
-## Checklist
-
-- [ ] All errors checked or explicitly ignored with `_ =` [5]
-- [ ] Errors wrapped with `fmt.Errorf("context: %w", err)` [6]
-- [ ] Interfaces defined at consumer, not producer [14]
-- [ ] Interfaces kept small (1-3 methods) [7]
-- [ ] Context as first parameter [16]
-- [ ] Goroutines have clear lifecycle/cancellation [13]
-- [ ] Channel direction specified in signatures [8]
-- [ ] Packages organized by domain, not by type [15]
-- [ ] No `init()` with side effects [1]
-- [ ] No `panic` or `log.Fatal` in library code [4]
+- `references/concurrency.md` — CSP-grounded concurrency patterns

package/src/assets/skills/java/SKILL.md

@@ -13,8 +13,6 @@ activation:
 
 # Java Patterns
 
-Reference for modern Java patterns, type system, and best practices.
-
 ## Iron Law
 
 > **FAVOR COMPOSITION OVER INHERITANCE**
@@ -24,125 +22,41 @@ Reference for modern Java patterns, type system, and best practices.
 > records for data, and sealed classes for restricted hierarchies. Extend only when the
 > "is-a" relationship is genuinely invariant. — Effective Java, Item 18 [1, Item 18]
 
-## When This Skill Activates
-
-- Working with Java codebases (records, sealed classes, Optional, streams)
-- Implementing concurrent code or API design
-- Structuring Java packages and dependencies
-
----
-
 ## Type System (Modern Java)
 
-**Records for data** [4][9] — Immutable carriers with auto-generated `equals`/`hashCode`/
-`toString`. Compact constructors validate before fields are sealed.
-
-```java
-// BAD: Mutable POJO. GOOD: Immutable record [1, Item 17][4]
-public record User(String name, String email, Instant createdAt) {
-    public User {
-        Objects.requireNonNull(name); Objects.requireNonNull(email);
-    }
-}
-```
-
-**Sealed classes** [5][9] — Close the subtype set, enabling exhaustive pattern matching. [6]
+- Use records for pure data, not mutable POJOs with `setName()/getName()`. Validate in the compact constructor (`Objects.requireNonNull`).
+- Use sealed interfaces for type hierarchies. They close the subtype set, so a switch over them is exhaustive with no `default`:
 
 ```java
 public sealed interface Result<T> permits Success, Failure {
     record Success<T>(T value) implements Result<T> {}
     record Failure<T>(String error) implements Result<T> {}
 }
-// Exhaustive — no default needed [6]
 switch (result) {
     case Success<User> s -> handleSuccess(s.value());
     case Failure<User> f -> handleError(f.error());
 }
 ```
 
-**Optional for absent values** [1, Item 22][25] — Never return `null`. Use functional
-chaining (`map`/`orElse`), not `isPresent()`/`get()`.
-
-```java
-public Optional<User> findById(String id) { return Optional.ofNullable(userMap.get(id)); }
-optional.map(User::name).orElse("Anonymous");
-```
-
----
+- Never return `null`: return `Optional`, and chain with `map`/`orElse`, not `isPresent()`/`get()`.
+- No raw generic types: `List<User>`, not `List`.
 
 ## Error Handling
 
-All `AutoCloseable` resources MUST use try-with-resources. [1] Custom unchecked exceptions
-carry structured fields for precise handling. [3]
+- Use try-with-resources for every `AutoCloseable` resource.
+- Throw specific or unchecked custom exceptions that carry structured fields for context, not `throws Exception`.
 
-```java
-try (var conn = dataSource.getConnection(); var stmt = conn.prepareStatement(sql)) {
-    stmt.setString(1, id); return mapResult(stmt.executeQuery());
-}
-```
-
----
+## Immutability and Composition
 
-## Immutability [1, Item 17]
-
-Prefer `List.of`/`Map.of`. Make defensive copies in constructors via `List.copyOf`. [1, Item 17][2]
-
-```java
-public final class Team {
-    private final List<String> members;
-    public Team(List<String> members) { this.members = List.copyOf(members); }
-    public List<String> members() { return members; }
-}
-```
-
----
-
-## Composition Over Inheritance [1, Item 18]
-
-Constructor-inject collaborators. Never extend a class solely to reuse methods. [1, Item 18][14]
-
-```java
-// BAD: class UserService extends BaseService extends AbstractDAO
-// GOOD: inject repository and eventBus as constructor parameters [1, Item 18]
-public class UserService {
-    public UserService(UserRepository repository, EventPublisher events) { ... }
-}
-```
-
----
-
-## Anti-Patterns
-
-| Pattern | Bad | Good | Source |
-|---------|-----|------|--------|
-| Returning null | `return null` | `return Optional.empty()` | [1, Item 22] |
-| Checked exception abuse | `throws Exception` | Specific or unchecked | [1] |
-| Raw types | `List list` | `List<User> list` | [1, Item 26][3] |
-| Deep inheritance | 4+ level hierarchy | Interfaces + composition | [1, Item 18][14] |
-| Mutable data objects | `setName()/getName()` | Records or immutable classes | [1, Item 17][4] |
-| Shared mutable state | `HashMap` across threads | `ConcurrentHashMap` or immutable | [2][12] |
-
----
+- Prefer `List.of`/`Map.of`. Make defensive copies in constructors with `List.copyOf`.
+- Do not share mutable state across threads (`HashMap`): use `ConcurrentHashMap` or immutable data.
+- Constructor-inject collaborators. Never extend a class only to reuse methods; replace deep hierarchies (4+ levels) with interfaces and composition.
+- Use streams for collection transforms.
 
 ## Extended References
 
-- `references/sources.md` — Full bibliography (28 sources)
+- `references/sources.md` — Full bibliography
 - `references/violations.md` — Common Java violations with citations
 - `references/patterns.md` — Extended Java patterns with citations
 - `references/detection.md` — Detection patterns for Java issues
 - `references/modern-java.md` — Modern Java features (17-21+) with JEP citations
-
----
-
-## Checklist
-
-- [ ] Records for pure data types [4]
-- [ ] Sealed interfaces for type hierarchies [5]
-- [ ] Optional instead of null returns [1, Item 22]
-- [ ] Composition over inheritance [1, Item 18]
-- [ ] Try-with-resources for all AutoCloseable [3]
-- [ ] Immutable collections (List.of, Map.of) [1, Item 17]
-- [ ] No raw generic types [1, Item 26]
-- [ ] Custom exceptions with context [1]
-- [ ] Streams for collection transforms [10][26]
-- [ ] Constructor injection for dependencies [1, Item 18]

package/src/assets/skills/patterns/SKILL.md

@@ -7,7 +7,7 @@ allowed-tools: Read, Grep, Glob
 
 # Implementation Patterns
 
-Reference for common implementation patterns. Use these patterns to write consistent, maintainable code.
+Reference for common implementation patterns.
 
 ## Iron Law
 
@@ -17,104 +17,37 @@ Reference for common implementation patterns. Use these patterns to write consis
 > use Result types. If it uses exceptions, use exceptions. Consistency trumps personal
 > preference. The best pattern is the one already in use.
 
-## When This Skill Activates
-
-- Implementing CRUD operations
-- Creating API endpoints
-- Writing event handlers
-- Setting up configuration
-- Adding logging
-- Database operations
-
----
-
 ## Pattern Categories
 
 ### CRUD Operations
 
-Create, Read, Update, Delete with Result types and proper error handling.
-
 **Core pattern**: Validate -> Transform -> Persist -> Return
 
-```typescript
-async function createUser(input: CreateUserInput): Promise<Result<User, CreateError>> {
-  const validated = validateCreateUser(input);
-  if (!validated.ok) return Err({ type: 'validation', details: validated.error });
-
-  const user: User = { id: generateId(), ...validated.value, createdAt: new Date() };
-  const saved = await userRepository.save(user);
-  if (!saved.ok) return Err({ type: 'persistence', details: saved.error });
-
-  return Ok(saved.value);
-}
-```
+Return `Result<T, E>`: a failed validation returns a `validation` error, a failed save a `persistence` error, and success returns the saved value.
 
 ### API Endpoints
 
-REST endpoint structure with auth, validation, and error mapping.
-
 **Core pattern**: Parse request -> Validate auth -> Execute -> Format response
 
-```typescript
-export async function handleGetUser(req: Request): Promise<Response> {
-  const id = parsePathParam(req, 'id');
-  if (!id.ok) return errorResponse(400, 'Invalid user ID');
-
-  const auth = await authenticate(req);
-  if (!auth.ok) return errorResponse(401, 'Unauthorized');
-
-  const result = await getUser(id.value);
-  if (!result.ok) return handleError(result.error);
-
-  return jsonResponse(200, result.value);
-}
-```
+A bad parameter returns 400 and a failed authentication 401 before any work runs. Map a domain error to its status in one handler, and return the success value as JSON.
 
 ### Event Handlers
 
-Async event processing with idempotency and error recovery.
-
 **Core pattern**: Validate event -> Process -> Handle errors -> Acknowledge
 
-```typescript
-async function handleUserCreated(event: UserCreatedEvent): Promise<void> {
-  const validated = validateEvent(event);
-  if (!validated.ok) { logger.warn('Invalid event'); return; }
-
-  await sendWelcomeEmail(event.userId);
-  await createDefaultSettings(event.userId);
-  logger.info('Event processed successfully');
-}
-```
+Make each handler idempotent, so a redelivered event does no harm. Log an invalid event as a warning and drop it; do not throw.
 
 ### Configuration
 
-Environment config with schema validation and feature flags.
-
 **Core pattern**: Define schema -> Load from env -> Validate -> Export frozen
 
-```typescript
-const ConfigSchema = z.object({
-  PORT: z.coerce.number().default(3000),
-  DATABASE_URL: z.string().url(),
-  NODE_ENV: z.enum(['development', 'production', 'test']).default('development'),
-});
-
-export const config = Object.freeze(ConfigSchema.parse(process.env));
-```
+Parse `process.env` once at startup through a schema (coerced types, defaults, required URLs), fail fast on an error, and export the result with `Object.freeze`.
 
 ### Logging
 
-Structured logging with context propagation and operation tracking.
-
 **Core pattern**: Context -> Level -> Message -> Data
 
-```typescript
-const logger = createLogger({ requestId: req.id, userId: user.id });
-logger.info('Processing order', { orderId: order.id, items: order.items.length });
-```
-
----
+Create the logger with request context (`requestId`, `userId`), and log a message with structured data (`{ orderId, items }`).
 
 ## Anti-Patterns to Avoid
 
@@ -125,38 +58,20 @@ logger.info('Processing order', { orderId: order.id, items: order.items.length }
 | Swallowing errors | Empty catch blocks | Handle or propagate with Result types |
 | Magic values | Unexplained numbers/strings | Extract to named constants |
 
----
-
 ## Build Optimization
 
-Production builds must exclude test files, debug artifacts, and sourcemaps.
-
-```json
-// tsconfig.prod.json
-{
-  "exclude": ["**/*.test.ts", "**/*.spec.ts", "**/tests/**"]
-}
-```
-
----
+Production builds must exclude test files, debug artifacts, and sourcemaps (for example `"exclude": ["**/*.test.ts", "**/*.spec.ts", "**/tests/**"]` in `tsconfig.prod.json`).
 
 ## Implementation Checklist
 
 Before implementing, verify:
 
-- [ ] Using Result types for operations that can fail
-- [ ] Validating input at system boundaries
-- [ ] Logging with context (requestId, userId, operation)
 - [ ] Handling all error cases explicitly
-- [ ] Making operations idempotent where possible
 - [ ] Using transactions for multi-step operations
 - [ ] No hardcoded values (use config)
-- [ ] Following existing codebase patterns
-
----
+- [ ] Input validated at system boundaries; operations idempotent where possible
 
 ## Extended References
 
-For full implementation examples:
 - `references/violations.md` - Extended violation examples (CRUD, API, Events, Config, Logging)
 - `references/patterns.md` - Extended correct patterns (CRUD, API, Events, Config, Logging)

package/src/assets/skills/performance/SKILL.md

@@ -1,135 +1,76 @@
 ---
 name: performance
-description: This skill should be used when reviewing code for N+1 queries or memory leaks.
+description: Use when reviewing code for N+1 queries or memory leaks.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---
 
 # Performance Patterns
 
-Domain expertise for performance optimization and bottleneck detection. Use alongside `devflow:review-methodology` for complete performance reviews.
+Detection patterns for performance and bottleneck review. Use with `devflow:review-methodology`.
 
 ## Iron Law
 
-> **MEASURE BEFORE OPTIMIZING**
+> **Measure before optimizing.**
 >
 > Profile first, optimize second. Every performance claim requires benchmarks. Brendan
-> Gregg's USE Method [1] (Utilization, Saturation, Errors) and Tom Wilkie's RED Method [2]
+> Gregg's USE Method (Utilization, Saturation, Errors) and Tom Wilkie's RED Method
 > (Rate, Errors, Duration) are the systematic starting points — not guesswork.
-> Gil Tene's coordinated omission warning [8]: averages lie — monitor P99, not mean latency.
+> Gil Tene's coordinated omission warning: averages lie — monitor P99, not mean latency.
 
----
-
-## Measurement Foundation [1][2][7][8][9]
-
-| Method | For | Measures |
-|--------|-----|---------|
-| USE Method [1] | System resources | Utilization, Saturation, Errors per resource |
-| RED Method [2] | Services | Rate, Errors, Duration per endpoint |
-| Flame Graphs [9] | CPU hot paths | Widest frames = hottest code — optimize those |
-| HDR Histogram [8] | Latency | Full distribution without coordinated omission |
-
-**Latency hierarchy** [7]: L1 cache ~1ns · L2 ~4ns · L3 ~40ns · RAM ~100ns · SSD ~100µs · Network (DC) ~500µs · HDD ~10ms. Knowing these prevents optimizing the wrong layer [4].
-
----
+Measurement tools: flame graphs for CPU hot paths (widest frames are hottest), HDR histograms for full latency distributions.
 
 ## Performance Categories
 
-### 1. Algorithmic Issues [5][12]
-
-**N+1 Query Problem** — database query inside a loop. O(n) round-trips [5].
-
-```typescript
-// VIOLATION: 1 + N queries — O(n) round-trips [5]
-for (const user of users) {
-  user.orders = await db.orders.findByUserId(user.id);
-}
-
-// CORRECT: Batch query with Map lookup — O(1) per access [5]
-const orders = await db.orders.findAll({ where: { userId: userIds } });
-const ordersByUser = new Map(groupBy(orders, 'userId'));
-users.forEach(u => u.orders = ordersByUser.get(u.id) || []);
-```
-
-**O(n²) Patterns** — linear search inside a loop [12].
-
-```typescript
-// VIOLATION: Array.includes is O(n), called n times → O(n²) [12]
-items.filter(item => selected.includes(item.id));
+### 1. Algorithmic Issues
 
-// CORRECT: Set lookup is O(1) → total O(n) [12]
-const selectedSet = new Set(selected);
-items.filter(item => selectedSet.has(item.id));
-```
+- **N+1 queries**: a database query inside a loop, O(n) round trips. Fix: one batch query, then a Map lookup.
+- **O(n²) patterns**: linear search inside a loop (`items.filter(i => selected.includes(i.id))`). Fix: a Set lookup.
 
-### 2. Memory Issues [4][10]
+### 2. Memory Issues
 
-**Memory Leaks** — resources not cleaned up. Hidden by GC until OOM [4].
-**Cache line false sharing** — hot fields on the same 64-byte line cause inter-core invalidation in high-throughput code [4][10].
-**Unbounded caches** — collections that grow forever. Use LRU with a `max` limit [4].
+- **Memory leaks**: resources not cleaned up, hidden by GC until OOM.
+- **Cache line false sharing**: hot fields on the same 64-byte line cause inter-core invalidation in high-throughput code.
+- **Unbounded caches**: collections that grow forever. Use LRU with a `max` limit.
 
-### 3. I/O Issues [3][16]
+### 3. I/O Issues
 
-**Blocking Operations** — synchronous I/O in request path blocks the event loop [3][16].
+- **Blocking operations**: synchronous I/O (`readFileSync`) in a request path blocks the event loop.
+- **Sequential when parallel is possible**: independent awaits run serially, so the total is the sum, not the max. Fix: `Promise.all`.
+- **Wrong layer**: CPU micro-tuning on a path bound by disk or network I/O (RAM ~100ns, SSD ~100µs, network ~500µs).
 
-```typescript
-const config = fs.readFileSync('./config.json');           // VIOLATION [3]
-const config = await fs.promises.readFile('./config.json'); // CORRECT [16]
-```
-
-**Sequential When Parallel Possible** — independent operations run serially [5].
-
-```typescript
-// VIOLATION: total = sum of all [5]
-const user = await getUser(id); const orders = await getOrders(id);
-// CORRECT: total = max of all
-const [user, orders] = await Promise.all([getUser(id), getOrders(id)]);
-```
-
-### 4. Database Issues [20]
+### 4. Database Issues
 
 Missing indexes, SELECT *, OFFSET pagination on large tables, LIKE with leading wildcard. See `references/violations.md`.
 
-### 5. Frontend / Web Vitals [6][17][21]
+### 5. Frontend / Web Vitals
 
 | Metric | Good | Poor | Measures |
 |--------|------|------|---------|
-| LCP [6] | < 2.5s | > 4s | Largest element load |
-| INP [21] | < 200ms | > 500ms | Input responsiveness |
-| CLS [6] | < 0.1 | > 0.25 | Layout stability |
+| LCP | < 2.5s | > 4s | Largest element load |
+| INP | < 200ms | > 500ms | Input responsiveness |
+| CLS | < 0.1 | > 0.25 | Layout stability |
 
 Unnecessary re-renders, missing virtualization, missing code splitting. See `references/violations.md`.
 
----
-
 ## Extended References
 
 | Reference | Content |
 |-----------|---------|
 | `references/sources.md` | Full bibliography (25 sources) |
-| `references/violations.md` | Extended violations with citations [n] |
-| `references/patterns.md` | Correct patterns with citations [n] |
+| `references/violations.md` | Extended violations |
+| `references/patterns.md` | Correct patterns |
 | `references/detection.md` | Grep commands, profiling, CI integration |
 
----
-
 ## Severity Guidelines
 
 | Severity | Examples |
 |----------|----------|
-| **CRITICAL** | N+1 with unbounded data [5], memory leaks [4], blocking I/O in handlers [3] |
-| **HIGH** | Sequential async [5], SELECT * [20], unbounded caches [4], LCP > 4s [6] |
-| **MEDIUM** | Suboptimal algorithm on small data [12], missing memoization, INP > 200ms [21] |
-| **LOW** | Micro-optimizations, premature optimization candidates [1] |
-
----
+| **CRITICAL** | N+1 with unbounded data, memory leaks, blocking I/O in handlers |
+| **HIGH** | Sequential async, SELECT *, unbounded caches, LCP > 4s |
+| **MEDIUM** | Suboptimal algorithm on small data, missing memoization, INP > 200ms |
+| **LOW** | Micro-optimizations, premature optimization candidates |
 
 ## Quick Detection
 
-```bash
-grep -rn "for.*await\|\.forEach.*async" --include="*.ts"  # N+1
-grep -rn "readFileSync\|writeFileSync" --include="*.ts"   # Sync I/O
-grep -rn "SELECT \*" --include="*.ts" --include="*.sql"   # SELECT *
-```
-
-See `references/detection.md` for comprehensive detection patterns.
+In the diff, search for `await` in a loop or `.forEach(async` (N+1), `readFileSync`/`writeFileSync` (sync I/O) and `SELECT *`.