prizmkit 1.1.120 → 1.1.122

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

@@ -1,224 +1,229 @@
 ---
 name: "prizmkit-test"
-description: "Risk-triggered full-stack test generation and orchestration. Detects architecture, runs existing tests, analyzes coverage gaps, generates missing unit/integration/E2E tests, validates boundary coverage, and writes a unified report. Use after development when behavior, public interfaces, data models, security/permission/payment logic, deployment readiness, or user-requested quality verification warrants testing. Supports full-project, module, feature selection, and generic change-artifact `scope=this-change`. Trigger on: 'test', 'run tests', 'verify code', 'quality check', 'test coverage', 'boundary tests', 'edge cases', 'add tests'. (project)"
+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, proves tests differentially, 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)"
 ---
 
 # PrizmKit Test
 
-A risk-triggered test generation and orchestration skill. It discovers existing tests, runs them, compares coverage against project interfaces and task acceptance criteria, generates missing tests, validates business-specific boundary coverage, and produces a unified report.
+`/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 not mandatory for every lifecycle path. Run it when risk or user intent warrants verification.
+This skill orchestrates each target project's native runners and conventions. It does not install a cross-language test runtime.
 
-### When to Use
-- Behavior changes that need verification
-- Public API/interface changes
-- Data model, schema, migration, persistence, or serialization changes
-- Security, permission, authentication, payment, billing, entitlement, or ownership logic
-- Deployment readiness checks
-- First-time test generation for a project with a test framework
-- User says "test", "run tests", "verify", "quality check", "add tests", or asks about coverage/boundaries
+## Model Choice vs Fixed Evidence Mechanics
 
-### When NOT to Use
-- Pure documentation edits
-- Formatting-only changes
-- Internal renames with no behavior impact
-- Tiny config tweaks with no runtime behavior change
-- Project has no test framework and no code to test
+Choose project-semantic parameters from the target project: framework, commands, cwd, timeout, retry/attempt policy, concurrency, Mock tools, test layers, module boundary, inventory patterns, mutation technology, and environment classification. Do not hard-code ecosystem-specific defaults when the project can decide them.
 
-## Precondition
+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 chained receipts, hash binding, append-only history, differential isolation/cleanup, and resume invalidation. Read `${SKILL_DIR}/references/trusted-evidence-execution.md` before inventory, execution, differential proof, 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.
 
-| Required State | Check | If Missing |
-|---|---|---|
-| `.prizmkit/prizm-docs/root.prizm` exists | File exists | Run `/prizmkit-init` first |
-| Test framework installed | Dependency in package.json or equivalent | Offer to skip, install manually, or generate a plan to add tests |
+## When to Use
 
-If Prizm docs may be stale, warn that gap analysis accuracy depends on current docs. Continue only if the user accepts the risk or the run uses explicit changed files.
+Use for:
 
-## Scope Model
+- 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.
 
-| Scope | Meaning |
-|---|---|
-| `full-project` | Analyze and test the whole project. |
-| `module:<name>` | Analyze one module from Prizm docs. |
-| `feature:<slug>` | Interactive selection of a historical feature/spec directory. |
-| `this-change` | Analyze the current change artifact and changed files only. |
+Documentation, comment, and formatting-only scopes use deterministic lightweight verification. They do not receive an unjustified full behavior-test claim.
 
-A **change artifact** is any artifact directory containing `spec.md` + `plan.md`, regardless of whether the work is a feature, bug fix, refactor, or migration. `scope=this-change` is not feature-only.
+## Preconditions and Safety
 
-Compatibility guard: Do not automatically apply `scope=this-change` to `.prizmkit/bugfix/<BUG_ID>/` or `.prizmkit/refactor/<REFACTOR_ID>/` by directory name alone. Treat those directories as change artifacts only when the caller provides `artifact_dir` and the directory contains `spec.md` + `plan.md` plus a changed-files source.
+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.
 
-## Context Loading
-
-Before execution, load context once:
-
-1. Architecture context: `root.prizm`, relevant L1 docs, and relevant L2 docs when scope requires interface or boundary detail.
-2. Project config: `.prizmkit/config.json` if present.
-3. Dependency manifest: `package.json`, `pyproject.toml`, `requirements.txt`, `go.mod`, or equivalent.
-4. For `scope=this-change`:
-   - `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 tests
-
-Do not load every module or every spec merely because they exist.
+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.
 
 ## Input
 
 | Parameter | Required | Description |
 |-----------|----------|-------------|
