prizmkit 1.1.153 → 1.1.155

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

@@ -1,13 +1,13 @@
 ---
 name: "prizmkit-test"
-description: "AI-led project-native testing for the complete affected business module and its Regression Ring. Adds comprehensive behavior, boundary, error, state, side-effect, permission, concurrency, idempotency, time, dependency, and consumer tests; repairs valid failures in a bounded loop; performs mandatory Main-Agent review plus one optional strict independent Test Reviewer; and returns TEST_PASS, TEST_NEEDS_FIXES, or TEST_BLOCKED with a human report and minimal terminal result. (project)"
+description: "Test one supplied current change with project-native affected-module and Regression Ring coverage. Use for contract testing, test-double fidelity, consumer/provider compatibility, browser and Full-stack E2E, persistence re-entry, and cross-boundary integration; returns TEST_PASS, TEST_NEEDS_FIXES, or TEST_BLOCKED with stage-owned report/result artifacts. (project)"
 ---
 
 # PrizmKit Test
 
 `/prizmkit-test` is the independent testing stage for the current workspace. It understands the affected business behavior, fills project-native test gaps, executes the tests, repairs valid failures, reviews the final tests, and reports a truthful testing-domain result.
 
-It does not build an evidence package, prove historical TDD order, validate a previous checkout, or manage pipeline/session state.
+It does not build an evidence package, prove historical TDD order, or validate a previous checkout.
 
 ## Atomic Skill Boundary
 
@@ -26,25 +26,21 @@ resolve current change and requirement context
 → return TEST_PASS | TEST_NEEDS_FIXES | TEST_BLOCKED
 ```
 
-After writing its result, this skill returns control to its caller. It must not:
-
-- invoke implementation, Code Review, retrospective, or committer;
-- update a workflow checkpoint or pipeline runtime state;
-- classify an AI CLI session as success, crash, retry, or continuation;
-- decide whether a workflow terminates or resumes;
-- call a testing-domain non-pass result a runtime failure.
+After writing its result, this Skill stops. It owns only testing-local source/test repairs and its two terminal artifacts. It does not invoke another Skill.
 
 ## Inputs and Outputs
 
 | Parameter | Required | Description |
 |---|---|---|
 | `scope` | No | `full-project`, `module:<name>`, `feature:<slug>`, or `this-change`. Defaults to `this-change` when current change context exists, otherwise `full-project`. |
-| `artifact_dir` | No | Active requirement directory containing available specification, plan, and prior review context. Reuse the caller-provided path. |
+| `artifact_dir` | Yes | Exact caller-supplied project-relative directory for the two terminal artifacts and any available specification, plan, and behavior context. Reuse it unchanged. |
 | `changed_files` | No | Explicit current changed paths. Highest-priority scope locator. |
 | `diff_base` | No | Git comparison base when explicit changed paths are absent. |
 | `test_commands` | No | Project-native commands when repository conventions are ambiguous. |
 
-Write exactly two terminal artifacts in `artifact_dir` when it is available; otherwise use a clearly reported caller-visible artifact directory selected from the active request context:
+Resolve `artifact_dir` before Test execution. In interactive use, ask the user to confirm an exact project-relative directory when omitted. In non-interactive use, a missing or unsafe directory is a response-only `TEST_BLOCKED` precondition failure: create no fallback directory or artifact and report that the caller must retry with `artifact_dir`. This precondition rejection is the sole case where terminal files cannot be written because their required identity is absent.
+
+For every invocation that passes input resolution, write exactly two terminal artifacts in the supplied `artifact_dir`:
 
 ```text
 {artifact_dir}/
@@ -52,16 +48,16 @@ Write exactly two terminal artifacts in `artifact_dir` when it is available; oth
 └── test-result.json
 ```
 
-Do not create `.prizmkit/test/evidence/`, manifests, hashes, attestations, package lifecycle records, or test-internal checkpoints.
+Do not create `.prizmkit/test/evidence/`, manifests, hashes, attestations, package state records, or test-internal checkpoints.
 
 ## Context Loading and Scope Resolution
 
 1. Reuse current requirement and workspace context already loaded by the Main Agent.
 2. Load `root.prizm`, the relevant module indexes, and the applicable detail docs before modifying source or tests.
 3. Inspect current staged, unstaged, untracked, deleted, and renamed paths. Changed lines locate impact but never define completeness.
-4. Read the available specification, acceptance criteria, plan, and prior review only as needed to establish expected behavior.
+4. Read the available specification, acceptance criteria, plan, and caller-supplied behavior context only as needed to establish expected behavior.
 5. Inspect manifests, runner configuration, CI conventions, existing test assertions, fixtures, fakes, mocks, contracts, and coverage support.
-6. If necessary scope cannot be determined safely, report the precise missing input and return `TEST_BLOCKED`.
+6. If necessary scope cannot be determined safely, report the precise missing input and return `TEST_BLOCKED` in the resolved artifact pair.
 
 Do not infer the active requirement solely from the name of an old artifact directory. Do not use a historical worktree, second checkout, mutation proof, baseline-failure proof, or test overlay.
 
@@ -101,29 +97,29 @@ Use the lowest layer that proves a property without losing relevant composition,
 
 ```text
 focused/unit
