# Changelog

> **This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.**

## Score

- CAI 76 → 71 (-4.4)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 80 → 65 (-14.7)
- Architecture 89 → 99 (+10.3)
- Maturity 76 → 73 (-3.1)
- Readiness 73 → 73 (+0.1)
- Security 77 → 83 (+6.8)

## Resolved (22)

- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- Inconsistent constructor signatures for PactConfig between Consumer and Provider domains. The Consumer config requires explicit `consumer_name` and `provider_name` arguments, while the Provider config only requires `provider_name`. This forces developers to remember different initialization patterns depending on which side of the pact they are configuring.
- Inconsistent method naming for generating the interaction JSON. Most builders use `interaction_json()`, but `MessageInteractionBuilder` uses `build_interaction_json()`. This inconsistency is confusing and suggests a lack of unified interface implementation.
- Inconsistent naming and argument structure for setting request/response payloads across different interaction builders. HTTP builders use `with_request` with positional arguments, while gRPC and Plugin builders use `with_request` with a hash. Message builders use `with_json_contents` or `with_proto_contents`. This lack of uniformity makes it difficult to write generic test code or switch between transport types.
- Off-boarding risk: anonymized user #1
- Outdated: rubocop-rails
- …and 2 more

## New (13)

- Duplicate intent between `ProviderServerRunner` and `ProviderStateServlet`. Both classes expose methods to add setup/teardown states with identical signatures. It is unclear why both exist and when to use one over the other, suggesting a potential architectural duplication.
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- Hotspot: lib/pact/consumer/plugin_http_interaction_builder.rb (lib/pact/consumer/plugin_http_interaction_builder.rb)
- Inconsistent constructor signatures for Consumer vs Provider PactConfig. The Consumer config requires `consumer_name` and `provider_name` as positional arguments, while the Provider config only requires `provider_name` (and omits `consumer_name`). This forces different initialization patterns for symmetric concepts.
- Inconsistent method names for generating the interaction JSON representation. Most builders use `interaction_json()`, but `MessageInteractionBuilder` uses `build_interaction_json()`. This is a minor naming inconsistency that breaks the pattern.
- Inconsistent naming and argument structure for defining responses. HTTP builders use `will_respond_with` with explicit HTTP components, while gRPC and Sync Message builders use `will_respond_with` with a generic hash. This mirrors the request inconsistency and breaks the symmetry between request and response definition patterns in the same builder types.
- Inconsistent naming and argument structure for setting request/response payloads across interaction builders. HTTP builders use `with_request` with explicit HTTP components, while gRPC and Sync Message builders use `with_request` with a generic hash. Message builders use `with_json_contents` or `with_proto_contents`. This creates a fragmented API where the same logical step (defining the request) has different names and argument shapes depending on the transport.
- Off-boarding risk: anonymized user #1
- PluginHttpInteractionBuilder.execute (cognitive 16) (lib/pact/consumer/plugin_http_interaction_builder.rb)
- Workflow token permissions not restricted (.github/workflows/release_gem.yml)
- Workflow token permissions not restricted (.github/workflows/test.yml)

## Changes since last survey

- 8 commits — 7 feature/other, 1 fixes

## By area

- .github/workflows — 4 commits
- (root) — 3 commits
- lib/pact — 1 commit

## Notable commits

- fix: fix: add interaction references to the interaction, not the pact
- change: chore(deps): pin dependencies (#422)
- change: chore(deps): update pact-foundation/pact-cli digest to 686f582 (#425)
- change: chore(deps): update pact-foundation/pact-cli digest to b44546c (#424)
- change: chore(deps): update pact-foundation/pact-cli digest to ce8e656
- change: chore(dev-deps): update appraisal activesupport to 6.1
- change: chore(dev-deps): update sbmt-kafka_consumer|provider dev gems
- change: chore(release): version 2.1.1