7.4 KiB
name, description, version, author, license, metadata
| name | description | version | author | license | metadata | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| corp-v1-channel-uat | Use when validating a deployed Corp v1 environment through UAT journeys. | 1.3.0 | Hermes Agent | MIT |
|
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
- Maintain a dedicated pnpm E2E repository as the authoritative home for functional non-unit tests and their fixtures, configuration, runner, and evidence contract.
- 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.
- 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.
- Collect machine-readable and human-reviewable evidence.
- Distinguish product failures, environment failures, and test defects.
- Return product/environment failures to Kanban and Delivery with reproducible evidence.
- Rerun the affected journey set after a verified redeployment.
- Hand a
UAT_PASSEDorUAT_FAILEDverdict to Releases without implying release approval.
Required E2E repository pipeline
Every project UAT repository uses two Gitea Actions workflows:
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
- Verify the Delivery handoff and freeze the deployment identity.
- Select journeys by explicit tags or release scope; never silently omit a required journey.
- Run the repository's pnpm/Taskfile validation and Playwright suite.
- Preserve JUnit/JSON results, traces, screenshots on failure, browser/project matrix, start/end time, and target identity.
- Classify every failure and publish the smallest reproducible report.
- Route implementation or environment defects back to Delivery through the project's Kanban process.
- Rerun after Delivery supplies a new verified deployment identity.
- Send the final UAT verdict and evidence index to Releases.
Evidence minimum
Every reported run includes:
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.