(magpie) branch main updated: refactor(skills): make the fix-released → REVIEW push atomic and non-deferrable (#767)

[po...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/magpie.git


The following commit(s) were added to refs/heads/main by this push:
     new 7bd8ce92 refactor(skills): make the fix-released → REVIEW push atomic and non-deferrable (#767)
7bd8ce92 is described below

commit 7bd8ce9210506f52fc96be34d2da5a695dd910ae
Author: Jarek Potiuk <ja...@potiuk.com>
AuthorDate: Tue Jul 7 01:10:09 2026 +0200

    refactor(skills): make the fix-released → REVIEW push atomic and non-deferrable (#767)
    
    The `pr merged → fix released` transition in security-issue-sync must
    regenerate + push the CVE JSON (allocated → review-ready) in the same
    apply pass as the label flip — never deferred to a later sync or a
    separate confirmation. A tracker labelled `fix released` whose CVE
    record is still DRAFT strands the release manager (gated on REVIEW)
    and silently stalls the advisory.
    
    - apply-and-push.md (Step 5b): add the atomicity rule and the single
      acceptable deferral (unavailable session → manual-paste hand-off +
      explicit "still DRAFT" blocker, never silent).
    - bulk-mode.md: clarify the CVE-affecting-bucket confirmation gate is
      for body-field content judgment only; the mechanical DRAFT→REVIEW
      state push rides the fix-released label-flip confirmation.
    
    Surfaced by the 2026-07-06 Apache Airflow sync, where 8 trackers
    advanced to `fix released` but their CVE records stayed DRAFT on
    Vulnogram until a separate manual push.
    
    Generated-by: Claude Code (Opus 4.8)
    
    Co-authored-by: Tester <t...@example.com>
---
 skills/security-issue-sync/apply-and-push.md | 28 ++++++++++++++++++++++++++++
 skills/security-issue-sync/bulk-mode.md      | 18 ++++++++++++++++++
 2 files changed, 46 insertions(+)

diff --git a/skills/security-issue-sync/apply-and-push.md b/skills/security-issue-sync/apply-and-push.md
index 0c9feb36..a3a5f67a 100644
--- a/skills/security-issue-sync/apply-and-push.md
+++ b/skills/security-issue-sync/apply-and-push.md
@@ -489,6 +489,34 @@ transition. This is the load-bearing gate for the release-manager
 hand-off (see Step 2b's *Two-stage gate*): the RM never receives
 the hand-off comment while the record is still in `allocated`.
 
+**The `pr merged → fix released` transition performs this push in
+the same apply pass — it is not deferrable.** When a sync run
+advances a tracker `pr merged → fix released`, the label flip and
+this 5a-regen + 5b-push are **one atomic unit**: the user's
+confirmation of the transition authorises the push, and both land in
+the same apply pass. The `fix released` label is in the generator's
+forward-state set (`compute_cna_private_state`), so the regenerated
+JSON carries `review-ready`, and the push advances the record
+`allocated → review-ready` — the very action that unblocks and
+performs the hand-off. Do **not** park the push behind a second
+confirmation, and do **not** defer it on the reasoning that "the
+release manager will promote the record": the RM owns
+`review-ready → publish-ready → advisory` (the hand-off steps); the
+`allocated → review-ready` promotion is sync's job at `fix released`.
+A tracker labelled `fix released` whose record is still
+`allocated` (Vulnogram: `DRAFT`) after the sync is a **process
+bug** — it strands the RM, who is gated on `review-ready`, and
+silently stalls the advisory.
+
+**The only acceptable deferral** is a genuinely-unavailable
+authenticated session at sync time (the adapter's session probe
+fails — see the decision flow below). Then, and only then, sync
+posts the **manual-paste** hand-off variant *and* raises an explicit
+blocker in the Step 6 recap (*"<CVE> still in `allocated`/DRAFT —
+push on the next authenticated sync"*), so the gap is loud, never
+silent. Completing the push is the first action of the next
+session-capable sync.
+
 The remaining transitions stay separate:
 
 - `review-ready` → `publish-ready` is a **release-manager UI
diff --git a/skills/security-issue-sync/bulk-mode.md b/skills/security-issue-sync/bulk-mode.md
index 990c32c6..25449913 100644
--- a/skills/security-issue-sync/bulk-mode.md
+++ b/skills/security-issue-sync/bulk-mode.md
@@ -257,6 +257,24 @@ concurrently, which is exactly what the sync needs.
      change tracker state but do not alter the published CVE
      record.
 
+   **The mechanical `allocated → review-ready` state push at
+   `fix released` is NOT gated by the CVE-affecting bucket's
+   per-item review.** That bucket's confirmation exists for
+   *body-field content judgment* — summary wording, CWE choice,
+   credit-line shape: the values a human should eyeball before they
+   ship to `cve.org`. The `allocated → review-ready` (Vulnogram:
+   `DRAFT → REVIEW`) state push that a `pr merged → fix released`
+   transition mandates (see the atomicity rule in
+   [`apply-and-push.md` Step 5b](apply-and-push.md#step-5b--push-the-regenerated-json-to-the-cve-tool-via-the-adapter))
+   is mechanical, not a judgment call: it rides the **same
+   confirmation as the `fix released` label flip** in the
+   non-CVE-affecting bucket and executes in the same apply pass. Do
+   not hold a fix-released tracker's record at `allocated`/`DRAFT`
+   waiting for a separate CVE-affecting-bucket sign-off — that is the
+   deferral the atomicity rule forbids. (A body-field *content*
+   change that happens to land on the same tracker still goes through
+   the CVE-affecting review; only the state push is exempt.)
+
 4. **Present buckets as merged bulk proposals; the
    CVE-affecting bucket gets a richer per-item view.** The
    proposal has three groups: