cc-test-planlisted

# Test Plan Workflow Scope: $ARGUMENTS Specify what to plan tests for. Examples: - A feature name: `user authentication` - A module or file path: `src/orders/OrderService.kt` - A Task Card title: `Add paginated product listing endpoint` - A PR or branch: `feature/payment-retry` If $ARGUMENTS is empty, describe the scope in your next message before invoking `tester`. --- ## Step 1 — Scope confirmation Before invoking `tester`, confirm the scope is well-defined. A valid scope includes: - The behavior or module under test - The acceptance criteria or expected behavior (from the Task Card if available) - Known edge cases or failure modes If the scope is vague (e.g., "test the whole service"), ask one clarifying question and wait for the answer. --- ## Step 2 — Test plan generation (tester) Invoke `tester` in planning mode — produce a test plan document, not test code. The plan will be used as input when tests are actually written. tester must produce a Test Plan covering the following layers: **Unit tests** - Individual functions or methods in isolation - One test per behavior, not per method - Input/output contracts, null handling, type coercion **Integration tests** - Interactions between two or more components - Database read/write cycles (if applicable) - External service boundaries (mocked or stubbed) **Contract tests** - API endpoint contracts: request shape, response shape, status codes - Event schema contracts (if event-driven components are in scope)