prizmkit 1.1.86 → 1.1.88

package/bundled/skills-windows/prizmkit-test/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: "prizmkit-test"
-description: "Full-stack test generation and orchestration. Detects architecture, discovers/runs existing tests, analyzes coverage gaps, generates missing tests (unit/integration/E2E), outputs unified report. Use after completing development to verify quality before deploy. Trigger on: 'test', 'run tests', 'check quality', 'verify code', 'generate tests', 'test coverage', 'fill test gaps', 'quality check', '测试', '验证', '跑测试', '补测试'. (project)"
+description: "Full-stack test generation and orchestration. Detects architecture, discovers/runs existing tests, analyzes coverage gaps, generates missing unit/integration/E2E tests including business-specific boundary cases, validates every interface with a required boundary coverage matrix, and outputs a unified report. Use after completing development to verify quality before deploy. Trigger on: 'test', 'run tests', 'check quality', 'verify code', 'generate tests', 'test coverage', 'fill test gaps', 'boundary tests', 'edge cases', 'quality check', '测试', '验证', '跑测试', '补测试', '边界测试'. (project)"
 ---
 
 # PrizmKit Test
 
-A comprehensive test generation and orchestration skill. Discovers existing tests, runs them, compares coverage against spec acceptance criteria and module interfaces, generates missing tests at three levels (unit → integration → E2E), and produces a unified report.
+A comprehensive test generation and orchestration skill. Discovers existing tests, runs them, compares coverage against spec acceptance criteria and module interfaces, generates missing tests at three levels (unit → integration → E2E), verifies business-specific boundary coverage for every in-scope interface, and produces a unified report.
 
 ### When to Use
 - After completing one or more features/refactors/bugfixes
@@ -34,11 +34,26 @@ Before execution, load context once:
 2. **Project config**: Read `.prizmkit/config.json` (tech stack, AI CLI config).
 3. **Dependencies**: Read `package.json` or equivalent to detect test framework and project type.
 
+For `scope=this-change`, load only:
+- `.prizmkit/prizm-docs/root.prizm`
+- relevant L1/L2 docs inferred from in-scope changed files
+- `artifact_dir/spec.md`
+- `artifact_dir/plan.md`
+- `artifact_dir/context-snapshot.md` if present
+- `artifact_dir/review-report.md` if present
+- changed source files and directly related existing tests
+
+Do not load all modules or all specs merely because they exist.
+
 ## Input
 
 | Parameter | Required | Description |
 |-----------|----------|-------------|
-| `scope` | No | User selects interactively in Phase 1. In headless mode, defaults to full project. |
+| `scope` | No | `full-project`, `module:<name>`, `feature:<slug>`, or `this-change`. In headless mode, defaults to `this-change` only when `artifact_dir` points to `.prizmkit/specs/<FEATURE_SLUG>/`; otherwise defaults to full project. |
+| `artifact_dir` | No | Feature artifact directory. For `scope=this-change`, must be `.prizmkit/specs/<FEATURE_SLUG>/`. Do not infer this-change scope from `.prizmkit/bugfix/` or `.prizmkit/refactor/`. |
+| `diff_base` | No | Git ref used to compute changed files for this feature. |
+| `changed_files` | No | Explicit caller-provided changed file list. Takes precedence over `diff_base`. |
+| `generation_policy` | No | Defaults to `in-scope-only` for `scope=this-change`. Out-of-scope gaps are reported but not generated. |
 
 ## Execution
 
@@ -72,7 +87,14 @@ Before execution, load context once:
 2. **Single module** — pick from L1 doc module names (e.g., "auth", "payment")
 3. **Single feature** — pick from `.prizmkit/specs/###-*/` directories
 
