prizmkit 1.1.120 → 1.1.121

package/bundled/skills/prizmkit-test/assets/evidence-package-template.json

@@ -0,0 +1,97 @@
+{
+  "protocol_version": "1.0",
+  "records": {
+    "change_classification": "change-classification.json",
+    "scope": "scope.json",
+    "target_inventory": "target-inventory.json",
+    "environment": "environment.json",
+    "behavior_risk_matrix": "behavior-risk-matrix.json",
+    "test_plan": "test-plan.json",
+    "infrastructure_changes": "infrastructure-changes.json",
+    "differential_proof": "differential-proof.json",
+    "executions": "executions.json",
+    "verdict": "verdict.json",
+    "validation": "validation.json",
+    "source_patch": "source-change.patch",
+    "derived_report": "test-report.md"
+  },
+  "directories": {
+    "requests": "requests/",
+    "receipts": "receipts/",
+    "raw_outputs": "raw/",
+    "generated_test_snapshots": "generated-tests/",
+    "contract_snapshots": "contracts/"
+  },
+  "stage_statuses": [
+    {
+      "name": "CHANGE_CLASSIFY",
+      "status": "pending",
+      "input_sha256": "<sha256>",
+      "outputs": []
+    },
+    {
+      "name": "SCOPE_DISCOVER",
+      "status": "pending",
+      "input_sha256": "<sha256>",
+      "outputs": []
+    },
+    {
+      "name": "CONTRACT_MODEL",
+      "status": "pending",
+      "input_sha256": "<sha256>",
+      "outputs": []
+    },
+    {
+      "name": "TEST_PLAN",
+      "status": "pending",
+      "input_sha256": "<sha256>",
+      "outputs": []
+    },
+    {
+      "name": "INFRA_READY",
+      "status": "pending",
+      "input_sha256": "<sha256>",
+      "outputs": []
+    },
+    {
+      "name": "TEST_BUILD",
+      "status": "pending",
+      "input_sha256": "<sha256>",
+      "outputs": []
+    },
+    {
+      "name": "EXECUTE_PROVE",
+      "status": "pending",
+      "input_sha256": "<sha256>",
+      "outputs": []
+    },
+    {
+      "name": "EVIDENCE_PACKAGE",
+      "status": "pending",
+      "input_sha256": "<sha256>",
+      "outputs": []
+    },
+    {
+      "name": "EVIDENCE_VALIDATE",
+      "status": "pending",
+      "input_sha256": "<sha256>",
+      "outputs": []
+    }
+  ],
+  "resume": {
+    "last_valid_stage": null,
+    "current_target_hashes": {
+      "source": "<sha256>",
+      "tests": "<sha256>",
+      "contracts": "<sha256>",
+      "lockfiles": "<sha256>",
+      "environment": "<sha256>",
+      "plan": "<sha256>"
+    },
+    "preserve_prior_executions": true,
+    "invalidate_downstream_on_input_change": true,
+    "semantic_review_required": true
+  },
+  "required_notice": "Evidence contains complete project-controlled command, environment, and output values. The project owns access control, retention, and upload policy. Production credentials, production services, and destructive real-data operations are prohibited.",
+  "compatibility": "legacy-test-report-interface-not-supported"
+}

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

@@ -1,220 +1,104 @@
-# Boundary Coverage Protocol
+# Behavior-Risk Completeness Protocol
 
-Use this protocol during `/prizmkit-test` Phase 4 and update it during Phase 5. The goal is to prevent a common false positive: treating "there is a test for this interface" as equivalent to "this interface is safely covered." A happy path proves that the interface can work once; boundary tests prove that the interface handles realistic invalid inputs, authorization failures, ownership rules, state transitions, and dependency failures.
+This protocol replaces interface-count and line-coverage completion with observable behavior/risk evidence. The authoritative matrix is `behavior-risk-matrix.json`, validated against `${SKILL_DIR}/assets/behavior-risk-matrix.schema.json`.
 
-## Required Boundary Matrix
+## Affected Module Boundary
 
