111 lines
5.2 KiB
Markdown
111 lines
5.2 KiB
Markdown
---
|
|
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
|
|
|
|
|
|
## 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 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)
|