feat: Business task validation — post-execution verification session (VALIDATE-001)

[vybe]

Summary

Add a validation phase after playbook/skill execution that runs a separate, clean-context Claude session to verify the business task was actually completed correctly. This addresses the problem where agent self-validation during execution is unreliable — the agent may claim success without actually completing all checklist items.

Motivation

When an agent runs a playbook (skill), it self-reports completion. But self-validation within the same context is unreliable: the agent may hallucinate success, skip steps, or mark items complete without verification. A clean validation session with a different prompt framing (auditor vs executor) produces more honest assessment.

Design

Validation Flow

Schedule/Trigger → Agent executes playbook → Execution completes
    → Validation session starts (same agent, clean context)
    → Validator reviews execution output + checklist
    → Pass: mark business_status=completed, notify if configured
    → Fail: mark business_status=failed, notify operator, trigger remediation if configured

Validation Session

• Runs on the same agent (has access to the same files, tools, state)
• Uses a clean context (new Claude session, no carry-over from execution)
• Receives as input:
  • The playbook/skill definition (checklist, acceptance criteria)
  • The previous execution's output/response
  • Instruction to validate, not execute — auditor framing
• Produces structured output:
  • pass / fail / partial status
  • Per-checklist-item validation results
  • Evidence for each item (what was checked, what was found)
  • Recommended remediation actions if failed

Business Status (new concept)

Execution records currently have a technical status (completed/failed/timeout). Add a business_status field:

• pending_validation — execution completed, awaiting validation
• validated — validation passed
• failed_validation — validation found incomplete/incorrect work
• skipped — validation not configured for this schedule

Configuration

• Per-schedule toggle: "Enable post-execution validation"
• Validation prompt template (customizable per schedule, with sensible default)
• On-failure action: notify_operator (default), retry_execution, notify_only
• Max validation retries before escalating to operator

Operator Notification

• On validation failure: post to operator queue with full context (execution output, validation results, checklist status)
• If Slack notifications configured: also post to Slack channel
• Operator can: acknowledge, trigger re-execution, or mark as acceptable

Database Changes

Add to schedule_executions:

• business_status TEXT — validation result
• validation_output TEXT — JSON validation details
• validated_at TEXT — timestamp

Add to agent_schedules:

• validation_enabled INTEGER DEFAULT 0
• validation_prompt TEXT — custom validation instructions
• on_validation_failure TEXT DEFAULT 'notify_operator'

UI

• Execution history shows both technical status and business status columns
• Validation results expandable in execution detail view
• Per-checklist-item pass/fail indicators
• Schedule config: validation toggle and settings

Acceptance Criteria

• Validation runs as a separate clean-context session after execution
• Same agent is used (access to workspace/tools)
• Previous execution output is provided as context
• Structured pass/fail result with per-item evidence
• business_status tracked separately from technical status
• Failed validation notifies operator (queue + optional Slack)
• Configurable per schedule
• Execution history UI shows business status

[vybe]

Paused pending #306 (2026-04-20)

Per orchestration simplification re-plan. A clean-context auditor session is a second full Claude session per task — 2x cost — to solve a correctness problem that cheaper primitives (output schemas, post-hoc validators running in-process) may subsume.

Worth re-evaluating after #306 lands because:

• Push-based completion changes what's available to a post-hoc validator (structured result envelope vs. scraped chat).
• Every new trigger type welds itself into the cleanup pyramid; adding this before Tier 2.5 consolidation would make that consolidation strictly harder.

Not cancelled — just paused until we know what the simpler model looks like. Re-open after CAPACITY-CONSOLIDATE and CLEANUP-COLLAPSE ship.

See docs/planning/ORCHESTRATION_RELIABILITY_2026-04.md — Tier 2 (marked paused) and Tier 2.5.