feat(setups): add the setup payment type, confirm risk and tamara fields by rodrigojara-cko · Pull Request #700 · checkout/checkout-sdk-java

rodrigojara-cko · 2026-10-26T14:21:05Z

Summary

payment_type on Payment Setup used the payments PaymentType, which sends PayLater, rejected by the API with 422, and reads every lowercase value except regular as null. It now has its own enum with the six spec values. The confirm response gets the risk it was missing and Tamara gets initialization and risk_assessment. last_payment_amount takes the specification's number type.

Changes

entities/paymentType/PaymentSetupPaymentType.java (new): REGULAR, RECURRING, MOTO, INSTALLMENT, PAY_LATER, UNSCHEDULED, sent lowercase. Used by PaymentSetupsRequest (default REGULAR), PaymentSetupsResponse and PaymentSetupsConfirmResponse; com.checkout.payments.PaymentType is unchanged.
PaymentSetupsConfirmResponse.java: risk (PaymentSetupRisk).
tamara/Tamara.java: initialization (default DISABLED, as the other methods) and riskAssessment; tamara/TamaraRiskAssessment.java (new).
customer/MerchantAccount.java: lastPaymentAmount is Double (was Long), the specification's number type, as the Flow and payment response fields. Its doc notes that the API currently stores it as an integer. The docs of all eight properties use the spec descriptions.
Klarna, Bacs, CashApp, PayPal, Stcpay, Tabby, Tamara: the initialization doc gives the spec description and default, and says that an update replaces the payment methods, so ENABLED must be sent again to keep a method enabled (API behaviour, not stated in the spec).
PaymentMethods.java, Order.java, the request and both responses: docs completed against the spec.
Doc only, against the spec: Bacs.allowPartialMatch, PayPal.brandName and action, Stcpay.otp and action, Knet.language, and the class docs of Order, PaymentMethods, Stcpay and Tabby.
ideal/Ideal.java description, knet/Knet.java language, bancontact/Bancontact.java accountHolderName: the doc says that the specification marks the field optional, but the API keeps the method invalid until it is sent.
Tests: every PaymentSetupPaymentType value written and read, the default, round trips through the request and both responses; PaymentSetupsConfirmResponseSerializationTest reads and round trips the confirm risk; Order and Tamara round trips with literal keys and the spec examples; PaymentSetupsTestIT uses the new enum.
PaymentSetupsPaymentMethodsSerializationTest.java (new): a round trip with every property under its literal wire key and a spec example test for Ach, Sepa, Swish, P24, Qpay, Ideal, Knet, Bancontact, Multibanco, Blik, Bacs, Alipay CN, Alipay HK, GCash, TNG, Dana, KakaoPay, TrueMoney, Alma, Benefit, EPS, MBWay, MobilePay, Octopus, PayNow, Sequra, Twint, Vipps and WeChatPay; last_payment_amount round trip under its literal key with the spec example 55.99.
PaymentSetupsNewFieldsSerializationTest.java, LocalDateFieldsRegressionTest.java: lastPaymentAmount uses 55.99.

API Reference

Breaking changes required by the API

paymentType on PaymentSetupsRequest, PaymentSetupsResponse and PaymentSetupsConfirmResponse is PaymentSetupPaymentType; code passing com.checkout.payments.PaymentType must switch, including PaymentType.REGULAR, which no longer compiles there (use PaymentSetupPaymentType.REGULAR).
The all-args constructor of PaymentSetupsConfirmResponse takes the new risk argument.

Breaking changes: type corrected to the specification

MerchantAccount.lastPaymentAmount is Double instead of Long. The specification types it as a number (example 55.99), which a Long cannot hold: if the API returns a decimal, reading the whole Payment Setup response fails. Code that passes a Long (for example lastPaymentAmount(1000L)) or reads the value as Long stops compiling and must use Double. The API currently stores the value as an integer (55.99 is stored as 55); that is reported separately.

