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.0
tier: 2
core: false
category: recommended
protocol: validation
loomStage: validation
adrRefs:
  - ADR-051
  - ADR-023
dependencies: []
sharedResources:
  - subagent-protocol-base
  - task-system-integration
compatibility:
  - claude-code
  - cursor
  - windsurf
  - gemini-cli
license: MIT
---

# 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

```bash
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

```markdown
# Validation Report: {{VALIDATION_TARGET}}

## Summary

- **Status**: PASS | PARTIAL | FAIL
- **Compliance**: {X}%
- **Critical Issues**: {N}

## Checklist Results

| Check | Status | Details |
|-------|--------|---------|
| {CHECK_1} | PASS/FAIL | {Details} |
| {CHECK_2} | PASS/FAIL | {Details} |

## Issues Found

### Critical
{List or "None"}

### Warnings
{List or "None"}

### Suggestions
{List or "None"}

## Remediation

{Required fixes if FAIL/PARTIAL, or "No remediation required" if PASS}
```

---

## Status Definitions

| Status | Meaning | Criteria |
|--------|---------|----------|
| **PASS** | Fully compliant | All checks pass, 0 critical issues |
| **PARTIAL** | Mostly compliant | >70% pass, no critical issues |
| **FAIL** | Non-compliant | <70% pass OR any critical issues |

---

## Task System Integration

@skills/_shared/task-system-integration.md

### Execution Sequence

1. Read task: `{{TASK_SHOW_CMD}} {{TASK_ID}}`
2. Start task: `{{TASK_START_CMD}} {{TASK_ID}}` (if not already started by orchestrator)
3. Execute validation checks
4. Write validation report to `{{OUTPUT_DIR}}/{{DATE}}_{{TOPIC_SLUG}}.md`
5. Append manifest entry to `{{MANIFEST_PATH}}`
6. Complete task: `{{TASK_COMPLETE_CMD}} {{TASK_ID}}`
7. Return summary message

---

## Subagent Protocol

@skills/_shared/subagent-protocol-base.md

### Output Requirements

1. MUST write validation report to: `{{OUTPUT_DIR}}/{{DATE}}_{{TOPIC_SLUG}}.md`
2. MUST append ONE line to: `{{MANIFEST_PATH}}`
3. MUST return ONLY: "Validation complete. Manifest appended to pipeline_manifest."
4. MUST NOT return validation content in response

### Manifest Entry Format

```json
{"id":"{{TOPIC_SLUG}}-{{DATE}}","file":"{{DATE}}_{{TOPIC_SLUG}}.md","title":"{{VALIDATION_TARGET}} Validation","date":"{{DATE}}","status":"complete","agent_type":"validation","topics":["validation","compliance","{{TOPIC}}"],"key_findings":["Overall: {PASS|PARTIAL|FAIL} at {X}%","{N} critical issues found","{SUMMARY_OF_MAIN_FINDINGS}"],"actionable":{TRUE_IF_ISSUES},"needs_followup":["{REMEDIATION_TASK_IDS}"],"linked_tasks":["{{EPIC_ID}}","{{TASK_ID}}"]}
```

---

## Validation Types

### Schema Validation

```bash
# JSON Schema validation example
{{VALIDATION_COMMANDS}}
```

**Checks**:
- Required fields present
- Field types correct
- Enum values valid
- Constraints satisfied

### Code Compliance

**Checks**:
- Style guide conformance
- Naming conventions
- Documentation requirements
- Security patterns

### Document Validation

**Checks**:
- Required sections present
- Frontmatter complete
- Links valid
- Format consistent

### Protocol Compliance

**Checks**:
- RFC 2119 keywords used correctly
- Required behaviors implemented
- Constraints enforced
- Error handling present

---

## Completion Checklist

- [ ] Task started via `{{TASK_START_CMD}}` (if not already started)
- [ ] All validation checks executed
- [ ] Results documented with PASS/FAIL status
- [ ] Compliance percentage calculated
- [ ] Critical issues flagged
- [ ] Remediation steps provided (if FAIL/PARTIAL)
- [ ] Validation report written to output directory
- [ ] Manifest entry appended
- [ ] Task completed via `{{TASK_COMPLETE_CMD}}`
- [ ] Return summary message only

---

## Context Variables

When invoked by orchestrator, expect these context tokens:

| Token | Description | Example |
|-------|-------------|---------|
| `{{VALIDATION_TARGET}}` | What is being validated | `CLEO Schema v2.6.0` |
| `{{TARGET_FILES_OR_SYSTEMS}}` | Files/paths to check | `schemas/*.json` |
| `{{VALIDATION_CRITERIA}}` | Checklist of requirements | RFC 2119 compliance items |
| `{{VALIDATION_COMMANDS}}` | Specific commands to run | `ajv validate --spec=draft7` |
| `{{TOPIC_SLUG}}` | URL-safe topic name | `schema-validation` |

---

## Anti-Patterns

| Pattern | Problem | Solution |
|---------|---------|----------|
| Skipping failing checks | Incomplete report | Run all checks, report all failures |
| Vague findings | Unclear remediation | Specific issue + file/line + fix |
| Missing severity | Can't prioritize | Always classify: critical/warning/suggestion |
| No remediation | Findings not actionable | Always provide fix for FAIL/PARTIAL |

---

## See also / References

This skill binds to the **validation** LOOM lifecycle stage. Governing ADRs:

- [ADR-051 — programmatic gate integrity](../../../../.cleo/adrs/ADR-051-programmatic-gate-integrity.md) — defines the evidence-atom grammar that the validator emits and re-validates.
- [ADR-023 — protocol validation dispatch](../../../../.cleo/adrs/ADR-023-protocol-validation-dispatch.md) — defines the protocol-validation routing layer that dispatches to this skill.

LOOM coverage matrix: [docs/skills/loom-coverage-matrix.md](../../../../docs/skills/loom-coverage-matrix.md).

## See references/

Progressive disclosure — load on demand only:

- `references/validation-modes.md` — schema/code/document/protocol modes, selection rubric, composition
- `references/schema-checking.md` — engine selection, draft selection, pitfalls, bulk validation
- `references/compliance-reports.md` — canonical scaffold, status calculus, severity, ct-ivt-looper integration
- `references/anti-patterns.md` — twelve validation failure modes with detection and remediation