[david-ruiz-cko]

Summary

Security hardening of the CI and publishing workflows (reported internally). Publishing is split into separate build, test, publish and release jobs and uses RubyGems trusted publishing, every workflow pins its actions by commit SHA with read-only default permissions, and CI installs dependencies only from committed lockfiles. No SDK code changes.

Changes

• .github/workflows/build-release.yml: four jobs. build (no secrets) builds and checks the gem and records its digest; test runs the sandbox suite; publish (environment rubygems) publishes with trusted publishing, no stored API key, and only the gem with the recorded digest; release creates the GitHub release with gh release create, replacing the archived create-release action. A manual run publishes a pre-release version as a dry run.
• .github/workflows/build-pull-request.yml, build-master.yml: actions pinned by commit SHA, read-only default permissions, no persisted checkout credentials, frozen installs from the committed lockfiles, no gem cache, lockfile checks before installing.
• .github/workflows/codeql-analysis.yml: CodeQL actions v4 pinned by commit SHA, read-only default permissions.
• Gemfile.lock, gemfiles/ruby_2_7.gemfile, gemfiles/ruby_2_7.gemfile.lock: committed lockfiles; the Ruby 2.7 leg has its own because some locked gems need Ruby 3.0 or later.
• .github/scripts/update-lockfiles.sh: regenerates both lockfiles in Linux containers; run it after changing dependencies or lib/checkout_sdk/version.rb.
• .github/scripts/check_lockfile_checksums.rb: checks that Gemfile.lock only uses rubygems.org and has a checksum for every gem.
• .github/scripts/verify_gem.rb: checks the built gem's name, version and file list before it is published.
• checkout_sdk.gemspec: faraday requirement is now >= 2.0, < 3; lockfiles are not packaged in the gem.
• .gitignore: lockfiles are no longer ignored.

API Reference

None.

Breaking changes

None. The gem now declares faraday < 3; no faraday 3 release exists. The packaged files are the same as in 2.8.2.

Tests

• Existing tests pass
• Serialization tests cover every new or changed property
• README updated if documented usage changed

CI legs Ruby 2.7, 3.1 and 3.3 pass with the committed lockfiles. The publishing steps were run locally in Linux containers matching the runner; actionlint is clean.

After merge: a RubyGems owner registers the trusted publisher (workflow build-release.yml, environment rubygems), then a manual run of build-release with a pre-release version is the dry run. Version bumps now also need .github/scripts/update-lockfiles.sh.

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-master.yml
• security_sensitive_path:.github/workflows/build-pull-request.yml
• security_sensitive_path:.github/workflows/build-release.yml
• security_sensitive_path:.github/workflows/codeql-analysis.yml

Operational gates

• ✅ jira_ticket (INT-1780)
• ✅ independent_review

Files analysed: 12

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-master.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-pull-request.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-release.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/codeql-analysis.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🔵 Advisory review: Sound, but needs your judgement

This PR needs a human approval. The code itself reads as correct; whether it should land depends on context I don't have.

This is a substantial CI/security hardening change that pins actions by SHA, adds trusted publishing, commits lockfiles, and splits the release into four jobs. The code is technically sound and consistent with its stated intent, but several consequential operational decisions require a human to validate before merge.

For you to decide

• The checkout action is pinned to SHA 3d3c42e5aac5ba805825da76410c181273ba90b1 with comment # v7.0.1, but the current stable actions/checkout is v4 — the reviewer should verify this SHA actually corresponds to the intended version and hasn't been mislabelled.
• The actions/upload-artifact is pinned to SHA cf430e030ddbb5b0abf93d22962f4752f3646cd9 with comment # v7.0.2, which is also a non-standard version number for that action (latest major is v4); the reviewer should confirm the SHA and version comment are correct.
• The build-release.yml diff is truncated — the publish and release jobs are not visible, so trusted publishing setup, the sha256 verification before publish, and the gh release create logic cannot be reviewed; a human must check those sections.
• Trusted publishing via RubyGems OIDC requires a matching trusted publisher registration on rubygems.org for the rubygems environment before the workflow will succeed; this is an out-of-band operational step that must happen before the first real release run.
• The set_version.rb script hardcodes expected line counts for the lockfiles (Gemfile.lock => 2, ruby_2_7.gemfile.lock => 1); if the CHECKSUMS section format ever changes these counts, the script will break silently or fail with a confusing error — a human should judge whether this fragility is acceptable.
• The verify_gem.rb ALLOWED_TOP_LEVEL list includes .overcommit.yml, .rspec, .rubocop.yml, and .ruby-version as permitted gem contents; a reviewer should confirm it is intentional to ship these CI/developer-tooling files inside the published gem.
• The update-lockfiles.sh script mounts the entire $PWD read-write into a Docker container (-v "$PWD:/src"), which means a compromised or misbehaving image could modify any file in the repo root; the reviewer should decide if this is an acceptable local-dev risk.
• The gemfiles/ruby_2_7.gemfile.lock has no CHECKSUMS section (Bundler 2.4.22 on Ruby 2.7 cannot produce them), so the lockfile checksum verification is skipped for the Ruby 2.7 CI leg — the reviewer should confirm this known gap is acceptable.
• The concurrency block in build-release.yml sets cancel-in-progress: false with a fixed group name build-release; this means a second push to master while a release is running will queue rather than fail, which is probably correct but should be explicitly confirmed as intended behaviour.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-master.yml
• security_sensitive_path:.github/workflows/build-pull-request.yml
• security_sensitive_path:.github/workflows/build-release.yml
• security_sensitive_path:.github/workflows/codeql-analysis.yml

Operational gates

• ✅ jira_ticket (INT-1780)
• ✅ independent_review

Files analysed: 12

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-master.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-pull-request.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-release.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/codeql-analysis.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-master.yml
• security_sensitive_path:.github/workflows/build-pull-request.yml
• security_sensitive_path:.github/workflows/build-release.yml
• security_sensitive_path:.github/workflows/codeql-analysis.yml

Operational gates

• ✅ jira_ticket (INT-1780)
• ✅ independent_review

Files analysed: 13

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-master.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-pull-request.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-release.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/codeql-analysis.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-master.yml
• security_sensitive_path:.github/workflows/build-pull-request.yml
• security_sensitive_path:.github/workflows/build-release.yml
• security_sensitive_path:.github/workflows/codeql-analysis.yml

Operational gates

• ✅ jira_ticket (INT-1780)
• ✅ independent_review

Files analysed: 14

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-master.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-pull-request.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-release.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/codeql-analysis.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud