epicenterhq Asymmetric Wins
An asymmetric win is a refusal that gives back more complexity than it costs in product capability.
The spine:
Preserve the product sentence.
Refuse the small promise.
Delete the code family.
The usual shape: trade a small amount of fidelity, compatibility, modes, or reproducibility to collapse a much larger implementation graph.
This is not arithmetic and not a quota. Do not remove arbitrary features. The job is to find the one small promise that owns a disproportionate code family, then decide whether refusing that exact promise leaves the product sentence intact.
Do not say "good enough" and ship drift. Name the product sentence first. Keep the workflow, safety, accessibility, and recognizable product feel. Refuse only the promise that was forcing a second system, and keep it when the evidence says the loss is load-bearing.
Compose With
one-sentence-testdetects the opportunity (the surface audit surfaces the convenience feature that forces a second product sentence). This skill owns the decision.refactoringcounts callers, fixtures, state branches, styling branches, docs paths, and other code-family evidence before the refusal is executed.ui-designowns visual direction, accessibility, brand, and whether a UI detail is load-bearing before pixel fidelity is refused.greenfield-clean-breaksexecutes the resulting breaking change, wave ordering, and old-path deletion.radical-optionslinks here instead of re-deriving the refusal move.
Domain Manifestations
The same move shows up in different clothes:
UI refactor
Refuse exact pixel or markup reproduction only when the core workflow,
hierarchy, accessibility, important states, and product feel survive.
Code refactor
Refuse legacy aliases, duplicate helpers, fallback parsers, and old call
shapes when callers can move to one canonical path.
Tests and reproducibility
Refuse exact old snapshots, fixture quirks, or transitional behavior when the
product contract is clearer than the old artifact.
Design artifacts
Refuse full HTML facsimiles and exhaustive component trees when a native
primitive, screenshot, compact sketch, or state table preserves the same
decision.
Architecture
Refuse keeping both mental models alive. A half-old, half-new system is
usually the expensive promise.
Procedure
1. Name the product sentence that must remain true.
2. List candidate refusal points: fast paths, old shapes, rare modes, provider
exceptions, compatibility aliases, fallback parsers, exact reproduction,
partial reflection, hand-reproduced UI structure.
3. For each candidate, name the deletion prize: methods, adapters, unions,
error variants, tests, docs branches, UI states, styling branches, fixtures,
screenshots, migrations, local markup, custom CSS, diagram upkeep.
4. Pick the candidate with the largest code family, not the most visible name.
5. Ask who loses what if that behavior is refused.
6. If the loss is a small convenience and the deletion removes a second shape,
refuse the behavior and write that refusal into the spec.
The rule is evidence-seeking, not dramatic: if the product sentence survives and the code family disappears, refusal is the default recommendation. Keep the feature when the user loss is load-bearing or when the "deletion" would only move complexity somewhere harder to see.
Decision Template
Use this shape in specs and design notes:
Product sentence:
...
Candidate refusal:
...
Deletion prize:
...
User loss:
...
Decision:
Refuse it / keep it because ...
UI Refactor Template
Use this when the promise is visual or interaction fidelity:
Product sentence:
...
Must preserve:
workflow, information hierarchy, accessibility, important states,
recognizable product feel, inspectable state, reviewable intent
Can refuse:
exact spacing, old breakpoints, one-off hover states, incidental animation,
pixel-perfect empty/loading/error states, duplicate responsive layouts,
locally reproduced HTML when a shared primitive owns the same contract,
exhaustive component trees when a smaller artifact preserves the decision
Deletion prize:
...
Replacement artifact:
shared primitive / screenshot / compact sketch / state table / full tree
Decision:
Refuse it / keep it because ...
Pixel, markup, and screenshot fidelity are load-bearing when the exact detail carries comprehension, accessibility, trust, brand, or a regression-sensitive state. Otherwise, exact reproduction is a promise like any other: keep it only when it earns the code family it forces.
UI Artifact Ladder
Use the smallest artifact that preserves the design decision:
1. Shared primitive or existing component
Use when the UI library already owns the structure, spacing, states, and
accessibility contract.
2. Screenshot or generated image
Use when visual appearance matters more than exact markup.
3. Compact sketch or state table
Use when the decision is hierarchy, state, or flow.
4. Partial tree
Use when parent-child structure is the point under review.
5. Full HTML diagram
Use only when exact DOM shape is the product contract or the bug.
Do not make agents reproduce a full HTML tree to prove a design unless the tree is the thing that must stay stable. Prefer the natural primitive, then verify the states that matter.
Worked Example: Social Sign-In
Product sentence:
All social sign-in routes through the API-hosted page via OAuth 2.1 PKCE.
Candidate refusal:
Browser SPAs can use Google GIS for a roughly 1-second sign-in.
Deletion prize:
signInWithIdToken
OIDCProvider narrowing
per-app GIS helpers
GIS blocked-browser UI
SocialSignInUnavailable
provider-specific SDK scaling for Apple and Microsoft
two social sign-in docs branches
two social sign-in test paths
User loss:
Google sign-in is a few seconds slower in browser SPAs.
Decision:
Refuse it. The UX loss is small; the second auth shape is permanent.
The product still has social sign-in. It refuses one fast path so one invariant can own every provider and environment.
For narrative context, see
docs/articles/20260504T160541-asymmetric-wins-support-fewer-features-to-collapse-complexity.md.