@kungfu-tech/buildchain 2.8.8-alpha.0 → 2.8.8-alpha.2

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

@@ -75,11 +75,25 @@ alpha branch or tag. The repository must create the next upstream anchor line
 explicitly, then run the normal channel promotion flow for that line.
 
 When branch protection requires pull requests, generated version-state commits
-are also routed through pull requests. The action creates an internal
-`buildchain/version-state/...` branch and PR, then stops before moving tags. Once
-that PR is reviewed, checked, and merged, the next promotion run verifies that
-the merge only changed declared version-state files from the legal source
-parent, then moves exact and floating refs.
+must still complete inside the promotion automation. The action updates
+Buildchain-managed channel protection before generated bookkeeping, adds the
+authenticated promotion token user or app to the bypass allowlist, then applies
+the generated version-state commit directly. If GitHub still rejects the direct
+update, promotion fails with a configuration diagnostic instead of opening a
+post-publish human PR.
+
+For Buildchain-owned automation, callers may pass
+`branch-protection-bypass-apps`, `branch-protection-bypass-users`, or
+`branch-protection-bypass-teams`. The action still configures managed
+`dev/vN/vN.M`, `alpha/vN/vN.M`, and `release/vN/vN.M` branches with one
+required approving review, strict GitHub Actions checks, admin enforcement,
+conversation resolution, no force pushes, and no deletions; the bypass
+allowance only lets the named automation identity apply generated version-state
+or channel bookkeeping without a second human review after the reviewed channel
+PR has already merged. Direct action calls automatically include the current
+promotion token's authenticated user or app when GitHub exposes it; explicit
+inputs are supplemental allowlist entries for less discoverable release
+authorities.
 
 ## Publish Transactions
 
@@ -202,7 +216,8 @@ The action outputs `transaction-id`, `transaction-state`,
 `release-passport-state-sha` is the durable ref commit after the generated
 `release-passport/*` files have been uploaded into that recovery ref.
 `finalization-needed=true` means publish evidence is valid, but protected branch
-or ref finalization needs a later promotion run.
+or ref finalization needs a later idempotent promotion run. It must not require
+a human version-state PR.
 Set `github-release: "true"` when the semver promotion should also publish the
 exact-tag GitHub Release. After the release transaction reaches `complete` and
 `finalization-needed` is false, the action creates or updates the GitHub Release
@@ -245,13 +260,14 @@ again, so the consumer-side passport is a complete audit entrypoint. Set
 passport generation.
 
 Finalization recovery is anchored to the durable transaction, not to a single
-workflow run SHA. After a generated version-state PR is merged, the current
-channel head can be a merge commit that contains or corresponds to the recorded
-`release_material_sha`; it does not have to equal the original `source_sha` or
-the transaction `release_sha`. Reruns accept exact tags that already point at
-the transaction release/material SHA or the finalized channel head, and continue
-moving any missing floating tags or dev/alpha refs before marking the
-transaction `complete`.
+workflow run SHA. After generated version-state bookkeeping is applied, the
+current channel head can be the generated version-state commit or a historical
+merge commit that contains or corresponds to the recorded `release_material_sha`;
+it does not have to equal the original `source_sha` or the transaction
+`release_sha`. Reruns accept exact tags that already point at the transaction
+release/material SHA or the finalized channel head, and continue moving any
+missing floating tags or dev/alpha refs before marking the transaction
+`complete`.
 
 Normal reruns accept already-published artifacts only when evidence matches.
 Missing required artifacts can be published on the next run. Conflicting
@@ -289,6 +305,13 @@ while the reusable build trust gate now checks the source-lock channel HEAD and
 merged same-repository PR lineage before heavy build runners start. This action
 still independently rechecks PR lineage, alpha/release tree equivalence, and
 generated version-state verification before moving channel refs and tags.
+The reusable `release-candidate-promote.yml` wrapper defaults
+`branch-protection-bypass-apps` to `github-actions`, so flow-internal promotion
+can complete generated `dev`/`alpha`/`release` bookkeeping while ordinary human
+pushes and PR merges remain governed by the one-review branch protection rule.
+The promotion action also auto-discovers the current token's authenticated user
+or app and adds it to the managed bypass allowlist, so consumers do not have to
+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

package/dist/site/buildchain-contract.json

@@ -4,7 +4,7 @@
   "product": {
     "name": "Buildchain",
     "package": "@kungfu-tech/buildchain",
-    "version": "2.8.8-alpha.0",
+    "version": "2.8.8-alpha.2",
     "repository": "https://github.com/kungfu-systems/buildchain"
   },
   "majorLine": "v2",
@@ -92,7 +92,7 @@
         "GitHub Release passport and evidence publication is delegated to promote-buildchain-ref after the semver release transaction completes"
       ],
       "breakingDigest": "sha256:403d2fcdb0c5eabe749e89102defad69745f70a1556707bec7831fcc2e9fa8f8",
-      "auditDigest": "sha256:320dd5103edabbb9c4e1a9ccdf314db3a74cc9049a7e66bf49a8820286e2cc7d"
+      "auditDigest": "sha256:02d15fd61002e4d3ab8ff279a01592c54b18c7cf4ce4593bb798359024e7eaf1"
     },
     {
       "contractVersion": 1,
@@ -134,7 +134,7 @@
         "semver GitHub Releases are created or updated only after transaction completion, with prerelease/latest metadata derived from the exact tag"
       ],
       "breakingDigest": "sha256:347b65aecd38bc671d8f697eabd15254f905b6f745389d7b26d7595a904a720c",
-      "auditDigest": "sha256:47c7c68b1c81cbe0a6cedb3da2841c33472e25e29b2353267a09e470667bcb93"
+      "auditDigest": "sha256:5d94f56a8abbca8cab057b0d0210cf5cafd50b223be635b537dd902c96b19cf2"
     },
     {
       "contractVersion": 1,
@@ -320,7 +320,7 @@
         "manual entries carry source file digests so downstream sites and agents can detect stale hand-written documentation"
       ],
       "breakingDigest": "sha256:7d0d2819e3a3e72989d9c57b5efe9d0bc0a79bc0f2c82a0c7b9d6c5a211a91f2",
-      "auditDigest": "sha256:65236c3c8d0558544f084ebffdfca2e811fb3d05695faa0d560ce4657c8d7285"
+      "auditDigest": "sha256:4ec7c2d40a5761399bbf966fdac099372d7707952f05baec39ae64ae0da703c0"
     },
     {
       "contractVersion": 1,
@@ -346,5 +346,5 @@
     }
   ],
   "compatibilityDigest": "sha256:36421b592a782decbfe31a7d8d42d70ce1100a56a2c4f4a0ccc21f0617dc72bf",
-  "contractDigest": "sha256:acaaa054295ba87561930e02a5d7ce87ab0ae9f2d139504755432779c6c40904"
+  "contractDigest": "sha256:fe0883948273f534a07d10e19697d28f2f9931597f09884aeb657efb3fbf9b12"
 }