Keel
Grounding report.
Every verification edge in aider, classified by who produces the signal and whether the actor being verified can write to that producer.
| target | aider |
|---|---|
| revision | 5dc9490bb35f9729ef2c95d00a19ccd30c26339c |
| generated | 2026-07-25T02:36:32.279Z |
anchored / (anchored + self_referential + unknown) = 7 / 7
Coverage (judged)
| node kind | judged |
|---|---|
| ci_step | 23 |
| review_gate | 1 |
| test_target | 1 |
ε-audit — not run
No verdict in this report carries a readable audit block, so nothing was re-decided and there is no agreement rate to report. This is not agreement, and it is not full agreement either: a rate over zero comparisons would state a measurement that was never taken. (“Readable” is load-bearing: a block can be present and state no comparison, and this state covers that too — see below if so.)
This run judged 25 of 62 gathered edges. Every number on this page describes that sample, not the whole surface — 37 gathered edges are absent from all of it. A cap is disclosed rather than smoothed: an undisclosed sample is how a ratio gets shopped.
Scope. Keel measures the shape of verification, not its quality. A repo can be 100% anchored with terrible tests. Anchoring says the signal comes from outside; it does not say the signal is sufficient.
Node graph — 25 node(s), in gather order
anchored — 7
Both gating test workflows run a bare `pytest`, so this config is what actually decides which suite the merge-blocking job executes (tests/basic, tests/help, tests/browser, tests/scrape). Pass/fail is the interpreter's verdict on executing those modules against the installed package: an author cannot make a failing assertion, an exception or a collection error report green without changing the code or the tests, and `addopts = -p no:warnings` only silences warnings rather than swallowing failures. Documented limit: the EXECUTION is anchored, the ORACLE is not — implementation and assertions live in the same repo and are co-authored, so the suite proves the code does what these tests say, not that the tests say the right thing. Second limit: `testpaths`/`norecursedirs` mean anything outside those four directories (e.g. benchmark/) never runs at all.
producer the CPython/pytest process exit code, for the suite this file's `testpaths` selects when CI runs a bare `pytest` — actor can write to it: no
- pytest.ini:4-9
- pytest.ini:3
- .github/workflows/ubuntu-tests.yml:52-56
- .github/workflows/windows-tests.yml:47-51
decided by agent · confidence 0.85
This config is not local-only advice: .github/workflows/pre-commit.yml runs `pre-commit run --show-diff-on-failure --color=always --all-files` under `set -o pipefail` on `pull_request`, so the hooks sit on the merge path. Each verdict is the exit status of a third-party tool at a pinned rev (isort 5.12.0, black 23.3.0, flake8 7.1.0, codespell v2.2.6) reading the committed bytes — black and isort fail the run when they had to rewrite a file, flake8 exits non-zero on a violation — and a contributor cannot make a violating file report clean without changing the file or the pinned config. Limit worth naming: what is asserted is import order, formatting, lint rules and spelling, never behaviour; and `SKIP: no-commit-to-branch` shows the hook set is selectively disabled in CI, so the config alone does not tell you every hook runs.
producer the exit statuses of isort, black, flake8 and codespell, each pinned to a rev and executed by pre-commit inside a CI job that runs on every pull request — actor can write to it: no
- .pre-commit-config.yaml:1-24
- .github/workflows/pre-commit.yml:22-28
- .github/workflows/pre-commit.yml:3-6
decided by agent · confidence 0.8
`python -m build` executes the packaging backend against the committed pyproject/setup metadata in an isolated env — a broken packaging config, an unresolvable dependency spec or a missing module makes the process exit non-zero, and asserting otherwise changes nothing. `twine upload dist/*` then hands the artifact to PyPI, a third party nobody in this repo can write to, which rejects a duplicate version or malformed metadata on its own authority. Limits: this workflow fires only on a `v[0-9]+.[0-9]+.[0-9]+` tag push, so it gates the release and never a merge, and the property asserted is packageability and uploadability, not that the code behaves.
producer the setuptools/build backend exit code, and PyPI's index server accepting or rejecting the upload — actor can write to it: no
- .github/workflows/release.yml:28-34
- .github/workflows/release.yml:3-7
decided by agent · confidence 0.7
`run: pytest` executes the suite pytest.ini selects against the package the previous step installed, and the step's exit status IS the interpreter's verdict on those modules; the workflow triggers on `pull_request` to main, so that exit code is on the merge path. A failing assertion, an import error or a segfault cannot be talked into reporting green without changing the code or the tests, and the matrix runs it on Python 3.10-3.14 so a version-specific break surfaces too. Documented limit: execution is anchored, the oracle is not — the same authors write the implementation and the assertions, so the suite proves the code matches these tests rather than that the tests are the right specification. Second limit: `paths-ignore` skips the job entirely for changes confined to aider/website, README.md or HISTORY.md.
producer the pytest process exit code on ubuntu-latest, across a five-way Python version matrix — actor can write to it: no
- .github/workflows/ubuntu-tests.yml:52-56
- .github/workflows/ubuntu-tests.yml:13-21
- .github/workflows/ubuntu-tests.yml:26-28
- pytest.ini:4-9
decided by agent · confidence 0.9
Same causal path as the Ubuntu job on a different OS: `run: pytest` executes the suite pytest.ini selects against the freshly `pip install .`-ed package, and the runner's exit status decides the job. It triggers on `pull_request` to main, so it blocks the merge, and running on windows-latest means path-separator and encoding breakage is caught by the platform actually executing the code rather than by anyone's claim about portability. Documented limit: the assertions are co-authored with the implementation, so this anchors execution, not the specification; and `paths-ignore` skips the job for website/README/HISTORY-only changes.
producer the pytest process exit code on windows-latest, across a five-way Python version matrix — actor can write to it: no
- .github/workflows/windows-tests.yml:47-51
- .github/workflows/windows-tests.yml:13-21
- .github/workflows/windows-tests.yml:25-28
decided by agent · confidence 0.9
`bundle exec jekyll build` runs the bundled Ruby toolchain over the committed markdown, layouts and Liquid templates under aider/website; a Liquid syntax error, malformed YAML front matter or a missing include makes jekyll exit non-zero and reddens the job, and no claim in the repo can override that. The deploy job carries `needs: build`, so a failed render blocks publication. Limit: it asserts only that the site renders — nothing about whether the documented content is true, and nothing about the Python package this repo actually ships.
producer the Jekyll/Ruby process exit code from building the committed site sources — actor can write to it: no
- .github/workflows/pages.yml:53-57
- .github/workflows/pages.yml:64-69
- .github/workflows/pages.yml:43-49
decided by agent · confidence 0.7
The step crawls the live https://aider.chat over the network, and its exit status is decided by responses that come back from servers: an internal page that does not exist answers 404 from the Pages CDN whatever the source tree claims, and an external target that has rotted answers 404/410 from a host nobody in this repo can write to. The signal is produced by executing requests against a deployed system rather than by reading an assertion in the tree. Two limits: it runs AFTER actions/deploy-pages in the same job, so it detects a broken site rather than preventing one; and it points at the live domain instead of the artefact just built, so if the deploy has not propagated it grades the previous deployment. The `--ignore-url` filter also removes media URLs from the crawl.
producer linkchecker's HTTP client, and the status codes returned by the Pages CDN and by the third-party hosts it crawls out to — actor can write to it: no
- .github/workflows/pages.yml:85-87
- .github/workflows/pages.yml:71-73
- .github/workflows/pages.yml:80-83
decided by agent · confidence 0.7
not_a_check — 18
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
The command installs declared dependencies so that later steps can run. Without a lockfile-freezing flag the resolver will refresh a stale lock rather than error, so the step cannot report a discrepancy between the manifest and the lock; its non-zero exits mean the network or the index failed, not that the repository is wrong. The assertion in such a job lives in whatever executes against the installed environment afterwards.
producer a package manager's dependency resolver populating an environment — actor can write to it: not established
- the run command is a bare dependency install with no --locked/--frozen equivalent
decided by probe (unfrozen-dependency-install) · confidence 0.8
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
`sudo apt-get update && sudo apt-get install -y libportaudio2` puts a shared library on the runner so the later `pip install .` and `pytest` steps have something to link against. Nothing in the repository is read or evaluated: a non-zero exit here means the mirror was unreachable or the package moved upstream, never that the code is wrong. The assertion in this job is the `pytest` step that runs afterwards, so this edge must not enter the ratio in either direction.
producer apt-get fetching an OS package from the Ubuntu mirrors onto the runner — actor can write to it: not established
- .github/workflows/ubuntu-tests.yml:41-44
decided by agent · confidence 0.9
The command installs declared dependencies so that later steps can run. Without a lockfile-freezing flag the resolver will refresh a stale lock rather than error, so the step cannot report a discrepancy between the manifest and the lock; its non-zero exits mean the network or the index failed, not that the repository is wrong. The assertion in such a job lives in whatever executes against the installed environment afterwards.
producer a package manager's dependency resolver populating an environment — actor can write to it: not established
- the run command is a bare dependency install with no --locked/--frozen equivalent
decided by probe (unfrozen-dependency-install) · confidence 0.8
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
The command installs declared dependencies so that later steps can run. Without a lockfile-freezing flag the resolver will refresh a stale lock rather than error, so the step cannot report a discrepancy between the manifest and the lock; its non-zero exits mean the network or the index failed, not that the repository is wrong. The assertion in such a job lives in whatever executes against the installed environment afterwards.
producer a package manager's dependency resolver populating an environment — actor can write to it: not established
- the run command is a bare dependency install with no --locked/--frozen equivalent
decided by probe (unfrozen-dependency-install) · confidence 0.8
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
The step's whole effect is to ask the Pages API for the site's base path and export it as an output the next step interpolates into `jekyll build --baseurl`. It evaluates nothing about the repository — a failure means the Pages API was unreachable or the repo has Pages disabled, which is a fact about the hosting configuration, not about the artefact. The assertion in this job is the jekyll build that consumes its output.
producer actions/configure-pages resolving the Pages site URL and exporting `steps.pages.outputs.base_path` — actor can write to it: not established
- .github/workflows/pages.yml:50-52
- .github/workflows/pages.yml:55
decided by agent · confidence 0.85
The step packages the directory the jekyll build in the same job just produced and hands it to the Pages artifact store so the deploy job can fetch it. Nothing about the repository is evaluated — the worst it can report is that a path the pipeline itself was responsible for creating is absent, a fact about the plumbing. The assertion in this job is the build step before it, so this edge must not enter the ratio in either direction.
producer actions/upload-pages-artifact tarring the _site tree the immediately preceding step wrote — actor can write to it: not established
- .github/workflows/pages.yml:58-61
- .github/workflows/pages.yml:53-55
decided by agent · confidence 0.85
The step fetches the tarball the build job uploaded and asks the Pages service to serve it. Success means GitHub accepted and published a bundle the same actor authored — a statement about the delivery channel, not a verdict on the artefact — and there is no condition between build and deploy other than the build's own exit code, so nothing is gated here. Naming the shoppability risk explicitly: I am not filing this here because it is hard, but because a successful publish is compatible with every possible content defect, so it asserts nothing about correctness in either direction. The post-deploy linkchecker step in the same job is where an assertion about the deployed site is actually made.
producer actions/deploy-pages publishing the artifact an earlier job in the same run uploaded — actor can write to it: not established
- .github/workflows/pages.yml:71-73
- .github/workflows/pages.yml:63-69
decided by agent · confidence 0.7
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
The command installs declared dependencies so that later steps can run. Without a lockfile-freezing flag the resolver will refresh a stale lock rather than error, so the step cannot report a discrepancy between the manifest and the lock; its non-zero exits mean the network or the index failed, not that the repository is wrong. The assertion in such a job lives in whatever executes against the installed environment afterwards.
producer a package manager's dependency resolver populating an environment — actor can write to it: not established
- the run command is a bare dependency install with no --locked/--frozen equivalent
decided by probe (unfrozen-dependency-install) · confidence 0.8
The step's whole effect is to put files or a toolchain on the runner so later steps have something to act on. It reads nothing about the repository's correctness and emits no pass/fail verdict about the artefact — a failure here means the runner could not fetch or install, not that the code is wrong. The check in such a job is whatever executes afterwards, so this edge must not enter the ratio in either direction.
producer a GitHub Actions provisioning action (repository checkout, toolchain setup, or dependency cache restore) — actor can write to it: not established
- the step body is a bare `uses:` of a checkout/setup/cache action with no command of its own
decided by probe (ci-provisioning-action) · confidence 0.9
Crystallization curve
Run economics