-→ module/component
-→ contract/integration
-→ code-level E2E when applicable
+→ module/component or UI component
+→ consumer/provider contract or integration
+→ Mock Browser or Full-stack E2E according to actual composition
 → complete affected-module regression
 → Regression Ring verification
 ```
 
-Do not mechanically test every private function. Add direct focused tests for critical low-level logic when complexity, boundaries, risk, or failure localization justify them; otherwise prove it through public behavior.
+Browser execution alone is not Full-stack E2E. Do not mechanically test every private function. Add direct focused tests for critical low-level logic when complexity, boundaries, risk, or failure localization justify them; otherwise prove it through public behavior.
 
 ## Test Construction
 
-Read `${SKILL_DIR}/references/test-coverage-model.md` and, when external or cross-module contracts apply, `${SKILL_DIR}/references/external-contract-mock-guidance.md`.
+Read `${SKILL_DIR}/references/test-coverage-model.md` and, whenever serialization, a producer-consumer boundary, or any test double replaces a producer or consumer, `${SKILL_DIR}/references/boundary-contract-and-test-double-guidance.md`.
 
-Expected behavior follows this precedence:
+Expected behavior follows boundary-specific authority:
 
-1. confirmed specification;
-2. machine-readable contract;
-3. acceptance criteria;
-4. trusted existing tests;
-5. callers and consumers;
-6. current implementation.
+1. confirmed specification and acceptance criteria;
+2. machine-readable wire contract;
+3. traceably generated type, client, server stub, or fixture;
+4. provider raw-wire contract evidence or authorized isolated observation;
+5. provider implementation, locked SDK behavior, and matching official documentation;
+6. trusted existing tests, callers and consumers, consumer-local types/fixtures/mocks, and other current implementation evidence.
 
-Conflicting higher-precedence truth that cannot be resolved is `TEST_BLOCKED`; do not preserve a possible implementation defect as a characterization test.
+Lower-authority material cannot override higher-authority truth or prove a property outside its boundary. Conflicts that cannot be resolved are `TEST_BLOCKED`; do not preserve a possible implementation defect as a characterization test.
 
 Tests must:
 
@@ -135,6 +131,20 @@ Tests must:
 - avoid vacuous assertions and assertions that merely duplicate implementation steps;
 - never delete or weaken a valid existing test just to obtain green output.
 
+## Boundary Contract and Composition Gate
+
+A test cannot prove a property that depends on production composition it replaces. Before test construction and again before `TEST_PASS`:
+
+1. Inventory every verdict-relevant mock, fake, fixture, route interception, mock server, container, emulator, or isolated service that crosses or replaces a producer-consumer boundary.
+2. Record its producer, consumer, boundary/protocol, contract authority, fidelity proof, composition removed, property not proven, composition-preserving test, and remaining risk.
+3. Treat consumer-local types, fixtures, and mocks as expectations, not provider truth, unless they are generated from or validated against the authoritative boundary contract.
+4. Classify tests by actual composition. An API-intercepted browser test is a Mock Browser Test, not Full-stack E2E.
+5. Require risk-relevant Provider Contract Tests to inspect raw wire payload before provider-owned deserialization.
+6. For any verdict-capable serialization or multi-layer risk in removed composition, require provider/consumer contract evidence, a composition-preserving integration test, or a Full-stack path appropriate to the risk and keeping the defect-bearing boundary real.
+7. For state-changing workflows, verify commit point, cancellation, pending/duplicate protection, failure recovery, reload or re-entry, retry/conflict/idempotency, and downstream consumption.
+
+If required composition-preserving evidence cannot run in a proven safe isolated environment, return `TEST_BLOCKED`. Never substitute a lower-layer green test or downgrade the proof requirement.
+
 Reuse an adequate existing framework. Add only the smallest necessary project-native infrastructure when a required property cannot otherwise be expressed.
 
 Minimal behavior-preserving testability seams are allowed, including dependency injection through an existing abstraction, pure-function extraction, an internal adapter, or controllable clock/randomness/state. Classify any production change under the repair boundary below.
@@ -145,13 +155,13 @@ The target project owns its runner, command, working directory, timeout, concurr
 
 During construction and repair, run the smallest relevant tests first. Before a pass decision, run all required layers, the complete affected-module regression, the Regression Ring, and project-wide regression when concrete coupling or project convention requires it.
 
-A nonzero execution is development feedback, not an immediate workflow stop. Classify it:
+A nonzero execution is testing feedback, not an immediate terminal result. Classify it:
 
 | Classification | Action |
 |---|---|
 | `test-defect` | Repair the test, fixture, mock, import, syntax, or test infrastructure. |
 | `local-production-defect` | Repair the proven internal implementation defect when public and cross-module contracts remain unchanged. |
-| `high-risk-production-defect` | Repair only when safe, then require delta Code Review and return `TEST_NEEDS_FIXES`. |
+| `high-risk-production-defect` | Do not repair it in this invocation; record the proven defect and return `TEST_NEEDS_FIXES`. |
 | `environment-unavailable` | Return `TEST_BLOCKED` with the unavailable safe prerequisite. |
 | `truth-unresolved` | Return `TEST_BLOCKED`; never guess the assertion. |
 | `flaky-or-unreliable` | Diagnose within budget; otherwise return `TEST_BLOCKED`. |
@@ -165,9 +175,9 @@ Never retry until green or weaken scope/assertions to manufacture a pass.
 
 ## Production Repair Boundary
 
-A repair may close inside this skill only when evidence establishes that it is limited to private/internal implementation, a behavior-preserving algorithm correction, test infrastructure, a behavior-preserving testability seam, or local error handling with unchanged public obligations.
+A repair may close inside this Skill only when evidence establishes that it is limited to private/internal implementation, a behavior-preserving algorithm correction, test infrastructure, a behavior-preserving testability seam, or local error handling with unchanged public obligations.
 
-Set `review_required=true` and `review_scope=delta` when a repair affects or may affect:
+Do not perform the repair in this invocation when it affects or may affect:
 
 - public API or observable public behavior;
 - schema, migration, serialization, or generated protocol shape;
@@ -178,7 +188,7 @@ Set `review_required=true` and `review_scope=delta` when a repair affects or may
 - compatibility guarantees;
 - any change whose locality cannot be established confidently.
 
-Record completed repairs and test results, return `TEST_NEEDS_FIXES`, and stop. Do not invoke Code Review or prescribe caller routing from this skill.
+Record the defect evidence and required correction, return `TEST_NEEDS_FIXES`, and stop. Do not prescribe or execute work outside this testing invocation.
 
 ## Mandatory Main-Agent Test Review
 
@@ -200,7 +210,10 @@ Every complete round checks:
 - critical low-level boundary logic;
 - incorrect truth precedence or expected behavior;
 - weak, vacuous, implementation-only, nondeterministic, or flaky assertions;
-- over-mocking, invented contracts, and missing negative side-effect assertions;
+- complete boundary/test-double inventory, boundary-appropriate authority, fidelity proof, and consumer-authored ideal fixtures not being treated as provider truth;
+- Provider raw-wire assertions, test-layer labels matching actual composition, and Browser Tests with intercepted critical APIs not being called Full-stack E2E;
+- any test that would still pass with the target defect, any verdict-capable composition removed without preserving evidence, and missing negative side-effect assertions;
+- state-changing workflow commit, cancellation, failure recovery, reload/re-entry, retry/conflict/idempotency, and repeated-operation coverage;
 - unjustified layer omissions or tests absent from actual native execution;
 - production repairs outside this skill's safe boundary.
 
@@ -244,17 +257,17 @@ Only after Main-Agent review converges, read `${SKILL_DIR}/references/independen
 - If response five still contains unresolved truth, input, or safety, return `TEST_BLOCKED`.
 - Never claim `TEST_PASS` for a final mutation that was not independently rechecked when independent review had already begun, unless the reference's strict downgrade rule establishes the permitted Main-Agent fallback.
 