-**Headless mode** — default to full project. If `artifact_dir` or `scope` was passed by the caller, use that.
+**Headless mode**:
+1. If `scope=this-change`, require `artifact_dir=.prizmkit/specs/<FEATURE_SLUG>/` and run in feature-scoped mode.
+2. If `artifact_dir=.prizmkit/specs/<FEATURE_SLUG>/` is provided without `scope`, treat it as `scope=this-change`.
+3. If `scope=full-project` is explicitly provided, run full-project mode even if an artifact directory exists.
+4. If `artifact_dir` points to `.prizmkit/bugfix/` or `.prizmkit/refactor/`, do not infer `scope=this-change`.
+5. If neither `scope` nor feature `artifact_dir` is provided, default to full project.
+
+`scope=this-change` is feature-only. It is valid only when `artifact_dir` is under `.prizmkit/specs/<FEATURE_SLUG>/`. Do not automatically apply `scope=this-change` to `.prizmkit/bugfix/<BUG_ID>/` or `.prizmkit/refactor/<REFACTOR_ID>/`. If the caller passes `scope=this-change` with a bugfix/refactor artifact directory, stop and report that this mode is unsupported for that artifact type. Bugfix and refactor workflows keep their existing reproduction-test and behavior-preservation test gates.
 
 ### Phase 2: Run Existing Tests
 
@@ -83,13 +105,37 @@ Before execution, load context once:
    - Which test files exist (for gap analysis)
    - Raw output (saved to report directory)
 
-3. If existing tests fail: record failures but continue — this is coverage data. Do not attempt to fix pre-existing test failures (they predate this session).
+3. Classify existing test failures before continuing:
+   - For `scope=this-change`, failures in changed tests, tests mapped to in-scope source files, or tests directly covering feature acceptance criteria are `In-Scope Failures` unless a captured pre-feature baseline proves they already failed before this feature.
+   - For `scope=this-change`, unrelated failures are `Baseline Failures`; record them without failing the scoped verdict.
+   - For other scopes, record failures as existing test failures and do not assume they are caused by this test-generation pass.
+
+4. If `scope=this-change` has any unexplained `In-Scope Failures`, the final report verdict must be `NEEDS_FIXES` or `BLOCKED`, not `PASS`. Do not hide them as baseline failures.
 
 ### Phase 3: Coverage Gap Analysis
 
 Staleness of `.prizmkit/prizm-docs/` was already checked during Context Loading (see Precondition). Gap analysis proceeds with the available data.
 
-Compare what exists against what should exist, across three levels:
+For `scope=this-change`:
+
+1. Build the in-scope source set using this priority:
+   - `changed_files` parameter
+   - `git diff --name-only <diff_base>`
+   - files/tasks listed in `artifact_dir/plan.md`
+   - File Manifest in `artifact_dir/context-snapshot.md`
+   - direct file/module mapping from `artifact_dir/spec.md` acceptance criteria
+2. Build the in-scope test set:
+   - tests already changed in this feature
+   - tests matching in-scope source files by project naming convention
+   - directly affected integration/E2E tests for feature acceptance criteria
+3. Analyze only:
+   - changed/new public interfaces
+   - feature acceptance criteria from `artifact_dir/spec.md`
+   - integration boundaries directly affected by in-scope files
+   - UI/E2E flows directly affected by this feature
+4. For unrelated historical gaps, record them under `Out of Scope Gaps`; do not generate tests and do not fail the feature verdict because of them.
+
+For other scopes, compare what exists against what should exist, across three levels:
 
 **Unit test gaps** — for each module in scope:
 - Read the corresponding L2 `.prizm` doc INTERFACES section to get exported functions/classes. If no L2 doc exists for a module, analyze source files directly to identify exported functions/classes.
@@ -106,30 +152,76 @@ Compare what exists against what should exist, across three levels:
 - Check existing E2E test files against these criteria
 - Flag uncovered criteria
 
