Change impact, before the migration

Understand the impact.
Before you migrate.

Investigate how a third-party API or SDK change affects your code. Follow the evidence. Decide what needs validating.

Explore the report

For engineering teams working through API / SDK changes.

Inside a Specc investigationInteractive example · Illustrative code

Migration review Stripe response changeIllustrative example

Assessed change

PaymentIntent.charges removed latest_charge

Stripe API · Example scope

Direct usage

The receipt builder reads the removed field.

This implementation accesses PaymentIntent.charges when creating a receipt. The new response shape needs a closer look here.

src/payments/receipt.ts

18export function buildReceipt(payment) {
19  const charge = payment.charges.data[0];
20  return { receiptUrl: charge.receipt_url };
21}

What to validate

Exercise receipt generation with the new response shape. Confirm the expected receipt URL is available.

Proposed scenario · Not executed by Specc

The intended fallback when no charge is available needs engineer confirmation.

TypeScript & JavaScript Source-linked evidence Proposed validation scenarios Commit-specific analysis

The work around the code change

A smaller diff can still
raise bigger questions.

What relies on this behaviour? What matters to the business? What should the team validate before migrating?

01 / Follow the source

Open the code behind
the conclusion.

The same source inspector used in Specc’s reports. Select a file, inspect the highlighted usage and follow the relationship back to the finding.

File and line references
Direct usage and downstream context
Visible boundaries when source is missing

Try the Files control. This source is illustrative.

02 / Make the assessment yours

Put the findings to work.

Set business importance, edit validation scenarios, include or dismiss a finding, then export the brief. These are Specc’s working review controls.

Actual Specc review interfaceIllustrative data · No account required · Changes reset on reload

Migration impact assessment

Example: receipt handling migration

Illustrative payments source / example-snap

Partial analysisScope limited

Partial analysis

Illustrative data, not an executed analysis. Production configuration and external services are not supplied.
Migration evidence: Partial. Example contract requires vendor verification.
Blast radius: Partial. Runtime configuration and external services are not supplied.
Validation: Unknown. Tests have not been supplied or executed.

View scope

Snapshot: example-snapshot · Run: illustrative-migration

2 files scanned · 0.0 seconds

Migration evidence: Partial — Example contract requires vendor verification.

Blast radius: Partial — Runtime configuration and external services are not supplied.

Validation: Unknown — Tests have not been supplied or executed.

Illustrative data, not an executed analysis. Production configuration and external services are not supplied.

Migration evidence: Partial. Example contract requires vendor verification.

Blast radius: Partial. Runtime configuration and external services are not supplied.

Validation: Unknown. Tests have not been supplied or executed.

Scope applies to the supplied repository snapshot. Unprovided services and runtime behaviour are not established by this report.

Assessed change

Illustrative change: PaymentIntent.charges removed; investigate latest_charge and the expected response shape.

View change details

Submitted change statement; engineer confirmation of the vendor contract is required.

Structured version details and verified vendor references were not recorded for this report. Inspect the submitted guidance before accepting applicability.

Review findings

2 findings · 2 with unresolved questions

0 of 2 findings reviewed. Validation has not been executed.

Only unreviewed

Direct usage found

Changed contract used in buildReceipt

Validation Review decision

Potential effect

The receipt builder reads PaymentIntent.charges, the field removed in this example change. Receipt handling may need adapting to the new response shape; confirm the intended fallback when no charge is available.

Business importance Unconfirmed

Business importance · engineer-providedImportance rationale

Why this may be affected

2const charge = payment.charges.data[0];

Relationship not verified — inspect these locations

Additional evidence (1)

Field access in buildReceipt at src/payments/receipt.ts:2

What to validate Not executed

Exercise receipt generation with a successful-payment fixture using the new response shape. Confirm the receipt URL and intended payment state.
Exercise a response with no available charge. Confirm the intended fallback with the integration owner before defining the assertion.

