Validate Task Resolution — Autonomous Agents Agentic Workflow

schema_version: 1
id: agent_ops_validate_resolution
title: "Validate Task Resolution"
description: "Read-only: after a ticket goes Done, judge whether its acceptance criteria were actually delivered — verified against the repo, not just the comments — and post one verdict comment"
overview: |
  The post-Done resolution check (Task Validation V2, SCRUM-1634). After a ticket's playbook run has
  finished, this ops workflow re-reads the ticket — its acceptance criteria AND every comment,
  including the prior runs' own gate comments ("PASS", "merged", "QA PASS", …) — and the repository,
  then judges one question: do the ticket's stated ACs appear DELIVERED, verified against the code and
  not just the comments? It exists because gates judge step advancement and QA workflows test
  behaviour, but nothing re-reads the ticket after Done against what actually landed.

  It is strictly recording-only. The agent reads the ticket and the repo, confirms the PRs/commits the
  comments name really exist and really contain the claimed change, and posts ONE verdict comment:
  VALIDATED, INCOMPLETE (with a numbered gap list + recommended next steps), or UNVERIFIABLE. It
  recommends only — it files nothing, changes no code, merges nothing, and never transitions the
  ticket. The engine records the verdict; a human acts on it.

category:
  level: pipeline
  domain: engineering

metadata:
  agent: true
  role: ops

params:
  agentic_app:
    type: string
    default: "cc"
    description: "Agent-app slug selecting the per-run env file ~/.agent-env.d/<slug> (AAP-C); 'cc'/subscription clears provider vars"
  ticket_url:
    type: string
    description: "Jira ticket URL (the Done ticket whose resolution is being validated)"
  hint:
    type: string
    default: ""
    description: "Optional extra instructions for the agent"
  entry_path:
    type: string
    default: "~/workspace"
    description: "Working directory for the agent"

steps:
  - type: terminal.open
    title: "Agent: Validate Task Resolution"
    cwd: "{{entry_path}}"
  - type: terminal.run
    cmd: |
      source ~/.agent-env
      # AAP-C (SCRUM-1506): clear any global provider vars so none can hijack a subscription run
      # (de-fang the brick), then source the per-run app env selected by slug when a file exists;
      # no file => subscription/default. base/19-secrets stages ~/.agent-env.d/<slug>.
      unset ANTHROPIC_BASE_URL ANTHROPIC_AUTH_TOKEN ANTHROPIC_API_KEY
      unset ${!CLAUDE_CODE_USE_@}
      if [ -f "$HOME/.agent-env.d/{{agentic_app}}" ]; then
        source "$HOME/.agent-env.d/{{agentic_app}}"
      fi
      claude --dangerously-skip-permissions "$(cat <<'SB_PROMPT'
      read the ticket with attachments and ALL comments - {{ticket_url}}. if it fails, stop and report the error.
      this is a READ-ONLY validation pass. the ticket is already Done; your job is to judge whether its acceptance criteria were ACTUALLY delivered — verified against the repository, not just taken on the word of the comments.
      read TWO sources and cross-check them:
        1. THE TICKET: the description's acceptance criteria (ACs), and EVERY comment — including the delivery run's own gate comments (triage, PR, review/merge, QA). those comments are claims to be verified, not evidence to be trusted.
        2. THE REPOSITORY: for each PR or commit named in the comments, confirm it actually exists and actually contains the claimed change (git log / git show / grep the merged code in the repo under {{entry_path}}); confirm the code the ACs require is present. if a claimed migration/deploy/config change is what closes an AC, confirm it was applied, not merely written.
      map each AC to the concrete evidence that implements it. an AC with no code behind it is a GAP no matter what the comments say.
      watch for the two canonical false-pass patterns:
        - SCOPED PASS: an approval that silently covers only part of the ticket — "PASS - scoped to Slice A", "code-level only", "not closeable pending X", deferred slices with no follow-up ticket. The headline reads done; the scope line admits it is not.
        - MASKED BLOCK: a green headline over an unresolved blocker in the same thread — a "QA PASS" over an unapplied migration or an undeployed/unmerged fix. The verdict and the body contradict each other; the body is the truth.
      {{hint}}
      decide EXACTLY ONE verdict:
        - VALIDATED: every stated AC is delivered and verified in the repo.
        - INCOMPLETE: one or more ACs are unmet, partially met, or scoped/masked away.
        - UNVERIFIABLE: you could not verify (repo unavailable, ACs absent/unclear, evidence inaccessible) — say precisely what blocked verification.
      READ-ONLY GUARDRAILS: recommend only. do not change code, do not open/merge/comment on any PR, do not change the ticket status, do not create or edit any issue, do not post more than one ticket comment. you file nothing — you recommend.
      write EXACTLY ONE comment to the ticket, as your FINAL action, shaped like this:
        - first line EXACTLY: "Validation verdict: VALIDATED" (or INCOMPLETE / UNVERIFIABLE) — the token appears here and NOWHERE else in the comment.
        - then a short evidence summary: which ACs you checked and the concrete repo evidence (PR/commit/file) for each.
        - for INCOMPLETE only: a NUMBERED gap list, each item = the unmet AC -> the evidence gap you found -> the recommended next step (including any follow-up ticket you think should exist, described but NOT created).
      TOKEN HYGIENE: state your verdict token exactly once (the lead line) and use none of VALIDATED / INCOMPLETE / UNVERIFIABLE anywhere else. quoting the delivery run's own "PASS"/"FAIL"/"merged" prose as evidence is allowed and safe — those are not this step's vocabulary — but do not invent new verdict-looking tokens.
      SB_PROMPT
      )"