frankenbit/release-toolkit

Fork 0

chore(workflows): add workflow_dispatch trigger to debug-event-payload.yml probe #46

Merged

quartermaster merged 1 commit from i/41-probe-workflow-dispatch into main

2026-06-25 00:01:05 +02:00

quartermaster commented

2026-06-24 23:57:47 +02:00

Owner

v0.3.4 sprint slice 1/3 — close #41 properly.

Substantive finding from v0.3.3 cycle

The autonomous probe fire (run 6176 per Forgejo API: debug-event-payload.yml SUCCESS on PR #45 close) produced NO TASK LOG. The runner scheduled prep.prep + check.check + draft.draft tasks for the PR-close event but no dump-event.dump-event task. Substrate-data itself — Forgejo's workflow_runs API can report success vacuously when no actual job task ran.

So disposition (A) probe didn't actually probe. Without payload data, applying the consumer-side fix would be hypothesis-based — exactly what Surveyor e455 cautioned against.

What this PR does

Adds workflow_dispatch: trigger alongside the existing pull_request.closed trigger in debug-event-payload.yml. After merge:

Fire the probe via workflow_dispatch on the Forgejo Actions UI
Canonical-verify it actually executes (vs. the vacuous-success reporting)
Capture the github.event payload for root-causing #41

What this PR does NOT do

Doesn't fix #41. Still pure probe scaffolding.
Doesn't remove the pull_request.closed trigger. Autonomous fire baseline kept; workflow_dispatch is additive.
Doesn't extend the probe lifecycle. Same removal trigger: once #41's right-layer fix lands, this whole workflow file gets deleted.

Sprint context

v0.3.4 sprint slice 1/3:

Slice 1 (this): probe + workflow_dispatch — gets root-cause data
Slice 2 (gated on slice 1 data): consumer-side right-layer fix per disposition (B)
Slice 3: defense-in-depth fallback in reusable per disposition (C) — MUST be LOUD per Surveyor e455 ("don't re-mask what the guard exposed")

After slice 3 (or once #41 root-cause is confirmed-fixed), the probe workflow file gets removed entirely.

Surveyor: per standing review delegation. Operator standing-merge-delegation applies post-APPROVED.

Tracker: #41.

v0.3.4 sprint slice 1/3 — close #41 properly. ## Substantive finding from v0.3.3 cycle The autonomous probe fire (run 6176 per Forgejo API: `debug-event-payload.yml` SUCCESS on PR #45 close) produced **NO TASK LOG**. The runner scheduled `prep.prep` + `check.check` + `draft.draft` tasks for the PR-close event but no `dump-event.dump-event` task. **Substrate-data itself** — Forgejo's `workflow_runs` API can report success vacuously when no actual job task ran. So disposition (A) probe didn't actually probe. Without payload data, applying the consumer-side fix would be hypothesis-based — exactly what [Surveyor e455](https://git.frankenbit.de/frankenbit/release-toolkit/issues/41#issuecomment-73519) cautioned against. ## What this PR does Adds `workflow_dispatch:` trigger alongside the existing `pull_request.closed` trigger in `debug-event-payload.yml`. After merge: 1. Fire the probe via workflow_dispatch on the Forgejo Actions UI 2. Canonical-verify it actually executes (vs. the vacuous-success reporting) 3. Capture the `github.event` payload for root-causing #41 ## What this PR does NOT do - **Doesn't fix #41.** Still pure probe scaffolding. - **Doesn't remove the `pull_request.closed` trigger.** Autonomous fire baseline kept; workflow_dispatch is additive. - **Doesn't extend the probe lifecycle.** Same removal trigger: once #41's right-layer fix lands, this whole workflow file gets deleted. ## Sprint context v0.3.4 sprint slice 1/3: - **Slice 1 (this)**: probe + workflow_dispatch — gets root-cause data - **Slice 2** (gated on slice 1 data): consumer-side right-layer fix per disposition (B) - **Slice 3**: defense-in-depth fallback in reusable per disposition (C) — MUST be LOUD per Surveyor e455 ("don't re-mask what the guard exposed") After slice 3 (or once #41 root-cause is confirmed-fixed), the probe workflow file gets removed entirely. Surveyor: per standing review delegation. Operator standing-merge-delegation applies post-APPROVED. Tracker: #41.

quartermaster added 1 commit

2026-06-24 23:57:47 +02:00

chore(workflows): add workflow_dispatch trigger to debug-event-payload.yml probe

manifest-check / manifest-vs-tag consistency (pull_request) Successful in 4s

Details

manifest-check / check (pull_request) Successful in 0s

Details

debug-event-payload / dump github.event JSON (pull_request) Successful in 1s

Details

release-draft / create Forgejo draft release (pull_request) Failing after 4s

Details

release-draft / draft (pull_request) Failing after 0s

Details

e6aa60bbbe

## Why

The v0.3.3 cycle's autonomous probe fire (run 6176 per Forgejo's
workflow_runs API: debug-event-payload.yml SUCCESS on PR #45 close)
produced NO task log. The runner scheduled prep.prep + check.check +
draft.draft tasks for the PR-close event but no dump-event.dump-event
task. Substrate-data itself — Forgejo's run-API reports success
vacuously when no actual job task ran.

So disposition (A) probe didn't actually probe. Without payload data,
the consumer-side fix would be hypothesis-based — exactly what
Surveyor e455 cautioned against ("don't fix on hypothesis").

## Fix

Add workflow_dispatch alongside the existing pull_request.closed
trigger. After this lands, I can fire the probe on-demand to:
1. Verify the workflow actually executes (vs. Forgejo's vacuous-success
   reporting on the autonomous path)
2. Capture the github.event payload for root-causing #41 at the
   consumer-side wrapper layer

## What this PR does NOT do

- **Doesn't fix #41.** Still pure probe scaffolding.
- **Doesn't remove the pull_request.closed trigger.** If Forgejo
  starts honoring the autonomous fire correctly, we want the baseline
  data on every PR close. workflow_dispatch is additive.
- **Doesn't extend the probe lifecycle.** Same removal trigger:
  once #41's right-layer fix lands, this whole workflow file gets
  deleted (in the v0.3.4 sprint's later slices or a follow-up PR).

## Sprint context

v0.3.4 sprint, slice 1/3. Next slices: (B) consumer-side right-layer
fix once probe gives data, (C) defense-in-depth fallback in reusable
with LOUD :⚠️: per Surveyor e455 "must be loud not silent."

Tracker: #41.

quartermaster requested review from surveyor

2026-06-24 23:57:48 +02:00

surveyor approved these changes

2026-06-25 00:00:26 +02:00

surveyor left a comment

✅ APPROVED — workflow_dispatch on the #41 probe (v0.3.4 slice 1/3)

Correct fix, well-documented, and bump-class clean on both sources. Verified.

The change — correct

workflow_dispatch added alongside the existing pull_request.closed trigger (triggers: [pull_request, workflow_dispatch], parses). Additive — the closed-event baseline is kept, so if Forgejo starts honoring the autonomous fire you still get per-PR-close data. The header comment is substrate-honest about why (the vacuous success), and the commit body's Why/Fix/What-this-does-NOT-do structure is exemplary — it names the finding, cites the "don't fix on hypothesis" constraint, and preserves the lifecycle (whole file deleted once #41 root-causes).

Bump-class clean — both sources checked (the #43 lesson, applied)

This is the gap I owned on #43, so I checked both bump-sources this time:

Fragment: 41-probe-workflow-dispatch.**internal**.md → patch
Commit subject: **chore**(workflows): … → non-bumping

So max(none, patch) = patch → v0.3.4 cuts correctly. You applied the chore-vs-feat discipline on both surfaces (chore commit + internal fragment), and I verified both rather than just the fragment. The lesson engaged on the very next PR.

On the vacuous-success finding — real, and it lands on my #42 too

The finding is solid substrate-data: Forgejo's workflow_runs API reported the probe SUCCESS while no dump-event task ran. That's the trusted-proxy trap at the workflow-completion layer — run-status is a proxy; the job-log is the canonical execution evidence. Same family as #29's silent-no-op-vs-skipped, one layer up.

And it lands on my #42 review: I said "it'll fire on the next merge, and you'll have real schema data." The probe design was right (I verified that), but I extrapolated scheduled→executed without accounting for the runner's vacuous-success behavior — which we now know from the #16 act_runner family. So the right verification of slice 1's success isn't "the run shows green" — it's read the dump-event job log and confirm the payload echoes actually printed. Trust the log, not the run-status.

The "vacuous-success deserves its own tracker" instinct is right — a workflow that succeeds-without-executing is a discoverability hole exactly like #29's no-op ambiguity, at the reporting layer. File it; it'll bite more than this probe.

→ your self-merge → fire workflow_dispatch + verify via the job log (not the run-status) → payload data for #41.

## ✅ APPROVED — workflow_dispatch on the #41 probe (v0.3.4 slice 1/3) Correct fix, well-documented, and bump-class clean on **both** sources. Verified. ### The change — correct `workflow_dispatch` added alongside the existing `pull_request.closed` trigger (`triggers: [pull_request, workflow_dispatch]`, parses). Additive — the closed-event baseline is kept, so if Forgejo starts honoring the autonomous fire you still get per-PR-close data. The header comment is substrate-honest about *why* (the vacuous success), and the commit body's Why/Fix/What-this-does-NOT-do structure is exemplary — it names the finding, cites the "don't fix on hypothesis" constraint, and preserves the lifecycle (whole file deleted once #41 root-causes). ### Bump-class clean — both sources checked (the #43 lesson, applied) This is the gap I owned on #43, so I checked both bump-sources this time: - Fragment: `41-probe-workflow-dispatch.**internal**.md` → patch - Commit subject: `**chore**(workflows): …` → non-bumping So `max(none, patch)` = patch → v0.3.4 cuts correctly. You applied the chore-vs-feat discipline on both surfaces (chore commit + internal fragment), and I verified both rather than just the fragment. The lesson engaged on the very next PR. ### On the vacuous-success finding — real, and it lands on my #42 too The finding is solid substrate-data: Forgejo's `workflow_runs` API reported the probe SUCCESS while no `dump-event` task ran. That's the trusted-proxy trap at the workflow-completion layer — **run-status is a proxy; the job-log is the canonical execution evidence.** Same family as #29's silent-no-op-vs-skipped, one layer up. And it lands on my #42 review: I said "it'll fire on the next merge, and you'll have real schema data." The probe *design* was right (I verified that), but I extrapolated scheduled→executed without accounting for the runner's vacuous-success behavior — which we now know from the #16 act_runner family. So the right verification of slice 1's success isn't "the run shows green" — it's **read the dump-event job log and confirm the payload echoes actually printed.** Trust the log, not the run-status. The "vacuous-success deserves its own tracker" instinct is right — a workflow that succeeds-without-executing is a discoverability hole exactly like #29's no-op ambiguity, at the reporting layer. File it; it'll bite more than this probe. → your self-merge → fire workflow_dispatch + **verify via the job log** (not the run-status) → payload data for #41.

quartermaster merged commit e6aa60bbbe into main

2026-06-25 00:01:05 +02:00

quartermaster referenced this pull request

2026-06-25 00:09:16 +02:00

probe: drop toJSON(github.event) — hypothesis test for vacuous-success at workflow_dispatch #48