ci: add workflow_dispatch so CI can be re-fired without a dummy commit - #32
Merged
Conversation
Between 2026-08-05T21:03Z and 2026-08-07 this repository created no
workflow run at all — not for a pull request, not for a push to main —
while the workflow reported state=active, Actions reported enabled, the
triggers were pull_request + push:[main], and the file parsed cleanly.
Sibling repositories in the same org ran normally in that window
(Standard's push to main and Engram's PR both ran and passed), so it was
specific to this repository and invisible from the API: nothing queued,
nothing waiting, and no failed run to notice.
Two merges landed here unvalidated as a result. Their gates were run
locally against merged main instead — reuse lint clean, validate-configs
0 failed, description cap clean, skill-refs OK, steelbore.scm in sync —
but "run it by hand and trust the transcript" is not a gate.
workflow_dispatch makes the recovery path a command rather than a commit:
gh workflow run ci.yml --ref main
The alternative was a commit whose only purpose is to produce an event,
pushed straight to main — which is exactly what the branch-and-PR rule
forbids. Worth having permanently rather than as a one-off: the lint job
is what enforces the §5.6 description cap and the steelbore.scm drift
check, and both fail silently when unenforced, which is the same class of
gap that let §3.2.1 sit unpublished for months.
No job, step, or trigger behavior changes — this only adds a way to start
the existing workflow by hand.
Verified: the workflow parses with all three triggers present and the
lint job's 8 steps intact; validate-configs (which walks this file) 302/0;
reuse lint clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014X5VySpBN97Nu8YjHy7gwo
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Between 2026-08-05T21:03Z and 2026-08-07 this repository created no workflow run at all — not for a pull request, not for a push to
main— while:state=activeenabled(allowed_actions: all)pull_request+push: [main]Sibling repositories in the same org ran normally in that window —
Standard's push tomainran and passed, and a freshEngramPR ran all five of its checks — so this was specific to this repository and invisible from the API: nothing queued, nothing waiting, and no failed run to notice.Two merges landed here unvalidated as a result (#31 and the Guile-mirror commit). Their gates were run by hand against merged
maininstead —reuse lintclean,validate-configs302/0, description cap clean,check-skill-refsOK,steelbore.scmin sync — but "run it by hand and trust the transcript" is not a gate.What this changes
Adds
workflow_dispatch:to the existing triggers, so the recovery path is a command rather than a commit:The alternative was a commit whose only purpose is to produce an event, pushed straight to
main— exactly what the branch-and-PR rule forbids.Worth having permanently rather than as a one-off: the
lintjob is what enforces the §5.6 description cap and thesteelbore.scmdrift check, and both fail silently when unenforced. That is the same class of gap that let §3.2.1 sit unpublished for months.No job, step, or trigger behavior changes. This only adds a way to start the existing workflow by hand.
Verification
pull_request,push,workflow_dispatch) and thelintjob's 8 steps intactvalidate-configs.py— which walks this very file — 302 checked, 0 failedreuse lintcleanNote:
workflow_dispatchonly becomes invocable once it is on the default branch, so this PR itself cannot demonstrate the manual trigger. If CI is still not firing on this PR, that is the bug this exists to work around — and dispatching after merge is the test.🤖 Generated with Claude Code
https://claude.ai/code/session_014X5VySpBN97Nu8YjHy7gwo