---
title: "Diagnostic rule reference"
description: "Every deterministic Typeship Diagnostic, why it matters, and the safest way for a developer or agent to resolve it."
url: https://typeship.dev/docs/reference/diagnostic-rules
markdown: https://typeship.dev/docs/reference/diagnostic-rules.md
section: "Reference"
---
> ## Documentation index
> Fetch the documentation index at https://typeship.dev/llms.txt or every prose page and both generated references at https://typeship.dev/llms-full.txt.
> Append .md to any prose docs URL, or send Accept: text/markdown, for the markdown twin of that page.
> Select existing code examples with Accept-Code-Language: typescript, python, or go (one value), or add ?codeLanguage=python to a Markdown URL. The query parameter takes precedence. Unsupported values return the full docs with a notice.

# Diagnostic rule reference

Every deterministic Typeship Diagnostic, why it matters, and the safest way for a developer or agent to resolve it.

{/* Generated by scripts/build-diagnostics-reference.mts. Edit analyzer rule metadata, not this file. */}

This catalog lists every Diagnostic Typeship can emit. Rule IDs are stable control fields; wording may improve as the analyzer becomes more precise.

A catalog entry explains the general rule. A live project finding remains authoritative because it adds the exact Definition Revision, source document, coordinate, evidence, policy state, and authoring brief.

## Recommended workflow

1. Retrieve the current report with `typeship projects retrieve-diagnostics <project_id>` or open **Console → Project → Diagnostics**.
2. Start with blocking or newly added findings. Read every affected location before editing.
3. Apply an exact reviewed patch when Typeship provides one. When **API-owner decision** is yes, ask rather than inventing behavior.
4. Change the source Definition, not generated output.
5. Refresh Diagnostics, confirm the exact rule and locations resolved, then review generated surface and compatibility changes.

> **For AI agents:** For a live project, copy the finding's 
> 
> **fix prompt**
> 
>  in Console or use its 
> 
> `authoring_brief`
> 
> . Those prompts are revision-bound and safer than the generic rule prompt below.

