Repository navigation
chore(deps): bump taiki-e/install-action from 2.87.27 to 2.87.29 - #310
Merged
temper-pulseengine[bot] merged 1 commit intoOct 20, 2026
Conversation
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.87.27 to 2.87.29. - [Release notes](https://github.com/taiki-e/install-action/releases) - [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md) - [Commits](taiki-e/install-action@v2.87.27...v2.87.29) --- updated-dependencies: - dependency-name: taiki-e/install-action dependency-version: 2.87.29 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
temper-pulseengine
Bot
deleted the
dependabot/github_actions/taiki-e/install-action-2.87.29
branch
October 20, 2026 00:44
avrabe
added a commit
that referenced
this pull request
Nov 1, 2026
Audited 2026-10-21: main's `required_status_checks.contexts` is `[]` and the repository has no rulesets. Every check in this repo is advisory. #305, #308, #292, #306, #310 and #297 all merged over a board nothing enforced, and the release that is being cut right now was gated by discipline rather than by CI. Requiring the individual contexts is the obvious fix and a trap in both directions: * rust.yml, formal-verification.yml and supply-chain.yml carry `on: pull_request: paths:`, so a PR touching none of their paths never gets a report from them — and a required context that never reports blocks the PR forever; * a job skipped INSIDE a workflow reports `skipped`, and on GitHub a skipped required context SATISFIES the merge button. So a paths filter is a gate-disabler either way. This adds one unfiltered workflow whose single job is the only context to require, and which judges what the other workflows actually concluded. Rules, all four failing closed: 1. every completed check-run must conclude in {success, skipped, neutral} — ONE predicate, an allowlist, so a conclusion GitHub invents tomorrow is rejected rather than inherited as green; 2. `Documentation claims hold` must be PRESENT. claim-check.yml has no paths filter, so its absence means it stopped running — the canary that keeps rule 1 from reading "everything was skipped" as mergeable; 3. everything must be finished; hitting the deadline FAILS, because a gate that gives up and passes is worse than no gate; 4. an API error, bad JSON or missing token exits non-zero. The audit's own finding is that a classifier's error path is usually its permissive one. What it deliberately does NOT do: re-derive from the path globs which workflows *should* have run. That would copy three filter lists into a fourth place, and a copy that drifts is how this class of bug starts. The honest cost is stated in the source — a job skipped by an in-workflow filter is taken at its word, with rule 2 as the floor. ## The decision table found a hole in itself `--self-test` drives 14 cases through the pure `classify()` function. Running mutations against the FIRST draft, two of six survived: BLOCKING = set() -> 14/14 still held "failure" added to OK -> 14/14 still held Both for the same reason: a failure was rejected twice, once by a blocklist and once by falling outside an allowlist, so either alone sufficed and neither could be isolated. That is the same redundant-guard pattern just reported in matrix.rs — reproduced from scratch in a new file, which is a decent argument for how easily it happens. Collapsed to the single allowlist, with the blocklist demoted to wording the error message. Re-running every mutation: allowlist gains "failure" 13/14 caught allowlist accepts everything 10/14 caught conclusion check removed 9/14 caught canary presence defeated 11/14 caught never waits for in-progress 11/14 caught waits on itself (deadlock) 12/14 caught 6 of 6. The workflow runs `--self-test` as its first step, so the gate proves itself before it judges anything. NOT wired into branch protection by this commit. A context that has never reported cannot be required without blocking every open PR, including the four in this release's stack. Protection gets set after this lands and reports once. Refs #316 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aR3Md1h46K9wAUWMQiESH
avrabe
added a commit
that referenced
this pull request
Nov 1, 2026
…#317) Audited 2026-10-21: main's `required_status_checks.contexts` is `[]` and the repository has no rulesets. Every check in this repo is advisory. #305, #308, #292, #306, #310 and #297 all merged over a board nothing enforced, and the release that is being cut right now was gated by discipline rather than by CI. Requiring the individual contexts is the obvious fix and a trap in both directions: * rust.yml, formal-verification.yml and supply-chain.yml carry `on: pull_request: paths:`, so a PR touching none of their paths never gets a report from them — and a required context that never reports blocks the PR forever; * a job skipped INSIDE a workflow reports `skipped`, and on GitHub a skipped required context SATISFIES the merge button. So a paths filter is a gate-disabler either way. This adds one unfiltered workflow whose single job is the only context to require, and which judges what the other workflows actually concluded. Rules, all four failing closed: 1. every completed check-run must conclude in {success, skipped, neutral} — ONE predicate, an allowlist, so a conclusion GitHub invents tomorrow is rejected rather than inherited as green; 2. `Documentation claims hold` must be PRESENT. claim-check.yml has no paths filter, so its absence means it stopped running — the canary that keeps rule 1 from reading "everything was skipped" as mergeable; 3. everything must be finished; hitting the deadline FAILS, because a gate that gives up and passes is worse than no gate; 4. an API error, bad JSON or missing token exits non-zero. The audit's own finding is that a classifier's error path is usually its permissive one. What it deliberately does NOT do: re-derive from the path globs which workflows *should* have run. That would copy three filter lists into a fourth place, and a copy that drifts is how this class of bug starts. The honest cost is stated in the source — a job skipped by an in-workflow filter is taken at its word, with rule 2 as the floor. ## The decision table found a hole in itself `--self-test` drives 14 cases through the pure `classify()` function. Running mutations against the FIRST draft, two of six survived: BLOCKING = set() -> 14/14 still held "failure" added to OK -> 14/14 still held Both for the same reason: a failure was rejected twice, once by a blocklist and once by falling outside an allowlist, so either alone sufficed and neither could be isolated. That is the same redundant-guard pattern just reported in matrix.rs — reproduced from scratch in a new file, which is a decent argument for how easily it happens. Collapsed to the single allowlist, with the blocklist demoted to wording the error message. Re-running every mutation: allowlist gains "failure" 13/14 caught allowlist accepts everything 10/14 caught conclusion check removed 9/14 caught canary presence defeated 11/14 caught never waits for in-progress 11/14 caught waits on itself (deadlock) 12/14 caught 6 of 6. The workflow runs `--self-test` as its first step, so the gate proves itself before it judges anything. NOT wired into branch protection by this commit. A context that has never reported cannot be required without blocking every open PR, including the four in this release's stack. Protection gets set after this lands and reports once. Refs #316 Claude-Session: https://claude.ai/code/session_012aR3Md1h46K9wAUWMQiESH Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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.
Bumps taiki-e/install-action from 2.87.27 to 2.87.29.
Release notes
Sourced from taiki-e/install-action's releases.
Changelog
Sourced from taiki-e/install-action's changelog.
... (truncated)
Commits
8cca091Release 2.87.29fc26824Update wasmtime manifest5018b2eUpdatezizmor@latestto 1.31.0d0e5204Updatewasmtime@latestto 49.0.3517774fUpdatewasm-tools@latestto 1.262.04bc69b1Update vacuum manifest0470a3fUpdateuv@latestto 0.13.17a2b747Updatetrivy@latestto 0.76.07efb533Updatetombi@latestto 1.8.4e5d37d6Updaterelease-plz@latestto 0.3.172Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)