prizmkit 1.1.140 → 1.1.142

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

@@ -1,285 +1,313 @@
 ---
 name: "prizmkit-test"
-description: "Auditable test-evidence protocol for AI-generated behavior changes. Classifies changes, discovers affected modules and regression rings, models observable behavior and risk, builds project-native tests and contract-driven mocks, validates current-workspace test evidence, preserves content-addressed raw evidence, and deterministically returns TEST_PASS, TEST_FAIL, or TEST_BLOCKED. Use after code/config/schema/dependency changes or when users ask to test, verify, add complete module tests, inspect boundaries, or produce auditable evidence. Supports full-project, module, feature, and scope=this-change. (project)"
+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)"
 ---
 
 # PrizmKit Test
 
-`/prizmkit-test` converts code changes into auditable testing evidence. Completeness means that the affected module's observable behavior, contracts, boundaries, invariants, errors, state transitions, and coupling risks are represented and proven. It does not mean mechanically reaching a line-coverage threshold.
+`/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.
 
-This skill orchestrates each target project's native runners and conventions. It does not install a cross-language test runtime.
+It does not build an evidence package, prove historical TDD order, validate a previous checkout, or manage pipeline/session state.
 
-## Model Choice vs Fixed Evidence Mechanics
+## Atomic Skill Boundary
 
-Choose project-semantic parameters from the target project: framework, commands, cwd, timeout, retry/attempt policy, concurrency, Mock tools, test layers, module boundary, inventory patterns, and environment classification. Do not hard-code ecosystem-specific defaults when the project can decide them.
-
-Fix only the protocol mechanisms needed for safe, replayable evidence: project/evidence/request locators, schema-shaped requests, path confinement, real process execution, complete raw capture, runner-generated receipts, append-only history, and resume invalidation. Read `${SKILL_DIR}/references/trusted-evidence-execution.md` before inventory, execution, resume, or replay; it defines the trust boundary and builder commands. Read `${SKILL_DIR}/references/evidence-request-protocol.md` when authoring any request or authoritative JSON record; it defines request ownership, structured N/A, and the schema map.
-
-## Canonical Evidence Builder Lifecycle
-
-The Main Agent supplies semantic requests only; it does not author authoritative package records. Initialize and drive one evidence directory through the builder in this order:
+The Main Agent owns this invocation from analysis through final report:
 
 ```text