-| `scope` | No | `full-project`, `module:<name>`, `feature:<slug>`, or `this-change`. |
-| `artifact_dir` | No | Change artifact directory. For `scope=this-change`, it must contain `spec.md` and `plan.md`. |
-| `diff_base` | No | Git ref used to compute changed files for this change. |
-| `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`; full-project can generate broader coverage. |
+| `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`.
+
+Do not infer a current change artifact from a legacy bug/refactor directory name alone; require explicit `artifact_dir` and changed-file evidence.
+
+## Authoritative Resources
+
+Load each resource only on its branch:
+
+- 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.
+
+## Required State Machine
+
+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.
 
-Headless default:
-- If `scope=this-change` is provided, require a valid `artifact_dir` with `spec.md` + `plan.md`.
-- If a valid `artifact_dir` is provided without `scope`, treat it as `scope=this-change`.
-- If neither scope nor artifact directory is provided, default to `full-project`.
+### 1. CHANGE_CLASSIFY
 
-## Execution
+Classify the scope as `behavior` or `lightweight` and write `change-classification.json`.
 
-### Phase 0: Architecture Detection
+- `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.
 
-1. Classify project type from loaded context and dependencies:
-   - Frontend
-   - Backend
-   - Fullstack
-   - Library/CLI
-   - Unknown
-2. Detect test framework:
-   - Jest, Vitest, pytest, Go test, Playwright, or custom `npm test`
-   - If multiple frameworks exist, use the one with the most relevant test files and list all detected frameworks in the report
-3. Interactive mode: show detected architecture/framework and ask for correction when uncertain.
-4. Headless mode: proceed with detected assumptions and record them in the report.
+Unknown classification follows the full protocol or becomes `TEST_BLOCKED`.
 
-### Phase 1: Scope Selection
+### 2. SCOPE_DISCOVER
 
-Interactive mode options:
+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:
 
-1. Full project
-2. Single module
-3. Single historical feature/spec directory
-4. Current change artifact when an artifact directory is available
+- 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.
 
-For `scope=this-change`, build the in-scope source set using this priority:
+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`.
 
-1. `changed_files` parameter
-2. `git diff --name-only <diff_base>`
-3. files/tasks listed in `artifact_dir/plan.md`
-4. file manifest in `artifact_dir/context-snapshot.md`
-5. file/module mapping from `artifact_dir/spec.md`
+### 3. CONTRACT_MODEL
 
-If no changed file source can be determined for `scope=this-change`, stop with a clear error and ask for `changed_files` or `diff_base`.
+Write `behavior-risk-matrix.json`. Resolve test truth in strict precedence:
 
-### Phase 2: Run Existing Tests
+1. specifications;
+2. machine-readable contracts;
+3. acceptance conditions;
+4. trusted existing tests;
+5. callers/consumers;
+6. current implementation.
 
-1. Find test files using project conventions: `tests/`, `__tests__/`, `*.test.*`, `*.spec.*`, or language-specific patterns.
-2. Run the detected test command in scope.
-3. Capture pass/fail counts, failed details, and raw output in the report directory.
-4. For `scope=this-change`, classify failures:
-   - In-Scope Failures: changed tests, tests mapped to in-scope source, or acceptance-criteria tests without baseline evidence.
-   - Baseline Failures: unrelated pre-existing failures.
-5. If `scope=this-change` has unexplained In-Scope Failures, final verdict must be `NEEDS_FIXES` or `BLOCKED`.
+Unresolved conflicting truth is `TEST_BLOCKED`, not a characterization test.
 
-### Phase 3: Coverage Gap Analysis
+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.
 
-For `scope=this-change`, analyze only:
+Coverage metrics are diagnostic signals only and never substitute for this matrix.
 
-- changed/new public interfaces
-- acceptance criteria from the change artifact
-- directly affected integration boundaries
-- directly affected UI/E2E flows
+### 4. TEST_PLAN
 
-Record unrelated historical gaps under `Out of Scope Gaps`; do not generate tests for them and do not fail the verdict because of them.
+Write `test-plan.json`. Select necessary unit, module/component, contract, integration, and code-level E2E tests by risk. Assess the ordered execution layers:
 
