docs(agents): record how the required context can become unsatisfiable #13

Merged

jlxq0 merged 1 commit from docs/gate-satisfiability into main

2026-08-27 02:46:37 +00:00

jlxq0 commented

2026-08-27 02:37:06 +00:00

Owner

Sits directly beneath the do not add it back note, because it is the same
class of fault: a gate whose behaviour is decided in a file the gate does not
point at.

The main rule requires CI / cargo*. Whether that context is ever produced
is decided by on.pull_request in .forgejo/workflows/ci.yml, which is bare
today — no paths:, no branches: — so every pull-request head produces it.
Add a filter and any PR the filter excludes produces no cargo context at all.
The required context can then never report success, so the gate turns from
"requires green" into "cannot be satisfied", with nothing in the protection
settings having changed and nothing in the rule naming the file that changed
it. A docs-only PR under a paths: filter is the likely first casualty, which
is to say a PR shaped exactly like this one.

The note also records why the on: block is the place to answer it: green PR
contexts on past commits are corroboration after the fact, and a repository
with no pull-request history has none available at all while the on: block
still answers.

Verification

cargo fmt --all --check, cargo clippy --all-targets --all-features --locked -- -D warnings, cargo test --all-features --locked (92 passed), cargo audit, cargo deny check bans licenses sources — all green at bbba1af on
rustc 1.98.0.

Not test-covered and cannot be, same as #8: no assertion reads a protection
rule or a workflow trigger.

Docs only. No Cargo.toml, Dockerfile or workflow change, so v0.1.3 stays
the released version and the running digest is untouched.

Sits directly beneath the `do not add it back` note, because it is the same class of fault: a gate whose behaviour is decided in a file the gate does not point at. The `main` rule requires `CI / cargo*`. Whether that context is ever produced is decided by `on.pull_request` in `.forgejo/workflows/ci.yml`, which is bare today — no `paths:`, no `branches:` — so every pull-request head produces it. Add a filter and any PR the filter excludes produces no `cargo` context at all. The required context can then never report success, so the gate turns from "requires green" into "cannot be satisfied", with nothing in the protection settings having changed and nothing in the rule naming the file that changed it. A docs-only PR under a `paths:` filter is the likely first casualty, which is to say a PR shaped exactly like this one. The note also records why the `on:` block is the place to answer it: green PR contexts on past commits are corroboration after the fact, and a repository with no pull-request history has none available at all while the `on:` block still answers. ## Verification `cargo fmt --all --check`, `cargo clippy --all-targets --all-features --locked -- -D warnings`, `cargo test --all-features --locked` (92 passed), `cargo audit`, `cargo deny check bans licenses sources` — all green at `bbba1af` on rustc 1.98.0. Not test-covered and cannot be, same as #8: no assertion reads a protection rule or a workflow trigger. Docs only. No `Cargo.toml`, `Dockerfile` or workflow change, so `v0.1.3` stays the released version and the running digest is untouched.

jlxq0 added 1 commit

2026-08-27 02:37:06 +00:00

docs(agents): record how the required context can become unsatisfiable

CI / cargo (pull_request) Successful in 40s

Details

CI / docker (pull_request) Successful in 18s

Details

bbba1af12d

The main protection requires CI / cargo*, and whether that context is ever
produced is decided by on.pull_request in .forgejo/workflows/ci.yml rather than
by the protection settings. It is bare today, so every PR head produces it. A
paths: or branches: filter added later would leave an excluded PR with no cargo
context, and the gate would flip from requires-green to unsatisfiable with the
rule unchanged and nothing in it naming the file responsible.

Same class as the docker exclusion note above it: a gate whose behaviour is
decided in a file the gate does not point at.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

jlxq0 merged commit 4cd6fdf2ff into main

2026-08-27 02:46:37 +00:00

jlxq0 deleted branch docs/gate-satisfiability

2026-08-27 02:46:38 +00:00

jlxq0 referenced this pull request from a commit

2026-08-27 02:46:38 +00:00

Merge pull request 'docs(agents): record how the required context can become unsatisfiable' (#13) from docs/gate-satisfiability into main