-### Phase 4: Generate Missing Tests
+### Phase 4: Boundary Coverage Matrix
+
+Phase 3 answers "which interfaces are missing tests?" Phase 4 answers "which business boundaries are missing for each interface?" Build this matrix before generating tests so the run does not mistake broad happy-path coverage for real safety coverage.
+
+A path, method, function, or class is not considered covered merely because a happy-path test exists; happy path proves the interface works once, while boundary tests prove it behaves safely under realistic invalid, unauthorized, edge, and failure states.
+
+Read `${SKILL_DIR}/references/boundary-coverage-protocol.md` for the required matrix format, category definitions, and completion gate. For every in-scope interface and API endpoint, classify applicable categories such as request validation, auth/permission/ownership, domain invariants, collection/pagination, date/time boundaries, state transitions, dependency failures, and response contract checks. In `scope=this-change`, build this matrix only for the in-scope feature interfaces/endpoints; unrelated interfaces belong in `Out of Scope Gaps`.
+
+For each category, mark one of:
+- `covered` — an existing test already asserts the boundary behavior
+- `generated` — this run generated and passed the test
+- `needs-review` — a valid generated test found behavior mismatch
+- `skipped` — not applicable, with a concrete reason
 
-Read `${SKILL_DIR}/references/test-generation-steps.md` for the detailed generation procedure — priority order (unit → integration → E2E), failure handling rules, and generation patterns for each test level.
+If an interface has only happy-path coverage, mark it `boundary-missing` and generate applicable boundary tests in Phase 5. Do not mark happy-path-only coverage as `covered`.
 
-When generating unit tests for service-like functions, use `${SKILL_DIR}/references/service-boundary-test-catalog.md` via the generation procedure so boundary cases reflect the function's business responsibility, not only generic null/empty inputs.
+### Phase 5: Generate Missing and Boundary Tests
 
-### Phase 5: Unified Report
+Read `${SKILL_DIR}/references/test-generation-steps.md` for the detailed generation procedure — boundary-matrix-driven workflow, priority order (unit → integration → E2E), failure handling rules, and generation patterns for each test level.
+
+When generating unit tests for service-like functions or API/integration tests for endpoints with business-specific behavior, use `${SKILL_DIR}/references/service-boundary-test-catalog.md` via the generation procedure so boundary cases reflect the interface's business responsibility, not only generic null/empty inputs.
+
+For `scope=this-change`:
+- Generate or update tests only for the in-scope source/test set.
+- Check for equivalent existing tests before writing new tests.
+- Do not create tests for unrelated modules just because coverage is missing.
+- Do not refactor unrelated tests.
+- Do not modify unrelated production code.
+- Do not expand to full-project coverage unless the user explicitly requested `scope=full-project`.
+- Generated tests must assert real behavior, boundaries, or integration contracts; do not add empty assertions or mock-success-only tests.
+
+### Phase 6: Unified Report and Boundary Validation
 
 Create `.prizmkit/test/{YYYY_MM_DD_HH_MM_SS}_testresult/` directory. Read `${SKILL_DIR}/references/test-report-template.md` for the full report format and artifact list.
 
+For `scope=this-change`, the report must include:
+- `## Scope` with mode, artifact dir, diff base, changed-files source, generation policy, in-scope source files, and in-scope test files
+- `## Existing Tests Run`
+- `## Generated / Updated Tests`
+- `## In-Scope Failures`
+- `## Baseline Failures`
+- `## Out of Scope Gaps`
+- `## Verdict` with `PASS`, `NEEDS_FIXES`, or `BLOCKED`
+
+`Out of Scope Gaps` are informational only for `scope=this-change`: they must not trigger generated tests and must not fail the verdict.
+
+After writing the report, run the deterministic boundary-report validator when the project has an OpenAPI file or the report contains a Boundary Matrix:
+
+```bash
+python3 ${SKILL_DIR}/scripts/validate_boundary_report.py \
+  --report .prizmkit/test/{timestamp}_testresult/test-report.md \
+  --openapi openapi.yaml
+```
+
+If the project has no OpenAPI file, omit `--openapi`. If validation fails, keep the report but do not claim the run is complete; report that tests may pass while boundary coverage remains incomplete.
+
 ## Output
 
 - Test report: `.prizmkit/test/{timestamp}_testresult/test-report.md`
 - Generated test files written to project test directories