-For other scopes, compare existing tests against expected coverage across:
+1. focused;
+2. module/component;
+3. contract/integration;
+4. complete affected-module regression;
+5. Regression Ring.
 
-- Unit tests for exported functions/classes and changed logic
-- Integration tests for module boundaries, API endpoints, DB operations, and external service seams
-- E2E tests for user-visible acceptance criteria when a UI exists
+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.
 
-### Phase 4: Boundary Coverage Matrix
+### 5. INFRA_READY
 
-Build the **Boundary Coverage Matrix** before generating tests. Happy-path coverage alone is not enough, and the boundary completion gate determines whether coverage is complete.
+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`.
 
-Read `${SKILL_DIR}/references/boundary-coverage-protocol.md` for matrix format, category definitions, and completion gate.
+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.
 
-For each in-scope interface or endpoint, classify applicable categories such as:
+### 6. TEST_BUILD
 
-- request validation
-- auth / permission / ownership
-- domain invariants
-- collection / pagination
-- date/time boundaries
-- state transitions
-- dependency failures
-- response contract
+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.
 
-Mark each category as:
+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`.
 
-- `covered`
-- `generated`
-- `needs-review`
-- `skipped` with reason
-- `boundary-missing`
+If a valid test reveals a business/contract defect, do not fix production behavior in this skill. Preserve the evidence for `TEST_FAIL`.
 
-### Phase 5: Generate Missing and Boundary Tests
+### 7. EXECUTE_PROVE
 
-Read `${SKILL_DIR}/references/test-generation-steps.md` for detailed generation rules.
+Run required layers in plan order through `${SKILL_DIR}/scripts/build_test_evidence.py execute`. 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, unique receipt, and receipt-chain binding to `executions.json`. Do not accept caller-authored execution JSON and do not retry until green.
 
-When generating unit tests for service-like functions or API/integration tests with business-specific behavior, use `${SKILL_DIR}/references/service-boundary-test-catalog.md`.
+Differentially prove each added/changed necessary behavior test:
 
-Rules:
-- Generate tests only for the selected scope.
-- Check for equivalent existing tests before writing new tests.
-- Do not modify unrelated production code.
-- Do not add empty assertions or mock-success-only tests.
-- If a valid generated test reveals behavior mismatch, mark it `needs-review` rather than changing production code inside this skill.
+- Prefer baseline failure plus current success in an isolated/uncontaminated environment.
+- If baseline is inapplicable, use a minimal controlled mutation tied to the same risk.
+- Bind proof to runner receipts, baseline commit, a stable source-snapshot hash, mutation apply/restore hashes, and complete cleanup. The source snapshot excludes runtime-managed `.prizmkit/state/`, evidence output under `.prizmkit/test/evidence/`, `.claude/worktrees/`, Git metadata, and Python bytecode caches because those paths change while the tested code remains identical.
+- Keep source identity separate from evidence integrity: the stable snapshot detects behavior-bearing project drift, while `manifest.json` hashes every evidence file and detects report/output tampering.
+- Completely remove mutations and verify the stable source snapshot is unchanged. Never rebind completed proof to the mutable live project tree.
+- Classify each proof as `PROVEN`, structured `NOT_APPLICABLE`, or `UNPROVEN`.
 
-### Phase 6: Unified Report and Boundary Validation
+Necessary `UNPROVEN` behavior, required flakiness, unavailable infrastructure after bounded recovery, failed cleanup, unreliable execution, or budget truncation yields `TEST_BLOCKED`.
 
-Create `.prizmkit/test/{YYYY_MM_DD_HH_MM_SS}_testresult/` and write `test-report.md` using `${SKILL_DIR}/references/test-report-template.md`.
+### 8. EVIDENCE_PACKAGE
 
-For `scope=this-change`, include:
+Create `.prizmkit/test/evidence/<evidence-id>/` from the package template with:
 
-- mode, artifact dir, diff base, changed-files source
-- in-scope source and test files
-- existing tests run
-- generated/updated tests
-- in-scope failures
-- baseline failures
-- out-of-scope gaps
-- verdict: `PASS`, `NEEDS_FIXES`, or `BLOCKED`
+- `manifest.json`
+- `change-classification.json`
+- `scope.json`
+- `behavior-risk-matrix.json`
+- `test-plan.json`
+- `infrastructure-changes.json`
+- `differential-proof.json`
+- `executions.json`
+- `verdict.json`
+- `source-change.patch`
+- complete `raw/` stdout/stderr
+- `generated-tests/` snapshots
+- `contracts/` snapshots
+- derived `test-report.md`
 
