## Boundary Business Rule Defects (Medium)

### Trigger Signals

Start this detection when the following code characteristics appear:
- Pagination/batch operations (`limit`, `offset`, `batch`, `bulk`, `forEach`, `Promise.all`)
- Parameter handling related to quantity/amount (`quantity`, `amount`, `price`, `count`)
- Time window judgment (`startDate`/`endDate`, `expiresAt`, `validUntil`)
- Null checks before collection operations (whether empty array/empty list cases are handled)

### Judgment Process

1. **Identify business-critical parameters**: `Read` extracts variables related to quantity, amount, and time from function parameters
2. **Check quantity/amount boundaries**: `Read` confirms whether the following validations exist:
   - Lower bound validation: disallow negative numbers, zero values (e.g., `quantity > 0`, `amount >= minAmount`)
   - Upper bound validation: purchase limits, maximum amounts, maximum batch sizes
   - Precision validation: whether amounts use integer cents/Decimal rather than floating-point numbers
3. **Check time windows**: `Read` confirms whether time-related judgments consider:
   - Timezone differences (`new Date()` vs `Date.now()` vs UTC)
   - Activity expiration validation (whether current time is checked before processing)
4. **Check batch operation limits**: `Read` confirms whether batch operations have:
   - Quantity upper limit (`Math.min(requestItems.length, MAX_BATCH)`)
   - Empty collection handling (empty array directly returns or errors)
5. **Check empty state handling**: `Read` confirms whether business handling when collections/lists are empty matches expectations

### Evidence Construction

After confirming a defect, the output must include:
- Unvalidated boundary conditions (which parameter is missing which validation, with file:line number)
- Boundary value trigger scenario (how specific input values trigger the issue)
- Business impact (consequences of negative quantity orders, zero-amount payments, batch delete-all, expired operations being accepted)

### Exclusions

- Already has independent parameter validation layer (DTO validation schema, class-validator, pydantic)
- Boundaries guaranteed by database constraints (NOT NULL, CHECK, UNSIGNED)
- Non-security-related parameters guaranteed by frontend validation
