Grounding report.

This node is the declaration of the rack-protection RSpec suite: `.rspec` is the options file every `rspec` invocation loads, and `--require spec_helper` is what pulls in the suite harness. The gating signal is the exit status of that rspec process, which the Ruby runtime computes by executing the committed specs against the committed lib/ — a failing example cannot be talked into green without editing code or specs, and rake's `ruby` helper propagates the non-zero status so the CI step (and, for the non-allow-failure matrix legs, the job) fails. TWO limits are recorded rather than smoothed away. (1) Confidence is deliberately low: the literal text of this node is configuration (`--color`, `--warnings`, `--require spec_helper`) and asserts nothing by itself; the anchoring is inherited from the process this file configures, and the same execution is also represented by the rake `default`/`test` targets, so the anchored count for this suite is arguably double-entered. (2) Execution is anchored, the oracle is not — implementation and specs are authored by the same maintainers, so green proves the code does what these specs say, not that the specs say the right thing.

producer the rspec process exit code, produced when CI runs `bundle exec rake` in rack-protection/ (test.yml:53-55) -> `task(:spec) { ruby '-S rspec' }` (rack-protection/Rakefile:13) — actor can write to it: no

• rack-protection/.rspec:1-3
• rack-protection/Rakefile:13
• .github/workflows/test.yml:50-55
• rack-protection/spec/spec_helper.rb:1-7

decided by agent · confidence 0.55 · confidence below 0.6 on an anchored verdict

`task default: :spec` (rack-protection/Rakefile:73) resolves to `task(:spec) { ruby '-S rspec' }` (line 13), and rake's `ruby` helper raises on a non-zero child status, so `rake` exits non-zero whenever an example fails. This is the target CI actually invokes: test.yml:53-55 runs `bundle exec rake` with working-directory rack-protection, and that step is only exempted from failing the job on the explicitly allow-failure matrix legs (ruby-head), so on every stable leg the rspec exit code blocks the run. An author cannot make a failing example report green without changing the code or the spec. Documented limit: the EXECUTION is anchored, the ORACLE is not — the same maintainers author lib/ and spec/, so green means the code does what these specs say, not that the specs say the right thing.

producer the rspec process exit code — the Ruby runtime executing rack-protection/spec against the committed lib/, surfaced through rake's `ruby` helper — actor can write to it: no

• rack-protection/Rakefile:73
• rack-protection/Rakefile:12-13
• .github/workflows/test.yml:50-55
• .github/workflows/test.yml:38

decided by agent · confidence 0.85

`task test: :spec` (rack-protection/Rakefile:74) is a second name for the identical body that `default` reaches, so invoking it runs the committed specs and rake propagates the runtime's non-zero status. Confidence is held below the `default` verdict for one specific reason: CI invokes the bare `bundle exec rake` (the default task), never `rake test`, so this particular NAME is not itself on the merge-blocking path — it is anchored because it executes the same suite, not because anything in this repo gates on it. Same oracle limit as the suite it aliases: execution independence holds, specification independence does not.

producer the same rspec process exit code reached through `task(:spec) { ruby '-S rspec' }` — actor can write to it: no

• rack-protection/Rakefile:74
• rack-protection/Rakefile:13
• .github/workflows/test.yml:55

decided by agent · confidence 0.7

The node declares the sinatra-contrib RSpec suite: `.rspec` supplies the default options every `rspec` run loads, and `--require spec_helper` is what loads the harness for the spec/ tree. The gating signal is that rspec process's exit status, computed by the Ruby runtime from the committed specs and lib/, and propagated by rake's `ruby` helper into the 'Run sinatra-contrib tests' step, which fails the job on all non-allow-failure matrix legs. Two limits, recorded not smoothed: (1) confidence is deliberately low because the literal content of this node is three CLI flags that assert nothing on their own — the anchoring is inherited from the process the file configures; (2) execution is anchored, the oracle is not, since implementation and specs are co-authored in the same repo.

producer the rspec process exit code, produced when CI runs `bundle exec rake` in sinatra-contrib/ (test.yml:156-162) -> `task(:spec) { ruby '-S rspec' }` (sinatra-contrib/Rakefile:9) — actor can write to it: no