-## External Services and Safety
+## Boundary Contracts and External Safety
 
-Read `${SKILL_DIR}/references/external-contract-mock-guidance.md` whenever an external service, persistence boundary, queue, filesystem, generated client, or cross-module endpoint affects the tested property.
+Read `${SKILL_DIR}/references/boundary-contract-and-test-double-guidance.md` for internal and external APIs, cross-module endpoints, persistence, queues, filesystems, caches, generated clients/servers, and any test double replacing a producer or consumer.
 
-- Prefer project-owned schemas, generated types, SDK interfaces, fixtures, and documentation.
-- Use approved retrieval of public official documentation only when project artifacts are insufficient.
+- Select authority for the property at the actual boundary; a database schema does not independently prove HTTP or message serialization.
+- Use approved retrieval of public official documentation only when higher-authority project artifacts are insufficient.
 - Never expose secrets, private source, proprietary payloads, or repository-private data during retrieval.
 - Never use production credentials, production databases/APIs/queues/storage, real user data, or destructive external operations.
 - If an endpoint cannot be proven non-production, do not connect to it.
-- Use contract-backed local fakes, mocks, fixtures, mock servers, containers, or project-owned isolated services.
-- Record necessary unverified external behavior as a remaining risk or `TEST_BLOCKED` when it prevents the verdict.
+- Use contract-backed local doubles or project-owned isolated services only within their stated proof boundary.
+- Missing fidelity or composition evidence that affects the verdict produces `TEST_BLOCKED`, not a conditional pass.
 
 ## Final Verification
 