Diagnostics report contract quality before generation. If generation itself fails or prints a warning, use [Errors and warnings](https://typeship.dev/docs/reference/errors-and-warnings).

## OpenAPI rules (42)

### The contract still uses Swagger 2.0

* **Rule ID:** `openapi.document.swagger2`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Typeship converts Swagger 2.0 before generation, but OpenAPI 3.1 expresses modern request bodies, nullability, webhooks, and JSON Schema more precisely.

**Why it matters:** Conversion keeps generation working but cannot recover intent the older format cannot express.

**How to fix:** Upgrade the source contract to OpenAPI 3.1

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.document.swagger2 (The contract still uses Swagger 2.0) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Typeship converts Swagger 2.0 before generation, but OpenAPI 3.1 expresses modern request bodies, nullability, webhooks, and JSON Schema more precisely. Impact: Conversion keeps generation working but cannot recover intent the older format cannot express.
4. Expected remediation: Upgrade the source contract to OpenAPI 3.1
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Examples contradict their declared schemas

* **Rule ID:** `openapi.example.schema_mismatch`
* **Severity:** error
* **Evidence:** contract
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Update the example or schema so the documented payload is valid in its request, response, parameter, or property context.

**Why it matters:** Humans, tests, and agents copy an example that generated validation rejects.

**How to fix:** Make the example and schema agree

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.example.schema_mismatch (Examples contradict their declared schemas) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Update the example or schema so the documented payload is valid in its request, response, parameter, or property context. Impact: Humans, tests, and agents copy an example that generated validation rejects.
4. Expected remediation: Make the example and schema agree
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Generated public names need collision resolution

* **Rule ID:** `openapi.generated_surface.name_collision`
* **Severity:** warning
* **Evidence:** implementation
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** An authored name collides with another authored name or a reserved generated resource, method, command, or tool name. Review the exact resolved names before publishing.

**Why it matters:** Typeship keeps the package compilable by qualifying or suffixing names, but the resulting CLI, MCP, or SDK surface may be surprising and can change when neighboring operations move.

**How to fix:** Choose distinct stable operation and resource names

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

**Generated surface effect:** Resolving the collision can rename CLI commands, MCP tools, and SDK methods.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.generated_surface.name_collision (Generated public names need collision resolution) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: An authored name collides with another authored name or a reserved generated resource, method, command, or tool name. Review the exact resolved names before publishing. Impact: Typeship keeps the package compilable by qualifying or suffixing names, but the resulting CLI, MCP, or SDK surface may be surprising and can change when neighboring operations move.
4. Expected remediation: Choose distinct stable operation and resource names
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### The API has no top-level description

* **Rule ID:** `openapi.info.description.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Add a short statement of purpose, audience, and important behavioral constraints to info.description.

**Why it matters:** Humans and agents otherwise begin with operation names but no model of what the API is for.

**How to fix:** Author the API overview

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.info.description.missing (The API has no top-level description) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Add a short statement of purpose, audience, and important behavioral constraints to info.description. Impact: Humans and agents otherwise begin with operation names but no model of what the API is for.
4. Expected remediation: Author the API overview
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Agent safety hints contradict each other

* **Rule ID:** `openapi.operation.agent_hints.contradictory`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** API, MCP

**What it checks:** An operation cannot be both read-only and destructive. Correct the advisory metadata to describe the operation's intended effect.

**Why it matters:** Clients may show the wrong approval affordance. These hints remain advisory and are not proof that the API enforces the claimed behavior.

**How to fix:** Correct the contradictory safety hints

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.agent_hints.contradictory (Agent safety hints contradict each other) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: An operation cannot be both read-only and destructive. Correct the advisory metadata to describe the operation's intended effect. Impact: Clients may show the wrong approval affordance. These hints remain advisory and are not proof that the API enforces the claimed behavior.
4. Expected remediation: Correct the contradictory safety hints
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Deprecated operations do not identify a replacement

* **Rule ID:** `openapi.operation.deprecation.replacement_missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Point callers to the supported operation or migration path in the description, external documentation, or an explicit replacement extension.

**Why it matters:** Generated clients can mark the method deprecated, but users and agents cannot migrate safely without a named alternative.

**How to fix:** Document the supported replacement

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

**Generated surface effect:** Removing the deprecated operation later will remove its CLI command, MCP tool, and SDK method.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.deprecation.replacement_missing (Deprecated operations do not identify a replacement) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Point callers to the supported operation or migration path in the description, external documentation, or an explicit replacement extension. Impact: Generated clients can mark the method deprecated, but users and agents cannot migrate safely without a named alternative.
4. Expected remediation: Document the supported replacement
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Operations are missing behavioral descriptions

* **Rule ID:** `openapi.operation.description.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Describe preconditions, side effects, important defaults, and when a caller should use the operation.

**Why it matters:** A signature alone cannot tell a human or agent how to use an operation safely.

**How to fix:** Document operation behavior

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.description.missing (Operations are missing behavioral descriptions) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Describe preconditions, side effects, important defaults, and when a caller should use the operation. Impact: A signature alone cannot tell a human or agent how to use an operation safely.
4. Expected remediation: Document operation behavior
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Destructive operations appear to be public

* **Rule ID:** `openapi.operation.destructive.security_missing`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Confirm that each DELETE operation intentionally has no authentication requirement.

**Why it matters:** An agent or client may expose a destructive action without any credential boundary.

**How to fix:** Declare the operation's authentication requirement

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.destructive.security_missing (Destructive operations appear to be public) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Confirm that each DELETE operation intentionally has no authentication requirement. Impact: An agent or client may expose a destructive action without any credential boundary.
4. Expected remediation: Declare the operation's authentication requirement
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Operation identifiers are not unique

* **Rule ID:** `openapi.operation.operation_id.duplicate`
* **Severity:** error
* **Evidence:** contract
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Every operationId must identify exactly one operation.

**Why it matters:** Generators must rename or overwrite methods, making the published API ambiguous.

**How to fix:** Choose one unique identifier per operation

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.operation_id.duplicate (Operation identifiers are not unique) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Every operationId must identify exactly one operation. Impact: Generators must rename or overwrite methods, making the published API ambiguous.
4. Expected remediation: Choose one unique identifier per operation
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Operations are missing stable identifiers

* **Rule ID:** `openapi.operation.operation_id.missing`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Give every operation a unique operationId. Typeship can derive names, but an authored identifier is the durable public method name.

**Why it matters:** Derived CLI commands, MCP tools, SDK methods, and future diffs can change when paths are reorganized.

**How to fix:** Add deterministic operation identifiers

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

**Generated surface effect:** Changing operationId can rename generated CLI commands, MCP tools, and SDK methods.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.operation_id.missing (Operations are missing stable identifiers) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Give every operation a unique operationId. Typeship can derive names, but an authored identifier is the durable public method name. Impact: Derived CLI commands, MCP tools, SDK methods, and future diffs can change when paths are reorganized.
4. Expected remediation: Add deterministic operation identifiers
5. Do not broaden the change beyond what the cited evidence proves.
6. If the live finding contains an exact spec_patch, review that patch and prefer it over reconstructing the edit.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Pagination signals are incomplete

* **Rule ID:** `openapi.operation.pagination.incomplete`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Make the detected cursor, page, or offset shape unambiguous, or configure this operation's pagination interpretation explicitly.

**Why it matters:** Generated pagination helpers may select the wrong style or be unable to continue a collection safely.

**How to fix:** Clarify the pagination contract

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.pagination.incomplete (Pagination signals are incomplete) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Make the detected cursor, page, or offset shape unambiguous, or configure this operation's pagination interpretation explicitly. Impact: Generated pagination helpers may select the wrong style or be unable to continue a collection safely.
4. Expected remediation: Clarify the pagination contract
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Pagination appears present but Typeship cannot interpret it

* **Rule ID:** `openapi.operation.pagination.unsupported`
* **Severity:** suggestion
* **Evidence:** implementation
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Use a supported cursor, page, or offset shape, or configure this operation's pagination fields explicitly. This is a generation limitation, not proof that the API lacks pagination.

**Why it matters:** Generated helpers expose a single call even though callers may need to continue the collection manually.

**How to fix:** Configure or document the pagination shape

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.pagination.unsupported (Pagination appears present but Typeship cannot interpret it) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Use a supported cursor, page, or offset shape, or configure this operation's pagination fields explicitly. This is a generation limitation, not proof that the API lacks pagination. Impact: Generated helpers expose a single call even though callers may need to continue the collection manually.
4. Expected remediation: Configure or document the pagination shape
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Path parameters do not match the URL template

* **Rule ID:** `openapi.operation.path_parameter.invalid`
* **Severity:** error
* **Evidence:** contract
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Every \{parameter} in a path must have a required path parameter with the same name.

**Why it matters:** Generated methods cannot construct the request URL reliably.

**How to fix:** Align path templates and parameter declarations

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.path_parameter.invalid (Path parameters do not match the URL template) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Every {parameter} in a path must have a required path parameter with the same name. Impact: Generated methods cannot construct the request URL reliably.
4. Expected remediation: Align path templates and parameter declarations
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Request bodies have no schema

* **Rule ID:** `openapi.operation.request_body.schema_missing`
* **Severity:** error
* **Evidence:** contract
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Every declared request-body media type needs a schema.

**Why it matters:** Generated callers cannot validate or type the request payload.

**How to fix:** Model request bodies

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.request_body.schema_missing (Request bodies have no schema) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Every declared request-body media type needs a schema. Impact: Generated callers cannot validate or type the request payload.
4. Expected remediation: Model request bodies
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Error correlation is inconsistent within an operation

* **Rule ID:** `openapi.operation.response.error_correlation.inconsistent`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Use one request, trace, or correlation identifier convention across the operation's structured failures, or document why some failures cannot carry it.

**Why it matters:** Operators and callers may be able to investigate one failure status but not another from the same generated method.

**How to fix:** Review error correlation coverage

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.error_correlation.inconsistent (Error correlation is inconsistent within an operation) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Use one request, trace, or correlation identifier convention across the operation's structured failures, or document why some failures cannot carry it. Impact: Operators and callers may be able to investigate one failure status but not another from the same generated method.
4. Expected remediation: Review error correlation coverage
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### One operation uses multiple error identity conventions

* **Rule ID:** `openapi.operation.response.error_identity.inconsistent`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Use one stable error discriminator convention across this operation's structured failures, or document why distinct error families are intentional.

**Why it matters:** Callers otherwise need status-specific branching merely to discover the domain error identity.

**How to fix:** Review the operation's error family

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.error_identity.inconsistent (One operation uses multiple error identity conventions) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Use one stable error discriminator convention across this operation's structured failures, or document why distinct error families are intentional. Impact: Callers otherwise need status-specific branching merely to discover the domain error identity.
4. Expected remediation: Review the operation's error family
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Error bodies have no stable machine-readable identity

* **Rule ID:** `openapi.operation.response.error_identity.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Expose a stable code, type, or equivalent domain error discriminator. RFC 9457 problem types are supported, but an existing sound domain format is equally valid.

**Why it matters:** Callers must branch on status codes or human prose instead of a stable domain failure identity.

**How to fix:** Choose a stable error identity

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.error_identity.missing (Error bodies have no stable machine-readable identity) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Expose a stable code, type, or equivalent domain error discriminator. RFC 9457 problem types are supported, but an existing sound domain format is equally valid. Impact: Callers must branch on status codes or human prose instead of a stable domain failure identity.
4. Expected remediation: Choose a stable error identity
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Failure responses have no machine-readable schema

* **Rule ID:** `openapi.operation.response.error_schema.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Give each declared error-body media type a schema with a stable code and recovery detail. Omit content for intentionally bodyless errors.

**Why it matters:** Humans see prose while agents and SDKs receive an untyped failure body they cannot branch on.

**How to fix:** Model structured error bodies

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.error_schema.missing (Failure responses have no machine-readable schema) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Give each declared error-body media type a schema with a stable code and recovery detail. Omit content for intentionally bodyless errors. Impact: Humans see prose while agents and SDKs receive an untyped failure body they cannot branch on.
4. Expected remediation: Model structured error bodies
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Operations declare no failure responses

* **Rule ID:** `openapi.operation.response.errors.missing`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Review the authentication, authorization, validation, conflict, not-found, throttling, and transient failures this operation can actually return, and document the applicable ones.

**Why it matters:** Generated software cannot distinguish expected recovery paths from unexpected transport failures.

**How to fix:** Define the operation's error contract

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.errors.missing (Operations declare no failure responses) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Review the authentication, authorization, validation, conflict, not-found, throttling, and transient failures this operation can actually return, and document the applicable ones. Impact: Generated software cannot distinguish expected recovery paths from unexpected transport failures.
4. Expected remediation: Define the operation's error contract
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Non-2xx outcomes are not generated as success

* **Rule ID:** `openapi.operation.response.non_2xx_success.unsupported`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** The informational or redirect response is valid HTTP/OpenAPI behavior. Typeship currently models generated success results from 2xx or a default-only response, so it cannot expose this contract as a typed success.

**Why it matters:** Generated CLI, MCP, and SDK surfaces may treat the expected non-2xx outcome as an API error.

**How to fix:** Review the generator limitation without changing status codes

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.non_2xx_success.unsupported (Non-2xx outcomes are not generated as success) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: The informational or redirect response is valid HTTP/OpenAPI behavior. Typeship currently models generated success results from 2xx or a default-only response, so it cannot expose this contract as a typed success. Impact: Generated CLI, MCP, and SDK surfaces may treat the expected non-2xx outcome as an API error.
4. Expected remediation: Review the generator limitation without changing status codes
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Rate-limit responses do not declare Retry-After

* **Rule ID:** `openapi.operation.response.retry_after.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** If the server supplies retry timing, declare the Retry-After response header. If it intentionally does not, document the caller's recovery rule instead.

**Why it matters:** Generated callers can retry with backoff, but cannot honor server-provided timing that the contract does not expose.

**How to fix:** Document rate-limit recovery timing

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.retry_after.missing (Rate-limit responses do not declare Retry-After) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: If the server supplies retry timing, declare the Retry-After response header. If it intentionally does not, document the caller's recovery rule instead. Impact: Generated callers can retry with backoff, but cannot honor server-provided timing that the contract does not expose.
4. Expected remediation: Document rate-limit recovery timing
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Successful response bodies have no schema

* **Rule ID:** `openapi.operation.response.success_schema.missing`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Add a schema to each declared response media type that returns a body. Omit content when the response is intentionally bodyless.

**Why it matters:** Generated clients return unknown data and MCP tools cannot publish a trustworthy output schema.

**How to fix:** Model successful response bodies

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.success_schema.missing (Successful response bodies have no schema) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Add a schema to each declared response media type that returns a body. Omit content when the response is intentionally bodyless. Impact: Generated clients return unknown data and MCP tools cannot publish a trustworthy output schema.
4. Expected remediation: Model successful response bodies
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Operations have no non-error response

* **Rule ID:** `openapi.operation.response.success.missing`
* **Severity:** error
* **Evidence:** contract
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Declare a successful, redirect, or default response that describes a possible non-error outcome.

**Why it matters:** Callers cannot know what a non-error outcome means or type its result.

**How to fix:** Describe the successful response

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.success.missing (Operations have no non-error response) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Declare a successful, redirect, or default response that describes a possible non-error outcome. Impact: Callers cannot know what a non-error outcome means or type its result.
4. Expected remediation: Describe the successful response
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Structured validation issues do not identify the invalid input

* **Rule ID:** `openapi.operation.response.validation_location.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** When a validation response exposes an issue array, give each issue a field, path, pointer, parameter, or location when the server can identify it.

**Why it matters:** Callers can learn that validation failed but cannot reliably map the failure back to the request value that needs correction.

**How to fix:** Expose validation issue locations

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.response.validation_location.missing (Structured validation issues do not identify the invalid input) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: When a validation response exposes an issue array, give each issue a field, path, pointer, parameter, or location when the server can identify it. Impact: Callers can learn that validation failed but cannot reliably map the failure back to the request value that needs correction.
4. Expected remediation: Expose validation issue locations
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Configured retries rely on unverified write safety

* **Rule ID:** `openapi.operation.retry.non_idempotent_unverified`
* **Severity:** warning
* **Evidence:** implementation
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Project configuration retries this POST or PATCH operation, but the contract exposes no idempotency-key input. Confirm server deduplication or narrow the retry policy.

**Why it matters:** A retry after an ambiguous transport failure could repeat a side effect.

**How to fix:** Verify or constrain non-idempotent retries

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.retry.non_idempotent_unverified (Configured retries rely on unverified write safety) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Project configuration retries this POST or PATCH operation, but the contract exposes no idempotency-key input. Confirm server deduplication or narrow the retry policy. Impact: A retry after an ambiguous transport failure could repeat a side effect.
4. Expected remediation: Verify or constrain non-idempotent retries
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Security requirements reference missing schemes

* **Rule ID:** `openapi.operation.security.reference_invalid`
* **Severity:** error
* **Evidence:** contract
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Every name in a security requirement must exist in components.securitySchemes.

**Why it matters:** Generated authentication configuration cannot satisfy the declared operation contract.

**How to fix:** Define or correct the referenced security scheme

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.security.reference_invalid (Security requirements reference missing schemes) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Every name in a security requirement must exist in components.securitySchemes. Impact: Generated authentication configuration cannot satisfy the declared operation contract.
4. Expected remediation: Define or correct the referenced security scheme
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### OAuth requirements reference undefined scopes

* **Rule ID:** `openapi.operation.security.scope_invalid`
* **Severity:** error
* **Evidence:** contract
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Every OAuth scope named by a security requirement must be defined by that security scheme.

**Why it matters:** A caller cannot request a scope the contract's authorization definition does not offer.

**How to fix:** Define or correct the OAuth scope

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.security.scope_invalid (OAuth requirements reference undefined scopes) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Every OAuth scope named by a security requirement must be defined by that security scheme. Impact: A caller cannot request a scope the contract's authorization definition does not offer.
4. Expected remediation: Define or correct the OAuth scope
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Stream events have no declared event identity

* **Rule ID:** `openapi.operation.stream.event_identity.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, SDK

**What it checks:** If a stream carries multiple event kinds, expose a stable type, event, kind, name, or id discriminator. A single-kind raw stream may document that fact instead.

**Why it matters:** Generated streaming callers can deliver events but cannot help consumers distinguish or resume them from the declared payload shape.

**How to fix:** Document stream event identity and resume behavior

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.stream.event_identity.missing (Stream events have no declared event identity) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: If a stream carries multiple event kinds, expose a stable type, event, kind, name, or id discriminator. A single-kind raw stream may document that fact instead. Impact: Generated streaming callers can deliver events but cannot help consumers distinguish or resume them from the declared payload shape.
4. Expected remediation: Document stream event identity and resume behavior
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Operations are missing summaries

* **Rule ID:** `openapi.operation.summary.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Add a short action-oriented summary to each operation.

**Why it matters:** Help output and tool discovery fall back to mechanical names instead of telling a caller what the operation does.

**How to fix:** Write concise operation summaries

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.summary.missing (Operations are missing summaries) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Add a short action-oriented summary to each operation. Impact: Help output and tool discovery fall back to mechanical names instead of telling a caller what the operation does.
4. Expected remediation: Write concise operation summaries
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Operations are not grouped into resources

* **Rule ID:** `openapi.operation.tags.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Assign at least one stable resource tag to each operation.

**Why it matters:** SDKs and command surfaces become a flat or mechanically grouped catalogue.

**How to fix:** Group operations by their first path resource

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

**Generated surface effect:** Adding or changing the first tag can rename CLI commands and MCP tools and move methods between SDK resources.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.tags.missing (Operations are not grouped into resources) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Assign at least one stable resource tag to each operation. Impact: SDKs and command surfaces become a flat or mechanically grouped catalogue.
4. Expected remediation: Group operations by their first path resource
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. If the live finding contains an exact spec_patch, review that patch and prefer it over reconstructing the edit.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Accepted work has no declared follow-up handle

* **Rule ID:** `openapi.operation.workflow.async_handoff.incomplete`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** A 202 response should tell callers how to observe accepted work when the operation is asynchronous, such as a Location header, status URL, or job identifier.

**Why it matters:** Humans and agents may start work successfully but have no contract-declared way to learn its outcome.

**How to fix:** Document the asynchronous follow-up workflow

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.workflow.async_handoff.incomplete (Accepted work has no declared follow-up handle) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: A 202 response should tell callers how to observe accepted work when the operation is asynchronous, such as a Location header, status URL, or job identifier. Impact: Humans and agents may start work successfully but have no contract-declared way to learn its outcome.
4. Expected remediation: Document the asynchronous follow-up workflow
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Batch operations do not expose per-item outcomes

* **Rule ID:** `openapi.operation.workflow.batch_outcome.incomplete`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** For bulk or batch work, describe per-item success and failure results, or state that the operation is atomic.

**Why it matters:** A caller cannot safely recover from partial success using only an aggregate response.

**How to fix:** Define batch completion and partial-failure semantics

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.workflow.batch_outcome.incomplete (Batch operations do not expose per-item outcomes) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: For bulk or batch work, describe per-item success and failure results, or state that the operation is atomic. Impact: A caller cannot safely recover from partial success using only an aggregate response.
4. Expected remediation: Define batch completion and partial-failure semantics
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### List workflows have no discoverable retrieve operation

* **Rule ID:** `openapi.operation.workflow.collection_retrieve.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Review whether callers need a stable single-resource lookup after listing a collection. A list-only feed, report, or aggregate may be intentional.

**Why it matters:** Humans and agents can discover identifiers in a collection but may have no typed path to fetch current details for one item.

**How to fix:** Review the collection-to-resource workflow

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.operation.workflow.collection_retrieve.missing (List workflows have no discoverable retrieve operation) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Review whether callers need a stable single-resource lookup after listing a collection. A list-only feed, report, or aggregate may be intentional. Impact: Humans and agents can discover identifiers in a collection but may have no typed path to fetch current details for one item.
4. Expected remediation: Review the collection-to-resource workflow
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Ambiguous operation inputs are missing descriptions

* **Rule ID:** `openapi.parameter.description.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Describe identifier meaning, units, time-zone expectations, money representation, defaults, or constraints where the name and schema do not make them self-evident.

**Why it matters:** A syntactically valid generated call can still send the wrong identifier, unit, currency, or time interpretation.

**How to fix:** Document the input semantics

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.parameter.description.missing (Ambiguous operation inputs are missing descriptions) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Describe identifier meaning, units, time-zone expectations, money representation, defaults, or constraints where the name and schema do not make them self-evident. Impact: A syntactically valid generated call can still send the wrong identifier, unit, currency, or time interpretation.
4. Expected remediation: Document the input semantics
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Schema properties are both read-only and write-only

* **Rule ID:** `openapi.schema.access_mode.contradictory`
* **Severity:** error
* **Evidence:** contract
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** A property cannot be excluded from both request and response shapes. Choose the direction in which it is present.

**Why it matters:** Generated request and response types cannot expose the property consistently.

**How to fix:** Correct the readOnly/writeOnly annotations

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.schema.access_mode.contradictory (Schema properties are both read-only and write-only) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: A property cannot be excluded from both request and response shapes. Choose the direction in which it is present. Impact: Generated request and response types cannot expose the property consistently.
4. Expected remediation: Correct the readOnly/writeOnly annotations
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Object schemas leave their dictionary shape implicit

* **Rule ID:** `openapi.schema.object.unconstrained`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** If this is an intentional open dictionary, declare additionalProperties explicitly. Otherwise define the known properties.

**Why it matters:** Generated SDKs expose an untyped dictionary and callers cannot tell whether arbitrary keys are intentional.

**How to fix:** Describe the object's allowed fields

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.schema.object.unconstrained (Object schemas leave their dictionary shape implicit) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: If this is an intentional open dictionary, declare additionalProperties explicitly. Otherwise define the known properties. Impact: Generated SDKs expose an untyped dictionary and callers cannot tell whether arbitrary keys are intentional.
4. Expected remediation: Describe the object's allowed fields
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Ambiguous schema properties are missing descriptions

* **Rule ID:** `openapi.schema.property.description.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Document properties whose identifier, unit, time-zone, money, nullability, or enum semantics are not clear from their name and schema.

**Why it matters:** Generated types carry the wire shape but not enough meaning to construct or interpret values reliably.

**How to fix:** Document the property semantics

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.schema.property.description.missing (Ambiguous schema properties are missing descriptions) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Document properties whose identifier, unit, time-zone, money, nullability, or enum semantics are not clear from their name and schema. Impact: Generated types carry the wire shape but not enough meaning to construct or interpret values reliably.
4. Expected remediation: Document the property semantics
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Server variables are missing defaults

* **Rule ID:** `openapi.server.variable.default_missing`
* **Severity:** error
* **Evidence:** contract
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Every variable used in an OpenAPI server URL must declare a default value.

**Why it matters:** The effective server URL is invalid under OpenAPI and cannot be resolved deterministically.

**How to fix:** Declare each server variable default

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.server.variable.default_missing (Server variables are missing defaults) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Every variable used in an OpenAPI server URL must declare a default value. Impact: The effective server URL is invalid under OpenAPI and cannot be resolved deterministically.
4. Expected remediation: Declare each server variable default
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Server selection needs client configuration

* **Rule ID:** `openapi.servers.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** The OpenAPI server configuration is valid, but Typeship cannot turn this effective relative or operation-specific server into its one client-wide default. Pass the intended base URL when constructing the client, or author a compatible root server if one default is appropriate.

**Why it matters:** Generated clients require an explicit base URL and do not silently apply a path- or operation-level override.

**How to fix:** Review client base URL configuration

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.servers.missing (Server selection needs client configuration) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: The OpenAPI server configuration is valid, but Typeship cannot turn this effective relative or operation-specific server into its one client-wide default. Pass the intended base URL when constructing the client, or author a compatible root server if one default is appropriate. Impact: Generated clients require an explicit base URL and do not silently apply a path- or operation-level override.
4. Expected remediation: Review client base URL configuration
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Webhook payloads have no stable event identity

* **Rule ID:** `openapi.webhook.event_identity.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Expose a stable type, event, kind, name, or id field when one endpoint delivers multiple event shapes, or document the single event kind.

**Why it matters:** Consumers may need endpoint-specific prose or payload guessing to route verified deliveries.

**How to fix:** Document webhook event identity

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.webhook.event_identity.missing (Webhook payloads have no stable event identity) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Expose a stable type, event, kind, name, or id field when one endpoint delivers multiple event shapes, or document the single event kind. Impact: Consumers may need endpoint-specific prose or payload guessing to route verified deliveries.
4. Expected remediation: Document webhook event identity
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Webhook payloads have no usable request schema

* **Rule ID:** `openapi.webhook.request_schema.missing`
* **Severity:** warning
* **Evidence:** implementation
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Declare a request-body schema for every webhook event Typeship should expose.

**Why it matters:** Typeship skips webhook entries whose payload cannot be typed, so generated verification helpers cannot return a useful event union.

**How to fix:** Model the webhook payload

**API-owner decision:** No, unless the live evidence conflicts with the API's intended behavior.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.webhook.request_schema.missing (Webhook payloads have no usable request schema) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Declare a request-body schema for every webhook event Typeship should expose. Impact: Typeship skips webhook entries whose payload cannot be typed, so generated verification helpers cannot return a useful event union.
4. Expected remediation: Model the webhook payload
5. Do not broaden the change beyond what the cited evidence proves.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Webhook verification inputs are not declared

* **Rule ID:** `openapi.webhook.verification.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Declare the signature, timestamp, delivery identifier, token, or security requirement consumers use to authenticate webhook deliveries.

**Why it matters:** A generated payload type does not prove that a delivery is authentic or protected against replay.

**How to fix:** Document webhook verification and replay protection

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic openapi.webhook.verification.missing (Webhook verification inputs are not declared) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Declare the signature, timestamp, delivery identifier, token, or security requirement consumers use to authenticate webhook deliveries. Impact: A generated payload type does not prove that a delivery is authentic or protected against replay.
4. Expected remediation: Document webhook verification and replay protection
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

## GraphQL rules (11)

### Unions or interfaces are missing descriptions

* **Rule ID:** `graphql.abstract_type.description.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Describe why the variants share one return type and how callers should distinguish them.

**Why it matters:** Generated union types are mechanically correct but difficult to use without domain context.

**How to fix:** Document abstract result types

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.abstract_type.description.missing (Unions or interfaces are missing descriptions) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Describe why the variants share one return type and how callers should distinguish them. Impact: Generated union types are mechanically correct but difficult to use without domain context.
4. Expected remediation: Document abstract result types
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Operation arguments are missing descriptions

* **Rule ID:** `graphql.argument.description.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Document identifiers, units, formats, defaults, and constraints on root-field arguments.

**Why it matters:** A type alone is often insufficient for a human or agent to construct a correct call.

**How to fix:** Describe operation arguments

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.argument.description.missing (Operation arguments are missing descriptions) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Document identifiers, units, formats, defaults, and constraints on root-field arguments. Impact: A type alone is often insufficient for a human or agent to construct a correct call.
4. Expected remediation: Describe operation arguments
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Enum values are missing descriptions

* **Rule ID:** `graphql.enum_value.description.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Explain values whose meaning is not completely captured by their names.

**Why it matters:** Callers can enumerate allowed values but cannot reliably choose among them.

**How to fix:** Document enum semantics

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.enum_value.description.missing (Enum values are missing descriptions) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Explain values whose meaning is not completely captured by their names. Impact: Callers can enumerate allowed values but cannot reliably choose among them.
4. Expected remediation: Document enum semantics
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Input fields are missing descriptions

* **Rule ID:** `graphql.input_field.description.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Document the meaning and constraints of fields in mutation and filter inputs.

**Why it matters:** Generated request types carry names and types but not the domain knowledge required to populate them.

**How to fix:** Describe GraphQL input fields

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.input_field.description.missing (Input fields are missing descriptions) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Document the meaning and constraints of fields in mutation and filter inputs. Impact: Generated request types carry names and types but not the domain knowledge required to populate them.
4. Expected remediation: Describe GraphQL input fields
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Mutations have many top-level arguments

* **Rule ID:** `graphql.mutation.arguments.unstructured`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Prefer one named input object for mutations with several fields.

**Why it matters:** A stable input type is easier to document, evolve, validate, and pass through SDKs and tools.

**How to fix:** Introduce a mutation input object

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.mutation.arguments.unstructured (Mutations have many top-level arguments) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Prefer one named input object for mutations with several fields. Impact: A stable input type is easier to document, evolve, validate, and pass through SDKs and tools.
4. Expected remediation: Introduce a mutation input object
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Mutations return only a scalar

* **Rule ID:** `graphql.mutation.result.scalar`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Return a structured payload when callers need an identifier, resulting object, warnings, or domain errors.

**Why it matters:** A Boolean or scalar result cannot explain partial success or provide a useful next action.

**How to fix:** Model a structured mutation payload

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.mutation.result.scalar (Mutations return only a scalar) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Return a structured payload when callers need an identifier, resulting object, warnings, or domain errors. Impact: A Boolean or scalar result cannot explain partial success or provide a useful next action.
4. Expected remediation: Model a structured mutation payload
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Paginated fields return a bare list

* **Rule ID:** `graphql.pagination.connection.incomplete`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Fields accepting first/last/after/before should return a connection with pageInfo and stable cursors.

**Why it matters:** Generated pagination helpers and agents cannot know whether or how to request another page.

**How to fix:** Return a complete connection type

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.pagination.connection.incomplete (Paginated fields return a bare list) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Fields accepting first/last/after/before should return a connection with pageInfo and stable cursors. Impact: Generated pagination helpers and agents cannot know whether or how to request another page.
4. Expected remediation: Return a complete connection type
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Review optional identifier arguments

* **Rule ID:** `graphql.query.identifier.nullable`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Confirm whether omission means a broader lookup, current subject, filter, or invalid call. Make the identifier non-null only when the schema's intended behavior requires it.

**Why it matters:** Generated callers correctly preserve nullability, but the contract alone may not explain what omission means.

**How to fix:** Review identifier nullability

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.query.identifier.nullable (Review optional identifier arguments) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Confirm whether omission means a broader lookup, current subject, filter, or invalid call. Make the identifier non-null only when the schema's intended behavior requires it. Impact: Generated callers correctly preserve nullability, but the contract alone may not explain what omission means.
4. Expected remediation: Review identifier nullability
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Deprecated root operations do not identify a replacement

* **Rule ID:** `graphql.root_field.deprecation.replacement_missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Name the supported query or mutation in the deprecation reason so generated callers have a migration path.

**Why it matters:** Generated clients preserve the deprecation marker, but users and agents cannot safely migrate from a generic reason.

**How to fix:** Name the replacement GraphQL operation

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

**Generated surface effect:** Removing the deprecated field later will remove its generated CLI command, MCP tool, and SDK method.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.root_field.deprecation.replacement_missing (Deprecated root operations do not identify a replacement) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Name the supported query or mutation in the deprecation reason so generated callers have a migration path. Impact: Generated clients preserve the deprecation marker, but users and agents cannot safely migrate from a generic reason.
4. Expected remediation: Name the replacement GraphQL operation
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Root operations are missing descriptions

* **Rule ID:** `graphql.root_field.description.missing`
* **Severity:** suggestion
* **Evidence:** heuristic
* **Affected surfaces:** API, CLI, MCP, SDK

**What it checks:** Describe when each query or mutation should be used, including side effects and important constraints.

**Why it matters:** Generated methods and tools have a signature but no behavioral guidance.

**How to fix:** Add GraphQL field descriptions

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.root_field.description.missing (Root operations are missing descriptions) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Describe when each query or mutation should be used, including side effects and important constraints. Impact: Generated methods and tools have a signature but no behavioral guidance.
4. Expected remediation: Add GraphQL field descriptions
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

### Custom scalars have no portable representation

* **Rule ID:** `graphql.scalar.mapping.missing`
* **Severity:** warning
* **Evidence:** heuristic
* **Affected surfaces:** CLI, MCP, SDK

**What it checks:** Map each custom scalar to string, integer, number, boolean, or JSON in project configuration.

**Why it matters:** Generated SDKs must expose unknown values instead of a useful native type.

**How to fix:** Declare scalar mappings in the Typeship project

**API-owner decision:** Yes. The contract identifies the concern but cannot prove the intended replacement.

#### Agent fix prompt

Copy this prompt into your coding agent. For a live finding, its revision-bound `authoring_brief` remains authoritative.

```text
Fix Typeship Diagnostic graphql.scalar.mapping.missing (Custom scalars have no portable representation) for project <project_id>.

1. Run `typeship projects retrieve-diagnostics <project_id>` and select the live finding whose `id` exactly matches this rule.
2. Confirm the finding's Definition revision, source documents, locations, evidence, and `authoring_brief`. Treat those live fields as authoritative over this generic prompt.
3. Rule contract: Map each custom scalar to string, integer, number, boolean, or JSON in project configuration. Impact: Generated SDKs must expose unknown values instead of a useful native type.
4. Expected remediation: Declare scalar mappings in the Typeship project
5. This rule requires API-owner intent. If the contract does not prove the right value, stop and ask the owner a focused question instead of guessing.
6. Edit the source Definition, not generated CLI, MCP, SDK, or documentation output.
7. Make the smallest source change, preserving intentional wire behavior and unrelated author changes.
8. Run `typeship projects refresh-diagnostics <project_id>`, retrieve Diagnostics again, and verify this exact rule/location is resolved without introducing new blocking findings.
9. Run the relevant generation and compatibility checks, then report the source changes and any CLI, MCP, or SDK surface changes.
```

## Sitemap

[Documentation index](https://typeship.dev/llms.txt)