• sinatra-contrib/.rspec:1-3
• sinatra-contrib/Rakefile:8-11
• .github/workflows/test.yml:156-162

decided by agent · confidence 0.55 · confidence below 0.6 on an anchored verdict

`rake install:rack-protection` depends on the file task for pkg/rack-protection-<version>.gem, whose body is `sh "cd ./rack-protection && gem build rack-protection.gemspec"`, and then runs `sh "gem install pkg/rack-protection-<version>.gem"` (Rakefile:145-181). RubyGems computes both verdicts from the committed gemspec and source: a malformed gemspec, a file listed but missing, or a version/dependency constraint that will not resolve produces a non-zero exit, rake's `sh` raises on it, and the step fails — which stops the job before the `gem push` steps at lines 27-29 ever run. An author cannot make an unbuildable gem report success without changing the tree. Documented limit: this proves the package builds and installs, not that Sinatra behaves correctly; and it gates the release workflow (tag push), not pull-request merges.

producer the `gem build` and `gem install` process exit codes, propagated by rake's `sh` helper — actor can write to it: no

• .github/workflows/release.yml:22-23
• Rakefile:145-149
• Rakefile:171-181

decided by agent · confidence 0.82

Same causal path as the rack-protection install step, over the root gem: the `install:sinatra` task depends on the pkg/sinatra-<version>.gem file task (`gem build sinatra.gemspec` in `.`) and then shells `gem install` on the built package (Rakefile:145-181). RubyGems reads the committed gemspec and tree to produce the exit status, rake's `sh` raises on non-zero, and a failure blocks the remaining steps of the release job. Documented limit: buildability and installability only — a green here says nothing about runtime behaviour, and this edge is on the tag-triggered release path, not the PR path.

producer the `gem build` and `gem install` process exit codes, propagated by rake's `sh` helper — actor can write to it: no

• .github/workflows/release.yml:24
• Rakefile:131-149
• Rakefile:171-181

decided by agent · confidence 0.82

Identical structure over ./sinatra-contrib: the file task shells `cd ./sinatra-contrib && gem build sinatra-contrib.gemspec`, then `install:sinatra-contrib` runs `gem install pkg/sinatra-contrib-<version>.gem` (Rakefile:145-181). The verdict is computed by RubyGems from the committed gemspec and source files, rake raises on a non-zero child status, and the failure stops the release job before publication. Documented limit: asserts the package builds and installs, not that the library is correct; and the workflow only runs on `v*` tags (release.yml:3-6), so this gates release rather than merge.

producer the `gem build` and `gem install` process exit codes, propagated by rake's `sh` helper — actor can write to it: no

• .github/workflows/release.yml:25
• Rakefile:145-149
• Rakefile:171-181
• .github/workflows/release.yml:3-6

decided by agent · confidence 0.82

Two things block the fork point here, and neither is resolvable from the clone. First, the file sits at .github/workflows/CODEOWNERS; GitHub reads CODEOWNERS only from the repository root, .github/, or docs/, so on that reading this file is never parsed and requests no reviews at all. Second, even a correctly-placed CODEOWNERS only blocks a merge when branch protection has 'require review from Code Owners' enabled, and that setting is repository configuration I cannot inspect — the implementation of this gate lives outside the tree. Whether it blocks anything therefore turns on state that is not in evidence, and it fails closed rather than being filed as inert (which would quietly shrink the denominator) or as a review gate (which would credit a signal I cannot show exists). If it is enforced, a further question remains open: @sinatra/team-sinatra approving a maintainer's own PR is a reviewer inside the same write boundary as the author.

producer cannot be established — a human review requirement, if one is enforced at all, is produced by GitHub branch-protection settings that live outside the repository — actor can write to it: not established

• .github/workflows/CODEOWNERS:1
• .github/ (only workflows/ present; no .github/CODEOWNERS, no root CODEOWNERS, no docs/CODEOWNERS)

decided by agent · confidence 0.6

The step arranges the machine — creates directories, sets ownership and permission bits, or adds a user — so that later steps have somewhere to work. No property of the committed source is read and no comparison is performed, so its exit code varies with the runner's state, never with whether the code is correct. Any assertion in such a job is made by whatever executes against the prepared environment afterwards.