@@ -262,11 +275,13 @@ Before writing `TEST_PASS`:
 
 1. Main-Agent review converged on the exact final state.
 2. Independent review converged or was strictly and visibly downgraded under its capability contract.
-3. Every required focused, module, contract/integration, applicable E2E, affected-module, and Regression Ring test passes reliably.
-4. Any required project-wide regression passes.
-5. No accepted correction, unresolved finding, verdict-capable scope edge, or required environment check remains.
-6. No high-risk production repair awaits delta Code Review.
-7. No mutation occurred after the final applicable review and execution.
+3. Every required focused, module/component, consumer/provider contract, integration, actual-composition E2E, affected-module, and Regression Ring test passes reliably.
+4. Every verdict-relevant test double has boundary-appropriate authority and fidelity proof, and every test-layer claim matches actual composition.
+5. Every verdict-capable property in removed composition has composition-preserving evidence; applicable Provider Contract Tests assert raw wire output and state-changing workflows cover the required lifecycle.
+6. Any required project-wide regression passes.
+7. No accepted correction, unresolved finding, verdict-capable scope edge, missing fidelity/composition proof, or required environment check remains.
+8. No high-risk production defect or correction remains.
+9. No mutation occurred after the final applicable review and execution.
 
 ## Terminal Results
 
@@ -276,15 +291,15 @@ Only these testing-domain outcomes are valid:
 TEST_PASS | TEST_NEEDS_FIXES | TEST_BLOCKED
 ```
 
-- `TEST_PASS`: final reviewed state passes every required native test and no high-risk repair awaits review.
-- `TEST_NEEDS_FIXES`: a known correction remains, a review/repair budget did not converge, or a completed high-risk repair requires delta Code Review.
+- `TEST_PASS`: final reviewed state passes every required native test and no high-risk correction remains.
+- `TEST_NEEDS_FIXES`: a known correction remains or a testing-local review/repair budget did not converge.
 - `TEST_BLOCKED`: expected truth, safe input, environment, execution reliability, external-target safety, or required review input prevents a safe verdict.
 
 No conditional pass exists.
 
 ## Terminal Report and Result
 
-Read `${SKILL_DIR}/references/test-report-template.md` before finalization. Write `test-report.md` and `test-result.json` together for every terminal outcome. The report must use the exact canonical `## Final Result` section and `- Result: <TEST_*>` marker from that template; do not rename it to `Terminal Result`, `Final Decision`, or another heading.
+Read `${SKILL_DIR}/references/test-report-template.md` before finalization. After required input resolution, write `test-report.md` and `test-result.json` together for every terminal outcome. The report must use the exact canonical `## Final Result` section and `- Result: <TEST_*>` marker from that template; do not rename it to `Terminal Result`, `Final Decision`, or another heading.
 
 `test-result.json` is a terminal projection, not a checkpoint:
 
@@ -302,12 +317,10 @@ Read `${SKILL_DIR}/references/test-report-template.md` before finalization. Writ
   },
   "repair_rounds": 1,
   "production_changed": false,