Breaking changes: default value

Tamara now sends "initialization":"disabled" by default (master sent {}), as the other methods with initialization. Harmless: an update replaces the payment methods, so omitting it also leaves Tamara disabled. Migration: set initialization to ENABLED to enable Tamara.

Follow-ups

Reported internally, for later:

Order.items and Order.shipping keep the payments types until the next major version.
The confirm response keeps its own class (PaymentSetupsConfirmResponse, a duplicate of PaymentSetupsResponse) until the next major version.
The responses inherit the Resource links, which the Payment Setups specification does not define.
CardAccountHolder keeps its name (the spec calls it PaymentSetupAccountHolder) until the next major version.
terminal.local_date_time is an Instant and loses the offset (tracked separately).
latestPayment on both responses stays typed Object (spec PaymentDetails) until a later major version.

README

No change needed.

payment_type used the payments PaymentType, which sends PayLater (rejected with 422) and cannot read the lowercase values the API returns. The confirm response gets risk, Tamara gets initialization and risk_assessment, and card_present is deprecated.

agent-wall-e · 2026-10-26T14:21:09Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:425>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 19

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

agent-wall-e · 2026-10-26T14:21:10Z

🔬 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
`exceeds_bounded_scope` — `425>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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 · 2026-10-26T14:21:18Z

🟢 Advisory review: Looks good to me

This PR still needs a human approval — wall-e cannot auto-approve it. For what it's worth, I read the diff and found nothing I'd block on.

This PR adds a dedicated PaymentSetupPaymentType enum with correct lowercase serialization, adds risk to PaymentSetupsConfirmResponse, adds initialization/riskAssessment to Tamara, and corrects lastPaymentAmount from Long to Double — all claims verified against the diff. The changes look correct and are well-tested.

What I checked

New PaymentSetupPaymentType enum uses @SerializedName for all six lowercase values matching the API spec, correctly replacing com.checkout.payments.PaymentType which would have sent PayLater (rejected) and misread lowercase values.
PaymentSetupsConfirmResponse now includes risk (PaymentSetupRisk) matching PaymentSetupsResponse, with both a deserialization test using a literal key and a round-trip test.
MerchantAccount.lastPaymentAmount changed from Long to Double is consistent with the spec example (55.99) and matches how other last_payment_amount fields are typed; the doc note about the API storing it as an integer is appropriately flagged.
TamaraRiskAssessment is a clean new class with @Builder/@Data/@NoArgsConstructor/@AllArgsConstructor; orderCountLast24h uses Integer matching the Tamara API convention.
Integration test PaymentSetupsTestIT correctly switches to PaymentSetupPaymentType.REGULAR.
The shouldNotReadPascalCasePaymentTypeTheApiDoesNotUse test confirms backward-incompatible deserialization of old PayLater-style values returns null — this is correct but the breaking-change implication is well-documented in the PR.
The diff is truncated so the full PaymentSetupsPaymentMethodsSerializationTest (835 lines) is not entirely visible, but the visible portion shows correct literal-key round-trip and spec-example patterns.

⚠️ 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}

Adds round trip and spec example tests for every payment method without one, documents that the API stores last_payment_amount as an integer, and drops the initialization doc sentence the spec does not support.

agent-wall-e · 2026-10-27T11:23:44Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:417>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 20

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

agent-wall-e · 2026-10-27T11:23:45Z

🔬 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
`exceeds_bounded_scope` — `417>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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 · 2026-10-27T12:42:14Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:417>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 20

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

agent-wall-e · 2026-10-27T12:42:15Z

🔬 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
`exceeds_bounded_scope` — `417>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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}

MerchantAccount.lastPaymentAmount is a Double, the type the specification gives last_payment_amount, as in the other SDKs. card_present and its classes are restored as on master: the API still supports them.

agent-wall-e · 2026-10-27T14:02:41Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:412>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 20

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

agent-wall-e · 2026-10-27T14:02:42Z

🔬 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
`exceeds_bounded_scope` — `412>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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 · 2026-10-27T15:35:20Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:415>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 23

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