producer shell filesystem/account provisioning commands (mkdir, chmod, chown, adduser, usermod) executed on the runner — actor can write to it: not established

• the run body consists of filesystem/account provisioning commands with no assertion, comparison, or explicit failure branch

decided by probe (runner-filesystem-provisioning) · confidence 0.75

The step arranges the machine — creates directories, sets ownership and permission bits, or adds a user — so that later steps have somewhere to work. No property of the committed source is read and no comparison is performed, so its exit code varies with the runner's state, never with whether the code is correct. Any assertion in such a job is made by whatever executes against the prepared environment afterwards.

producer shell filesystem/account provisioning commands (mkdir, chmod, chown, adduser, usermod) executed on the runner — actor can write to it: not established

• the run body consists of filesystem/account provisioning commands with no assertion, comparison, or explicit failure branch

decided by probe (runner-filesystem-provisioning) · confidence 0.75

This is `task all: %i[readmes index]` inside `namespace :doc` (rack-protection/Rakefile:15-38), so it is `doc:all`. Descending into both children: `doc:readmes` scrapes leading comments out of lib/rack/protection/*.rb and writes doc/*.rdoc; `doc:index` copies README.md to doc/rack-protection-readme.md. Neither compares anything to anything — they are pure emitters, so the aggregate has no pass/fail axis other than a Ruby exception (a missing file), which is not an assertion about the correctness of the library. Excluded from the ratio because there is no verdict here to be grounded or ungrounded.

producer rake's dependency resolver invoking doc:readmes and doc:index, whose bodies only write files — actor can write to it: not established

• rack-protection/Rakefile:37
• rack-protection/Rakefile:16-35

decided by agent · confidence 0.85

`task doc: 'doc:all'` (rack-protection/Rakefile:41) is a one-line alias onto the doc namespace whose entire effect is generating doc/*.rdoc and doc/rack-protection-readme.md from source comments and README.md. No rendered output is compared against a committed baseline, no strictness flag turns a documentation warning into an error, and nothing in the chain shells out to a checker — so the target emits artefacts and asserts nothing about correctness.

producer rake delegating to doc:all, i.e. the two file-writing documentation tasks — actor can write to it: not established

• rack-protection/Rakefile:40-41
• rack-protection/Rakefile:15-38

decided by agent · confidence 0.85

The body reads rack-protection.gemspec, harvests authors from `git shortlog -sn`, a file list from `Dir['lib/**/*']` and the version from Rack::Protection::VERSION, substitutes them into the text, and re-writes the same file (rack-protection/Rakefile:44-70). It is a code generator in the same family as a formatter that only rewrites: there is no comparison stage, no `git diff --exit-code` afterwards, and no exit status that varies with any property of the library other than the substitutions succeeding. Nothing is asserted, so it is excluded from the ratio rather than counted either way.

producer the task body itself, which regex-substitutes fields into rack-protection.gemspec and writes the file back — actor can write to it: not established

• rack-protection/Rakefile:43-70

decided by agent · confidence 0.85

`task gemspec: 'rack-protection.gemspec'` (rack-protection/Rakefile:72) is a bare alias whose only dependency is the generator described above, which rewrites the gemspec in place from git and filesystem metadata. Invoking it produces a modified working tree, not a verdict; there is no downstream comparison in the chain that could fail on a property of the code.

producer rake delegating to the 'rack-protection.gemspec' file-rewriting task — actor can write to it: not established

• rack-protection/Rakefile:72
• rack-protection/Rakefile:44-70

decided by agent · confidence 0.8

