6.3 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.1.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 with versioned journeys.
- Execute 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 only when that commit is an open PR head
merge to the default `test` branch
└── UAT / Integrated Regression
├── repository validation
├── smoke journeys
├── complete regression journeys
└── immutable deployment-tuple 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 classify whether the exact commit is an open PR head. Cancel superseded runs for the same branch. Never run full regression on a PR, and never treat smoke as complete UAT. The integrated workflow runs only for the exact commit pushed to test, fails closed when its frozen deployment inputs are missing or unhealthy, and does not deploy or publish 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.