@kungfu-tech/buildchain 2.11.14-alpha.5 → 2.11.14-alpha.7

package/AGENTS.md

@@ -24,6 +24,17 @@ uses: kungfu-systems/buildchain/actions/promote-buildchain-ref@v2
 uses: kungfu-systems/buildchain/.github/workflows/.build.yml@v2
 ```
 
+Consumers intentionally following the alpha channel should pair the workflow
+shell with the matching floating ref:
+
+```yaml
+uses: kungfu-systems/buildchain/.github/workflows/.build.yml@v2-alpha
+```
+
+The reusable workflow derives its runtime from that called-workflow ref.
+Passing `buildchain-ref: v2-alpha` explicitly is also accepted as an official
+channel selection; it is not treated as a train or exact-SHA override.
+
 For new repositories, prefer the CLI:
 
 ```sh

package/actions/promote-buildchain-ref/README.md

@@ -6,18 +6,18 @@ compatibility refs from buildchain release channels:
 - `alpha/v2/v2.0` creates or reuses the next exact prerelease tag such as
   `v2.0.1-alpha.0`, writes that version into package version state, points the
   alpha and dev channel branches at the version commit, then promotes
-  `v2.0-alpha`;
+  `v2.0-alpha` and, when this is the highest published alpha minor, `v2-alpha`;
 - `release/v2/v2.0` creates or reuses the next exact release tag such as
   `v2.0.0`, writes that version into package version state, points the release
   channel branch and release tags at the release commit, then prepares a second
   source commit for the next exact prerelease tag such as `v2.0.1-alpha.0` and
   points the alpha/dev channel branches plus `v2.0-alpha` at that prerelease
-  commit;
+  commit, and moves `v2-alpha` only if no higher v2 minor has published an alpha;
 - `publish-gate/major` accepts a reviewed PR from a production release line such
   as `release/v2/v2.0`, writes the next major production version such as
   `v3.0.0`, points `publish-gate/major`, `release/v3/v3.0`, `v3.0`, and `v3`
   at that release commit, then prepares `v3.0.1-alpha.0` for
-  `alpha/v3/v3.0`, `dev/v3/v3.0`, and `v3.0-alpha`. The older `major-gate`
+  `alpha/v3/v3.0`, `dev/v3/v3.0`, `v3.0-alpha`, and `v3-alpha`. The older `major-gate`
   branch name is a compatibility alias only.
 
 The release branch name defines the minor line. For example,
@@ -359,11 +359,14 @@ declare the same release authority twice.
 The tag names intentionally follow the old ABV release semantics:
 exact release tags are `vX.Y.Z`, exact alpha tags are `vX.Y.Z-alpha.N`, floating
 release tags are minor/major tags such as `v2.0` and `v2`, and floating alpha
-tags are minor-line tags such as `v2.0-alpha`. Bare tags such as `1.0.0` are not
+tags are minor-line tags such as `v2.0-alpha` plus cross-minor major tags such
+as `v2-alpha`. A major alpha tag only moves for the highest minor in that major
+with a published alpha, so older-line maintenance cannot roll consumers back.
+Bare tags such as `1.0.0` are not
 maintained as buildchain release entrypoints.
 
 Repository rulesets should protect exact tags, not every `v*` tag. A ruleset
-such as `refs/tags/v*` also protects floating channel tags like `v2.0-alpha`,
+such as `refs/tags/v*` also protects floating channel tags like `v2.0-alpha` and `v2-alpha`,
 which Buildchain must update after exact tags and publish evidence are durable.
 Use an exact-tag rule such as `refs/tags/v*.*.*` for immutable evidence tags and
 leave floating channel tags mutable for the promotion token.

package/dist/site/buildchain-contract.json

@@ -4,7 +4,7 @@
   "product": {
     "name": "Buildchain",
     "package": "@kungfu-tech/buildchain",
-    "version": "2.11.14-alpha.5",
+    "version": "2.11.14-alpha.7",
     "repository": "https://github.com/kungfu-systems/buildchain"
   },
   "majorLine": "v2",
@@ -50,7 +50,7 @@
         "retryable GitHub fallback fetches use a bounded attempt budget before exact source SHA and tree verification"
       ],
       "breakingDigest": "sha256:a6a35370d6b0d0f46e1b2712dcc01961fe53c2febde95409a27a485c10a36650",
-      "auditDigest": "sha256:51ae2f281edc42b6d825976cdc3312a0e42e968e7eb71bef68cd4b30bc7cd382"
+      "auditDigest": "sha256:d07b446c85a29ba854baa8438d6f7aca15ebccaf7673527d6a1d2912b2fb66e6"
     },
     {
       "contractVersion": 1,
@@ -141,7 +141,7 @@
         "channel-aware artifact host facts are checked against the deploy plan before adapter side effects"
       ],
       "breakingDigest": "sha256:da569f90374e878948e3d5160ed9929338ce0572473ca8ee54867b0fe1aaeace",
-      "auditDigest": "sha256:a229811cdba006d4d04cec00e7df7a7363bbe2bf45e8429790f7f98b34f8be34"
+      "auditDigest": "sha256:9834ea899b16cb5603551df460b9e62fa4229c320d13f91a2353b696563fe07c"
     },
     {
       "contractVersion": 1,
@@ -442,7 +442,7 @@
         "manual entries carry source file digests so downstream sites and agents can detect stale hand-written documentation"
       ],
       "breakingDigest": "sha256:7d0d2819e3a3e72989d9c57b5efe9d0bc0a79bc0f2c82a0c7b9d6c5a211a91f2",
-      "auditDigest": "sha256:122883035b7031a7ad9da0efe72d37c527b9cecc7f4eb896932fe411d9b6a821"
+      "auditDigest": "sha256:ea66c5781a32f641938a7b3b6554eec6e26e6beda67b549c4b9485c6c1a6b776"
     },
     {
       "contractVersion": 1,
@@ -468,5 +468,5 @@
     }
   ],
   "compatibilityDigest": "sha256:1396e42444aaf3f26a40121faf3d599eb9db13537f627fc8dbcef2475af8af44",
-  "contractDigest": "sha256:ccd926bd34136b4fba29e4d62c51bc5c60b97e2e6f5e1383040113531b542395"
+  "contractDigest": "sha256:cac32376b91ac2f828d7e9053bbb678d4e2a1d8503f2cd1c2252a04277b37623"
 }