-- Existing test output, generated test copies, and E2E artifacts in the report directory
+- Existing test output, generated test copies, E2E artifacts, and boundary validation output in the report directory
 
 ## Recovery
 
 If the session is interrupted:
 - Check `.prizmkit/test/` for the most recent report directory — it contains what was completed before interruption
-- Re-run `/prizmkit-test` — it starts fresh, but Phase 2 will skip tests that already pass, and Phase 3 will re-evaluate gaps
+- Re-run `/prizmkit-test` — it starts fresh, but Phase 2 will skip tests that already pass, and Phase 3/4 will re-evaluate gaps and boundary coverage
 
 ## Examples
 
-Read `${SKILL_DIR}/references/examples.md` for worked examples of full-project and single-feature test runs.
+Read `${SKILL_DIR}/references/examples.md` for worked examples of full-project, single-feature, and happy-path-only remediation runs.
 
-**HANDOFF:** Independent skill — no handoff. User may proceed to `/prizmkit-committer` if all tests pass, or fix issues manually if tests are marked "needs-review".
+**HANDOFF:** Independent skill — no handoff. User may proceed to `/prizmkit-committer` only if tests pass and the boundary completion gate passes. If tests are marked `needs-review` or boundary validation fails, fix issues manually or run another targeted `/prizmkit-test` pass.

package/bundled/skills-windows/prizmkit-test/references/boundary-coverage-protocol.md

