Nothing asserts the CI workflow's own prohibitions: the edited trigger and both guard clauses are prose only #19

New Issue

2026-09-02T17:53:01Z

claude commented

2026-09-02 17:53:01 +00:00

.gitea/workflows/ci.yaml carries prohibitions that nothing enforces. Two of
them are load-bearing, and both were reinforced by the edited trigger change:

the pull_request types: list must keep edited — reverting it to
ready_for_review or to the bare default silently restores the permanent
draft-skip, which is the exact regression that change fixed;
the job's if: guard must keep both clauses. Its own comment says
"Never drop it": the github.event_name != 'pull_request' half is what
stops the negation from also skipping pushes to the integration branch,
since a push event has no pull_request context.

Nothing reads this file. No suite under scripts/tests/ (or scripts/ in
gitdan-actions) parses it, so every one of these rules lives only as prose in
a comment. Per comments-are-not-exposition: if a comment asserts something,
the assertion belongs in a test — prose cannot fail, and a comment is not a
guard for future workers.

Why this is filed rather than fixed in the PR that found it

Surfaced by the review of daniel/gitdan-actions PR #18 (review 928) as a
non-blocking nit, and deliberately not ridden along: neither repo has any
suite that reads workflow YAML, so this is new machinery rather than a small
correction in a file already open. The reviewer's own estimate is ~10 lines.

Both repos have the same gap, with the same two prohibitions, so this is
filed in each rather than cross-referenced from one — a note in the other
repo's tracker is not somewhere anybody reads.

Acceptance criteria

A test asserts edited is present in the pull_request types: list,
and fails if it is removed or replaced by ready_for_review.
A test asserts the if: guard retains both clauses.
Both are red-proven: demonstrated failing against a mutated workflow
before being wired in.
The suite is wired into the repo's standard gate, so it runs in CI
rather than on request.
Any comment whose warning is now enforced points at the test instead of
restating the rule at length.

References

daniel/gitdan-actions PR #18 / daniel/gitdan PR #92 — the edited swap
that reinforced both prohibitions.
daniel/emowheel commit 08da820 — the original derivation.

`.gitea/workflows/ci.yaml` carries prohibitions that nothing enforces. Two of them are load-bearing, and both were reinforced by the `edited` trigger change: - the `pull_request` `types:` list must keep `edited` — reverting it to `ready_for_review` or to the bare default silently restores the permanent draft-skip, which is the exact regression that change fixed; - the job's `if:` guard must keep **both** clauses. Its own comment says "Never drop it": the `github.event_name != 'pull_request'` half is what stops the negation from also skipping pushes to the integration branch, since a `push` event has no `pull_request` context. Nothing reads this file. No suite under `scripts/tests/` (or `scripts/` in gitdan-actions) parses it, so every one of these rules lives only as prose in a comment. Per `comments-are-not-exposition`: if a comment asserts something, the assertion belongs in a test — prose cannot fail, and a comment is not a guard for future workers. ## Why this is filed rather than fixed in the PR that found it Surfaced by the review of `daniel/gitdan-actions` PR #18 (review 928) as a non-blocking nit, and deliberately not ridden along: neither repo has any suite that reads workflow YAML, so this is new machinery rather than a small correction in a file already open. The reviewer's own estimate is ~10 lines. Both repos have the same gap, with the same two prohibitions, so this is filed in each rather than cross-referenced from one — a note in the other repo's tracker is not somewhere anybody reads. ## Acceptance criteria - [ ] A test asserts `edited` is present in the `pull_request` `types:` list, and fails if it is removed or replaced by `ready_for_review`. - [ ] A test asserts the `if:` guard retains both clauses. - [ ] Both are red-proven: demonstrated failing against a mutated workflow before being wired in. - [ ] The suite is wired into the repo's standard gate, so it runs in CI rather than on request. - [ ] Any comment whose warning is now enforced points at the test instead of restating the rule at length. ## References - `daniel/gitdan-actions` PR #18 / `daniel/gitdan` PR #92 — the `edited` swap that reinforced both prohibitions. - `daniel/emowheel` commit `08da820` — the original derivation.

claude added the enhancement label 2026-09-02 17:53:01 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: daniel/gitdan-actions#19