Hyrax product card

03

You stay in control

Your team chooses

Review what matters, dismiss what does not, and approve the upgrades worth shipping.

Human control · stable HYRAX-N refs · approve, dismiss or request changes

storefront-web · Findings

Findings16

CriticalPCI DSS: Raw PAN routed through application backend — full CDE scope

HYRAX-345·src/pages/Checkout.tsx:58·Large effort

FixDismiss

HighFloat arithmetic used for monetary totals — precision risk on payment amounts

HYRAX-369·src/utils/cart.ts:11·Medium effort

Reason

FixDismissDismissed

HighEasy winCheckout allows submission before live prices load — user may be charged a stale price

HYRAX-368·src/pages/Checkout.tsx:34·Small effort

FixDismissVerifyingPR ready

HighEasy winMissing AbortController in SearchBox and Checkout — stale responses race to update state

HYRAX-365·src/components/SearchBox.tsx·Small effort

FixDismiss

Proposed fix · HYRAX-368

Proposed fix

[Hyrax] Block checkout submit until live prices load

Isolated worktree
Tests before the change
Tests after the change
Build, lint and format
Second review by an independent agent
Re-scan: the issue is gone

You review and merge. Hyrax never merges on its own.Review pull request

Change Review

Review the change,
not just the code.

Change Review starts from the ticket (a Linear issue) and gathers everything behind it: every linked pull request across every repository, the review discussion on each, and the live state of the feature flags those PRs use. Hyrax then writes one short, plain-language review of the whole change.

Modern changes rarely live in one pull request. A single feature now spans a backend service, a web app, a mobile client and an infrastructure repo. It's written partly by AI coding agents, and it ships behind feature flags that decide who actually sees it. Code review still happens one diff at a time, so no one sees the whole change. Reviewers check that each PR is well written, but no one checks that the PRs together deliver what was asked.

What a team gets on one page

What's changingTwo or three sentences anyone on the team can read, not just the engineer who wrote it.
Asked vs. builtEvery requirement in the ticket, checked against the code as met, partly met, not met or needs a person. Teams can add their own acceptance criteria in plain words.
Before and afterWhat a user or admin will notice, written as a diff in plain English, with sketches of affected screens or system diagrams for backend changes.
How it shipsWhich flags gate the change and where each is switched on today, including flags the code reads that were never created.
Sources for every sentenceEach statement links to the PR, ticket or flag it came from, so nothing has to be taken on trust.

Change Review · ACME-412

LinearACME-412 · Apple Pay at checkout

checkout-service #118 Merged storefront-web #342 In review acme-infra #57 Merged 2 flags

Gathering the change

What's changing

Shoppers on supported devices can pay with Apple Pay on the checkout page.² The payment service accepts Apple Pay and runs the same fraud checks as cards.¹ Refunds go back to Apple Pay.¹

Asked vs. built

Apple Pay button on the payment step for supported devicesMet
Same fraud checks as card paymentsMet
Refunds return to Apple PayPartly met
Receipt email names the payment methodNot met
TeamWorks for guests who are not signed inNeeds a person

ACME-412 · Before and after · How it ships

Before and after

Checkout offers card and PayPal
Checkout offers Apple Pay on supported devices
Apple Pay orders refund to Apple Pay

How it ships

apple_pay_checkout	Staging On	Production 10%
apple_pay_refunds	Read by storefront-web #342 · never created

2storefront-web #342 · PaymentStep.tsx

Why it matters now

A feature is only done
when every part of it is.

01

AI writes more of the code.

Line-by-line review doesn't scale when changes arrive faster than people can read them. Change Review raises the question to "is this the change we meant to make?"

02

Work spans repositories.

A feature is only done when every part of it is. Change Review sees all the parts at once, including the PR that hasn't merged yet.

03

Shipping is decoupled from merging.

With flags, "merged" doesn't mean "live". Change Review shows who can see the change today, not just whether the code went in.

04

More people need to understand the change.

Product managers, QA, support and leadership get a readable account of what's shipping, without reading diffs.

05

It helps without getting in the way.

Change Review is advisory: it never blocks a merge. It sits alongside existing code review and gives the team a shared picture of the change before it reaches customers.