[ken0nek]

Description

The suite never asserts ready_for_complete. The string occurs once, in validation_test.py, among the statuses a failed operation may leave behind. A server that never leaves incomplete passes all 11 tests in checkout_lifecycle_test.py, and the Node sample server is such a server.

This change adds one test, test_ready_for_complete_when_nothing_is_outstanding. It creates a checkout with a buyer, and the existing helper selects a fulfillment destination and option. The test reads the session with Get Checkout and checks that it has no error message and no Action. It then calls Complete Checkout and requires completed. Last, it asserts that the status it read before completion was ready_for_complete.

The completion proves the premise. If the business places the order with no further input, nothing was outstanding when the test read the status, and the status should have said so. test_complete_checkout already requires the same fixture to complete, so the only new demand on a server is the status.

Results against samples 822431e:

Server	This test	checkout_lifecycle_test.py
Python sample server	passes	12 of 12
Node sample server	fails: "reported status 'incomplete' before completion, expected 'ready_for_complete'"	11 of 12
Node sample server with the fix in Universal-Commerce-Protocol/samples#253	passes	12 of 12

The test does not cover the converse case. The Python sample server returns ready_for_complete at create for a session with no fulfillment, and then refuses Complete Checkout on it. A second test would catch that, and it is not part of this change.

Related: #111 lets other assertions in this file fail. It does not touch readiness. Both PRs add to the same file, so whichever lands second needs a rebase. Universal-Commerce-Protocol/ucp#949 raises the spec question.

Type of change

• New feature (non-breaking change which adds functionality)

---

Is this a Breaking Change or Removal?

No. The change removes no schema file and no field.

---

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules