sdods analyze
Analyze an application repository and propose an SDODS project.
sdods analyze [path] [-p <slug> | --slug <slug>] [--name <name>] [--openapi <file>] [--browsers <list>]
[--apply] [--force] [--no-import-specs] [--report-only]| Flag | Meaning |
|---|---|
path | application repository (default: current directory) |
-p, --project <slug> | slug for the proposed project (default: from the app directory name); --slug alias |
--name <name> | display name |
--openapi <file> | OpenAPI spec path relative to the app (auto-detected otherwise) |
--browsers <list> | comma list of browsers for the proposal |
--apply | write the proposed project under projects/<slug> |
--force | overwrite an existing project when applying |
--no-import-specs | do not copy existing Playwright specs into recorded/imported |
--report-only | print the analysis and skip the proposal |
Read-only unless --apply. Detects the package manager and monorepo shape, the framework, routes (Next.js, React Router, Vue Router, Nuxt, Angular, Express, Fastify, NestJS, Spring, Flask, FastAPI, Django), OpenAPI documents, the test-id attribute in use, existing tests and their locator quality, authentication libraries and login pages, env files and dev-server ports, CI provider, i18n and accessibility tooling. The proposal contains a validated sdods.project.yaml (modules, processes, routes), envs/*.yaml, starter @smoke features per module, a coverage map and a checklist.
Modules are inferred by fusing several signals rather than by splitting the URL: an OpenAPI tag (weight 1.00) outranks the monorepo workspace owning the file (0.90), a domain directory such as src/modules/<x>/ (0.80), the file that defines the route (0.70), and finally the first URL segment (0.30) as a floor. A synonym table (0.20) folds login/signin/logout/session onto auth, and merges only — it never creates a module. Routes that cannot name anything (catch-alls, optional groups, a bare root in a generic file) are listed as skipped instead of being collected into a home bucket. The proposal prints each module with its confidence, winning signal and source file; see modules.
bun run sdods analyze ../my-app --report-only
bun run sdods analyze ../my-app --apply --slug my-app
bun run sdods lint -p my-app && bun run sdods run -p my-app -e local -t @smokesdods init --from <app> runs the same analysis while scaffolding a new workspace.