-Run the deterministic boundary-report validator when the project has an OpenAPI file or the report contains a Boundary Matrix:
+Hash baseline, diff, the stable source snapshot, inventoried source/tests/contracts/lockfiles, environment, plan, and every evidence file. Runtime state, evidence output, linked Agent worktrees, Git metadata, and bytecode caches are outside source identity; evidence files remain independently content-addressed through `manifest.json`. Set `environment_claim=mocked-code-level-only` and `compatibility=legacy-test-report-interface-not-supported`.
+
+### 9. EVIDENCE_VALIDATE
+
+Run:
 
 ```bash
-python3 ${SKILL_DIR}/scripts/validate_boundary_report.py \
-  --report .prizmkit/test/{timestamp}_testresult/test-report.md \
-  --openapi openapi.yaml
+python3 ${SKILL_DIR}/scripts/validate_test_evidence.py \
+  --evidence-dir .prizmkit/test/evidence/<evidence-id> \
+  --project-root <target-project-root> \
+  --attest
 ```
 
-If no OpenAPI file exists, omit `--openapi`. If validation fails, keep the report but do not claim boundary coverage is complete.
+The validator checks every authoritative record against its shipped schema, live target inventories, patch/diff binding, stage dependencies, 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, proof-linked isolated failures/current successes, production/unknown external-target safety, cleanup, and package integrity. `--attest` writes an integrity/protocol attestation, not proof against a malicious same-permission producer. 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, invalid differential proof, cleanup failure, unjustified structured N/A, unresolved risk, or a false real-environment claim fails validation. `TEST_PASS` requires validator success and means code-level evidence is replayable and validated under this protocol.
+
+## Resume and Idempotency
+
+When interrupted or re-invoked:
+
+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.
+
+For a large module or bounded budget, persist matrix/checkpoint progress and return `TEST_BLOCKED` until complete evidence exists. Never silently reduce scope.
+
+## Terminal Verdicts
+
+Only these testing-domain outcomes are valid:
+
+- `TEST_PASS`: every required module behavior/risk and Regression Ring check is proven, required executions pass reliably, cleanup succeeds, no verdict-capable unresolved edge remains, and deterministic validation passes.
+- `TEST_FAIL`: a valid reliable test reproduces an implementation or resolved-contract failure.
+- `TEST_BLOCKED`: unknown scope, conflicting truth, unavailable/unreliable/flaky necessary execution, incomplete evidence, unproven tests, failed cleanup, budget truncation, or deterministic validation failure.
+
+No conditional pass exists.
 
-## Output
+## Derived Report and Handoff
 
-- Test report: `.prizmkit/test/{timestamp}_testresult/test-report.md`
-- Generated or updated test files
-- Raw existing-test output, generated-test copies, E2E artifacts, and boundary validation output in the report directory
+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:
 
-## Recovery
+- testing-domain verdict;
+- evidence directory and ID;
+- validator result and key execution pointers;
+- sensitivity and mocked-versus-real warning;
+- explicit notice that the legacy test-report interface is not supported.
 
-If interrupted:
+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.
 
-- Check `.prizmkit/test/` for the most recent report directory.
-- Re-run `/prizmkit-test`; it starts fresh but can reuse passing tests and existing generated files.
-- Preserve any `needs-review` findings in the next report.
+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.
 
 ## Examples
 
-Read `${SKILL_DIR}/references/examples.md` for worked examples of full-project, module, feature selection, and change-artifact runs.
+Read `${SKILL_DIR}/references/examples.md` only when a concrete normal, legacy gap-filling, contract-coupled, failure, blocked, recovery, or tampering example is needed.
 
-**HANDOFF:** Independent skill. If tests fail, boundary validation fails, or generated tests are marked `needs-review`, fix issues manually or run another targeted `/prizmkit-test` pass. Proceed to `/prizmkit-committer` only when testing was required and the report verdict allows it.
+**HANDOFF:** Return the strict testing verdict and structured evidence pointers only.