Workeros — Reconciliation + Shipping Plan

1 · Where we are

Three versions, none of them shippable as-is

We've been building on the wrong base, which is why regressions keep surfacing by screenshot.

staging GOOD LOOK

workeros-ui-fixes-20260615

soft corners
correct Emily icon
no Brain banner
faster

✗ missing today's 31 fixes

main REGRESSED

origin/main · what we built on

boxy corners
wrong Emily icon
Brain banner back
slow loads

✓ has the structure today's PRs target

31 PRs FLOATING

today's work · unmerged

activation, run page
6 decisions, channels
design tokens, perf

✗ nothing deployed · nobody can use it

The pattern: HubSpot logo → weekly card → composer box → corners → Emily → Brain banner — every regression found one screenshot at a time, because we're improving a branch built on the wrong base. The fix isn't more patches; it's the right base + a deployed baseline.

2 · The reconciliation (in progress)

Cherry-pick today's fixes onto the good base → one correct branch

Your call: base = staging, layer today's work on top. This makes the 4 app regressions fall out of the right base, not separate patches.

✓

Base = staging (the good version)

soft corners, right Emily, no banner, fast — inherited, not re-fixed

↓

1

Cherry-pick today's 31 fix-commits on top

cherry-pick the commits only (not merge) so main's regressions don't ride along — running now, resilient to rate-limits

↓

2

Conflicts → keep staging's look + the new feature's behavior

never reintroduce: Brain banner, Emily sparkle, boxy corners, borders, warm tokens (lint guards enforce it)

↓

3

Same for the landing

reset composer/logos to known-good (composer box already fixed) + the 6 new asks (#364–369)

↓

4

→ ONE "correct state" preview (engine + landing)

I verify login + walk every screen myself — that's when the screenshot-regression hunt stops

3 · How to ship it (your call)

Getting the correct state into prod

You gate merges. Once the reconciled preview is verified, pick how it lands:

A · Walk → ship onceREC

You walk the clean preview, approve, I merge the reconciled branch → main → deploy prod once.

+ one clean landing, known baseline

+ stops the drift immediately

– one bigger merge to review

B · Wave merge

Merge in batches (design-system → features → landing), deploy after each wave.

+ smaller reviews

– many deploys, longer to baseline

– drift window between waves

C · Ship now, iterate live

Merge the reconciled branch + deploy prod immediately, fix remaining polish on prod.

+ fastest to live

– iterates in public

– less review before prod

After it lands — guardrails so this can't recur: every future fix branches off the deployed baseline (never a stale checkout), the lint guards (tokens/borders/em-dash) stay in CI, and we add `workeros.floom.dev` to auto-track main so deploys can't silently lag. That's how we stop discovering drift.