pal-e-docs

Validation Template

template-validation Template

active template
Project

Validation Template

Every ticket that reaches needs_approval (merged) must have a validation note before moving to done. The validation note proves the work actually works — not "I think it's fine" but "here's the evidence."
Principle: verified beats reported. A ticket isn't done until production confirms it.

When to Create

  • After merge, before done. The PR is merged, deploy is complete (or immediate for non-CI repos). Now validate. The board item should be in the validation column.
  • Who creates it: Betty Sue scopes the validation. The /validate-ticket skill automates note creation and check execution. Dev/QA agents or Betty Sue herself can also execute the checks manually. For infra tickets, may need kubectl/curl. For frontend, may need browser screenshots.
  • The signal: If you can't define what "working" looks like for a ticket, the acceptance criteria were too vague — go back and fix them.
  • Procedure: Follow sop-validation for the full step-by-step procedure including repo-type checklists and evidence requirements.

Template

Naming Convention

Slug: validation-{issue-number}-{YYYY-MM-DD} (e.g., validation-182-2026-03-27)
Note type: doc (until validation is added to NoteType enum)
Tags: validation,{verdict} (e.g., validation,pass)
Project: same as the ticket

Validation Types

Ticket Type Typical Validation Tools
Terraform/infra <code>tofu plan</code> shows no drift, <code>kubectl get</code> confirms resource state bash, kubectl
API endpoint curl the endpoint, verify response shape + status code curl, jq
Frontend Screenshot of the page, browser console clean chrome-devtools, playwright
Bug fix Reproduce the original bug scenario — confirm it no longer occurs varies
Convention/docs Read the updated note, verify content matches intent pal-e-docs MCP
Hook/enforcement Trigger the hook, verify it fires correctly bash, simulated tool call

Relationship to Board Flow

The validation column is the right-side gate, mirroring the todo review gate on the left side. Left gate: "is the scope right?" Right gate: "does it actually work?"

DORA Integration

  • MTTR: Time from merge to validation PASS = recovery verification latency
  • Change Failure Rate: FAIL verdicts signal regressions — the merge introduced a problem
  • Lead Time: Clock stops at validation PASS, not at merge
  • sop-validation — the full post-merge validation procedure with repo-type checklists
  • sop-board-workflow — column semantics (validation column and two-gate model)
  • skill-validate-ticket — the /validate-ticket agent skill that automates this template
  • template-review — sibling template for the left-side gate (pre-implementation review)
  • convention-validation-checkpoints — the three verification loops (per-phase, per-session, periodic)
  • template-board — sub-board template (includes validation in acceptance criteria)
  • template-issue — acceptance criteria in issues feed the validation check table
  • note-conventions — canonical reference for note types, slugs, tags, and linking