-Build this matrix before writing tests and update it after generated tests pass or produce `needs-review` findings. In `scope=this-change`, build the matrix only for interfaces/endpoints in the reviewed change artifact or changed-file set; unrelated interfaces are recorded under `Out of Scope Gaps` and do not trigger generated tests.
+Use an explicit project module when available. Otherwise derive a cohesive boundary from files that jointly implement one observable responsibility. Record the boundary decision, every declared module root, and every discovered file. Every changed file must appear in inventory or an evidence-backed exclusion.
 
-| Module | Interface | Service Type | Happy Path | Request Validation | Auth / Permission / Ownership | Domain Invariants | Collection / Pagination | Date / Time | State Transitions | Dependency Failure | Response Contract | N/A Reasons | Final Status |
-|--------|-----------|--------------|------------|--------------------|-------------------------------|-------------------|-------------------------|-------------|-------------------|-------------------|-------------------|-------------|--------------|
-| auth | POST /auth/login | Auth / Session | covered | generated | N/A — public route | generated | N/A — no collection input | N/A — no date input | covered | skipped — password hasher not injectable | covered | ... | boundary-covered |
+Inventory discovery is a guard against obvious omissions, not a deterministic proof of semantic completeness. Static patterns cannot fully resolve reflection, registration, generated code, runtime configuration, or business concepts spread across unexpected files; preserve those as model judgment or unresolved edges.
 
-## Status Values
+- **Primary Scope:** all observable behavior of the affected module.
+- **Regression Ring:** direct callers, consumers, shared contracts, and state dependencies.
+- **Unresolved Edges:** dynamic or unprovable coupling, each marked verdict-capable or informational.
 
-Use these values consistently:
+Changed lines locate the module but do not define completeness. A verdict-capable unresolved edge prevents `TEST_PASS`.
 
-- `covered` — an existing test already asserts this behavior.
-- `generated` — this run generated a test and the test passed.
-- `needs-review` — a generated test is valid, but production behavior mismatched the expected contract.
-- `unresolved` — the test could not be made runnable after the allowed fix attempts.
-- `skipped` — not applicable or not practical in this run, with a concrete reason in `N/A Reasons`.
-- `boundary-missing` — applicable boundary exists but no test covers it yet.
+## Behavior-Risk Matrix
 
-## Completion Gate
+For each public observable behavior, record:
 
-An in-scope interface is complete only when:
+| Dimension | Required Content |
+|-----------|------------------|
+| Public behavior | User/caller-observable capability or guarantee |
+| Contract source | Specification, machine-readable contract, acceptance condition, trusted test, caller, or implementation |
+| Preconditions | Required identity, state, configuration, or dependency state |
+| Inputs | Valid classes, empty/null/type/format variants |
+| Boundaries | Contract-defined min/max/exact transition values |
+| Outputs | Values, errors, response shape, generated identifiers |
+| Side effects | Writes, calls, events, files, messages, or absence of partial effects |
+| State transitions | Before/after state and idempotent/retry semantics |
+| Error behavior | Validation, authorization, dependency, timeout, and malformed-response outcomes |
+| Risks | Functional, boundary, permission, concurrency, idempotency, time, dependency, consumer |
 
-1. It has happy-path coverage when a happy path exists.
-2. Every applicable boundary category is `covered`, `generated`, or `needs-review`.
-3. Every non-applicable category has a concrete reason.
-4. No applicable category remains `boundary-missing`.
-5. The final status is one of:
-   - `boundary-covered`
-   - `generated-needs-review`
-   - `skipped-with-reason`
+Every risk cell is:
 
-If an interface has only happy-path coverage, set `Final Status` to `boundary-missing` and continue generating applicable boundary tests. Do not call the run complete while any in-scope interface is `boundary-missing` or `happy-path-only`.
+- `applicable`: mapped to one or more actual test IDs and execution IDs;
+- `not_applicable`: a structured decision containing behavior-specific rationale, typed evidence, considered signals, and explanations for every detected conflict;
+- `unresolved`: missing truth, testability, execution, or proof.
 
-## How to Decide Whether Existing Tests Count
+The model decides applicability from project semantics. The validator checks the structure and obvious signal conflicts only: identity/role/tenant suggests permission risk; locks/shared mutable state/workers suggest concurrency; retry/dedup/idempotency keys suggest idempotency; timeout/TTL/expiry suggests time; clients/contracts/network/storage suggest dependency; callers/consumers/shared contracts suggest consumer risk. A detected signal does not force applicability when the structured conflict explanation and evidence establish why it is irrelevant.
 
-An existing test counts for a boundary category only when it:
+“Covered by happy path,” “probably fine,” or bare “N/A” is invalid rationale.
 
-- targets the same public interface or endpoint,
-- creates the boundary input, state, dependency failure, or authorization context,
-- asserts the expected error code, exception, state change, response shape, or side effect,
-- verifies behavior rather than only checking that the call returned a response.
+## Truth Resolution
 
-Examples:
+Use this precedence and record the consulted sources:
 
-- `POST /users/create` returns HTTP 200 with non-empty data → happy path only.
-- `POST /users/create` with missing email asserts `code=10001` → request validation boundary.
-- `POST /items/delete` with another user's item asserts forbidden/not-found code → ownership boundary.
-- Service create method with mocked repository failure asserts no partial side effect → dependency failure boundary.
+1. specification;
+2. machine-readable contract;
+3. acceptance condition;
+4. trusted existing test;
+5. caller/consumer;
+6. current implementation.
 
-## Boundary Categories
+Do not freeze a possible current implementation bug into a characterization test. Conflicting higher-precedence sources that cannot be resolved produce `TEST_BLOCKED`.
 
-### Request Validation
+## Applicable Risk Guidance
 
-Use when the interface accepts client input or public parameters.
+### Functional and Boundary
 
-Generate applicable cases for:
-- missing required fields,
-- empty string / empty array / empty object,
-- malformed JSON or wrong content type when the framework exposes that behavior,
-- wrong type,
-- unsupported enum,
-- invalid numeric values: zero, negative, min/max, just above max,
-- invalid string format: URL, email, phone, date, timestamp, UUID/ULID, object key.
+Cover typical/minimal/complex valid inputs; null/empty/wrong type; numeric/string/collection limits; malformed formats; output/error shape; every contract-relevant branch. Do not mechanically test private branches with no observable effect.
 
-### Auth / Permission / Ownership
+### Permission
 
-Use when the interface depends on identity, roles, tenant, ownership, entitlement, or token state.
+Apply for identity, role, tenant, ownership, policy, entitlement, secret, or protected-resource behavior. Include missing/invalid identity, wrong owner/tenant, insufficient grant, and default-deny behavior.
 
-Generate applicable cases for:
-- missing auth,
-- malformed auth header,
-- invalid/expired/revoked token,
-- authenticated user accessing another user's resource,
-- missing role/permission/entitlement,
-- default-deny when ownership cannot be proven.
+### Concurrency
 
-### Domain Invariants
+Apply when shared mutable state, locks, optimistic versions, duplicate workers/calls, race-prone caches, or transaction ordering can change observable results. Use deterministic coordination rather than timing sleeps.
 
-Use when business rules constrain combinations of fields or state.
+### Idempotency
 
-Generate applicable cases for:
-- ratios or totals that must sum to a value,
-- start date before end date,
-- calorie/weight/amount ranges,
-- unsupported lifecycle status,
-- duplicate unique identifiers,
-- device binding requirements,
-- token rotation/reuse semantics,
-- image quality / provider classification rules,
-- product-specific thresholds such as 90%-110% calorie hit boundaries.
+Apply to retries, deduplication keys, create/update/delete repetition, webhook/job replay, token rotation, and state transitions. Assert both result and side-effect count.
 
-### Collection / Pagination
+### Time
 
