From d857989111671c7a607a8acc0e7d047af03127ef Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Mon, 27 Apr 2026 05:13:35 +0100 Subject: [PATCH] docs: clarify package acceptance release role --- .agents/skills/openclaw-testing/SKILL.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/.agents/skills/openclaw-testing/SKILL.md b/.agents/skills/openclaw-testing/SKILL.md index 36020eecea6..441e6b589f3 100644 --- a/.agents/skills/openclaw-testing/SKILL.md +++ b/.agents/skills/openclaw-testing/SKILL.md @@ -234,6 +234,13 @@ Use the manual `Package Acceptance` workflow when the question is "does this installable package work as a product?" rather than "does this source diff pass Vitest?" +In release validation, treat Package Acceptance as the package-candidate shard +inside the larger release umbrella, not as a competing full-test path. Full +Release Validation and private release gauntlets should call Package Acceptance +for tarball resolution, Docker product/package proof, and optional Telegram QA +against the same resolved `package-under-test` artifact; keep orchestration, +secret policy, blocking/advisory status, and evidence rollup in the caller. + Good defaults: ```bash