---
name: corp-v1-channel-uat
description: Use when validating a deployed Corp v1 environment through UAT journeys.
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [corp-v1, discord, channel, uat, e2e, playwright, acceptance]
---

# Corp v1 UAT Channel

## When to Use

Use this skill when a Corp v1 project needs a distinct UAT stage between Delivery and Releases, a versioned E2E journey repository, or acceptance evidence tied to an exact deployed environment. Do not use it for application implementation, cluster deployment, or release approval.

## Purpose

The UAT channel owns repeatable end-to-end acceptance testing against an already deployed environment. It sits after Delivery and before Releases.

UAT does not build application images, change manifests, synchronize Argo CD, patch workloads, or approve a release. It verifies user-visible behavior and returns evidence tied to an exact deployed revision.

## Required input gate

Do not start a run until Delivery provides:

- application repository and exact commit;
- immutable OCI image digest for every tested workload;
- deployable GitOps repository and exact commit;
- Argo CD Application name, synchronized revision, sync state, and health state;
- target environment and base URL;
- deployment timestamp and relevant task/feature/release identity;
- known limitations and required test-data preconditions.

If any identity is mutable, missing, or contradictory, record `BLOCKED` rather than testing an unknown deployment.

## Responsibilities

1. Maintain a dedicated pnpm E2E repository with versioned journeys.
2. Execute journeys against the exact deployed environment supplied by Delivery.
3. Collect machine-readable and human-reviewable evidence.
4. Distinguish product failures, environment failures, and test defects.
5. Return product/environment failures to Kanban and Delivery with reproducible evidence.
6. Rerun the affected journey set after a verified redeployment.
7. Hand a `UAT_PASSED` or `UAT_FAILED` verdict to Releases without implying release approval.

## UAT verdicts

These verdicts are acceptance dimensions; they do not replace the project's canonical Task status:

- `NOT_READY` — deployment evidence is incomplete.
- `READY_FOR_UAT` — the exact deployment gate is satisfied.
- `UAT_IN_PROGRESS` — a run is active against the frozen deployment identity.
- `UAT_FAILED` — one or more required journeys failed.
- `UAT_PASSED` — every required journey passed for the frozen identity.
- `BLOCKED` — execution cannot proceed for a recorded external reason.

A new application image, GitOps commit, Argo CD revision, or materially changed environment invalidates an earlier verdict and requires a new run identity.

## Workflow

1. Verify the Delivery handoff and freeze the deployment identity.
2. Select journeys by explicit tags or release scope; never silently omit a required journey.
3. Run the repository's pnpm/Taskfile validation and Playwright suite.
4. Preserve JUnit/JSON results, traces, screenshots on failure, browser/project matrix, start/end time, and target identity.
5. Classify every failure and publish the smallest reproducible report.
6. Route implementation or environment defects back to Delivery through the project's Kanban process.
7. Rerun after Delivery supplies a new verified deployment identity.
8. Send the final UAT verdict and evidence index to Releases.

## Evidence minimum

Every reported run includes:

```text
run_id
journey_repository + exact commit
application_repository + exact commit
image digests
GitOps repository + exact commit
Argo CD application + synchronized revision + sync/health
base URL and environment
journey IDs/tags and browser matrix
started_at + completed_at
result counts
artifact paths/URLs
failure classification and linked defect/task
verdict
```

Do not publish credentials, cookies, tokens, personal test data, videos containing secrets, or raw environment dumps.

## Authority

UAT may autonomously run approved journeys, collect evidence, identify reproducible defects, maintain test implementation, and issue a verdict grounded in complete evidence.

UAT must not modify product requirements, application behavior, deployment desired state, cluster resources, release allocation, release approval, or canonical Task lifecycle to make a test pass.

## References

- [Journey repository contract](references/journey-repository-contract.md)
- [Deployment evidence contract](references/deployment-evidence-contract.md)
- [Defect and retest workflow](references/defect-and-retest-workflow.md)
- [Status and reporting](references/status-and-reporting.md)