134 lines
7.4 KiB
Markdown
134 lines
7.4 KiB
Markdown
---
|
|
name: corp-v1-channel-uat
|
|
description: Use when validating a deployed Corp v1 environment through UAT journeys.
|
|
version: 1.3.0
|
|
author: Hermes Agent
|
|
license: MIT
|
|
metadata:
|
|
hermes:
|
|
tags: [corp-v1, discord, channel, uat, e2e, playwright, acceptance]
|
|
---
|
|
|
|
# Corp v1 UAT Channel
|
|
|
|
|
|
## Hermes Kanban direct-link contract
|
|
|
|
Whenever a response mentions a Hermes Kanban board, initiative, card, or task, it must include a direct dashboard link in the form `[descriptive board label](<dashboard-public-url>/kanban?board=<board-slug>)`. Resolve the dashboard public URL and exact board slug before reporting; never provide only a board name, slug, card count, “visible cards,” or “available in the dashboard.” If no task-specific deep link exists, link the board and include the exact task ID or title in the same statement. Project-adopted skills must replace this generic form with their verified project board URL.
|
|
|
|
## 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 as the authoritative home for functional non-unit tests and their fixtures, configuration, runner, and evidence contract.
|
|
2. Keep application image/container/Helm build, rendering, publication, and static artifact validation in Delivery. The E2E repository must not build/publish application images, install Helm, render charts, or validate artifact publication.
|
|
3. Execute source-coupled functional non-unit suites against an exact application-source checkout and black-box journeys against the exact deployed environment supplied by Delivery.
|
|
4. Collect machine-readable and human-reviewable evidence.
|
|
5. Distinguish product failures, environment failures, and test defects.
|
|
6. Return product/environment failures to Kanban and Delivery with reproducible evidence.
|
|
7. Rerun the affected journey set after a verified redeployment.
|
|
8. Hand a `UAT_PASSED` or `UAT_FAILED` verdict to Releases without implying release approval.
|
|
|
|
## Required E2E repository pipeline
|
|
|
|
Every project UAT repository uses two Gitea Actions workflows:
|
|
|
|
```text
|
|
non-default branch push
|
|
└── CI / Change Validation
|
|
├── repository validation for every exact pushed commit
|
|
└── smoke journeys for explicit PR events or exact review-associated commits
|
|
|
|
merge to the default `test` branch
|
|
└── UAT / Integrated Regression
|
|
├── repository validation
|
|
├── smoke journeys
|
|
├── complete regression journeys
|
|
└── structured regression evidence
|
|
```
|
|
|
|
Use one change workflow for both pre-PR branches and PR heads. A PR-open or PR-reopen event adds the first smoke-bearing run. Do not subscribe that workflow to `pull_request.synchronize`; later branch pushes are the single trigger and compare the exact commit with Gitea pull-request head refs without exposing a broad API token to candidate-controlled code. Gitea retains those refs after closure, so an unchanged closed-PR head may conservatively receive smoke again; a new branch-only commit receives repository validation only. Cancel superseded change runs for the same branch. Never run full regression on a PR, and never treat smoke as complete UAT.
|
|
|
|
Integrated regression runs only for exact commits pushed to `test`; they queue rather than cancel one another so every merged commit receives a result. This automatic run proves the integrated journey set against the configured non-production URL but does not issue `UAT_PASSED`. A release-facing UAT verdict requires a separately frozen Delivery handoff plus pre-run and post-run live verification of application commit, image digests, deployable GitOps commit, Argo CD revision/sync/health, environment, and base URL. Neither workflow deploys or publishes application artifacts.
|
|
|
|
## 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)
|