Product

How it runs

Buying the Pack does not buy an autonomous migration. It buys a workflow with the deterministic parts written as scripts, the generative parts kept small and reviewable, and gates your agent cannot clear on its own. Here is exactly which is which, what happens when a checkpoint fails, and what any of it does to your repository.

A script does it

Deterministic and repeatable. Same input, same output, no model involved. These are the parts you can trust without reading them.

Inventory the app: A static analyzer reads the repository without executing it, and lists native dependencies, screens, navigation and patches. A per-screen extractor lists the component, props, route params, hooks, query keys, network calls, test ids, user-visible strings and platform branches.
Hold the plan to what was accepted: Acceptance writes a SHA-256 hash of the plan. Progress updates keep it: status lines, notes and gate ticks are excluded from the hash. Any other edit — scope, order, dependencies, titles, gates, prose, the design decision — voids the acceptance.
Measure parity: Capture a matched screenshot pair per screen, compare after masks, and compare the two event logs. The numbers are produced by the scripts, not asserted by the agent.
Pick the next checkpoint: Prints the first checkpoint in file order that is not done or blocked and whose dependencies are all done. You cannot skip ahead of a dependency by accident.

Your coding agent does it, supervised

Not deterministic. The same checkpoint run twice can produce different native code. Every output is yours to review before it ships.

Fill in the behaviour a spec cannot extract: The extractor lists what the code contains. The agent reads the screen and writes Purpose, States and Open questions, and is instructed never to invent behaviour: an unknown becomes an open question rather than a guess.
Write the SwiftUI and Compose screens: From the spec's JSON and the running app, building each state the spec lists, with a test per state. This is the step that produces code you will own, and the step whose output varies between runs.
Replace a native module: Covered mappings are applied; anything without a known equivalent gets the structure for a Swift and Kotlin service behind an interface, with the behaviour differences written down rather than smoothed over.

You decide it

The Pack refuses to proceed without these. They are not prompts you can skip; the scripts exit non-zero.

Accept the plan before any work starts: No checkpoint may move to in-progress, in-review or done while the plan is unaccepted or has changed since acceptance. The scripts refuse with exit 2.
Choose brownfield or rewrite, and whether to keep your design: The assessment recommends one with its reasons. Adopting each platform's own UI conventions needs a recorded design decision, because it changes what the parity numbers mean.
Sign off every drift, in writing: A screen between 1% and 2% is not a pass. Sign-off must come from someone who did not write the port, and the porting agent may never sign off its own work.
Approve the checkpoint: Human approval is one of five gates, alongside tests passing on both platforms, parity passing or drift accepted, and both reviewer agents passing. A checkpoint cannot be marked done with an unticked gate.

When a checkpoint fails

A gate that can be talked around is not a gate. These are the answers the scripts enforce, not a policy anyone can waive.

Does the workflow stop?: Yes, at the checkpoint. A checkpoint above the 2% gate is a fail, and no sign-off is permitted for it. The parity gate stays unticked, and a checkpoint cannot be marked done with an unticked gate.
Can the agent retry its own way past it?: It can port again, and it cannot clear the gate by moving the goalposts. Raising the threshold or adding a mask to turn a fail into a pass is forbidden, and so is masking the element the checkpoint ports.
What if a checkpoint is blocked by something outside the code?: Mark it blocked with a note. Blocked is a first-class status, and the next-checkpoint script skips it rather than stalling the migration. Waiting on a third-party key is the usual case.
Can a human accept a known difference?: Between 1% and 2%, yes, in writing, by someone who did not write the port. Above 2%, no. That boundary is the whole point of having one.
Is a failed result kept?: The report and the diff images attach to the checkpoint, and the plan is committed to your repository, so its history is the record of what was accepted and when. Nothing is overwritten silently.
Can the plan be changed after it is accepted?: Yes, and doing so voids the acceptance by design. Re-accepting without a human reviewing the change is called out as something never to do, and overwriting an accepted plan with a fresh draft requires telling the owner.
Can a step be re-run safely?: Scripts can. The agent steps are not deterministic, so treat a re-run as new output to review rather than a repeat of the last one. Keep each checkpoint reviewable on its own, and the measurement will reproduce even when the code does not.

What it writes

A checkpoint plan, committed next to your code, with an acceptance block that records who accepted it and when.
One spec per screen, as Markdown for reviewers and JSON for the porting skills.
Parity reports, diff images and event comparison output per checkpoint.
The native code the agent writes for each checkpoint, in the location the plan's brownfield or rewrite decision chose.

What it leaves alone

Your React Native app, except for test ids. Where a screen has none and a parity flow needs them, they are added to the React Native app in their own separate commit, so the change is reviewable on its own.
Your server data. A capture flow that changes server state is forbidden, so parity runs read-only against a seeded database or a mock.
Your code, as far as the network is concerned. The scripts run locally and send no code, reports or telemetry anywhere. Your coding agent sends what it reads to its own model provider, under that provider's terms, and the Pack does not change that.
Your git history. The Pack tells you to commit; it does not commit for you.

The gate at the end of every checkpoint is the parity gate. What parity means lists what it measures and the six things it does not check at all. The Pack page lists every skill, agent and script by name.