/ct-validator

name: ct-validator
description: Compliance validation for verifying systems, documents, or code against requirements, schemas, or standards. Performs schema validation, code compliance checks, document validation, and protocol compliance verification with detailed pass/fail reporting. Use when validating compliance, checking schemas, verifying code standards, or auditing protocol implementations. Triggers on validation tasks, compliance checks, or quality verification needs.
version: 2.0.4
protocol: validation
adrRefs:
  - ADR-051
  - ADR-023
dependencies: []
sharedResources:
  - subagent-protocol-base
  - task-system-integration
compatibility:
  - claude-code
  - cursor
  - windsurf
  - gemini-cli
license: MIT
metadata:
  version: 2.0.4
  tier: on-demand
  install: harness
  covers:
    - packages/core/src/validation/protocols/cant/validation.cant
    - packages/core/src/validation/protocols/protocols-markdown/validation.md
  loomStage: validation
  lastReviewed: 2026-09-28
  stability: stable

Validator Context Injection

**Protocol**: @src/protocols/implementation.md **Type**: Context Injection (cleo-subagent) **Version**: 2.0.0

---

Purpose

Context injection for compliance validation tasks spawned via cleo-subagent. Provides domain expertise for verifying that systems, documents, or code comply with specified requirements, schemas, or standards.

---

Capabilities

1. **Schema Validation** - Verify data structures against JSON Schema 2. **Code Compliance** - Check code against style guides and standards 3. **Document Validation** - Verify documents meet structural requirements 4. **Protocol Compliance** - Check implementations against specifications

---

Out of Scope (T9675)

`ct-validator` operates on the **`validation`** LOOM lifecycle stage (stage 7). It performs **static** schema, compliance, and audit checks against artifacts that already exist on disk (specs, ADRs, JSON files, RFC 2119 keyword usage, manifest schemas).

This skill does NOT:

• Run a test suite, framework detection, or iterative IVT loop. Those belong to **`ct-ivt-looper`** at the `testing` stage (stage 8). When dynamic verification is required — e.g. "does the implementation actually pass its tests?" — chain to `ct-ivt-looper` rather than expanding scope here.
• Modify code or apply fixes. The validator reports; downstream skills remediate.

Chain handoffs

| Direction | When | Handoff | |---|---|---| | `ct-validator` → `ct-ivt-looper` | Spec is valid but implementation needs dynamic verification | Emit a manifest entry, then dispatch the `testing` stage | | `ct-ivt-looper` → `ct-validator` | IVT loop converged; need to audit the resulting artifacts against schema/compliance | Dispatch the `validation` stage after the test convergence record |

Governance: see **ADR-051** (programmatic gate integrity) which defines the evidence atoms each stage emits and that the other stage may re-validate, and **ADR-023** (protocol validation dispatch) which routes between them.

---

Validation Methodology

Standard Workflow

1. **Define scope** - What is being validated 2. **Identify criteria** - What rules apply 3. **Execute checks** - Run validation against criteria 4. **Document findings** - Record pass/fail with details 5. **Report status** - Summarize compliance level

---

Blast-Radius Test Scope (MANDATORY · T9842)

When acting as the IVTR Lead in the **Validate** phase (R2), the targeted test files named in the task spec are NOT sufficient evidence on their own when the Implement phase touched an infrastructure file. Targeted-only test review is how cross-package regressions slip past the Lead.

Precedent — T9814 R2

T9814 swapped `BEGIN IMMEDIATE` for SAVEPOINTs in `packages/core/src/store/sqlite-data-accessor.ts` to support nested transactions for `add-batch`. Every targeted test passed (6/6 add-batch, 34/34 add, 9/9 allocate). IVTR Lead R2 approved on the targeted scope. CI then surfaced `agent-resolver.test.ts preferTier` failing — the resolver depended on the outer `BEGIN IMMEDIATE` semantics that SAVEPOINTs do not replicate verbatim. Hotfix commit `baa996d2b` restored the outer-tx case. The Lead's targeted-only review missed a regression CI caught seconds later.

Rule

If ANY file in the impl-phase evidence bundle's `filesChanged` matches a canonical infrastructure path, the Lead MUST run the full per-package vitest suite for every touched package — NOT the targeted files alone.

Canonical infrastructure paths

• `packages/core/src/store/**` — DB chokepoint, transactions, migrations
• `packages/core/src/orchestration/**` — spawn-prompt, dispatch resolution, IVTR
• `packages/core/src/dispatch/**` and `packages/cleo/src/dispatch/**` — typed dispatch
• `packages/contracts/src/**` — cross-package types (every consumer rebuilds)
• `packages/worktree/src/**` — worktree-create / git-shim integration
• `packages/core/src/migration/**` — schema bootstrapping
• any path whose basename contains `transaction`, `pragma`, or `migration`

Required test commands per touched package

pnpm --filter @cleocode/<pkg> run test  # for each touched package

Attach the JSON output of each run as evidence (`cleo docs add --labels test-output`) and reference the sha256 set in the `--next` call. Approving on targeted-only results when infrastructure paths are touched is grounds for loop-back with reason `infra-test-scope-violation`.

Enforcement

The IVTR Lead spawn prompt is auto-enriched by `resolvePhasePrompt()` in `packages/core/src/lifecycle/ivtr-loop.ts` — when an infrastructure touch is detected via `detectInfrastructureTouch()` (`packages/core/src/lifecycle/infra-touch.ts`), a `### Blast-Radius Test Scope — MANDATORY (T9842)` block is appended to the Validate-phase Lead prompt, listing the touched packages and the exact `pnpm --filter` commands the Lead must run.

---

Output Format

Validation Report Structure

# Validation Report: {{VALIDATIO