agent-wall-e · 2026-10-27T15:35:21Z

🔬 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
`exceeds_bounded_scope` — `415>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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 · 2026-10-29T13:37:36Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:430>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 23

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

agent-wall-e · 2026-10-29T13:37:37Z

🔬 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
`exceeds_bounded_scope` — `430>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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 · 2026-10-29T13:38:14Z

Quality Gate passed

Issues
1 New issue
0 Accepted issues

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

See analysis details on SonarQube Cloud

…suing This release adds the Payment Setup payment type, the risk settings on the Payment Setup confirm response and the Tamara risk assessment fields. It also adds the subscription details and the retry attempt count to payment responses, and lets you revoke and suspend Issuing cards without a request body. Customer retries on hosted payments and payment links now use the type the API accepts, and the update card headers the API no longer documents are deprecated. Every deprecated member keeps working and will be removed in the next major version. **Added** Issuing (#697) * `IssuingClient#revokeCard(String cardId)`, `#suspendCard(String cardId)`, `#revokeCardSync(String cardId)` and `#suspendCardSync(String cardId)`. The existing overloads that take a `RevokeCardRequest` or `SuspendCardRequest` now accept `null`, because the request body is optional in the API. Payment Setups (#700) * `PaymentSetupPaymentType` with the values of the Payment Setups API: `REGULAR` (`regular`), `RECURRING` (`recurring`), `MOTO` (`moto`), `INSTALLMENT` (`installment`), `PAY_LATER` (`pay_later`), `UNSCHEDULED` (`unscheduled`). * `PaymentSetupsConfirmResponse#risk` (`PaymentSetupRisk`). * `Tamara#initialization` (`PaymentMethodInitialization`, default `DISABLED`) and `Tamara#riskAssessment`, with the new `TamaraRiskAssessment` (`premiumCustomer`, `riskScore`, `orderCountLast24h`, `linkedDeviceCount`). Payments (#701) * `PaymentResponse#subscription` (`PaymentSubscription`). * `PaymentRetryResponse#attemptsMade`, returned by get payment details. **Changed** * `PaymentRetryRequest#enabled` is no longer deprecated. It is the required switch for asynchronous retries on payment requests (#701). * Request and response fields of payments, payment retries, hosted payments, payment links, payment sessions and Payment Setups now document whether they are required or optional, with the limits, defaults and enum values of the API reference (#700, #701). * Payment Setup payment methods document that an update replaces the payment methods, so `initialization` must be sent as `ENABLED` again to keep a method enabled (#700). **Fixed** * The `Retry` response of a payment request no longer reports `maxAttempts` as 6 when the API did not return it (#701). **Deprecated** All deprecated members keep working and will be removed in the next major version. * `CardUpdateHeaders` and the `IssuingClient#updateCard` and `#updateCardSync` overloads that take it: the API no longer documents the `return-encrypted-cvv` and `Encryption-Key` headers. Headers that are set are still sent. Use `updateCard(String, UpdateCardRequest)` or `updateCardSync(String, UpdateCardRequest)` (#697). * `HostedPaymentRequest#setCustomerRetry(PaymentRetryRequest)` and `HostedPaymentRequestBuilder#customerRetry(PaymentRetryRequest)`: customer retries only accept `max_attempts`, so only that value is kept. Use the `CustomerRetry` overloads (#701). * `PaymentLinkRequest#setCustomerRetry(PaymentRetryRequest)` and `PaymentLinkRequestBuilder#customerRetry(PaymentRetryRequest)`: same reason. Use the `CustomerRetry` overloads (#701). **Breaking changes required by the API** ⚠️ * `PaymentSetupsRequest#paymentType`, `PaymentSetupsResponse#paymentType` and `PaymentSetupsConfirmResponse#paymentType` change from `com.checkout.payments.PaymentType` to `PaymentSetupPaymentType`. The Payment Setups API only accepts the lowercase values; the old type sent `PayLater`, which the API rejects with a 422, and read every value except `regular` as null. Migration: replace `PaymentType.X` with `PaymentSetupPaymentType.X` (#700). * `MerchantAccount#lastPaymentAmount` (Payment Setups customer) changes from `Long` to `Double`, because the API defines it as a number (for example `55.99`). Migration: pass a `Double` (for example `500d`) and read the getter as `Double` (#700). * `HostedPaymentRequest#customerRetry` and `PaymentLinkRequest#customerRetry` change from `PaymentRetryRequest` to `CustomerRetry`, because customer retries only accept `max_attempts` (0 to 5). Code that sets the field keeps compiling through the deprecated overloads; code that reads `getCustomerRetry()` now gets a `CustomerRetry`. Migration: `CustomerRetry.builder().maxAttempts(n).build()` (#701). **Dependencies** * gson 2.14.0, slf4j-api 2.0.18 and commons-codec 1.22.1, all still compatible with Java 8 (#702).

This release adds the Payment Setup payment type, the risk settings on the Payment Setup confirm response and the Tamara risk assessment fields. It also adds the subscription details and the retry attempt count to payment responses, and lets you revoke and suspend Issuing cards without a request body. Customer retries on hosted payments and payment links now use the type the API accepts, and the update card headers the API no longer documents are deprecated. Every deprecated member keeps working and will be removed in the next major version. **Added** Issuing (#697) * `IssuingClient#revokeCard(String cardId)`, `#suspendCard(String cardId)`, `#revokeCardSync(String cardId)` and `#suspendCardSync(String cardId)`. The existing overloads that take a `RevokeCardRequest` or `SuspendCardRequest` now accept `null`, because the request body is optional in the API. Payment Setups (#700) * `PaymentSetupPaymentType` with the values of the Payment Setups API: `REGULAR` (`regular`), `RECURRING` (`recurring`), `MOTO` (`moto`), `INSTALLMENT` (`installment`), `PAY_LATER` (`pay_later`), `UNSCHEDULED` (`unscheduled`). * `PaymentSetupsConfirmResponse#risk` (`PaymentSetupRisk`). * `Tamara#initialization` (`PaymentMethodInitialization`, default `DISABLED`) and `Tamara#riskAssessment`, with the new `TamaraRiskAssessment` (`premiumCustomer`, `riskScore`, `orderCountLast24h`, `linkedDeviceCount`). Payments (#701) * `PaymentResponse#subscription` (`PaymentSubscription`). * `PaymentRetryResponse#attemptsMade`, returned by get payment details. **Changed** * `PaymentRetryRequest#enabled` is no longer deprecated. It is the required switch for asynchronous retries on payment requests (#701). * Request and response fields of payments, payment retries, hosted payments, payment links, payment sessions and Payment Setups now document whether they are required or optional, with the limits, defaults and enum values of the API reference (#700, #701). * Payment Setup payment methods document that an update replaces the payment methods, so `initialization` must be sent as `ENABLED` again to keep a method enabled (#700). **Fixed** * The `Retry` response of a payment request no longer reports `maxAttempts` as 6 when the API did not return it (#701). **Deprecated** All deprecated members keep working and will be removed in the next major version. * `CardUpdateHeaders` and the `IssuingClient#updateCard` and `#updateCardSync` overloads that take it: the API no longer documents the `return-encrypted-cvv` and `Encryption-Key` headers. Headers that are set are still sent. Use `updateCard(String, UpdateCardRequest)` or `updateCardSync(String, UpdateCardRequest)` (#697). * `HostedPaymentRequest#setCustomerRetry(PaymentRetryRequest)` and `HostedPaymentRequestBuilder#customerRetry(PaymentRetryRequest)`: customer retries only accept `max_attempts`, so only that value is kept. Use the `CustomerRetry` overloads (#701). * `PaymentLinkRequest#setCustomerRetry(PaymentRetryRequest)` and `PaymentLinkRequestBuilder#customerRetry(PaymentRetryRequest)`: same reason. Use the `CustomerRetry` overloads (#701). **Breaking changes required by the API** ⚠️ * `PaymentSetupsRequest#paymentType`, `PaymentSetupsResponse#paymentType` and `PaymentSetupsConfirmResponse#paymentType` change from `com.checkout.payments.PaymentType` to `PaymentSetupPaymentType`. The Payment Setups API only accepts the lowercase values; the old type sent `PayLater`, which the API rejects with a 422, and read every value except `regular` as null. Migration: replace `PaymentType.X` with `PaymentSetupPaymentType.X` (#700). * `MerchantAccount#lastPaymentAmount` (Payment Setups customer) changes from `Long` to `Double`, because the API defines it as a number (for example `55.99`). Migration: pass a `Double` (for example `500d`) and read the getter as `Double` (#700). * `HostedPaymentRequest#customerRetry` and `PaymentLinkRequest#customerRetry` change from `PaymentRetryRequest` to `CustomerRetry`, because customer retries only accept `max_attempts` (0 to 5). Code that sets the field keeps compiling through the deprecated overloads; code that reads `getCustomerRetry()` now gets a `CustomerRetry`. Migration: `CustomerRetry.builder().maxAttempts(n).build()` (#701). **Dependencies** * gson 2.14.0, slf4j-api 2.0.18 and commons-codec 1.22.1, all still compatible with Java 8 (#702).

rodrigojara-cko requested a review from a team October 26, 2026 14:21

feat(setups): add serialization tests for the setup payment methods

fd711b6

Adds round trip and spec example tests for every payment method without one, documents that the API stores last_payment_amount as an integer, and drops the initialization doc sentence the spec does not support.

github-advanced-security Bot found potential problems Oct 27, 2026

View reviewed changes

Comment thread ...m/checkout/handlepaymentsandpayouts/setups/PaymentSetupsPaymentMethodsSerializationTest.java Resolved

test(setups): add multibanco serialization tests

03d1e1f

rodrigojara-cko added 2 commits October 27, 2026 14:28

fix(setups): type last_payment_amount as a number; keep card_present

be4cfe6

MerchantAccount.lastPaymentAmount is a Double, the type the specification gives last_payment_amount, as in the other SDKs. card_present and its classes are restored as on master: the API still supports them.

docs(setups): note that an update replaces the payment methods

72cc569

docs(setups): note the ideal, knet and bancontact fields the API needs

7b6844a

rodrigojara-cko added 2 commits October 29, 2026 13:00

docs(setups): use the spec descriptions for merchant account and knet

338404d

test(setups): describe what the old payment type sent and read

c63dda9

david-ruiz-cko approved these changes Oct 29, 2026

View reviewed changes

rodrigojara-cko merged commit 7892e51 into master Oct 30, 2026
6 checks passed

rodrigojara-cko deleted the feat/INT-1738-payment-setup-gaps branch October 30, 2026 06:53

armando-rodriguez-cko mentioned this pull request Nov 2, 2026

Release 8.9.0 - payment setups, retries and issuing #705

Open

Conversation

rodrigojara-cko commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

agent-wall-e Bot commented Oct 26, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 26, 2026

Uh oh!

agent-wall-e Bot commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🟢 Advisory review: Looks good to me

What I checked

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 29, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 29, 2026

Uh oh!

sonarqubecloud Bot commented Oct 29, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

rodrigojara-cko commented Oct 26, 2026 •

edited

Loading

agent-wall-e Bot commented Oct 26, 2026 •

edited

Loading