app-api-contract-testinglisted

Author, validate, publish, and centrally verify consumer-driven contracts for cross-app API calls. Use when: 1. An app's runtime calls another app via AppApisApi.callAppApi(...), 2. Authoring or editing *.contract.json files, 3. Confirming a provider you depend on still behaves as expected, 4. Checking whether a provider change would break dependent apps.
fusebase-dev/fusebase-flow · ★ 9 · Testing & QA · score 77

Install: claude install-skill fusebase-dev/fusebase-flow

# Cross-App API Contract Testing When this app calls another app via Gate `AppApisApi.callAppApi(...)`, it becomes a **consumer** that depends on the **provider** operation behaving a certain way. A *contract* captures that expectation. Contracts are **authored and validated locally, then verified centrally** (`public-api → Gate` runs the real provider call) — there is no local runtime verification command. A contract is identified by **`providerAppId + operationId`** — the business contract is the provider *operation*, not the HTTP transport. ## When to do this (during app development) - After adding or changing a `callAppApi(...)` dependency in runtime code. - Before relying on a provider, or after a provider you depend on is upgraded (run `verify-consumer`). - Before shipping a change to an app **other apps call** (run `verify-provider` to catch every dependent consumer org-wide). ## Prerequisites - `fusebase auth --api-key=<id>.<key>` (an API key is required). - `orgId`/`productId` in `fusebase.json`, and the app configured with a `path`. - The `cross-app-api-calls-analysis` flag (already enabled — this skill is only present when it is). ## Workflow ```bash # 1. Discover dependencies — scans runtime TS for callAppApi(...) and writes # fusebaseAppApiDependenciesMeta into fusebase.json fusebase analyze app-apis --feature <appId> # 2. Scaffold draft contracts from the resolved callsites fusebase app-api-contracts scaffold --app <appId> # → drafts are bar