-Use when the interface accepts or returns lists, pages, filters, or cursors.
-
-Generate applicable cases for:
-- empty result,
-- one item,
-- many items,
-- duplicate IDs,
-- omitted page / page size defaults,
-- page 0, negative page, max page size, max + 1,
-- invalid filters,
-- nullable filters such as true/false/null,
-- stable ordering or total count when specified.
-
-### Date / Time
-
-Use when the interface parses, stores, filters, expires, schedules, or compares time.
-
-Generate applicable cases for:
-- invalid date / timestamp format,
-- timezone assumptions,
-- inclusive vs exclusive date range boundaries,
-- start after end,
-- exact expiry instant and just before/after expiry,
-- today/yesterday/stale streak or schedule semantics,
-- leap day/month end when relevant.
-
-### State Transitions
-
-Use when the interface creates, updates, deletes, confirms, unbinds, retries, logs out, refreshes, or changes status.
-
-Generate applicable cases for:
-- create then read,
-- update sets expected derived fields,
-- delete excludes from later reads,
-- double delete / unbind idempotency when specified,
-- refresh rotates token and rejects old token,
-- batch operation with empty list vs explicit IDs,
-- retry count below/at/above max,
-- no partial writes when one operation fails.
-
-### Dependency Failure
-
-Use when collaborators are mockable or the test layer can safely simulate failures.
-
-Generate applicable cases for:
-- repository/database error,
-- storage/signing provider failure,
-- SMS/push/email provider failure,
-- LLM/API client error,
-- timeout/network failure,
-- malformed provider response,
-- ID/random/clock failure when injectable.
-
-If a dependency cannot be mocked in the current test layer, mark it `skipped` with a reason and consider a lower-level unit test where it can be mocked.
-
-### Response Contract
-
-Use for API endpoints and public adapters.
-
-Generate applicable cases for:
-- unified envelope fields (`code`, `message`, `data`) or framework-specific response format,
-- fixed business error codes,
-- response field names and snake_case/camelCase contract,
-- omitted vs empty data shape,
-- generated IDs and derived fields,
-- side-effect visibility in response.
-
-## Endpoint and Interface Mapping
-
-Use names, routes, methods, schemas, binding tags, repository calls, and service logic to choose categories. When names and behavior disagree, trust behavior.
-
-| Pattern | Likely Categories |
-|---------|-------------------|
-| register / signup / create user | request validation, auth/session, domain invariants, dependency failure, response contract |
-| login | request validation, auth/session, rate limit, token response, dependency failure |
-| refresh / logout | token state, rotation/revocation, idempotency, dependency failure |
-| get / detail | auth/ownership, not found, response contract, dependency failure |
-| list / search / trends | auth, filters, pagination/empty result, date range, response contract, dependency failure |
-| create | request validation, domain invariants, state transition, dependency failure, response contract |
-| update / set goal / confirm | request validation, ownership, partial update semantics, domain invariants, state transition |
-| delete / unbind | request validation, ownership, not found, soft delete, double operation behavior |
-| upload / sign url | request validation, file/storage rules, provider failure, response contract |
-| AI / provider / recognize | request validation, date/time, provider error mapping, quality classifications, async job state |
-| stats / analytics | date range, empty data, boundary thresholds, response shape, dependency failure |
-| achievement / streak | empty state, date continuity, threshold boundaries, state persistence |
-
-## N/A Reason Rules
-
-A skipped category must explain why it does not apply or why it cannot be exercised at this level.
-
-Good reasons:
-- `N/A — public route; no authenticated principal expected`
-- `N/A — endpoint has no collection input or paginated response`
-- `N/A — dependency is not injectable at handler level; covered by service unit test`
-- `N/A — function is pure and has no stateful side effects`
-- `N/A — E2E skipped because project has no UI layer`
-
-Bad reasons:
-- `N/A`
-- `not tested`
-- `probably fine`
-- `covered by happy path`
-
-## Report Requirements
-
-The final report must include:
-
-1. The Boundary Matrix.
-2. A Completion Gate summary:
-   - interfaces total,
-   - boundary-covered count,
-   - generated-needs-review count,
-   - skipped-with-reason count,
-   - boundary-missing count,
-   - happy-path-only count.
-3. A clear final status:
-   - `All tests passing and boundary coverage complete`, or
-   - `Tests passing, but boundary coverage incomplete`, or
-   - `Tests failing`, or
-   - `Needs human review`.
-
-If any interface remains `boundary-missing` or `happy-path-only`, the final report must not say "ready for commit" without qualifying that boundary coverage is incomplete.
+Apply to expiry, schedules, windows, date ranges, TTL, time zones, and clock-sensitive signatures. Control the clock and test exact boundary plus before/after.
+
+### Dependency
+
+Apply to databases, filesystems, queues, providers, clocks/randomness, cross-module adapters, and network clients. Use contract-driven doubles and assert failure mapping, no partial side effects, retry bounds, and cleanup.
+
+### Consumer
+
+Apply when callers depend on return shape, errors, side effects, ordering, generated assets, shared types/contracts, state, or invocation conventions. Regression Ring executions prove these assumptions.
+
+## Completion Rule
+
+The affected module is complete only when:
+
+1. every observable behavior is represented;
+2. every applicable risk has tests and reliable execution evidence;
+3. every N/A cell has a concrete rationale;
+4. every necessary new/changed test has differential proof;
+5. complete affected-module regression passes;
+6. Regression Ring verification passes;
+7. no verdict-capable unresolved edge remains;
+8. cleanup and deterministic package validation succeed.
+
+Line, branch, and function coverage are diagnostic signals for possible omitted behavior. They never substitute for matrix evidence and no mechanical threshold is required.
+
+## Derived Markdown
+
+`test-report.md` may render a compact matrix summary, but it is not authoritative. The JSON matrix and hashed test/execution records control the verdict. Editing the report or any linked artifact without regenerating hashes must fail deterministic validation.

