Release 2.8.0

[ali-farhadi-cko]

Automated release of CheckoutComponentsSDK 2.8.0

Changelog

• [ADDED] Saved cards with RememberMe in Flow
• [ADDED] Remember Me account lookup by prefilled phone number
• [UPDATED] Risk SDK version to 6.0.1

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:2019>250

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 18

---

_{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
exceeds_bounded_scope — 2019>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]

🟠 Advisory review: Concerns worth a look

This PR needs a human approval. Before you give it, these are the things I'd want resolved.

This release bumps the SDK to 2.8.0 and adds saved-cards-with-RememberMe support in the sample app. Two concrete issues need resolution before approving.

Concerns

• CHANGELOG.md has an orphan '##' separator between the 2.8.0 and 2.7.0 entries (line ~16), which is a formatting artifact that will render as a stray horizontal rule in every changelog viewer.
• CHANGELOG.md release date for 2.8.0 is '06.10.2026' — this is a future date (and 2.7.0 is dated '24.09.2026'), so either the date format is wrong (DD.MM.YYYY vs MM.DD.YYYY) or both entries were given incorrect dates.
• Package.swift changes the Risk SDK dependency from from: "4.0.1" (any version ≥ 4.0.1) to exact: "6.0.1" — this is a major-version jump of 2 with a breaking constraint; the reviewer should confirm the binary xcframework checksums were generated against a build that actually used Risk SDK 6.0.1 and that this major bump is intentional.
• SampleApplication/Release-SPM-File/Package.swift uses from: "6.0.1" (semver-open) while the main Package.swift uses exact: "6.0.1" (pinned) — the two manifests have diverging resolution strategies for the same dependency, which could cause the sample app to resolve a different Risk SDK version than the released framework was built against.
• The sdkChecksum in SampleApplication/Release-SPM-File/Package.swift (b1d3d123...) differs from the main Package.swift sdkChecksum (f473d4fb...) — this is expected if they point to different binaries, but it should be verified that the sample-app release file checksum matches the artifact it actually downloads.
• test_applyLaunchConfig_explicitEmptyCustomerFields_overridesDefaults asserts that passing empty strings clears defaults, but applyCustomerSettings in LaunchConfigHydrator.swift applies customer fields unconditionally (no empty-string guard), meaning this is already the implemented behaviour — the test is valid, but the reviewer should confirm the intent is to clear defaults on empty string, not treat empty string as 'not provided'.

⚠️ 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: MINOR

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

Classification reasons

• exceeds_bounded_scope:2021>250

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 18

---

_{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
exceeds_bounded_scope — 2021>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]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:2048>250

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 18

---

_{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
exceeds_bounded_scope — 2048>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]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:2048>250

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 18

---

_{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
exceeds_bounded_scope — 2048>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]

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