Skip to content

RFC: Pact MkII — a ground-up redesign of the Pact framework - #146

Open
rholshausen wants to merge 2 commits into
masterfrom
rfc/pact-mkii
Open

RFC: Pact MkII — a ground-up redesign of the Pact framework#146
rholshausen wants to merge 2 commits into
masterfrom
rfc/pact-mkii

Conversation

@rholshausen

Copy link
Copy Markdown

This RFC is a thought experiment made concrete: if we designed Pact from scratch today, what would we keep, change, and throw away? It proposes Pact MkII (working title), built on five pillars:

  1. One core, thin SDKs — a single reference engine behind a coarse-grained, versioned protocol (WASM component / subprocess / minimal C ABI embeddings), replacing the lock-step pact-jvm + pact-reference implementations and the fine-grained C FFI.
  2. Declarative interactions, compiled plans — DSLs produce declarative interaction specs; the engine compiles them to inspectable matching plans (pact explain), building on the v2 matching engine prototyped in pact-reference.
  3. Everything is a component — transports, content handlers, matchers, generators and hooks all implement the same interfaces, including the built-in ones; plugins stop being a bolt-on.
  4. Shapes with honest optionalityoptional, oneOf, anyOf and cardinality, made safe by variant testing (every declared variation is actually exercised and replayed), plus provider-published shapes with a subsumption check to catch response variance the consumer never declared.
  5. Scriptable lifecycle — named hook points (auth injection, state setup, message production) with declarative config first and scripts as the escape hatch.

The consumer-driven workflow, the pact file as artifact, and the broker/can-i-deploy workflow are all retained. v1–v4 pact files remain verifiable and a pact upgrade tool is proposed. Deterministic verification remains the foundation; AI assistance (SDK maintenance, mismatch diagnosis, agentic orchestration) is strictly optional.

Backwards compatibility is explicitly not a constraint for this exercise, though a migration path is sketched. Feedback is welcome on any part, but the unresolved questions section lists the areas where community input would help most: naming/versioning, the day-one scope of the component model, variant sampling defaults, and subsumption policy.

🤖 Generated with Claude Code

rholshausen and others added 2 commits July 30, 2026 16:09
Proposes a single-engine architecture with thin generated SDKs, declarative
interactions compiled to inspectable matching plans, components/plugins as
the core design, a shape language with variant testing for optional and
polymorphic values, provider shapes with a subsumption check, and scriptable
lifecycle hooks.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@rholshausen
rholshausen marked this pull request as ready for review July 30, 2026 06:13
@YOU54F

YOU54F commented Jul 30, 2026

Copy link
Copy Markdown
Member

good read, will take some time to mull over. sounds really promising

@rholshausen

Copy link
Copy Markdown
Author

good read, will take some time to mull over. sounds really promising

Even Claude agrees:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants