Ship library change to consumers

Use Polygraph to ship a change to a published library and check every consumer before you release.

You own a design system, an API client, or an internal SDK, and many teams depend on it. You publish a new version, hoping nothing breaks. You checked a few repos, but missed some. It's common in such scenarios for downstream consumers to break when they try to upgrade weeks later.

At this point you and the downstream teams scramble to fix the issue. That's a lot of unnecessary context switching on both sides.

With Polygraph, one session fully understands your library and its consumers, you can test the change against each consumer first, then open PRs where it's safe and flag the teams where it isn't.

Scenario: A change with downstream impact

You're removing a deprecated component from your design system and need to know which consumers break before you cut a release.

Example prompt

I'm inside the library repo and run polygraph session start.

Add acme/web-app, acme/admin-dashboard, and acme/mobile-shell to this
session. They all depend on @acme/design-system.

In the design system, remove the deprecated <Modal> component. Consumers
should migrate to <Dialog>, which replaces it. Its API is different. There's
no closeOnOverlayClick, and focus trapping is built in.

Then check each consumer against my change. Build and test each one, and
report which pass, which break, and where they still use <Modal>.
Don't open any PRs yet.

The agent makes the change in your library, puts it in front of each consumer, and runs their build and tests. You get a per-consumer result before anything ships.

Route the outcomes

Once you have the results, ask the agent to act on them:

For consumers that passed, open a draft PR bumping @acme/design-system to the
next version.

For consumers that break only on a straight <Modal> -> <Dialog> swap, apply
the swap, rerun their tests, and include it in the same PR.

For consumers that used <Modal> features <Dialog> handles differently (like
closeOnOverlayClick), open a draft PR with the failing output and @-mention
the owning team from CODEOWNERS. Link this session in the body.

Clean consumers get a ready-to-merge bump. Mechanical breaks get the fix applied and verified. Anything that needs human judgment lands on the owning team's desk with the failure and the context attached.

Hand off to consumer teams

The consuming team can reference your Polygraph session from their own, which gives them your trace (the library change, the validation output, the failing commands) while keeping their verification on their own branches.

From the consumer team's side:

Reference Polygraph session <session-id> and pull the @acme/design-system
changes from it. Tell me what's changed so I can understand and verify it.

Your session stays the record of what you shipped and who it affected. Theirs is their own verification and shipping timeline.