feat(inventory): add Inventory endpoint family

[armando-rodriguez-cko]

Summary

Implements the new Inventory product added to the API on 2026-09-10: stock adjustments,
atomic multi-variant reservations (create/get/commit/release), stock levels (get/set), and
beta product knowledge (get/set/delete). All 10 endpoints require the OAuth scope
agentic:inventory, no secret/public key support, reusing this SDK's existing
AuthorizationType::$oAuth client pattern.

Also verified the same swagger diff's PaymentSessionCaptureFlag/PaymentSessionCaptureOn
and PaymentInterfacesPanPreference/PaymentInterfacesProvisionNetworkToken schema
extraction: confirmed no-op for this SDK.

Changes

• lib/Checkout/Inventory/InventoryClient.php — new client, all 10 methods
• lib/Checkout/Inventory/Requests/ — InventoryAdjustmentRequest, InventoryReservationRequest,
  InventorySetLevelsRequest, InventorySetProductRequest
• lib/Checkout/Inventory/Entities/ — InventoryMoney, InventoryReservationItem,
  InventoryConditionType
• lib/Checkout/CheckoutApi.php — wired the new client in
• test/Checkout/Tests/Inventory/InventoryClientTest.php — 10 tests, 23 assertions

Responses stay untyped arrays (@return array), matching every other domain in this SDK;
only request bodies get typed classes per this SDK's convention. No dedicated error-response
class either, since errors surface generically via CheckoutApiException.

API Reference

• POST /inventory/adjustments
• POST /inventory/reservations
• GET /inventory/reservations/{id}
• POST /inventory/reservations/{id}/commit
• POST /inventory/reservations/{id}/release
• GET /inventory/{variant_id}
• PUT /inventory/{variant_id}
• GET /inventory/{variant_id}/product (Beta)
• PUT /inventory/{variant_id}/product (Beta)
• DELETE /inventory/{variant_id}/product (Beta)

Breaking changes

None. Purely additive.

README

No README changes needed.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:778>250

Operational gates

• ✅ jira_ticket (INT-1698)
• ✅ independent_review

Files analysed: 10

---

_{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 — 778>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.

Adds a new Inventory API client with 10 endpoints, request/entity classes, and unit tests. The implementation is structurally consistent with the rest of the SDK, but there are several concrete problems worth resolving before approval.

Concerns

• The diff is truncated in multiple places (InventoryClient.php getInventor..., InventorySetProductRequest.php $expira..., and the test file cut mid-method), so the full implementation cannot be verified — the reviewer must check the complete files.
• The InventoryClient is wired to $baseApiClient in CheckoutApi.php constructor, but other OAuth-only clients in this SDK (e.g. IssuingClient) may use a dedicated OAuth ApiClient instance; using $baseApiClient for an OAuth-only endpoint could result in auth failures at runtime if $baseApiClient is not an OAuth client.
• Unit tests mock $this->apiClient->method('post') without ->with(...) constraints, so the tests do not actually verify that the correct URL path or request body is passed — commit and release both call post and share the same mock, making it impossible to distinguish which call returns which response when both are exercised.
• The shouldCommitInventoryReservation and shouldReleaseInventoryReservation tests both stub method('post') with a single willReturn, but since these are on the same mock object, if both tests ever run through a shared mock they could interfere; more importantly neither test verifies the path segment (commit vs release) is actually appended.
• The InventoryConditionType pseudo-enum uses public static $new, $used, $refurbished — these are mutable static properties, not constants, which is inconsistent with how other enums are defined in this SDK (typically const) and allows accidental mutation.
• The test file builds buildExpectedInventoryLevelsResponse() and buildExpectedProductKnowledgeResponse() helper methods whose implementations are in the truncated portion of the diff, so the actual assertions being made cannot be fully reviewed.
• The getInventoryLevels method accepts an optional $expand query parameter — it is unclear from the truncated diff whether this is appended as a query string or silently ignored, which would be a functional bug.
• No integration/functional tests are included, which is fine if the SDK pattern doesn't require them, but the truncation means this cannot be confirmed.

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

[sonarqubecloud]

Quality Gate passed

Issues
28 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