Extended-stable and changelog-only validation

Extended-stable validation

Extended-stable validation uses the same candidate-owned helper: the exact source candidate C also owns qualification Q=C. Independently trusted P admits and verifies that request. Keep those roles and the canonical release context separate; deliberately backport missing qualification contracts before freezing C.

VALIDATION_SHA="<exact-candidate-sha>"PUBLISHER_SHA="<recorded-full-trusted-main-ancestor-sha>"CONTEXT_REF="extended-stable/YYYY.M.33"pnpm ci:full-release \  --sha "$VALIDATION_SHA" \  --target-ref "$CONTEXT_REF" \  --admission-workflow-sha "$PUBLISHER_SHA" \  --admission-workflow-ref main \  -f validation_purpose=publish \  -f publication_selection_json='{"route":"extended-stable","npmDistTag":"extended-stable","publishOpenclawNpm":true,"pluginPublishScope":"all-publishable","plugins":[]}' \  -f release_profile=stable \  -f run_release_soak=true \  -f fail_fast=false \  -f rerun_group=all \  -f reuse_evidence=false \  -f dispatch_release_evidence=false

After independent admission, the helper creates release-ci/<Q-prefix>-<unique-id> at Q=C and dispatches from that immutable named branch. It passes the exact candidate as ref and expected_sha, with the canonical branch in target_context_ref. GitHub workflow dispatch --ref accepts a branch or tag, not a raw SHA. The release branch supplies context, not qualification authority. Never create the transport ref manually or substitute a moving-main harness.