package/bundled/skills/prizmkit-test/references/contract-mock-protocol.md

@@ -0,0 +1,65 @@
+# Contract-Driven Mock Protocol
+
+Use this protocol for external databases, queues, filesystems, SaaS APIs, browser-facing backends, generated clients, and cross-module endpoints. Code-level evidence is mock-first; linking a real test database or deployed environment is outside `/prizmkit-test`.
+
+## Contract Source Precedence
+
+Use the highest available source:
+
+1. Shared machine-readable contract used by producer and consumer: OpenAPI, JSON Schema, Protocol Buffers, GraphQL schema, database schema, AsyncAPI, shared language types, or generated client model.
+2. Versioned contract fixture already stored by the target project.
+3. Locally derived contract fixture built from a named source such as public adapter types, caller expectations, migration schema, provider documentation snapshot, or captured non-production example already authorized for the project.
+
+Never invent request/response fields independently when a shared source exists. Never derive expected behavior only from the changed implementation when a higher-precedence source disagrees.
+
+## Required Contract Snapshot
+
+Copy the exact contract input into `contracts/` and record:
+
+- contract ID and version when available;
+- source path or derivation source;
+- SHA-256;
+- producer and consumer/module names;
+- derivation command or steps;
+- unsupported or ambiguous fields;
+- whether it represents an external provider, local module, or persistence boundary.
+
+If derivation is not reproducible or sources conflict, add an Unresolved Edge and issue `TEST_BLOCKED` when it can affect the verdict.
+
+## Building Doubles
+
+Generate or configure fakes, mocks, fixtures, and mock servers from the contract snapshot. Verify both request and response directions where applicable:
+
+- required/optional fields and nullability;
+- field names, types, enums, formats, and bounds;
+- status/error variants;
+- stateful sequence or transition rules;
+- pagination/cursor semantics;
+- idempotency, time, and concurrency behavior;
+- malformed, timeout, and dependency-failure variants.
+
+A mock-success-only double is insufficient. Record the matrix behavior/risk cells each double supports and the tests/executions that exercised them.
+
+## Databases and Stateful Services
+
+Prefer an in-memory fake or isolated disposable service only when it preserves the contract being tested. Do not point code-level tests at production or a user-linked deployed test database. For database adapters, derive the fixture from schema/migrations/shared models and test transaction, constraint, rollback, and error behavior relevant to the affected module.
+
+Any isolated resource must have a unique identifier, bounded lifetime, and verified cleanup. Cleanup failure produces `TEST_BLOCKED`.
+
+## Real-Environment Separation
+
+Every package and report must state:
+
+- `environment_claim=mocked-code-level-only`
+- Mocked code-level evidence does not verify a real deployed environment.
+- Real test-environment, production, credential, network policy, data migration, and operational validation require a separate authorized process.
+
+Reject a package that claims deployment/environment verification from contract mocks, local fakes, containers, or isolated services.
+
+## Prohibitions
+
+- No production credentials, databases, queues, APIs, object storage, or real user data.
+- No destructive operation against external data.
+- No independently invented incompatible mock contract.
+- No silent contract drift.
+- No automatic upload of complete raw evidence; the project owns access, retention, and upload policy.