-init → capture-change → inventory → prepare-tests → execute → finalize → validate --attest → resume
+resolve current change and requirement context
+→ discover affected module and Regression Ring
+→ model observable behavior and applicable risks
+→ inspect and add project-native tests
+→ execute and repair valid failures: maximum three rounds
+→ mandatory Main-Agent test review: maximum ten completed rounds
+→ optional independent Test Reviewer: one unit, maximum five responses
+→ final native regression on the exact final state
+→ write test-report.md and test-result.json
+→ return TEST_PASS | TEST_NEEDS_FIXES | TEST_BLOCKED
 ```
 
-Use `${SKILL_DIR}/scripts/build_test_evidence.py` for every lifecycle command:
-
-- `init`: creates the package directories and pins the baseline identity.
-- `capture-change`: captures the complete canonical change, including untracked, deleted, renamed, and copied files; never substitute plain `git diff`. `inventory` then requires its changed-file set to match the capture exactly and rejects stale captures or unaccounted live paths.
-- `inventory`: hashes current source/tests/contracts/lockfiles, rejects category overlap, excludes runtime-only paths, and validates directory roots plus the complete capture-derived changed-file set.
-- `prepare-tests`: discovers repository-native test files from the canonical capture and inventory, generates stable builder-owned test IDs, derives existing/added/modified status, and snapshots only added/modified live test sources.
-- `execute`: runs native project commands and owns `executions.json`, `receipts/`, and `raw/`. Each request uses exactly one binding mode: `test_ids`, `test_paths`, or `auto_bind=true`. The builder infers recognized package-wide or explicit file/directory/glob command scope, blocks opaque commands or mismatched declarations, and persists verified canonical `test_ids` only.
-- `finalize`: derives builder-owned target hashes, runs semantic-record and required-layer checks, rechecks canonical capture freshness, blocks every selected unreliable execution, and owns the payload manifest, verdict, generated-test snapshots, and evidence identity. It leaves the package in a mutable `payload-finalized` state until validator attestation; malformed semantic records fail before package relocation.
-- `render-report`: recovery/debugging command that derives `test-report.md`; normal finalization and attestation render it automatically, and it is never authoritative.
-- `resume`: preserves prior receipts and refuses to rebind an identity-changing package; create a new package after scope/source identity changes.
+After writing its result, this skill returns control to its caller. It must not:
 
-`test-plan.json` is the only source of builder-generated test IDs. An execution request provides exactly one of native `test_paths`, `auto_bind=true`, or canonical `test_ids`; the actual command must expose the same deterministic scope, including all prepared tests for recognized package-wide commands. The builder blocks opaque or mismatched command scope and rewrites verified requests to canonical `test_ids` only before execution. Assess all five layers explicitly, but set `required=true` only when risk requires it; every omitted layer needs structured N/A evidence. The same binding applies test ↔ behavior ↔ execution; current-workspace receipts are the execution evidence.
+- 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.
 
-The builder/validator, not the Main Agent, produces or updates `manifest.json`, `executions.json`, `receipts/*`, `validation.json`, `verdict.json`, `test-report.md`, and `source-change.patch`. Semantic records are authored through schema-shaped requests and must pass the builder preflight before finalization. `validation.json` is produced only by `validate_test_evidence.py --attest`; a package is not a `TEST_PASS` until the second strict validation succeeds.
+## 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. |
+| `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. |
 
-For a formal requirement, `/prizmkit-test` runs after the Main-Agent code-review stage reaches `PASS` and before retrospective:
+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:
 
 ```text
-plan → implement → code-review → test → retrospective → committer
+{artifact_dir}/
+├── test-report.md
+└── test-result.json
 ```
 
-Read `${SKILL_DIR}/references/workflow-state-protocol.md` before reading or updating lifecycle state. Reuse the caller's `artifact_dir`; do not select another recent plan. When an active `orchestrator` is recorded, return the testing result and next-stage metadata to it instead of invoking another skill independently.
-
-## Atomic Stage Boundary
-
-`prizmkit-test` owns only auditable test evidence generation, validation, and the testing-domain verdict. It writes the authoritative `TEST_*` result and `next_stage`, then returns control. When an external orchestrator is active, it must not invoke retrospective or implementation itself. The active orchestrator owns the next-stage invocation and repair routing.
-
+Do not create `.prizmkit/test/evidence/`, manifests, hashes, attestations, package lifecycle records, or test-internal checkpoints.
 
-- behavior-changing source code;
-- runtime configuration, schema, migration, generated-runtime, lockfile, or dependency changes;
-- public interfaces and data contracts;
-- frontend, backend, library, CLI, adapter, and multi-module changes;
-- legacy modules whose observable test coverage is incomplete;
-- explicit test, boundary, evidence, confidence, or audit requests.
+## Context Loading and Scope Resolution
 
-Documentation, comment, and formatting-only scopes use deterministic lightweight verification. They do not receive an unjustified full behavior-test claim.
+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.
+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`.
 
-## Preconditions and Safety
+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.
 
-1. Load `root.prizm`, relevant L1/L2 docs, project manifests, runner configuration, and changed scope once.
-2. Never use production credentials, production databases, production APIs, production queues/storage, or destructive operations against real data.
-3. Preserve complete command/environment/output values as requested. Mark the package `sensitivity=project-controlled`; the project owns access control, retention, and upload policy.
-4. Treat code-level dependencies as mock-first. Real deployed test-environment validation is a separate authorized activity.
-5. Never delete existing tests.
-6. Evidence-protocol recovery is separately bounded: allow at most two package initializations and two semantic preflight failures for one canonical change identity. After the budget is exhausted, return `TEST_BLOCKED`; do not create another versioned package or hand-edit finalized evidence.
-7. For `TEST_FAIL`, classify and persist an evidence-backed `repair_scope` of `test-infrastructure`, `production`, `runtime`, `schema`, `dependency`, `public-interface`, or `unknown`. Test-infrastructure scope routes to implement then test; production-family scope routes to implement, code-review, then test. If evidence cannot support a safe classification, return `TEST_BLOCKED`.
+## Coverage Model
 
-If test infrastructure is missing, the infrastructure preparation state establishes only the necessary project-native infrastructure autonomously. Do not ask the user to install routine test dependencies in a headless run; verify dependency versions before editing manifests.
+Read `${SKILL_DIR}/references/test-coverage-model.md` before designing or reviewing tests.
 
-## Input
+### Affected Business Module
 
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| `scope` | No | `full-project`, `module:<name>`, `feature:<slug>`, or `this-change`. Defaults to `this-change` with a valid artifact directory, otherwise `full-project`. |
-| `artifact_dir` | No | Change artifact containing `spec.md` + `plan.md`; used to resolve acceptance conditions and changed scope. |
-| `changed_files` | No | Explicit changed files; highest-priority scope input. |
-| `diff_base` | No | Git baseline used when `changed_files` is absent. |
-| `evidence_target` | No | Existing evidence ID/directory to validate and resume. |
-| `execution_budget` | No | Bounded time/attempt budget. Incomplete necessary work is `TEST_BLOCKED`, never truncated to pass. |
-| `test_commands` | No | Explicit project-native commands when discovery is ambiguous. |
-
-For `scope=this-change`, determine changed files from `changed_files`, `diff_base`, current diff, artifact plan/context manifest, then spec mapping. Unknown scope is `TEST_BLOCKED`.
+Prefer an explicit project module. If none exists, derive one cohesive boundary from files that jointly implement the same observable responsibility. Cover every discoverable observable behavior of that module, including relevant legacy behavior whose tests are incomplete.
 
-Do not infer a current change artifact from a legacy bug/refactor directory name alone; require explicit `artifact_dir` and changed-file evidence.
+### Regression Ring
 
-## Authoritative Resources
+Expand only along concrete coupling evidence:
 
-Load each resource only on its branch:
+- direct callers;
+- consumers of values, errors, events, files, or ordering;
+- shared schemas, types, protocols, generated assets, and adapters;
+- persistence, cache, lock, queue, transaction, and other shared state dependencies.
 
-- Read `${SKILL_DIR}/references/evidence-protocol.md` before a behavior evidence run or validation/resume decision — it defines state contracts, identity, proof, and verdict semantics.
-- Load `${SKILL_DIR}/assets/evidence-manifest.schema.json` when creating or validating `manifest.json`.
-- Load `${SKILL_DIR}/assets/behavior-risk-matrix.schema.json` during `CONTRACT_MODEL` or matrix validation.
-- Load `${SKILL_DIR}/assets/authoritative-records.schema.json` when creating or validating any other authoritative request/record.
-- Load `${SKILL_DIR}/assets/evidence-package-template.json` when initializing or resuming an evidence directory.
-- Read `${SKILL_DIR}/references/contract-mock-protocol.md` only when dependency, contract, or external-boundary risks require doubles.
-- Read `${SKILL_DIR}/references/test-generation-steps.md` during `INFRA_READY`, `TEST_BUILD`, or `EXECUTE_PROVE`.
-- Read `${SKILL_DIR}/references/service-boundary-test-catalog.md` only when domain boundary signals need risk discovery.
-- Read `${SKILL_DIR}/references/boundary-coverage-protocol.md` when defining module roots, exclusions, Regression Ring, or behavior-risk completeness.
+Do not perform an unconditional repository-wide sweep.
 
-## Required State Machine
+### Behavior and Risks
 
-Execute in this exact order: CHANGE_CLASSIFY, SCOPE_DISCOVER, CONTRACT_MODEL, TEST_PLAN, INFRA_READY, TEST_BUILD, EXECUTE_PROVE, EVIDENCE_PACKAGE, EVIDENCE_VALIDATE. Do not claim a later state complete without valid applicable predecessor outputs.
+Model outside-in from business capability or acceptance criterion to public entry point, rules, invariants, state, side effects, low-level logic, dependencies, and consumers. For each behavior, assess applicable:
 
-### 1. CHANGE_CLASSIFY
-
-Classify the scope as `behavior` or `lightweight` and write `change-classification.json`.
+```text
+functional | boundary | error | state | side-effect | permission
+concurrency | idempotency | time | dependency | consumer
+```
 
-- `behavior`: code, runtime config, schema, migration, generated runtime, dependency, or mixed/uncertain scope; full protocol required.
-- `lightweight`: exclusively docs/comments/formatting with deterministic evidence that runtime behavior cannot change.
+A dimension may be omitted only with a concise behavior-specific reason. Coverage percentages are diagnostic signals, never a completion threshold.
 
-Unknown classification follows the full protocol or becomes `TEST_BLOCKED`.
+### Test Layers
 
-### 2. SCOPE_DISCOVER
+Use the lowest layer that proves a property without losing relevant composition, then add higher layers for composition risk:
 
-Write `scope.json`, `target-inventory.json`, and `source-change.patch`. Use a model-authored inventory request with the bundled builder so actual discovered files are hashed. Record:
+```text
+focused/unit
+→ module/component
+→ contract/integration
+→ code-level E2E when applicable
+→ complete affected-module regression
+→ Regression Ring verification
+```
 
-- changed files, all declared module roots, and evidence-backed exclusions;
-- affected module boundary (`explicit` or `cohesion-derived`);
-- Primary Scope containing all observable behavior of that module;
-- Regression Ring containing direct callers, consumers, shared contracts, and state dependencies, each mapped to planned tests;
-- contract, lockfile, test, and module-boundary discovery evidence;
-- Unresolved Edges for dynamic/unprovable coupling.
+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.
 
-Require every changed file to appear in inventory or a structured exclusion. Inventory and static discovery constrain obvious omissions but cannot deterministically prove semantic completeness; preserve that residual model judgment. Any verdict-capable unresolved edge blocks `TEST_PASS`.
+## Test Construction
 
-### 3. CONTRACT_MODEL
+Read `${SKILL_DIR}/references/test-coverage-model.md` and, when external or cross-module contracts apply, `${SKILL_DIR}/references/external-contract-mock-guidance.md`.
 
-Write `behavior-risk-matrix.json`. Resolve test truth in strict precedence:
+Expected behavior follows this precedence:
 
-1. specifications;
-2. machine-readable contracts;
-3. acceptance conditions;
+1. confirmed specification;
+2. machine-readable contract;
+3. acceptance criteria;
 4. trusted existing tests;
-5. callers/consumers;
+5. callers and consumers;
 6. current implementation.
 
-Unresolved conflicting truth is `TEST_BLOCKED`, not a characterization test.
-
-For every observable behavior, record contract source, preconditions, input classes/boundaries, outputs, side effects, transitions, errors, and functional/boundary/permission/concurrency/idempotency/time/dependency/consumer risks. Every applicable cell maps to tests and executions or remains explicitly unresolved.
+Conflicting higher-precedence truth that cannot be resolved is `TEST_BLOCKED`; do not preserve a possible implementation defect as a characterization test.
 
-Coverage metrics are diagnostic signals only and never substitute for this matrix.
+Tests must:
 
-### 4. TEST_PLAN
+- assert observable outputs, errors, state transitions, side effects, ordering, counts, and absence of partial effects;
+- isolate only dependencies irrelevant to the property being proved;
+- follow project-native naming, location, framework, fixture, and helper conventions;
+- control clocks, randomness, concurrency, synchronization, and fixtures deterministically;
+- verify failure cleanup and useful diagnostics;
+- avoid vacuous assertions and assertions that merely duplicate implementation steps;
+- never delete or weaken a valid existing test just to obtain green output.
 
-Write the semantic preparation request under `requests/` and invoke `prepare-tests`; do not hand-author the resulting `test-plan.json`. Provide only repository-native `project_path` values, behavior mappings, selectors/runner hints, and the five layer decisions. The builder derives test IDs, status, snapshots, and hashes from inventory and canonical Git capture. Assess the ordered execution layers:
+Reuse an adequate existing framework. Add only the smallest necessary project-native infrastructure when a required property cannot otherwise be expressed.
 
-1. focused;
-2. module/component;
-3. contract/integration;
-4. complete affected-module regression;
-5. Regression Ring.
+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.
 
-Every omitted layer uses a structured N/A decision containing rationale, typed evidence, considered signals, and explicit explanations for detected conflicts. The model owns semantic judgment; deterministic validation checks shape and obvious conflicts.
+## Native Execution and Failure Repair
 
-### 5. INFRA_READY
+The target project owns its runner, command, working directory, timeout, concurrency, retry behavior already encoded by the project, coverage tooling, and isolated integration environment. Do not impose an ecosystem-specific command policy.
 
-Discover and reuse native runners and conventions. Install only required dependencies, configure commands, and create fixtures/fakes/contract mock servers/isolated services as needed. Avoid duplicate frameworks and record every infrastructure change and verification in `infrastructure-changes.json`.
+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.
 
-External dependencies use `${SKILL_DIR}/references/contract-mock-protocol.md`. Shared machine-readable contracts are preferred; locally derived contract fixtures must record their source. Independently invented incompatible mocks are rejected.
+A nonzero execution is development feedback, not an immediate workflow stop. Classify it:
 
-### 6. TEST_BUILD
+| 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`. |
+| `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`. |
 
-Fill gaps across the whole affected module's observable behavior, contracts, boundaries, invariants, failure paths, transitions, and coupling risks. Do not test only the changed happy path or unrelated private implementation lines.
+Use at most three execution-failure repair rounds. One round is reproduce → establish truth → repair → focused verification → affected-module and Regression Ring verification. Initial test construction is not a repair round. After the third unsuccessful round:
 
-Minimal behavior-preserving production refactoring is allowed only for test seams such as dependency injection, pure-function extraction, adapters, or controllable state. If testing requires changing a public production contract, issue `TEST_BLOCKED`.
+- known remaining correction → `TEST_NEEDS_FIXES`;
+- unresolved truth, reliability, safety, or environment → `TEST_BLOCKED`.
 
-If a valid test reveals a business/contract defect, do not fix production behavior in this skill. Preserve the evidence for `TEST_FAIL`.
+Never retry until green or weaken scope/assertions to manufacture a pass.
 
-### 7. EXECUTE_PROVE
+## Production Repair Boundary
 
-Run required layers in plan order through `${SKILL_DIR}/scripts/build_test_evidence.py execute`. Use exactly one of `test_paths`, `auto_bind=true`, or canonical `test_ids`; each must exactly match a deterministically inferable native command scope. The builder blocks opaque or mismatched commands and persists verified canonical test IDs before the native command runs. The model selects project-native argv, cwd, timeout, attempts, concurrency, layer, environment classification, and tool probes in schema-shaped requests. The runner performs the actual process execution and appends complete environment/tool versions, raw stdout/stderr hashes, request hash, runner hash, and unique receipt to `executions.json`. Do not accept caller-authored execution JSON and do not retry until green.
+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.
 
-Validate the current implementation directly in the project root:
+Set `review_required=true` and `review_scope=delta` when a repair affects or may affect:
 
-- Run every required layer through the project-native runner; do not create historical checkouts or mutate a second copy of the repository.
-- Bind each applicable behavior risk to planned tests and selected, reliable execution receipts. A passing current-state test is valid evidence even when the historical implementation would also have passed it.
-- Preserve complete runner receipts, raw outputs, request bindings, and replay links. The builder owns execution provenance; the Main Agent does not author receipt records.
-- Required test failures produce `TEST_FAIL`; any selected unreliable execution, missing mapping, unavailable execution, unresolved risk, or budget truncation produces `TEST_BLOCKED`. `TEST_PASS` requires every selected execution to be reliable with exit code zero and every planned test to have a selected reliable zero-exit receipt.
+- public API or observable public behavior;
+- schema, migration, serialization, or generated protocol shape;
+- dependency or lockfile;
+- authorization, identity, secrets, permissions, or tenant isolation;
+- persistence, transaction, data integrity, or concurrency semantics;
+- cross-module contracts or consumer obligations;
+- compatibility guarantees;
+- any change whose locality cannot be established confidently.
 
-TDD history, baseline-failure proof, and mutation sensitivity are outside this skill. This skill validates whether the current implementation satisfies the modeled behavior and risk evidence.
+Record completed repairs and test results, return `TEST_NEEDS_FIXES`, and stop. Do not invoke Code Review or prescribe caller routing from this skill.
 
-### 8. EVIDENCE_PACKAGE
+## Mandatory Main-Agent Test Review
 
-Create `.prizmkit/test/evidence/<evidence-id>/` from the package template with:
+The Main Agent must personally review the complete current production-and-test state after construction and required execution. This responsibility may not be delegated.
 
-- `manifest.json`
-- `change-classification.json`
-- `scope.json`
-- `behavior-risk-matrix.json`
-- `test-plan.json`
-- `infrastructure-changes.json`
-- `executions.json`
-- `verdict.json`
-- `source-change.patch`
-- complete `raw/` stdout/stderr
-- `generated-tests/` snapshots
-- `contracts/` snapshots
-- derived `test-report.md`
+Use at most ten completed rounds. Track report facts:
 
-Hash baseline, diff, inventoried source/tests/contracts/lockfiles, environment, plan, and every evidence file. Evidence files remain individually content-addressed through `manifest.json`. Set `environment_claim=mocked-code-level-only`.
-
-### 9. EVIDENCE_VALIDATE
-
-The validator runs in two passes:
-
-**First pass (pre-check, no `--attest`):**
-
-```bash
-python3 ${SKILL_DIR}/scripts/validate_test_evidence.py \
-  --evidence-dir .prizmkit/test/evidence/<evidence-id> \
-  --project-root <target-project-root>
+```yaml
+main_review_rounds: 0
+accepted_findings: 0
+fixed_findings: 0
+rejected_findings: 0
+unresolved_findings: 0
 ```
 
-The first pass validates the payload while the package remains `payload-finalized`; `validation.json` is intentionally empty until attestation. Builder-derived target hashes and lifecycle records are generated before this check. If this pass finds semantic errors, repair the mutable staging package and rerun finalize; never repair a sealed package.
+Every complete round checks:
 
-The validator checks every authoritative record against its shipped schema, live target inventories, patch/diff binding, changed-file/module-root/exclusion/Regression Ring cross-links, generated-test snapshots, planned-test execution links, runner-generated receipts/request/raw-output hashes, successful behavior-risk mappings, production/unknown external-target safety, and package integrity.
+- missing behavior, acceptance criteria, Regression Ring edges, and applicable risk dimensions;
+- 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;
+- unjustified layer omissions or tests absent from actual native execution;
+- production repairs outside this skill's safe boundary.
 
-### Second pass (attestation)
+For each candidate finding record exactly one decision:
 
-```bash
-python3 ${SKILL_DIR}/scripts/validate_test_evidence.py \
-  --evidence-dir .prizmkit/test/evidence/<evidence-id> \
-  --project-root <target-project-root> \
-  --attest
+```text
+accepted | rejected | unresolved
 ```
 
-`--attest` writes an integrity/protocol attestation into `validation.json`, marks `EVIDENCE_VALIDATE` complete, re-derives `test-report.md`, re-hashes final records in `manifest.json`, seals the package, and then runs a **second** strict validation against the refreshed package. A package is not a `TEST_PASS` until this second strict validation succeeds. Use builder replay when feasible to rerun recorded requests and create new linked receipts. Store validation output. Tampering, schema/identity/hash mismatch, source/test/lockfile drift, missing matrix mappings, wrong execution order, unjustified structured N/A, unresolved risk, or a false real-environment claim fails validation.
+Round behavior:
 
-## Resume and Idempotency
+```text
+accepted = 0 and unresolved = 0
+→ Main-Agent review converged
 
-When interrupted or re-invoked:
+accepted > 0 and rounds remain
+→ repair directly
+→ targeted native verification
+→ next complete review round
 
-1. validate existing manifest, hashes, and stage outputs;
-2. recompute code/test/contract/dependency/environment/plan input hashes;
-3. preserve prior executions and raw output immutably;
-4. invalidate the first changed stage and every downstream result;
-5. resume from the last valid predecessor.
+known correction remains after round ten
+→ TEST_NEEDS_FIXES
 
-For a large module or bounded budget, persist matrix/checkpoint progress and return `TEST_BLOCKED` until complete evidence exists. Never silently reduce scope.
+truth, safety, input, or environment remains unresolved
+→ TEST_BLOCKED
+```
 
-## Terminal Verdicts
+All evidence-based rejections with no unresolved item are normal convergence. Any mutation invalidates prior review and execution of that content.
 
-Only these testing-domain outcomes are valid:
+## Optional Independent Test Reviewer
 
-- `TEST_PASS`: every required module behavior/risk and Regression Ring check is covered by current-workspace tests, required executions pass reliably, no verdict-capable unresolved edge remains, and deterministic validation passes.
-- `TEST_FAIL`: a valid reliable test reproduces an implementation or resolved-contract failure. The authoritative verdict record must include `repair_scope` and enough evidence for the next stage to route safely.
-- `TEST_BLOCKED`: unknown scope, conflicting truth, unavailable/unreliable/flaky necessary execution, incomplete evidence, unmapped tests, budget truncation, or deterministic validation failure.
+Only after Main-Agent review converges, read `${SKILL_DIR}/references/independent-test-review.md` and follow its complete contract.
 
-No conditional pass exists.
+- Create at most one Reviewer for this invocation.
+- Permit at most five responses.
+- Use native continuation of the exact same Reviewer after an accepted correction.
+- The Reviewer is optional and available only when every structural capability in the reference is proven.
+- If capability is unavailable or unproven, create no weaker replacement; record a visible strict downgrade and preserve the converged mandatory Main-Agent review.
+- The Main Agent retains adjudication, mutation, execution, final result, and reporting authority.
+- If response five still contains an accepted correction, return `TEST_NEEDS_FIXES`.
+- 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.
 
-## Workflow State and Handoff
+## External Services and Safety
 
-Before writing state, read `${SKILL_DIR}/references/workflow-state-protocol.md`.
+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.
 
-On `TEST_PASS`, update the active workflow state with `status=TEST_PASS`, `stage_result=TEST_PASS`, and `next_stage=retrospective`. On `TEST_FAIL`, persist the evidence-backed `repair_scope`, set `status=TEST_FAIL` and `stage_result=TEST_FAIL`, and return to implementation; test-infrastructure scope selects `next_stage=implement` with a direct test resume, while production-family scope selects `next_stage=implement` and requires code review before testing again. On `TEST_BLOCKED`, preserve the blocker and any validated finalized evidence paths, do not modify production code speculatively, and return a blocked result. A validator `PASS` means only that the evidence package is structurally valid; it does not mean the testing verdict passed. The authoritative verdict is the validated evidence record; the derived Markdown report is only a compatibility view. If an active orchestrator exists, return the terminal result and `next_stage` to it; do not invoke the next skill independently.
+- Prefer project-owned schemas, generated types, SDK interfaces, fixtures, and documentation.
+- Use approved retrieval of public official documentation only when 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.
 
-## Derived Report and Handoff
+## Final Verification
 
-Generate `test-report.md` from structured evidence using `${SKILL_DIR}/references/test-report-template.md`. It is a replaceable view, not the source of truth. Report only:
+Before writing `TEST_PASS`:
 
-- testing-domain verdict;
-- evidence directory and ID;
-- validator result and key execution pointers;
-- sensitivity and mocked-versus-real warning;
-- authoritative evidence pointers for external automation and interactive consumers.
+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.
 
-Do not embed an independent AI reviewer, decide overall code quality, claim broad Spec compliance, repair a validly detected business defect, authorize commit/release, or perform deployed test/production validation. The derived report is a view; `verdict.json`, validation records, and the evidence manifest remain authoritative.
+## Terminal Results
 
-## Compatibility
+Only these testing-domain outcomes are valid:
 
-Consumers must read authoritative `TEST_*` evidence. During migration, a legacy Markdown report may be used only as a compatibility view after the authoritative verdict has passed validation.
+```text
+TEST_PASS | TEST_NEEDS_FIXES | TEST_BLOCKED
+```
 
-Existing Pipeline and Skill consumers are not migrated by this protocol. Temporary post-install incompatibility with callers expecting the legacy report is accepted and must be stated, not hidden.
+- `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_BLOCKED`: expected truth, safe input, environment, execution reliability, external-target safety, or required review input prevents a safe verdict.
 
-## Examples
+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.
+
+`test-result.json` is a terminal projection, not a checkpoint:
+
+```json
+{
+  "schema_version": 1,
+  "result": "TEST_PASS",
+  "report": "test-report.md",
+  "main_review_rounds": 3,
+  "independent_review": {
+    "status": "completed",
+    "responses": 2,
+    "downgrade_reason": null,
+    "final_state_rechecked": true
+  },
+  "repair_rounds": 1,
+  "production_changed": false,
+  "review_required": false,
+  "review_scope": null,
+  "unresolved_items": []
+}
+```
 
-Read `${SKILL_DIR}/references/examples.md` only when a concrete normal, legacy gap-filling, contract-coupled, failure, blocked, recovery, or tampering example is needed.
+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.
 
-**HANDOFF:** Return the strict testing verdict and structured evidence pointers only.
+**HANDOFF:** Return the testing result plus `test-report.md` and `test-result.json` paths to the caller, then stop.