Expected behaviour, fixtures and environment requirements need engineer confirmation.

Edit validation scenarios

Validation scenarios (separate scenarios with a blank line)

Existing tests · Not executed by Specc

No related tests were identified.

Inspected assertion details were not recorded. Review assertions and production-relevant scenarios before deciding coverage is sufficient.

Unknowns and boundaries

The runtime dependency path is not verified. Inspect callers and relevant configuration.
No related tests were identified. Locate coverage or define a new validation scenario.

Review decision

Notes / missing contextReason for dismissal

Not reviewed. This decision does not mark validation as completed.

Loading the example workspace…

Evidence over certainty

A finding is a starting point.
Not a safety guarantee.

Code relationships are inspectable.: Source references help you check a conclusion, rather than take an AI explanation on trust.
Runtime behaviour can remain unknown.: Dynamic calls, configuration and services outside the supplied code can limit the investigation. Those gaps belong in the report.
Review stays with your team.: Specc proposes validation work. It does not execute those tests or autonomously repair your integration.

A few things to know

Before you investigate.

What does Specc need?

A repository or uploaded source files, plus a description of the third-party API or SDK change. Version details and vendor guidance help define the investigation. The initial focus is TypeScript and JavaScript.

Does Specc run tests or change my code?

No. Specc investigates code and proposes validation scenarios. Your team reviews the evidence, makes the migration changes and executes the tests.

Can it establish every downstream effect?

No. Runtime configuration, dynamic behaviour and services outside the supplied source can remain unknown. Scope limitations and unresolved relationships belong in the assessment.

Can we evaluate a completed migration?

Yes. A historical migration gives you something concrete to compare against. Agree the code-access approach with us, then start from the code before the migration and its change description.

Early access / Design partners

Bring the migration
you already lived through.

We’re inviting API-heavy engineering teams to compare Specc’s findings with real migration outcomes. Start with a completed change and the code as it was before.

Agree the code-access approach with us first.

Direct usage found

Changed contract used in buildReceipt

Validation Review decision

Potential effect

Business importance Unconfirmed

Business importance · engineer-providedImportance rationale

Why this may be affected

2const charge = payment.charges.data[0];

Relationship not verified — inspect these locations

Additional evidence (1)

Field access in buildReceipt at src/payments/receipt.ts:2

What to validate Not executed

Exercise receipt generation with a successful-payment fixture using the new response shape. Confirm the receipt URL and intended payment state.
Exercise a response with no available charge. Confirm the intended fallback with the integration owner before defining the assertion.

Expected behaviour, fixtures and environment requirements need engineer confirmation.

Edit validation scenarios

Validation scenarios (separate scenarios with a blank line)

Existing tests · Not executed by Specc

No related tests were identified.

Inspected assertion details were not recorded. Review assertions and production-relevant scenarios before deciding coverage is sufficient.

Unknowns and boundaries

The runtime dependency path is not verified. Inspect callers and relevant configuration.
No related tests were identified. Locate coverage or define a new validation scenario.

Review decision

Notes / missing contextReason for dismissal

Not reviewed. This decision does not mark validation as completed.

Understand the impact.Before you migrate.

Explore a migration report

The receipt builder reads the removed field.

What to validate

A smaller diff can stillraise bigger questions.

Open the code behindthe conclusion.

Put the findings to work.

Example: receipt handling migration

Assessed change

Review findings

Potential effect

Why this may be affected

What to validate Not executed

Unknowns and boundaries

Review decision

A finding is a starting point.Not a safety guarantee.

Before you investigate.

Bring the migrationyou already lived through.

Example: receipt handling migration

Assessed change

Review findings

Potential effect

Why this may be affected

What to validate Not executed

Unknowns and boundaries

Review decision

Understand the impact.
Before you migrate.

A smaller diff can still
raise bigger questions.

Open the code behind
the conclusion.

A finding is a starting point.
Not a safety guarantee.

Bring the migration
you already lived through.