Out of the POM.
Into structured control.
One command moves your suite off page objects into a versioned, graded repo.
One command in, no more page objects out.
Migrate what you already have.
No blank slate. cor analyze scans your existing Page Object Model or spec files and builds a locator map; cor migrate rewrites the call sites for you and retires the page object file — an inline call or a generated base class, your choice.
One versioned repo, not forty scattered files.
Locators aren’t hardcoded strings buried in spec files anymore — they’re graded, named entries in a repo you can branch, diff, and review like code. cor branch diff shows exactly what changed before it merges.
Fix it once. Every test picks it up.
Update a locator centrally and every test that references it resolves the new graded value on its next run — no find-and-replace across forty spec files, same call shape you already use, zero added time to write or run a test.
Everything else lives in the same repo.
A few more ways to use the same graded locator repo.
Catch drift before it catches you.
cor audit compares what’s in the COR repo against what’s actually referenced in your code — locators used in tests but missing from the repo, or captured but never used — so mismatches show up as a report, not a surprise.
Self-heal
Opt-in, not a requirement. Wrap an action in selfHealingAction() (Playwright) or use cy.corLocate() (Cypress) and a failed primary selector retries each graded alternative in confidence order before giving up — logged, never silent.
First-run enrichment
Locators migrated from code start with just a selector string. The first time each one runs, the SDK automatically brings it up to the same richer fidelity the browser extension would have captured — no re-capture needed.
Common questions.
Can I install it today?
Not yet — the SDK and CLI are not published to npm. The browser extension is live and free right now, and captures the same locators the SDK will resolve, so anything you capture today carries over. Join the waitlist to hear when the packages ship.
What does migrating an existing suite actually involve?
One command. `cor migrate` scans your existing spec and page-object files, extracts every hardcoded selector it finds, and writes them into a versioned locator repo — leaving your test logic untouched. You review the extraction before anything is committed; nothing is rewritten behind your back.
Do I have to abandon the Page Object Model?
No. COR replaces the selector-storage half of a page object, not the actions on it. Your existing page-object classes keep their methods — they resolve their selectors from COR instead of holding hardcoded strings. Teams using Screenplay, App Actions, or plain helper functions work the same way.
Which frameworks will be supported at launch?
Playwright, Cypress, WebdriverIO, and Nightwatch adapters, plus the framework-agnostic CLI. The underlying engine already generates locators for Selenium, TestCafe, and Puppeteer, so those follow.
Is self-healing on by default?
No, it is opt-in per action. You wrap a call in selfHealingAction() (Playwright) or use cy.corLocate() (Cypress), and only then does a failed primary selector retry graded alternatives. Every heal is logged rather than applied silently — a test that passes because something healed should never look identical to one that simply passed.
Does my test suite need network access to run?
Locators are pulled once and cached, so a run does not depend on a live round trip per selector. Pinning a commit or tag makes a run fully reproducible against an exact locator set.