Impact GateReference
Supported contracts and coverage
Prepare contracts for analysis and understand which evidence the current release can establish.
On this page
Supported inputs#
| Input | Current connected support | Important boundary |
|---|---|---|
| Provider API contracts | OpenAPI 3 documents in YAML or JSON | Documents need valid paths and resolvable local references; unsupported constructs leave gaps. |
| JavaScript / TypeScript consumers | Supported HTTP client patterns such as fetch and axios | Highly dynamic URLs, indirect runtime configuration, or unresolved wrappers may not be mapped. |
| Java consumers | Supported HTTP client patterns, including supported Spring clients | Framework support depends on recognizable source patterns; arbitrary reflection is not established. |
| Service identity | Repository roots and supported package / Spring / deployment manifests | Discovery may need review in monorepos or unusual layouts. |
| Runtime observations | Not connected | Production caller counts and observation windows remain unknown. |
| External models | Not enabled | The connected worker performs deterministic analysis. |
Source-language support describes extraction capabilities, not complete support for every library or code pattern. Check repository Coverage and individual report notes for the actual result in your codebase.
Prepare a contract#
Commit the document
Keep the OpenAPI document in the selected provider repository on its default branch.
openapi.yaml,openapi.yml, or a JSON document containing theopenapifield are recognized examples.Use OpenAPI 3 and valid paths
Include an OpenAPI 3 version and a valid
pathsobject. Swagger 2 documents are not supported by the connected indexer.Bundle schema references
Use resolvable local references such as
#/components/schemas/Product. External references and unresolved references prevent a complete contract comparison.Describe the interface faithfully
Include request parameters, required fields, responses, media types, and relevant security requirements. Update this contract when the implementation changes.
Index and inspect
Save repository selection or choose Re-index. Open Coverage, then inspect the endpoint and its schemas in API usage.
# Minimal illustrative provider contract.
openapi: 3.0.3
info:
title: Product API
version: 1.0.0
paths:
/v1/products/{id}:
get:
parameters:
- name: id
in: path
required: true
schema:
type: string
responses:
'200':
description: Product details
content:
application/json:
schema:
type: object
required: [id, priceCents]
properties:
id:
type: string
priceCents:
type: integerThis example illustrates document shape. Adapt it to your actual interface and normal contract validation process. Renaming the response field would change the contract, while a source-only rename without a matching contract update can leave drift unverified.
Examples of contract changes#
| Change | Why it needs review |
|---|---|
| Remove an endpoint or response field | A consumer may still request the endpoint or read the field. |
| Add a required request parameter or tighten a constraint | Previously accepted requests can become invalid. |
| Change a response type, media type, or success code | Parsing and status handling assumptions can change. |
| Remove an accepted request enum value | Existing clients may still send that value. |
| Add a response enum value | Consumers with exhaustive handling may not understand it. |
| Change descriptions or operation metadata | These usually do not alter the HTTP interface; review actual document differences. |
The report describes the detected change kind and its before/after values. The actual impact depends on consumer evidence and coverage; a breaking contract difference can be recorded even when no static caller was located.
Why coverage can be partial#
- No supported provider document was found, or a document was invalid.
- External or unresolved references prevented a complete contract comparison.
- A repository contains source languages or client patterns outside supported extraction.
- GitHub returned a truncated tree or an expected blob was unavailable.
- A file exceeded the per-file budget, contained binary data, or was a symlink.
- The repository or consumer analysis exceeded a processing budget.
Current repository collection uses a budget of 1,500 candidate files and approximately 24 MiB of declared file data, with a 500 KiB per-file cutoff. Contracts and manifests are prioritized before source when selecting files. Dependencies, build output, test/fixture directories, and lockfiles are excluded. These limits bound collection and do not promise exhaustive parsing of a repository.
Supported files, Skipped files, OpenAPI documents, and the notes under Coverage describe the saved result. Re-indexing can resolve a missing document or restored access, but it does not add support for an unsupported language.
What remains unknown#
- Implementation behavior or removed routes that are not reflected in the supported contract.
- Consumers outside selected, indexed repositories and clients maintained outside GitHub.
- Production traffic volume and caller inactivity without runtime observations.
- Deployment host associations for relationships inferred from endpoint paths.
- Highly dynamic or reflective calls that static extraction cannot resolve.
- Non-HTTP interfaces such as message queues, gRPC, and application-level WebSocket protocols.
- Downstream effects beyond the code and relationship evidence actually inspected.