@@ -0,0 +1,220 @@
+# Boundary Coverage Protocol
+
+Use this protocol during `/prizmkit-test` Phase 4 and update it during Phase 5. The goal is to prevent a common false positive: treating "there is a test for this interface" as equivalent to "this interface is safely covered." A happy path proves that the interface can work once; boundary tests prove that the interface handles realistic invalid inputs, authorization failures, ownership rules, state transitions, and dependency failures.
+
+## Required Boundary Matrix
+
+Build this matrix before writing tests and update it after generated tests pass or produce `needs-review` findings. In `scope=this-change`, build the matrix only for in-scope feature interfaces/endpoints; unrelated interfaces are recorded under `Out of Scope Gaps` and do not trigger generated tests.
+
+| Module | Interface | Service Type | Happy Path | Request Validation | Auth / Permission / Ownership | Domain Invariants | Collection / Pagination | Date / Time | State Transitions | Dependency Failure | Response Contract | N/A Reasons | Final Status |
+|--------|-----------|--------------|------------|--------------------|-------------------------------|-------------------|-------------------------|-------------|-------------------|-------------------|-------------------|-------------|--------------|
+| auth | POST /auth/login | Auth / Session | covered | generated | N/A — public route | generated | N/A — no collection input | N/A — no date input | covered | skipped — password hasher not injectable | covered | ... | boundary-covered |
+
+## Status Values
+
+Use these values consistently:
+
+- `covered` — an existing test already asserts this behavior.
+- `generated` — this run generated a test and the test passed.
+- `needs-review` — a generated test is valid, but production behavior mismatched the expected contract.
+- `unresolved` — the test could not be made runnable after the allowed fix attempts.
+- `skipped` — not applicable or not practical in this run, with a concrete reason in `N/A Reasons`.
+- `boundary-missing` — applicable boundary exists but no test covers it yet.
+
+## Completion Gate
+
+An in-scope interface is complete only when:
+
+1. It has happy-path coverage when a happy path exists.
+2. Every applicable boundary category is `covered`, `generated`, or `needs-review`.
+3. Every non-applicable category has a concrete reason.
+4. No applicable category remains `boundary-missing`.
+5. The final status is one of:
+   - `boundary-covered`
+   - `generated-needs-review`
+   - `skipped-with-reason`
+
+If an interface has only happy-path coverage, set `Final Status` to `boundary-missing` and continue generating applicable boundary tests. Do not call the run complete while any in-scope interface is `boundary-missing` or `happy-path-only`.
+
+## How to Decide Whether Existing Tests Count
+
+An existing test counts for a boundary category only when it:
+
+- targets the same public interface or endpoint,
+- creates the boundary input, state, dependency failure, or authorization context,
+- asserts the expected error code, exception, state change, response shape, or side effect,
+- verifies behavior rather than only checking that the call returned a response.
+
+Examples:
+
+- `POST /users/create` returns HTTP 200 with non-empty data → happy path only.
+- `POST /users/create` with missing email asserts `code=10001` → request validation boundary.
+- `POST /items/delete` with another user's item asserts forbidden/not-found code → ownership boundary.
+- Service create method with mocked repository failure asserts no partial side effect → dependency failure boundary.
+
+## Boundary Categories
+
+### Request Validation
+
+Use when the interface accepts client input or public parameters.
+
+Generate applicable cases for:
+- missing required fields,
+- empty string / empty array / empty object,
+- malformed JSON or wrong content type when the framework exposes that behavior,
+- wrong type,
+- unsupported enum,
+- invalid numeric values: zero, negative, min/max, just above max,
+- invalid string format: URL, email, phone, date, timestamp, UUID/ULID, object key.
+
+### Auth / Permission / Ownership
+
+Use when the interface depends on identity, roles, tenant, ownership, entitlement, or token state.
+
+Generate applicable cases for:
+- missing auth,
+- malformed auth header,
+- invalid/expired/revoked token,
+- authenticated user accessing another user's resource,
+- missing role/permission/entitlement,
+- default-deny when ownership cannot be proven.
+
+### Domain Invariants
+
+Use when business rules constrain combinations of fields or state.
+
+Generate applicable cases for:
+- ratios or totals that must sum to a value,
+- start date before end date,
+- calorie/weight/amount ranges,
+- unsupported lifecycle status,
+- duplicate unique identifiers,
+- device binding requirements,
+- token rotation/reuse semantics,
+- image quality / provider classification rules,
+- product-specific thresholds such as 90%-110% calorie hit boundaries.
+
+### Collection / Pagination
+
+Use when the interface accepts or returns lists, pages, filters, or cursors.
+
+Generate applicable cases for:
+- empty result,
+- one item,
+- many items,
+- duplicate IDs,
+- omitted page / page size defaults,
+- page 0, negative page, max page size, max + 1,
+- invalid filters,
+- nullable filters such as true/false/null,
+- stable ordering or total count when specified.
+
+### Date / Time
+
+Use when the interface parses, stores, filters, expires, schedules, or compares time.
+
+Generate applicable cases for:
+- invalid date / timestamp format,
+- timezone assumptions,
+- inclusive vs exclusive date range boundaries,
+- start after end,
+- exact expiry instant and just before/after expiry,
+- today/yesterday/stale streak or schedule semantics,
+- leap day/month end when relevant.
+
+### State Transitions
+
+Use when the interface creates, updates, deletes, confirms, unbinds, retries, logs out, refreshes, or changes status.
+
+Generate applicable cases for:
+- create then read,
+- update sets expected derived fields,
+- delete excludes from later reads,
+- double delete / unbind idempotency when specified,
+- refresh rotates token and rejects old token,
+- batch operation with empty list vs explicit IDs,
+- retry count below/at/above max,
+- no partial writes when one operation fails.
+
+### Dependency Failure
+
+Use when collaborators are mockable or the test layer can safely simulate failures.
+
+Generate applicable cases for:
+- repository/database error,
+- storage/signing provider failure,
+- SMS/push/email provider failure,
+- LLM/API client error,
+- timeout/network failure,
+- malformed provider response,
+- ID/random/clock failure when injectable.
+
+If a dependency cannot be mocked in the current test layer, mark it `skipped` with a reason and consider a lower-level unit test where it can be mocked.
+
+### Response Contract
+
+Use for API endpoints and public adapters.
+
+Generate applicable cases for:
+- unified envelope fields (`code`, `message`, `data`) or framework-specific response format,
+- fixed business error codes,
+- response field names and snake_case/camelCase contract,
+- omitted vs empty data shape,
+- generated IDs and derived fields,
+- side-effect visibility in response.
+
+## Endpoint and Interface Mapping
+
+Use names, routes, methods, schemas, binding tags, repository calls, and service logic to choose categories. When names and behavior disagree, trust behavior.
+
+| Pattern | Likely Categories |
+|---------|-------------------|
+| register / signup / create user | request validation, auth/session, domain invariants, dependency failure, response contract |
+| login | request validation, auth/session, rate limit, token response, dependency failure |
+| refresh / logout | token state, rotation/revocation, idempotency, dependency failure |
+| get / detail | auth/ownership, not found, response contract, dependency failure |
+| list / search / trends | auth, filters, pagination/empty result, date range, response contract, dependency failure |
+| create | request validation, domain invariants, state transition, dependency failure, response contract |
+| update / set goal / confirm | request validation, ownership, partial update semantics, domain invariants, state transition |
+| delete / unbind | request validation, ownership, not found, soft delete, double operation behavior |
+| upload / sign url | request validation, file/storage rules, provider failure, response contract |
+| AI / provider / recognize | request validation, date/time, provider error mapping, quality classifications, async job state |
+| stats / analytics | date range, empty data, boundary thresholds, response shape, dependency failure |
+| achievement / streak | empty state, date continuity, threshold boundaries, state persistence |
+
+## N/A Reason Rules
+
+A skipped category must explain why it does not apply or why it cannot be exercised at this level.
+
+Good reasons:
+- `N/A — public route; no authenticated principal expected`
+- `N/A — endpoint has no collection input or paginated response`
+- `N/A — dependency is not injectable at handler level; covered by service unit test`
+- `N/A — function is pure and has no stateful side effects`
+- `N/A — E2E skipped because project has no UI layer`
+
+Bad reasons:
+- `N/A`
+- `not tested`
+- `probably fine`
+- `covered by happy path`
+
+## Report Requirements
+
+The final report must include:
+
+1. The Boundary Matrix.
+2. A Completion Gate summary:
+   - interfaces total,
+   - boundary-covered count,
+   - generated-needs-review count,
+   - skipped-with-reason count,
+   - boundary-missing count,
+   - happy-path-only count.
+3. A clear final status:
+   - `All tests passing and boundary coverage complete`, or
+   - `Tests passing, but boundary coverage incomplete`, or
+   - `Tests failing`, or
+   - `Needs human review`.
+
+If any interface remains `boundary-missing` or `happy-path-only`, the final report must not say "ready for commit" without qualifying that boundary coverage is incomplete.

package/bundled/skills-windows/prizmkit-test/references/examples.md

@@ -26,17 +26,26 @@ Scope: Full project (all modules, all specs)
 | payment | api/checkout | integration | missing |
 | — | Checkout flow | e2e | missing |
 
-**Phase 4**: Generated 5 unit tests (3 passing, 2 assertion failures marked "needs-review"), 1 integration test (passing), 1 E2E test (passing).
+**Phase 4 — Boundary Matrix** (excerpt):
+| Module | Interface | Service Type | Happy Path | Request Validation | Auth / Permission / Ownership | Domain Invariants | Dependency Failure | Final Status |
+|--------|-----------|--------------|------------|--------------------|-------------------------------|-------------------|-------------------|--------------|
+| auth | login() | Auth / Session | covered | boundary-missing | boundary-missing | skipped | boundary-missing | boundary-missing |
+| payment | processPayment() | Payment / Billing | covered | boundary-missing | boundary-missing | boundary-missing | boundary-missing | boundary-missing |
 
-**Phase 5 — Report Summary**:
+**Phase 5**: Generated 5 unit boundary tests (3 passing, 2 assertion failures marked `needs-review`), 1 integration boundary test (passing), 1 E2E test (passing).
+
+**Phase 6 — Report Summary**:
 ```
 Generated: 5 unit (2 needs-review), 1 integration, 1 E2E
+Boundary gate: failed — 2 interfaces need human review
 Report: .prizmkit/test/2026_05_23_14_30_00_testresult/test-report.md
 Needs human review: processPayment (returns 400 for negative amounts, expected 422), refund (missing authorization header causes 500 instead of 401)
 ```
 
 ## Example 2: Single-Feature Targeted Test
 
+This is an interactive single-feature selection. It is different from headless `scope=this-change`, which is driven by `.prizmkit/specs/<FEATURE_SLUG>/` and changed files.
+
 **User**: `/prizmkit-test`
 
 **Phase 0 — Architecture Detection**:
@@ -49,22 +58,86 @@ Test framework: Vitest
 ```
 Scope: Single feature — 042-payment-gateway
 Test files in scope: 2
+```
 
 **Phase 2 — Existing Tests**: 2 test files, 8 tests, all passing.
 
 **Phase 3 — Gap Analysis** (excerpt):
 | Module | Interface | Type | Status |
 |--------|-----------|------|--------|
-| payment | processPayment() | unit | missing |
-| payment | refund() | unit | missing |
+| payment | processPayment() | unit | boundary-missing |
+| payment | refund() | unit | boundary-missing |
+
+**Phase 4 — Boundary Matrix**:
+| Module | Interface | Service Type | Happy Path | Request Validation | Auth / Permission / Ownership | Domain Invariants | State Transitions | Dependency Failure | Final Status |
+|--------|-----------|--------------|------------|--------------------|-------------------------------|-------------------|-------------------|-------------------|--------------|
+| payment | processPayment() | Payment / Billing | covered | boundary-missing | boundary-missing | boundary-missing | generated | boundary-missing | boundary-missing |
+| payment | refund() | Payment / Refund | covered | boundary-missing | boundary-missing | boundary-missing | boundary-missing | skipped — provider sandbox unavailable | boundary-missing |
 
-**Phase 4**: Generated 2 unit tests (both passing). No integration/E2E applicable for this scope.
+**Phase 5**: Generated 8 unit tests covering amount boundaries, currency mismatch, missing entitlement, duplicate idempotency key, partial refund, full refund, over-refund, and repository failure. All passing.
 
