Turn stainless.yml into a migration map.

Why Sourced can make that claim

Sourced has converted thousands of OpenAPI schemas and Stainless-style config shapes to harden the converter around maximum compatibility. The migration path starts from the files Stainless customers already own, treats stainless.yml as the contract, generates SDK/docs previews, and reports every compatibility gap before anything is published.

• Stainless inputs are treated as the contractSourced reads OpenAPI plus stainless.yml and preserves the migration-critical fields: package names, resources, subresources, method names, auth environment variables, production repo settings, README example intent, and docs/MCP metadata.
• SDK compatibility is checked before publishingSourced generates TypeScript and Python SDK previews, then reports generated method coverage, skipped methods, constructor/auth shape, package metadata, error behavior, pagination, multipart, streaming, and other runtime review points before any registry write.
• Docs compatibility is part of the same conversionSourced scans Stainless Docs Platform dependencies, hosted SDKJSON/API usage, Astro/Starlight setup, docs routes, redirects, custom-domain requirements, generated reference pages, sitemap, and llms.txt as part of the migration path.
• Drift is reported instead of hiddenIf stainless.yml references a method missing from OpenAPI, or docs still depend on hosted Stainless reference data, Sourced keeps that in the compatibility report so teams can fix the source contract before customers see a changed SDK or docs site.