Org Web Adapter

Editing hungryroot/contract-testing/colin-vs-henry-doc.org

:PROPERTIES:
:ID:       8ca107d6-7ace-4dc0-a026-e29ff7c3f87c
:END:
#+title: Contract Testing: Colin's Proposal vs Henry's Sodapop RFC

* Sources
- [[https://hungryroot.atlassian.net/wiki/spaces/BA/pages/1535868929/Backend+Project+Proposal+Contract+Testing+with+Schemathesis+and+Pact][BE: Contract Testing with Schemathesis and Pact]] (Colin Powell)
- [[https://hungryroot.atlassian.net/wiki/spaces/WD/pages/1584168961/RFC+Client-Safe+Sodapop+UI+Attachments+and+Suggested+Action+Contracts][RFC: Client-Safe Sodapop UI Attachments and Suggested Action Contracts]] (Henry Ng)

* Where They Align

Both propose Pact for consumer-driven contract testing. Same model:
- Consumers: web, iOS, Android
- Provider: server
- Goal: block incompatible deploys

Both enforce explicit contract versioning (=action.add.v1=, =action.add.v2=) and
deprecation windows. Philosophically identical.

* Where They Differ

| Dimension              | Colin (BE)                               | Henry (Sodapop RFC)                              |
|------------------------+------------------------------------------+--------------------------------------------------|
| Layer                  | REST API schema (OpenAPI/DRF)            | Sodapop AI response UI contracts                 |
| Problem                | Schema drift: spec ≠ implementation      | Capability mismatch: server emits UI clients can't render |
| Phase 1                | Schemathesis (OpenAPI validation)        | Capability registry + server-owned profiles      |
| Pact path              | Pact Broker (PactFlow) from Phase 2      | Lightweight path (shared fixtures + CI) first, broker later |
| Novel concept          | None beyond standard Pact                | Server-side capability profiles by client identity |
| Conversation history   | Not addressed                            | Full cross-platform replay safety model          |
| Owners defined?        | Placeholder [Assign Owner]               | Henry authored; resolution location open question |

* Key Tensions

** Two Pact setups, one broker question
Colin's doc plans PactFlow from Phase 2. Sodapop RFC defers broker until
"fixtures become painful." If web ships the lightweight path first, we could
end up with divergent contract validation infrastructure before Phase 2 lands.

** Scope gap
Colin's doc covers the Django REST API. Sodapop RFC covers Sodapop AI
responses. Neither covers the other's domain — but both need Pact, so the
broker ownership and CI integration need to be shared infrastructure, not two
separate things.

** Capability registry is unowned
Sodapop RFC leaves open: "should resolution live in Hungryroot API layer or
Sodapop?" — that's a backend decision that directly affects Phase 2 scope.

* Practical Synthesis

Colin's Phase 1 (Schemathesis) is orthogonal to the Sodapop RFC — no
conflict, different layer entirely. Start it independently.

Colin's Phase 2 (Pact Broker) *is* the Sodapop RFC's "Contract Testing With
Pact" section. Henry's doc even says as much. The smart move: coordinate on a
single shared Pact Broker before either team sets one up solo. Colin's doc has
the infra plan; Henry's doc has the Sodapop-specific contracts. They need each
other.

Recommend getting Henry into the Phase 2 kickoff (already scheduled June 3).
The capability registry ownership question is a blocker for both.