I. Skill Overview

Core Governing Principles

1. Alpha/Nightly pipelines trigger automatically every 12 hours, or via manual user invocation.
2. Beta releases are manually triggered via Discord, built from pre-validated Alpha or release branches.
3. Stable/Latest production releases always require explicit human operator approval.
4. Releases must never be created from dirty working checkouts or directly off the main branch.
5. Publishing only proceeds after all validation gates on the dedicated release branch pass completely.
6. After a successful Alpha publish, all bugfix commits from the release branch are forward-ported back to main, with validation confirming main CI returns fully green status.

II. Core Functional Capabilities

1. Branch Naming & Versioning Standards

• Branch Prefix: tideclaw/alpha/
• Full Branch Name: tideclaw/alpha/YYYY-MM-DD-HHMMZ
• Base Reference: The exact commit SHA of origin/main captured at trigger time
• Release Git Tag: vYYYY.M.PATCH-alpha.N
• npm Distribution Tag: alpha

PATCH Version Logic

1. Increment the highest PATCH value from all stable/beta releases by 1 to initialize a new train, then iterate the alpha.N suffix within that train.
2. If an active beta track already exists for the target PATCH number, the new Alpha build shifts to the next sequential monthly PATCH train.

2. Pipeline Initialization Workflow

3. Reuse Prior Stabilization Fixes

1. Load the Tideclaw persistent state file from $release-private to retrieve the last successfully published Alpha branch and associated fix commit SHAs.
2. Enumerate all Tideclaw Alpha branches created within the trailing 3-day UTC window.
3. For each candidate branch, identify commits absent from the current origin/main HEAD.
4. Cherry-pick only stability-critical bugfix commits; skip version bumps, changelog release entries, Git tag artifacts, auto-generated release notes, state-file-only commits, and debug instrumentation logic.
5. Resolve cherry-pick merge conflicts: If an equivalent fix already exists on main, skip the commit; otherwise apply minimal conflict resolution logic to retain core fix behavior.

4. Iterative Repair Loop

1. Execute narrow-scoped local validation gates first: incremental change tests, release preflight checks, type/lint/build validation suites.
2. If local checks fail, apply minimal targeted corrective commits directly on the active Alpha branch.
3. Re-run the failed validation suite after every corrective commit iteration.
4. Never mask failures by modifying baseline expectation files, expected-failure lists, ignore rules, or release inventory manifests unless the official release documentation explicitly authorizes the change with documented justification.
5. Classify flaky test failures: Re-run the failing suite once; if the failure persists on the second run, treat it as a legitimate blocking defect.
6. Preserve small, easily forward-portable fixes if the patch delivers clear tangible value to the upstream main branch.

5. Release CI Orchestration

1. Calculate the next sequential vYYYY.M.PATCH-alpha.N tag by scanning existing Git tags, published npm package versions, and GitHub release records.
2. Align the package version and release metadata of the Alpha branch to match the computed tag, commit the changes, and push the branch to the remote repository.
3. Dispatch release validation workflows via the official GitHub CLI; raw browser/fetch HTTP clients are not used for API orchestration.
4. All write operations (workflow dispatch, job cancellation, publish pipeline triggering) on the Tideclaw host utilize the dedicated binary /usr/local/bin/gh-tideclaw-write.

Gate Classification

• Blocking Gates (mandatory full pass to proceed): Core CI validation, plugin prerelease audit, npm preflight checks, package preparation, install smoke tests, Git tag reachability validation, publishing integrity verification
• Advisory Gates (non-blocking, only report failures to Discord): Cross-OS compatibility checks, live channel integration tests, QA Lab validation, package acceptance audits, long-running Docker E2E suites, Telegram package delivery E2E validation

6. Release Validation & Official npm Publishing

1. After the full release validation and npm preflight workflows return green status on the identical branch HEAD commit, create and push the official release Git tag from that exact commit.

2. Dispatch the production publish wrapper workflow targeting the same Alpha branch, referencing the successful npm preflight run ID and full release validation run ID.
3. Direct npm publishing is prohibited from the Tideclaw host machine; all package delivery leverages GitHub Actions OIDC authentication.
4. The openclaw-npm-release.yml workflow with preflight_only=true only builds and stages package artifacts without publishing. A subsequent invocation of the openclaw-release-publish.yml wrapper is required to complete public registry delivery.

7. Post-Publish Alpha Completion Validation

1. Corresponding Git tag exists on the remote repository
2. Matching GitHub Release record exists and is marked as a prerelease
3. Release body contains hyperlinks to the npm version page, registry tarball, cryptographic integrity hash, and full CI/proof audit trail
4. npm view openclaw@<version> returns the exact published version, alpha distribution tag, tarball artifact, integrity checksum, and official publish timestamp
5. Local install/package smoke tests pass per repository release documentation specifications
6. The Tideclaw persistent state file logs the released version, Git tag, base commit SHA, target branch, fix commit SHAs, all associated workflow run IDs, npm integrity hash, and completion timestamp

8. Forward-Port Backmerge Workflow

1. Create a new forward-port branch originating from the current origin/main HEAD.
2. Cherry-pick only the pure stability fixes that resolved Nightly/release validation failures.
3. Exclude all commits containing Alpha version bumps, changelog release entries, release note generation logic, Git tag artifacts, auto-generated release assets, and state-file-only modifications.
4. Split mixed commits containing both valid fixes and release/version metadata changes: Reapply only the fix-related code hunks to the forward-port branch.
5. Resolve merge conflicts by implementing minimal, main-compatible fix logic.
6. Push the forward-port branch and open a pull request; wait for the full main branch CI suite to return green status.
7. Log the final PR and merge commit SHA, alongside an inventory of commits intentionally excluded from forward-porting.

9. Branch Retention & Cleanup Policy

1. Preserve all branches created within the trailing 3-day UTC window.
2. Retain branches referenced by active running workflows, open pull requests, published release tags, or persistent state file records.
3. Only delete Tideclaw-owned Alpha branches; human-authored branches, beta release branches, stable production branches, and branches with unrecognized prefixes are never removed.

10. Discord Manual Trigger Commands

Alpha Release Triggers (usable in #releases or #maintainers channels)

• @Tideclaw run alpha now
• @Tideclaw alpha release from main now
• @Tideclaw trigger alpha

1. Create a brand-new branch named tideclaw/alpha/YYYY-MM-DD-HHMMZ based on the latest origin/main commit.
2. Execute the full standard Alpha release pipeline sequence.
3. Halt execution and output a warning if any active Alpha/Beta/Stable release workflow is already running.
4. Triggers sent to the #maintainers channel require explicit @Tideclaw bot mention syntax.

Beta Release Triggers

• @Tideclaw beta release from vYYYY.M.PATCH-alpha.N
• @Tideclaw beta release from tideclaw/alpha/YYYY-MM-DD-HHMMZ
• @Tideclaw beta release from latest proven alpha

1. Command must include the exact phrase beta release alongside a source Alpha tag/branch reference, or the keyword latest proven alpha.
2. Create a dedicated Beta branch originating from the pre-validated Alpha source reference.
3. Beta version format: vYYYY.M.PATCH-beta.N, paired with the npm beta distribution tag.
4. Publishing leverages GitHub Actions OIDC authentication; direct npm publishing from the host machine is forbidden.

III. Primary Applicable Use Cases

1. Automated 12-Hour Nightly Alpha Releases
    
   Automatically run Alpha/Nightly build pipelines every 12 hours, ensuring open-source community access to up-to-date development snapshots.
2. On-Demand Manual Alpha Pipeline Invocation
    
   Maintainers can trigger full Alpha release workflows at any time via Discord commands, creating isolated dedicated branches from the current main branch and executing the complete release sequence.
3. Pre-Stable Beta Release Preparation
    
   Launch Beta release pipelines from pre-audited Alpha builds to prepare validated candidates for full stable production deployment.
4. Release Branch Iterative Bug Remediation
    
   Run local validation suites and iterative repair loops on Alpha/Beta release branches to ensure release candidates clear all mandatory quality gates.
5. Post-Release Forward-Port Synchronization
    
   After successful Alpha/Beta publishing, backport only stabilization fix commits to the upstream main branch to keep core development code synchronized with release branch improvements.

IV. Cross-Skill Integration Matrix

V. Critical Governing Rules

1. Isolated Branch Mandate: All Alpha pipeline operations must execute on segregated tideclaw/alpha/ branches, preventing transient main branch failures from blocking Nightly distribution.
2. No Dirty Checkout Publishing: Releases are never dispatched from uncommitted dirty working tree states.
3. No Direct Main Branch Publishing: All standard release workflows run on dedicated offshoot branches, never directly on the main branch.
4. Forward-Port PR Restriction: Backport pull requests exclusively contain stabilization bugfixes; exclude Alpha version bumps, release notes, changelog entries, Git tag artifacts, auto-generated assets, and state-file modifications.
5. Dedicated Bot Commit Identity: Configure git user identity for all automated commits:

6. Protected Main Branch Safety: Never push commits directly to the protected main branch; all forward-port changes are delivered via pull request + automated merge workflows.
7. Secret Redaction Rule: No raw secret credentials are printed in any logs or output streams.
8. Pipeline Termination Conditions: The workflow aborts execution if any of the following conditions are met:
   • Release documentation/scripts contain conflicting version or publishing path specifications
   • Mandatory required secrets/auth credentials are unavailable
   • GitHub Actions workflow dispatch or event observation fails
   • Mandatory release gates remain failing after legitimate targeted fix attempts
   • npm/GitHub published state exhibits inconsistent metadata post-publish
   • Forward-port pull request cannot pass CI without requiring large-scale product-level design changes

VI. Summary