The body globs lib/sinatra/*.rb, extracts the leading `# ` comment block with a regex, and writes each result to doc/<name>.rdoc (sinatra-contrib/Rakefile:14-26). Every branch is an emit: `next` on excluded files, `Dir.mkdir` if the output directory is absent, `File.open(..., 'w')` to write. Nothing is compared against a baseline and no exit status varies with a property of the library, so the target asserts nothing about correctness and is excluded from the ratio.

producer the task body, which scrapes leading comments from lib/sinatra/*.rb and writes doc/*.rdoc — actor can write to it: not established

• sinatra-contrib/Rakefile:14-26

decided by agent · confidence 0.85

The step arranges the machine — creates directories, sets ownership and permission bits, or adds a user — so that later steps have somewhere to work. No property of the committed source is read and no comparison is performed, so its exit code varies with the runner's state, never with whether the code is correct. Any assertion in such a job is made by whatever executes against the prepared environment afterwards.

producer shell filesystem/account provisioning commands (mkdir, chmod, chown, adduser, usermod) executed on the runner — actor can write to it: not established

• the run body consists of filesystem/account provisioning commands with no assertion, comparison, or explicit failure branch

decided by probe (runner-filesystem-provisioning) · confidence 0.75

`task all: %i[readmes index]` sits inside `namespace :doc` (sinatra-contrib/Rakefile:13-37), so it is `doc:all`. Its two children generate doc/*.rdoc from source comments and copy README.md to doc/sinatra-contrib-readme.md. The aggregate inherits their shape exactly: files are produced, nothing is verified, and there is no pass/fail axis to ground.

producer rake's dependency resolver invoking doc:readmes and doc:index, both of which only write files — actor can write to it: not established

• sinatra-contrib/Rakefile:36
• sinatra-contrib/Rakefile:14-34

decided by agent · confidence 0.85

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 authentication setup for the later `gem push` steps: the job requests `id-token: write` (release.yml:13-14) and this action turns that token into credentials on the runner. A failure here means the OIDC exchange or the trusted-publishing configuration is wrong, never that the gems are wrong — it evaluates no property of the checked-out tree. It is provisioning, in the same family as checkout and setup-ruby, so it must not enter the ratio in either direction.

producer the rubygems credential-configuration action exchanging the job's OIDC token for a RubyGems API key and writing it to the runner — actor can write to it: not established

• .github/workflows/release.yml:21
• .github/workflows/release.yml:13-14

decided by agent · confidence 0.85

`rake release:rack-protection` depends on `package:rack-protection` (a .gem and a `git archive` tarball) and then runs `gem install <pkg> --local && gem push <pkg>` (Rakefile:183-192). Its distinctive effect is promotion: uploading the package to the public index. A failure means the upload was rejected — duplicate version, bad credentials, registry outage — not that the code is wrong. The one assertion inside the body, that the built gem installs, is not new information here: the install: steps at lines 23-25 of the same job already ran exactly that against the same pkg/ artefacts and are classified anchored on their own, so counting it again would double-enter one signal. Recorded openly because not_a_check is the shoppable class: the promotion reading is what excludes this node, not the difficulty of judging it.

producer `gem push` handing an already-built .gem to rubygems.org (plus a redundant local install of the same package) — actor can write to it: not established

• .github/workflows/release.yml:26-27
• Rakefile:183-192
• .github/workflows/release.yml:23-25

decided by agent · confidence 0.62

Same shape as the rack-protection release step: `release:sinatra` builds/packages then `gem install --local && gem push` (Rakefile:183-192). The step's purpose and its distinctive failure modes are publication-side (version already on rubygems.org, credential exchange, registry availability), none of which is a statement about whether the checked-out code is correct. The build-and-install assertion that shares the body is already carried by the `install:sinatra` edge earlier in the same job, so this node is excluded rather than counted twice.

producer `gem push` handing the already-built sinatra .gem to rubygems.org — actor can write to it: not established

• .github/workflows/release.yml:28
• Rakefile:183-192

decided by agent · confidence 0.62

`release:sinatra-contrib` resolves through the root Rakefile's release namespace to `gem install <pkg> --local && gem push <pkg>` (Rakefile:183-192). The step promotes an artefact an earlier step produced; its exit status reports whether the index accepted the upload, not whether the library behaves. The genuine build/install gate for this package is the separate `install:sinatra-contrib` step (release.yml:25), which is where that signal is counted.

producer `gem push` handing the already-built sinatra-contrib .gem to rubygems.org — actor can write to it: not established

• .github/workflows/release.yml:29
• Rakefile:183-192
• .github/workflows/release.yml:25

decided by agent · confidence 0.62

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