[david-ruiz-cko]

Summary

Security hardening (reported internally): input validation for request paths. Identifiers passed to client methods are percent-encoded by the SDK, and invalid identifiers raise CheckoutArgumentException before any request is sent (see Breaking changes). Request paths for valid identifiers are unchanged.

Changes

• lib/checkout_sdk/checkout_utils.rb: new encode_path_segment, RFC 3986 path segment encoding (unreserved characters kept, everything else percent-encoded as UTF-8) with input validation.
• lib/checkout_sdk/client.rb: build_path encodes every argument with encode_path_segment.
• lib/checkout_sdk/apm/bacs/bacs_client.rb: multi-segment private constant split into single segments; request path unchanged.
• lib/checkout_sdk/apm/previous/sepa/sepa_client.rb: same, for the four mandate operations.
• lib/checkout_sdk/instruments/instruments_client.rb: same, for get_bank_account_field_formatting.
• lib/checkout_sdk/payments/setups/payment_setups_client.rb: input validation.
• README.md: Exception handling, identifier encoding and when CheckoutArgumentException is raised.
• spec/checkout_sdk/client_spec.rb: new, path building, request paths through Faraday's test adapter, and the request paths of the split constants.
• spec/checkout_sdk/checkout_utils_spec.rb: encode_path_segment.
• spec/checkout_sdk/payments/setups/payment_setups_client_spec.rb: input validation.

API Reference

None.

Breaking changes ⚠️

• Client methods validate identifiers and path parameters and raise CheckoutSdk::CheckoutArgumentException for invalid values before sending a request. The rules are in the README, Exception handling.
• Identifiers are percent-encoded by the SDK. An identifier that the caller had already encoded is encoded again (SKU%201 is sent as SKU%25201).
• Migration: pass identifiers unencoded, and validate or rescue CheckoutArgumentException where identifiers come from user input.

Tests

• Existing tests pass (unit suite and rubocop lib; integration tests run in CI against the sandbox)
• Serialization tests cover every new or changed property (no request or response properties changed)
• README updated if documented usage changed (Exception handling)

Related

None.

[agent-wall-e]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket (UTF-8)
• ✅ independent_review

Files analysed: 1

---

_{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
no_low_class_matched	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
prod_source_modified	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

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.

The diff only shows the version bump and a CI permissions fix — the substantive security changes (encode_path_segment, build_path encoding, constant splits, new specs) are not visible in the diff provided.

For you to decide

• The diff is partial: none of the claimed changes to checkout_utils.rb, client.rb, bacs_client.rb, sepa_client.rb, instruments_client.rb, payment_setups_client.rb, README.md, or any spec files are present, so their correctness cannot be verified.
• The CI permissions addition (contents: write) is operationally significant and looks intentional for release automation, but a reviewer should confirm the repository's security posture allows this on the master branch.
• Version bump from 2.8.1 to 2.8.2 is consistent with the stated patch-level security release, but the actual security fix cannot be reviewed from what is shown.

---

_{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-release.yml

Operational gates

• ✅ jira_ticket (UTF-8)
• ✅ independent_review

Files analysed: 2

---

_{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-release.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