What TuscanoLabs actually does

Point TuscanoLabs at a GitHub repo or upload your test files. The scanner walks the project, identifies test files, page objects, fixtures, and CI configuration, and figures out which test framework is in use.

• Source frameworks: Selenium (JS, TS, Java, Python) and Cypress (JS, TS, BDD). WebdriverIO, TestCafe, and Puppeteer coming soon.
• Source languages: Java, Python, JavaScript, and TypeScript. C# coming soon.
• Test runners detected: JUnit 4, JUnit 5, TestNG, pytest, unittest, Mocha, Jest, Vitest
• Page-object, BDD/Cucumber, and API test patterns identified automatically
• Recognises pom.xml, requirements.txt, package.json and CI workflows for context

We don't pipe your tests through a single LLM call and hope for the best. Layer 1 is a library of hand-written conversion rules — 40+ for Cypress alone — that handle the common cases identically every time. Layer 2 is an AI fallback that fixes the remaining edges with full project context.

• Layer 1: deterministic rules — same input always produces the same output
• Layer 2: Claude-based AI fallback for non-standard or custom patterns
• AI prompt is enriched with helper files, page objects, and project context — not just the file in isolation
• Validation gate runs syntax checks, import resolution, and confidence scoring on each converted file
• Failed conversions are flagged with a specific reason, not silently dropped

TuscanoLabs reads your existing test architecture and chooses an idiomatic Playwright shape — instead of forcing every project into the same template.

• Page Object Model (POM) repos generate Playwright POM classes with fixtures
• Cucumber/BDD repos generate playwright-bdd feature files and step definitions
• API test suites generate Playwright APIRequestContext-based tests
• Mixed projects get a structure recommendation per area, not a forced one-size answer

The output of every scan is a structured migration report — not a wall of warnings. It's designed to answer the questions that come up in a planning meeting: how big is this, how risky, where do we start.

• Migration readiness score with risk level (low / medium / high)
• File-by-file effort estimate broken down by complexity
• Top failed patterns so you know where the conversion will need help
• Tech stack and CI summary so you can plan the surrounding work
• Manual vs assisted hours estimate for sprint planning
• Downloadable as PDF for stakeholder review

After Convert All runs, every file shows up in a side-by-side diff view. You can edit any converted file inline, regenerate a single file with the AI, or report a specific issue back to us — and the whole project downloads as a ready-to-test ZIP.

• Side-by-side original vs converted diff for every file
• Per-file regenerate (re-runs Layer 2 with the latest context)
• Inline editor for hand-tweaking output before download
• Per-file 'Report issue' button feeds the conversion learning loop
• ZIP download includes a ready-to-run Playwright project (config, scaffolding, generated tests)

TuscanoLabs generates a complete Playwright project, not just file-level snippets. The scaffolding, config, and helper structure match the language you target.

• Target languages: TypeScript, JavaScript, Python, Java
• Standard, POM, BDD (playwright-bdd), and API output shapes
• Selectors mapped from CSS/XPath to Playwright locators where possible
• Custom Cypress commands expanded inline so output runs without your old plugins
• Generated tests aim to be runnable on day one — review still recommended

Every claim on this card is auditable in the migrations and edge function code. We try not to write anything we couldn't defend in a customer's vendor questionnaire.

• TLS in transit, encryption at rest, AES-GCM for sensitive credentials
• Row-level security per account on every customer-data table
• Uploaded source files automatically purged 30 days after the scan
• GitHub access tokens encrypted at rest, deleted on disconnect
• One-click report deletion from the dashboard
• Source code is never used to train AI models — Anthropic's commercial terms apply

When the AI corrects a deterministic output, we log the (before, after) pair and the framework it came from. Pairs that recur become candidates for promotion to Layer 1 rules — so the deterministic engine grows from real customer data, not guesses.

• Per-file Report issue button captures user-flagged problems with the original snippet
• AI-vs-deterministic corrections logged automatically (no source code stored long-term)
• Recurring corrections (5+ times) surface as rule candidates in our internal admin
• Customer-driven coverage growth, not a fixed rule list