A **design link** binds a Figma file to a workspace. Once linked, frames you transfer keep a connection to their source, so Pathrule can tell you when the Figma file has moved on and the code bound to it has not.

## Setting up a link

1. In the Design surface, add a design link and choose the Figma file.
2. Supply your Figma access token when prompted. It is used for that one registration request, and it is never persisted or logged. The request also verifies your Pathrule session and your workspace access before anything is written.
3. Pathrule registers a webhook on the file so later changes arrive as drift notices instead of being discovered by accident weeks later.

You can unregister a link at any time, which removes the webhook and stops the notices.

## What a transfer gives you

A transfer produces a **pixel-exact contract**, not shippable code. The frames arrive as a Pathrule design: layers with stable ids, geometry, sizing, layout direction, token variables, component instances, and text. Images are recoded to WebP on the way in, so a transferred screen does not drag a multi-megabyte PNG through every later read.

What it does not give you is a component tree in your framework. That translation is yours, and it should be written from the design's intent using your project's own primitives.

## Implementing a transferred design

Follow this order. It is not stylistic.

1. **Tokens first.** A screen implemented before the token it depends on gets literal values baked in, and nobody goes back to unpick them.
2. **Components next**, because every screen inherits them.
3. **Screens last**, and only where the design actually changed.

Two rules go with it:

- **Bind the token variable, never the resolved value.** A hardcoded hex is the exact failure this pipeline exists to prevent.
- **Never invent a name, a role, or a behaviour the design does not state.** Report the gap in your run summary instead. A design that says nothing about an empty state is a question, not a licence.

## When Figma and the render disagree

If a frame came from Figma, a [fidelity check](/docs/design/verify) treats the Figma metadata as the reference in preference to Pathrule's own render. Comparing an implementation against a Pathrule render of a Figma frame would certify an importer bug as correct, so the check goes back to the source of truth. Colour is the exception in the other direction: Figma metadata carries no colour, so appearance findings always come from the design's resolved paint.

## What to read next

- [Design overview](/docs/design/overview) for how a design is read as intent.
- [Verifying a design against the running app](/docs/design/verify) for the finish condition on a transferred screen.