| name | activity-edge-case-refinement |
| description | Systematically discover edge cases by category with concrete examples. Use when expanding coverage for input domains, state transitions, timing, and failure modes. |
Activity: Edge-Case Refinement
Systematic edge-case discovery by category with concrete examples for each. Produces a categorized edge-case catalog mapped to acceptance criteria, ensuring no high-risk boundary goes untested. Invoked by the verifier agent in Design Mode.
RFC 2119 Notice: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.
Goal
Discover and catalog edge cases across all relevant categories for the feature under test. Every edge case MUST be tied to at least one acceptance criterion and include a concrete, testable example.
Context
This activity assumes:
- A numbered list of acceptance criteria is available (produced by Phase 2 of
verifier).
- E2E scenarios and contract scenarios have already been drafted (or will be composed alongside).
- The output feeds into the edge-case section of the test plan assembled by
verifier.
Edge-Case Categories
You MUST evaluate every category below against the source artifact. For each category that applies, produce ≥1 concrete edge case. For categories that do not apply, explicitly note N/A — {reason}.
1. Input Domain
Boundary values, empty/null/missing inputs, maximum-length strings, special characters, Unicode, encoding mismatches.
Example: A name field accepts 1–100 characters. Edge cases: empty string, 1 character, 100 characters, 101 characters, string with only whitespace, string with emoji, string with null bytes.
2. State Transitions
Invalid state transitions, re-entrant operations, concurrent state changes, transitions from terminal states.
Example: An order can move pending → confirmed → shipped → delivered. Edge cases: attempt pending → shipped (skip confirmed), attempt delivered → pending (reverse), call confirm twice on the same order.
3. Timing & Concurrency
Race conditions, timeouts, out-of-order events, duplicate submissions, slow network responses.
Example: Two users submit the same promo code simultaneously. Edge case: both requests arrive before either is committed — does the system apply the code twice or correctly reject one?
4. Idempotency
Repeated identical requests, retry storms, duplicate webhook deliveries.
Example: POST /api/payments is called twice with the same idempotency key. Edge case: second call should return the same result without creating a duplicate payment.
5. Failure Modes
Network failures mid-operation, partial writes, downstream service unavailability, disk full, database connection loss.
Example: Payment gateway returns a timeout after charging the card. Edge case: system must not create a second charge on retry — check for charge-before-confirm pattern.
6. Auth & Permissions
Expired tokens, revoked permissions mid-session, privilege escalation, cross-tenant data access.
Example: User A has read access to project X. Edge case: User A attempts DELETE /api/projects/X — should receive 403, not 404 or 500.
7. Data Boundaries
Integer overflow, float precision, date boundaries (leap years, DST transitions, epoch limits), empty collections, maximum record counts.
Example: A date picker allows selecting a delivery date. Edge cases: Feb 29 in a leap year, Feb 29 in a non-leap year, Dec 31 23:59:59 UTC, Jan 1 00:00:00 UTC, dates in year 2038.
8. Resource Exhaustion
Memory pressure, connection pool depletion, rate limiting, disk space, file descriptor limits.
Example: API rate limit is 100 requests/minute. Edge cases: 100th request (should succeed), 101st request (should return 429), requests resume after the window resets.
9. API Versioning
Backward compatibility, deprecated field handling, schema migration, version header omission.
Example: API v2 renames userName to username. Edge cases: v1 client sends userName to v2 endpoint, v2 client sends username to v1 endpoint, request with no version header.
Edge-Case Template
### EC-{id}: {Edge-Case Title}
| Field | Value |
| ------------------- | --------------------------------------------------------------------------------------- |
| **AC(s)** | AC-{n} |
| **Category** | {category name from list above} |
| **Input / Setup** | {Concrete input or precondition} |
| **Expected Result** | {Observable behavior} |
| **Risk if Missed** | {Consequence of not testing this — data loss, security breach, silent corruption, etc.} |
Example Walkthrough: "Requested vs Delivered" Validation
Given a user story with AC-5: "Discount code can only be used once per user."
Deriving the edge case:
- Parse AC: "used once per user" → requires per-user uniqueness check.
- Category: Idempotency + Timing & Concurrency.
- Concrete edge case:
EC-7: Same discount code submitted twice simultaneously
| Field | Value |
|---|
| AC(s) | AC-5 |
| Category | Idempotency, Timing & Concurrency |
| Input / Setup | User sends two POST /api/cart/discount requests with the same code in parallel (within 50ms). |
| Expected Result | Exactly one application succeeds. The second returns an error indicating the code was already used. |
| Risk if Missed | User gets double discount — revenue loss, potential abuse vector. |
Validating "requested vs delivered":
- Requested (AC-5): Code used once per user.
- Delivered: Run the edge case; if both requests succeed → DRIFT detected. If exactly one succeeds → PASS.
Output
This skill returns a categorized list of edge cases in the template format above. The calling agent (verifier) assembles them into the edge-case section of the test plan.
Execution Checklist
Use this checklist to verify completeness before returning results:
Final Instructions
- You MUST evaluate all 9 categories — do not skip any.
- You MUST produce at least one concrete edge case per applicable category.
- You MUST include the "Risk if Missed" field for every edge case.
- You MUST NOT reference internal implementation details — all edge cases describe observable behavior.
- You MUST flag ACs that appear to have no meaningful edge cases and explain why.
- You SHOULD prioritize edge cases by risk severity when the catalog is large.