-  "review_required": false,
-  "review_scope": null,
   "unresolved_items": []
 }
 ```
 
-Allowed `independent_review.status` values are `completed`, `downgraded`, and `not_applicable`. `completed` requires one through five responses and `final_state_rechecked=true`; `downgraded` requires zero responses, a non-empty reason, and `final_state_rechecked=false`; `not_applicable` requires zero responses, no reason, and `final_state_rechecked=false`. `review_scope` is `delta` only when `review_required=true`; otherwise it is null. The report and JSON must agree on result, review requirement, and unresolved items. If consistency cannot be established, write a truthful `TEST_BLOCKED` result rather than fabricating pass.
+Allowed `independent_review.status` values are `completed`, `downgraded`, and `not_applicable`. `completed` requires one through five responses and `final_state_rechecked=true`; `downgraded` requires zero responses, a non-empty reason, and `final_state_rechecked=false`; `not_applicable` requires zero responses, no reason, and `final_state_rechecked=false`. `TEST_PASS` requires an empty `unresolved_items`; each non-pass result requires at least one exact unresolved correction or blocker. The report and JSON must agree on result, production-change diagnostics, and unresolved items. If consistency cannot be established, write a truthful `TEST_BLOCKED` result rather than fabricating pass.
 
-**HANDOFF:** Return the testing result plus `test-report.md` and `test-result.json` paths to the caller, then stop.
+Return only the testing result, `test-report.md`/`test-result.json` paths, execution summary, repair diagnostics, and unresolved items.

package/bundled/skills/prizmkit-test/references/boundary-contract-and-test-double-guidance.md

@@ -0,0 +1,206 @@
+# Boundary Contract and Test Double Guidance
+
+## Purpose
+
+Apply one contract discipline to every serialized or producer-consumer boundary, whether internal or external: browser/backend APIs, cross-module endpoints, persistence, queues, filesystems, caches, generated clients/servers, SDK providers, and any test double that replaces a producer or consumer.
+
+Mocks are test tools, not proof of provider behavior or a deployed environment. Consumer-local types, fixtures, and mocks are expectations, not provider truth. A test cannot prove a property that depends on production composition it replaces.
+
+## Boundary-Specific Contract Authority
+
+Choose the highest authority that actually defines the property at the tested boundary:
+
+1. confirmed specification;
+2. machine-readable wire contract, such as OpenAPI, JSON Schema, Protocol Buffers, GraphQL, or AsyncAPI;
+3. type, client, server stub, or fixture that is traceably generated from that contract;
+4. provider raw-wire contract test or explicitly authorized isolated provider observation;
+5. provider implementation, version-locked SDK behavior, and matching public official service documentation;
+6. consumer-local types, existing tests, historical fixtures, and mocks.
+
+Lower-authority material cannot override higher-authority material. A generated artifact must retain traceable provenance. A database schema can define applicable persistence structure and constraints, but a database schema cannot independently prove network serialization. Current provider implementation is evidence, not automatic product truth when it conflicts with a higher-authority contract.
+
+Use the current locked/provider version when behavior differs by version. Record the source path, public URL, document/version identifier, generated provenance, raw-wire test, or isolated observation used in `test-report.md`.
+
+Never invent fields, statuses, error shapes, retry rules, pagination behavior, ordering, or timing guarantees without a traceable source. If authorities conflict and expected behavior cannot be resolved safely, return `TEST_BLOCKED`.
+
+## Safe Documentation Retrieval
+
+Public official service documentation retrieval may be used only to read the minimum contract material needed for tests.
+
+- Do not send source code, repository-private content, proprietary payloads, secrets, credentials, or user data to a public endpoint.
+- Prefer a project-local or vendored source when it is authoritative.
+- Distinguish official provider documentation from blogs, examples, forum answers, and third-party tutorials.
+- When official sources conflict with the project's pinned generated client or schema, apply the skill's truth precedence and report the conflict.
+- If the required contract cannot be established, return `TEST_BLOCKED` when it prevents a safe verdict.
+
+## Boundary and Test-Double Inventory
+
+Inventory every test double that crosses or replaces a producer-consumer boundary, including mocks, fakes, fixtures, route interceptions, mock servers, containers, emulators, and isolated services. Record:
+
+| Field | Required Content |
+|---|---|
+| Producer | Component that creates the value, message, file, state, or response. |
+| Consumer | Component that parses, reads, maps, or acts on it. |
+| Boundary type | Internal/external API, module, persistence, queue, filesystem, cache, generated client/server, or other boundary. |
+| Serialization or protocol | JSON, HTTP, event/message, database encoding, file format, RPC, or other wire form. |
+| Contract authority | Boundary-appropriate source and provenance from the authority order. |
+| Test Double | Mock, fake, fixture, interception, server, container, emulator, or isolated service. |
+| Fidelity proof | Generation, schema validation, shared raw-wire fixture, contract framework, or authorized isolated observation. |
+| Composition removed | Serializer, adapter, network, provider, persistence, process, or other production component replaced. |
+| Property not proven | Behavior that depends on the removed composition. |
+| Composition-preserving test | Contract, integration, or Full-stack path that keeps the verdict-relevant combination real. |
+| Remaining risk | Unproven behavior and its effect on the verdict. |
+
+A boundary with no test double still records its authority and the composition-preserving test when that boundary affects the verdict.
+
+## Test-Double Fidelity Proof
+
+A cross-boundary test double is fidelity-proven only when at least one of these applies:
+
+- generated from the authoritative contract with provenance;
+- validated against the authoritative schema during tests;
+- shared with a provider raw-wire contract test that validates the same fixture;
+- captured through an explicitly authorized isolated provider observation with source/version provenance;
+- checked by the project's consumer/provider contract framework.
+
+A consumer-authored ideal fixture without one of these proofs may support local UI or logic tests, but it does not count as provider compatibility evidence. Record its proof boundary explicitly.
+
+## Build the Smallest Faithful Double
+
+Use the target project's existing fake, fixture, mock library, mock server, container, or isolated service when adequate. Model only behavior relevant to the affected module, but preserve the contract property being tested.
+
+Applicable variants include:
+
+- normal success;
+- empty success;
+- minimum, maximum, pagination, cursor, or size boundary;
+- malformed or contract-invalid response;
+- timeout or cancellation;
+- rate limiting or quota rejection;
+- authentication or authorization rejection;
+- transient service failure;
+- permanent service failure;
+- partial response or interrupted stream;
+- retry, replay, and idempotency behavior;
+- transaction, constraint, rollback, or conflict behavior for stateful services.
+
+Do not require every variant mechanically. Select variants from the actual behavior/risk model and explain material omissions.
+
+## Assertions
+
+Assert the application's observable handling of the contract:
+
+- outbound request shape, required headers or metadata, and serialization;
+- response mapping, nullability, enum and format handling;
+- retry count and retryable versus permanent classification;
+- timeout and cancellation propagation;
+- pagination and cursor behavior;
+- idempotency and side-effect counts;
+- state transition, rollback, cleanup, and absence of partial effects;
+- consumer-visible error type or result.
+
+A mock-success-only test is insufficient when dependency failure can change observable behavior.
+
+### Provider Raw-Wire Assertions
+
+A Provider Contract Test for an HTTP response, message, event, file, cache value, or other serialized output must inspect the raw wire payload before any provider-owned model rehydrates it. Select risk-relevant assertions for:
+
+- required, optional, omitted, `null`, empty, and zero values;
+- field names, scalar types, enums, formats, timestamps, and default/omission behavior;
+- status or result code, error envelope, required headers, and metadata;
+- exact bytes or encoding when consumers depend on them.
+
+Deserializing output back into the provider's own model is not sufficient because defaults and zero values can conceal missing fields, nullability changes, or serializer-tag drift.
+
+## Avoid Over-Mocking
+
+Keep production composition real when that composition is the property under test. Mock at a stable external boundary rather than mocking the method being verified or every internal collaborator.
+
+Reject a double when it:
+
+- repeats the current implementation instead of the external contract;
+- bypasses serialization, mapping, retries, or state transitions under test;
+- returns impossible provider behavior;
+- asserts only that a mock was called without proving the business result;
+- silently drifts from the project or official contract.
+
+Use contract/integration or isolated infrastructure tests when a mock cannot preserve the relevant transaction, protocol, or composition property.
+
+## Test Layer Taxonomy
+
+Classify a test by the production composition it actually executes, not by runner or user-interface presence:
+
+| Layer | Critical Provider Replaced? | Proof Capability |
+|---|---:|---|
+| Focused / Unit Test | yes | Local logic, boundaries, and deterministic errors. |
+| UI Component Test | yes | Component rendering and interaction under supplied data. |
+| Mock Browser Test | yes | Browser UI workflow under intercepted or fixture-backed boundaries. |
+| Consumer Contract Test | contract-validated double | Consumer handling of the authoritative contract. |
+| Provider Contract Test | not applicable | Provider raw wire behavior at its serialization boundary. |
+| Integration Test | no for the combination under test | The named modules or infrastructure composed together. |
+| Full-stack E2E | no for critical production boundaries | Complete user path across real application layers in safe isolation. |
+
+Browser execution alone does not make a test Full-stack E2E. A browser test that intercepts a critical API is a Mock Browser Test and cannot prove browser/backend compatibility, provider serialization, persistence, or reload behavior.
+
+## Composition-Preserving Verdict Rule
+
+Locate each material risk in the combination where the defect can occur. Preserve that combination for risks involving consumer/provider serialization, UI/API behavior, API/persistence behavior, generated client/server compatibility, queue producer/consumer behavior, filesystem writer/reader behavior, cache producer/consumer behavior, or transaction/lock/retry/recovery state.
+
+Lower layers may diagnose a defect, but they cannot supply verdict evidence for a property that their doubles remove. Before `TEST_PASS`:
+
+1. identify every verdict-capable risk located in removed composition;
+2. require a provider contract, consumer contract plus provider raw-wire evidence, composition-preserving integration test, or Full-stack E2E path that proves the property without replacing that composition;
+3. verify the preserving test would fail while the target defect exists;
+4. record the preserving evidence and remaining risk in the report.
+
+If required composition-preserving verification cannot run in a proven safe isolated environment, return `TEST_BLOCKED`. Do not substitute a lower-layer green result or relabel a Mock Browser Test as E2E.
+
+## Databases and Stateful Services
+
+Prefer project-provided isolated infrastructure, a faithful local fake, or a disposable service. Derive structure and constraints from schemas, migrations, models, or official protocol contracts.
+
+Any disposable resource must have:
+
+- a unique non-production identity;
+- bounded lifetime;
+- deterministic setup;
+- verified cleanup;
+- no dependency on production credentials or data.
+
+Test relevant constraints, transactions, rollback, concurrency, idempotency, and failure mapping. Cleanup failure that undermines reliability produces `TEST_BLOCKED`.
+
+## Production and Data Prohibitions
+
+Never use:
+
+- production credentials or tokens;
+- production databases, APIs, queues, object storage, caches, or services;
+- real customer or user data;
+- a target whose non-production status cannot be established;
+- destructive operations against external data.
+
+Project configuration may be reused only when it demonstrably selects a safe isolated test target. If safety cannot be proven, do not connect; report the unexecuted check and return `TEST_BLOCKED` when it is necessary for the verdict.
+
+## Reporting
+
+For every verdict-relevant boundary or test double, complete the Boundary and Test-Double Inventory fields. Distinguish local/unit, consumer-contract, provider-contract, integration, Mock Browser, and Full-stack evidence. State whether a composition-preserving test exists and whether any missing proof changes the verdict.
+
+Also record:
+
+- variants exercised;
+- production resources used: `no`;
+- unresolved fidelity or deployed-environment risk.
+
+Do not claim that a local mock, fake, contract snapshot, container, isolated service, or Mock Browser Test verifies composition it replaces or a deployed production environment.
+
+## Generic Composition Example
+
+For a browser reading a provider response:
+
+1. Treat the machine-readable wire contract as the response-shape authority.
+2. Add a Provider Contract Test that asserts the raw serialized response, including a risk-relevant omitted or null field.
+3. Validate the Consumer Contract Test fixture against the same contract or share the provider-validated fixture.
+4. Classify a route-intercepted browser flow as a Mock Browser Test; it proves UI behavior under that fixture but not live browser/provider compatibility.
+5. Add a safe integration or Full-stack E2E path that keeps browser mapping, provider serialization, and required persistence real when those components contain the verdict-capable risk.
+
+The field names and protocol vary by project; the authority, fidelity, proof-boundary, and composition reasoning remain the same.

package/bundled/skills/prizmkit-test/references/independent-test-review.md

@@ -18,7 +18,7 @@ Main Agent builds and executes project-native tests
 → TEST_PASS | TEST_NEEDS_FIXES | TEST_BLOCKED
 ```
 