-**Phase 5 — Report Summary**:
+**Phase 6 — Report Summary**:
 ```
-Generated: 2 unit tests (all passing)
+Generated: 8 unit tests (all passing)
+Boundary gate: passed
 Report: .prizmkit/test/2026_05_23_15_00_00_testresult/test-report.md
-All tests passing. Ready for commit.
+All tests passing and boundary coverage complete. Ready for commit.
+```
+
+## Example 3: Existing Happy Path Is Not Enough
+
+**User**: `/prizmkit-test user module`
+
+**Existing tests found**:
+```
+TestHandler_UpdateProfile_Success
+TestHandler_GetProfile_Success
+```
+
+**Boundary Matrix result**:
+| Module | Interface | Service Type | Happy Path | Request Validation | Auth / Permission / Ownership | Domain Invariants | Dependency Failure | Final Status |
+|--------|-----------|--------------|------------|--------------------|-------------------------------|-------------------|-------------------|--------------|
+| user | POST /user/update-profile | Validation / CRUD | covered | boundary-missing | boundary-missing | boundary-missing | boundary-missing | boundary-missing |
+| user | POST /user/get-profile | CRUD / Auth | covered | N/A — empty request | boundary-missing | N/A — no domain input | boundary-missing | boundary-missing |
+
+**Correct action**:
+Generate tests for:
+- missing auth,
+- invalid gender,
+- invalid activity level,
+- implausible height/weight when specified by service contract,
+- user not found,
+- repository failure,
+- response envelope shape.
+
+**Incorrect action**:
+Do not report `user` as covered just because both endpoints have success tests.
+
+
+## Example 3: Feature Pipeline this-change Run
+
+**Caller**: `/prizmkit-test scope=this-change artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`
+
+**Expected behavior**:
+- Reads `.prizmkit/specs/{{FEATURE_SLUG}}/spec.md`, `plan.md`, and optional `context-snapshot.md`.
+- Builds in-scope files from changed files and feature artifacts.
+- Generates or updates only tests for this feature's changed files, public interfaces, and acceptance criteria.
+- Records unrelated historical gaps under `Out of Scope Gaps`.
+- Does not generate tests for unrelated modules.
+- Does not infer this-change mode from `.prizmkit/bugfix/{{BUG_ID}}/` or `.prizmkit/refactor/{{REFACTOR_ID}}/`.
+
+**Report excerpt**:
+```markdown
+## Scope
+- Mode: this-change
+- Artifact Dir: .prizmkit/specs/{{FEATURE_SLUG}}/
+- Generation Policy: in-scope-only
+
+## Out of Scope Gaps
+- payment: missing legacy tests, but this feature did not change payment code.
+
+## Verdict
+PASS
 ```
 
-**HANDOFF**: Independent skill — no handoff. User may proceed to `/prizmkit-committer` if all tests pass, or fix issues manually if tests are marked "needs-review".
+**HANDOFF**: Independent skill — no handoff. User may proceed to `/prizmkit-committer` only if tests pass and the boundary completion gate passes, or fix issues manually if tests are marked `needs-review`.

package/bundled/skills-windows/prizmkit-test/references/service-boundary-test-catalog.md

@@ -1,13 +1,13 @@
 # Service Boundary Test Catalog
 
-Use this catalog during `/prizmkit-test` Phase 4a when generating unit tests for service-like functions or class methods. The goal is to turn "write boundary tests" into service-specific scenarios that match the unit's business responsibility.
+Use this catalog during `/prizmkit-test` Phase 4 and Phase 5 when classifying boundary responsibilities and generating unit tests for service-like functions, integration tests for module boundaries, or API/handler tests for endpoints with business-specific behavior. The goal is to turn "write boundary tests" into service-specific scenarios that match the interface's business responsibility instead of stopping at generic null/empty inputs or happy paths.
 
 ## How to Use This Catalog
 
-1. Classify the tested unit by reading its name, module path, parameters, dependencies, state changes, and related Prizm docs/spec acceptance criteria.
-2. Select every service type that applies. A function can be both a payment service and an idempotency service, or both a repository and pagination service.
+1. Classify the tested unit, module boundary, or endpoint by reading its name, route, method, module path, parameters, request schema, dependencies, state changes, and related Prizm docs/spec acceptance criteria.
+2. Select every service type that applies. A function or endpoint can be both a payment service and an idempotency service, or both a repository and pagination service.
 3. Map candidate boundaries to the actual contract in code/docs. Assert behavior that is specified or clearly implied; if expected behavior is unclear, mark the case as `needs-review` instead of inventing production behavior.
-4. Mock external dependencies for unit tests: databases, network calls, file storage, queues, payment gateways, email providers, clocks, and random ID generators.
+4. Mock external dependencies for unit tests and handler-level tests when the project already uses fake repositories/providers: databases, network calls, file storage, queues, payment gateways, email providers, clocks, and random ID generators.
 5. Record non-applicable categories as `N/A` with a short reason in the boundary coverage report so skipped categories are explicit.
 
 ## Service Type Detection