The shared publisher requires admitted candidate-owned evidence, complete rerun_group=all coverage, and the exact successful attempt. Its protected release-publish/* ref selects P, not Q. Publication-tooling updates do not change the frozen candidate or qualification identities. Retained historical cross-revision requests keep their original recovery contract; new explicit main/protected diagnostic runs cannot replace Q=C publication proof.

Product or qualification-harness repairs change C/Q and require new qualification. Provider, approval, or runner recovery retains the original identities and inputs. Do not omit required package, installer, update, channel, or live behavior because the target is old.

For a regular release whose qualified Code SHA already contains final notes, use that same commit as the Release SHA. Retain its successful full validation parent and exact prepared publication artifacts; no extra commit or validation run is needed solely to separate those roles.

If notes change after qualification, commit the selected release entry and its permitted record/index updates as a new Release SHA and run the same helper for that commit. Product evidence reuse is optional and requires GitHub to prove that the Release SHA descends from the green Code SHA. The complete changed path set must include CHANGELOG/YYYY.M.PATCH.md and may also include only CHANGELOG.md and CHANGELOG/records/YYYY.M.PATCH.md. Entry/record additions or modifications are allowed; the root index may only be modified. Renames, deletions, other release files, and docs source edits do not qualify. This path records split-changelog-release-v1; historical root-only receipts retain their changelog-only-release-v1 contract. Reuse still qualifies the changed package and image bytes. Any other source change returns to full Code validation. See Releasing for the publication sequence.

The conceptual phases map to current inputs:

• beta-publish: release_profile=beta, run_release_soak=false
• postpublish-confidence: validation_purpose=postpublish-confidence, no publication selection, exact published package plus run_release_soak=true or explicit focused groups
• stable-publish: release_profile=stable

For an actual beta package on its matching canonical release branch or beta tag, all with release_profile=beta and no soak records coveragePolicy=npm-beta-v1. It retains Linux, macOS, and Windows Node checks, Control UI, plugins, package integrity, install/update acceptance, Linux/Windows/macOS cross-OS package checks, QA parity, core runtime-pair/restart proof, and runtime tool coverage. Native app qualification, product performance, and published-package Telegram confidence are deferred. Broad live/E2E and QA-live also remain outside this bounded gate.

Run deferred confidence against the exact published beta with run_release_soak=true, or select ci, performance, npm-telegram, package, or the relevant QA/live group explicitly. Selected children must still finish and pass their existing policy; a deferred check is not run, never passed. Stable, full, soak-enabled, and focused validation retain their existing confidence coverage. main and non-beta targets do not qualify for npm-beta-v1.

For a regular final package on its matching release branch or tag, all with release_profile=stable records coveragePolicy=npm-stable-v1 and uses CI's npm-stable scope. Numeric corrections qualify, including an unchanged base package whose base tag resolves to the same source SHA. This policy defers only macOS Swift/OpenClawKit, iOS/Watch, Android, and native i18n. Linux, macOS, and Windows Node coverage, Control UI, plugins, package and installer acceptance, QA, stable soak, and blocking product performance remain required. Extended-stable, main without release context, full, and explicit ci runs retain full CI. Evidence reuse requires the same coverage policy, exact package version, target context, and effective inputs; a beta or historical full receipt cannot silently replace stable npm qualification.

Native publication owns the deferred qualification. For an npm-stable release, OpenClaw Release Publish starts an exact-source full CI run with Android enabled in parallel with core publication. Only successful native qualification and core publication permit the separate Android job to issue a v3 approval receipt and dispatch the tag-owned APK publisher. The receipt binds the exact native CI run, attempt, and tooling ref. The publisher rechecks that proof before writing approval, immediately before dispatch, before APK attestation, and before each asset upload. Frozen tags without the v3 consumer, including v2026.8.2 and its same-source corrections, must use release_profile=full; publication rejects npm-only evidence for those targets before starting core publication. Their historical full-validation route retains the v2 approval contract. Native failures are recorded and block Android approval, while core npm publication and GitHub release finalization remain independent. The parent may remain active for native work after core publication completes. macOS retains its separate native validation, signing, notarization, and promotion gates. Stable npm publication still rejects evidence without soak and blocking product performance.

macOS app signing, notarization, appcast publication, and Windows Hub asset promotion run in parallel with or after npm publication and never delay npm. Their own artifact validation and promotion gates still apply; Windows Hub assets remain required before the regular GitHub release leaves draft.

Package Acceptance normally builds the candidate tarball from the resolved ref, including full-SHA runs dispatched with pnpm ci:full-release. After a beta publish, pass release_package_spec=openclaw@YYYY.M.PATCH-beta.N to reuse the shipped npm package across release checks, Package Acceptance, cross-OS, release-path Docker, and package Telegram. Use package_acceptance_package_spec only when Package Acceptance should intentionally prove a different package. The Codex plugin live package lane follows the same state: published release_package_spec values derive codex_plugin_spec=npm:@openclaw/codex@<version>; SHA/artifact runs pack extensions/codex from the selected ref; and operators can set codex_plugin_spec directly for npm:, npm-pack:, or git: plugin sources. The lane grants the explicit Codex CLI install approval required by that plugin, then runs Codex CLI preflight and same-session OpenAI agent turns. Its final zero-retry, medium-thinking turn sends visible progress with omitted Codex final, reads randomized workspace inputs, writes their exact artifact, and sends explicit completion. This catches the v2026.7.1 regression where an ordinary progress send terminated the turn.

Selected source Telegram QA and standalone npm Telegram tests must pass before normal release validation can pass. Selected Package Acceptance Telegram must also pass in every profile. Missing credentials, an exhausted pool, and failed attempts do not count as successful proof. Exact candidate identity, credential isolation, and lease cleanup remain required.

Package Acceptance Telegram E2E is automatically deferred for every beta-profile all run without soak, including beta-profile checks of main. The effective skip_package_telegram_e2e=true is captured in the inputs and summary as not run. Soak-enabled runs and explicit rerun_group=package keep Telegram selected by default. The existing -f skip_package_telegram_e2e=true input remains available for an explicit beta deferral; it is rejected for stable and full and does not disable the focused rerun_group=npm-telegram workflow.

Selected-test requirements are separate from explicit omissions. The reviewed Telegram-only exceptions are 2026.8.1-owner-approved and 2026.9.1-owner-approved. The reviewed Telegram and Matrix QA-live exceptions are 2026.9.5-owner-approved, 2026.9.7-owner-approved, 2026.9.8-owner-approved, and 2026.9.9-owner-approved. Pass the selected value with -f telegram_waiver=<value>. Any future exception requires a reviewed code change; a matching <target-version>-owner-approved string alone is not authorization. The value must name the validated target's actual package.json version, the sealed candidate version must match, and the profile must be stable or full. Beta, prerelease, and unlisted targets are rejected. Package-spec overrides must be exactly openclaw@<target-version>; blank specs select the sealed candidate. It omits source Telegram QA, Package Acceptance Telegram E2E, and the published-package Telegram E2E; their evidence states waived / not run, never passed. Telegram unit tests and every other selected gate remain active, including stable soak and performance checks. An explicit Telegram rerun or suite filter, including an aggregate such as qa-live or qa-live-non-slack that selects Telegram, conflicts with the waiver and is rejected. The declaration and target version bind the immutable execution plan, manifest, and reuse identity; the publisher carries the waiver into release verification notes. The beta-only package deferral above remains unchanged.

Source Telegram QA uses the release checks' shared context check: an exact candidate SHA must remain an ancestor of its canonical branch, or equal its release tag. Both build and execution admission independently repeat that check and retain candidate-version, signature/merge-attribution, and live maintainer checks. Advancing a release branch does not select a new candidate or invalidate the old one.