-Keep at most one Reviewer active for this invocation and permit at most one replacement. Prefer native continuation and never reuse a Reviewer from another lifecycle stage. A compliant replacement may continue the same shared response budget only with complete latest state, never only a conversation summary.
+Keep at most one Reviewer active for this invocation and permit at most one replacement. Prefer native continuation and never reuse a Reviewer from another invocation. A compliant replacement may continue the same shared response budget only with complete latest state, never only a conversation summary.
 
 ## Host Capability Gate
 
@@ -50,7 +50,7 @@ Rules:
 
 ## Stage-Specific Review Input
 
-Resolve exact requirement identity from workflow state or explicit handoff on every response:
+Use the exact caller-supplied testing identity on every response:
 
 ```text
 artifact_dir: [EXACT_ARTIFACT_DIR]
@@ -67,9 +67,9 @@ The Main Agent supplies:
 - exact artifact, spec, and plan paths plus current contents;
 - complete current production-and-test change;
 - affected business module, observable behaviors, applicable risks, and Regression Ring;
-- existing, added, and modified tests, fixtures, mocks, schemas, contracts, and selected layers;
+- existing, added, and modified tests, fixtures, mocks, schemas, contracts, selected layers, and the complete boundary/test-double inventory with authority, fidelity, removed composition, proof limits, preserving evidence, and verdict impact;
 - native test commands and results executed by Main Agent;
-- test-stage repairs;
+- testing-local repairs;
 - response number and total budget;
 - prior adjudication and actual corrections on continuation or replacement.
 
@@ -100,7 +100,7 @@ Execution boundaries:
 - Complete this review personally.
 - Do not create, schedule, resume, continue, request, or coordinate another execution unit.
 - Do not ask the Main Agent to create a helper.
-- Do not re-enter orchestration, delegation, another review workflow, or an equivalent process.
+- Do not re-enter delegation or another review process.
 - Do not modify, create, delete, rename, stage, commit, or otherwise mutate files.
 - Do not execute shell, Git, tests, builds, network calls, external processes, or any operation that can change state.
 - Use read-only checkout access only for concrete module, caller, consumer, schema, type, configuration, fixture, test, or contract coupling.
@@ -119,13 +119,20 @@ First validate input consistency. Then review:
 - selection of focused, module, contract/integration, applicable E2E, module-regression, and Regression Ring layers;
 - assertion strength and observable effect;
 - vacuous or false-positive tests and tests that cannot fail for the intended defect;
-- over-mocking or removal of production composition;
-- mock fidelity to project or public official contracts;
+- every producer-consumer boundary and test double having boundary-appropriate contract authority and fidelity proof;
+- any consumer-authored ideal fixture being treated only as consumer expectation unless independently contract-validated;
+- Provider Contract Tests containing raw Provider serialization evidence, including risk-relevant omitted, null, empty, zero, type, and field-name behavior;
+- each Browser Test being classified from actual production composition, with intercepted critical APIs classified as Mock Browser rather than Full-stack E2E;
+- no test claim exceeding the property its test double can prove and no verdict-capable composition being removed without preserving contract, integration, or Full-stack evidence;
+- each relevant test being able to fail while the target defect exists;
+- state-changing workflows covering commit, cancellation, failure recovery, reload or re-entry, retry/conflict/idempotency, and repeated operation semantics;
 - nondeterminism and flakiness risk;
 - native execution results matching the declared scope;
-- production repairs that require delta Code Review;
+- production defects or attempted repairs outside the permitted testing-local repair boundary;
 - remaining risks being stated honestly.
 
+Return `CORRECTION_NEEDED` when a verdict-relevant producer-consumer combination is replaced by a test double without authoritative fidelity proof and composition-preserving evidence, or when a test-layer claim exceeds the actual composition executed.
+
 Do not rewrite the requirement, modify code, execute tests, or perform broad exploration.
 Return exactly one result using the Reviewer Output Protocol.
 ```
@@ -159,7 +166,7 @@ All initial execution boundaries and the Reviewer Output Protocol remain mandato
 
 ## Reviewer Output Protocol
 
-Return exactly one form. Do not add severity, confidence, dimension, workflow routing, or acceptance fields.
+Return exactly one form. Do not add severity, confidence, dimension, caller routing, or acceptance fields.
 
 ### No Correction Needed
 
@@ -262,6 +269,7 @@ Record:
 - each response number `1..5`, input identity, result, and correction count;
 - every Main-Agent adjudication and its evidence;
 - actual repair and native verification;
+- boundary authority/fidelity, removed-composition, proof-limit, preserving-evidence, layer-classification, and mutation-lifecycle corrections;
 - whether the exact final state was independently rechecked;
 - capability basis, continuation mode (`native`, `replacement`, `mixed`, or `not-applicable`), and replacement count.