# Does This Release Affect Your Code? Trace the Behavior Before You Upgrade

A release note says your authentication SDK has changed its sign-in redirects. Your product uses that SDK. You have a callback route. It sounds like work for your coding agent.

But what work?

“Upgrade the SDK and fix anything that breaks” gives the agent a migration before you have established a problem. The useful first question is smaller: **where does your product depend on the behavior that changed?**

The answer might justify a patch, a focused investigation or no action. Each can be a good outcome. The point is to spend your next hour on evidence that changes the decision.

## Turn the announcement into a question about your product

Start with the specific change, rather than the release headline.

“Improved authentication” is too broad to investigate. “Sign-in now uses a different default destination when no redirect is supplied” gives you something to trace: calls that omit a redirect.

That redirect change is hypothetical. [ShipFoundry’s sample investigation](https://shipfoundry.ai/docs/sample-investigation-brief) uses a fictional authentication update to illustrate the same problem, not to report a real release or customer result.

For any actual update, extract three things from its source:

- The behavior being added, changed or removed.
- The versions, configurations or users affected.
- When the change takes effect, including any migration deadline.

Then phrase the question in terms of your product:

> Do any of our sign-in paths rely on the SDK’s default redirect destination?

For a performance release, the question might be whether the improved operation contributes meaningfully to your build time. For an API retirement, it might be whether your running service still calls the retiring endpoint.

This step makes the investigation useful even when the answer is no.

## Follow the change from dependency to behavior

A package manifest tells you that a dependency belongs to your project. Its version entry may be a permitted range. The lockfile records resolved versions, so inspect the relevant application’s lockfile entry rather than treating the manifest as proof of what it uses.

If your decision concerns production, also establish which revision is deployed. Your current checkout may already contain changes that users have never received.

Version numbers help set expectations. Under [Semantic Versioning](https://semver.org/), incompatible public API changes require a major version increment once a package reaches 1.0.0. Versions below 1.0.0 and prereleases have weaker stability expectations. Those rules communicate compatibility intent; you still need the release’s actual description to identify the behavior at issue.

Now follow that behavior into your code.

In the fictional sign-in case, a useful trace might be:

```text
Resolved SDK version
  → authentication wrapper
  → sign-in calls
  → callback route
  → destination shown to the user
```

Each step answers a different question. Is the affected SDK present? Where is it used? Does your wrapper supply a redirect? Do callers bypass that wrapper? What happens after authentication completes?

Use exact searches for the package, changed method, option or endpoint. Then read the surrounding code. If you find an import in a shared wrapper, follow its callers. A wrapper can hide the SDK name from every route that depends on it.

Imagine two repositories using the same SDK:

**In the first,** all relevant sign-in calls supply an explicit destination, and the hypothetical release leaves explicit destinations unchanged. That supports a no-action decision for this particular default change.

**In the second,** sign-in calls omit the destination. That establishes possible exposure, but you still need to understand the old and new defaults and the intended user experience.

The package match was identical. The behavior produced different decisions.

Also distinguish “I found no use” from “there is no use.” A text search can miss aliases, generated clients or calls hidden behind another library. Remote APIs can change without a dependency upgrade, and provider settings may live outside the repository. Name those gaps when they matter.

A precise finding is more useful than a sweeping one:

> The inspected sign-in paths supply explicit destinations. Provider configuration was not checked.

## Test the consequence you care about

Finding the affected call is evidence of relevance. It is not evidence that a proposed migration works.

In the redirect example, the consequence is whether a user reaches the intended page after signing in. A successful build alone cannot demonstrate that.

Read the relevant tests before deciding what to run. Do they check the destination, or only that the sign-in function was called? Do they exercise the callback route, or replace the SDK with a mock that always returns the expected result?

For this hypothetical change, useful verification could include:

- Sign-in reaches the intended destination.
- A supported return path survives the callback.
- A failed sign-in produces the expected error state.
- A missing destination behaves as your product requires.

Choose checks that distinguish the behavior before and after the change. Run them against the current version to establish a baseline, then against a proposed upgrade in an authorized test environment.

If a provider-backed flow cannot run, report that limit. “Local checks passed; the provider callback was not exercised” tells the next person what remains to be established. “Verified” hides it.

## Give your agent the unresolved question

You do not need to finish every investigation yourself. You do need to give your coding agent a task whose scope matches the evidence.

Here is a compact handoff for the fictional redirect change:

```markdown
Investigate whether the documented default redirect change affects sign-in.

Confirm the repository revision and resolved SDK version.
Trace sign-in calls, wrappers and callback handling.
Identify calls that omit an explicit destination.
Compare those calls with the release's affected conditions.

Investigation only. Do not edit code or provider settings.

Return:

- Applicability finding, with file and symbol references.
- Tests run, results and checks not run.
- Missing evidence.
- Recommended next action and verification steps.
```

Attach the actual release link and any repository references you have found. The agent should check those references against its current checkout.

This is the distinction in [ShipFoundry’s investigation brief documentation](https://shipfoundry.ai/docs/investigation-briefs): an Engineering Spike resolves whether and how to act; a Hand To Agent brief describes a specific implementation supported by evidence. A task label does not itself authorize edits or deployment.

Once the investigation establishes a change worth making, give the implementation its own bounded scope and acceptance checks.

## Close the decision, even when you do nothing

Applicability and priority are separate judgments. An optional improvement may affect your code yet offer little value this week. A retiring endpoint may deserve immediate work because continued operation has a deadline.

Close the check with an action, a reason and any condition that would reopen it:

| Decision    | What supports it                                                | What to record                    |
| ----------- | --------------------------------------------------------------- | --------------------------------- |
| Act         | Relevant behavior, a justified change and specific verification | Scope, expected result and checks |
| Investigate | A plausible connection with a consequential unknown             | The question and missing evidence |
| Defer       | Relevant work whose timing does not yet justify it              | Reason and revisit trigger        |
| No action   | Evidence that the changed behavior does not apply               | Inspected scope and why           |

Include the repository revision. “No action for this default redirect change at this commit” remains understandable later, when someone adds a new sign-in path.

ShipFoundry’s documented workflow applies this approach to recurring release triage through [read-only GitHub connection and repository-backed recommendations](https://shipfoundry.ai/docs/quickstart). Its [readiness guidance](https://shipfoundry.ai/docs/trust-and-readiness) preserves the distinction between a stack match, repository evidence and a usable handoff. Tests and review still establish whether the resulting change works.

Before your next upgrade task, ask for one sentence:

> At this revision, this release affects this behavior because of this code, and our next step is this.

If the evidence cannot yet support that sentence, you have a focused investigation to run. If it supports no action, record the finding and get back to building.