
Company News
Free Business Plan Upgrades for Open Source Maintainers
Open source maintainers are under more pressure than ever. We're raising our open source program from the Team plan to the Business plan, free.
repo-test-architect
Advanced tools
Audit-first test strategy agent for repository-native test planning.
Audit-first test strategy tooling for codebases.
Repo Test Architect builds a deterministic audit graph before asking any model or agent to reason about tests. The goal is to identify repo-native, high-value test work from facts the tool can inspect locally: project roots, framework signals, existing tests, source classifications, blockers, and remaining risk.
The current implementation can:
go.work members through a supported bounded adapter*.cs compile include, finite target-conditioned package shapes, bounded nearest-file build and central-package props, exact immutable test-field receivers, stable direct-call results, inline out results, framework exception and collection/string assertions, one-hop test helpers, and guarded well-known System type collisions, through a supported bounded .NET adapterNative test generation is intentionally deferred. generate_selected_test returns a structured deferred artifact until adapter-specific generation policy and repair-loop fixtures exist.
Repo Test Architect is an early public alpha. Treat its findings as evidence-backed review input rather than an automatic instruction to change a repository.
Node.js 20 or newer is required.
Run the CLI without a global install:
npx --yes repo-test-architect doctor
npx --yes repo-test-architect analyze .
Or install the CLI and MCP server binaries:
npm install --global repo-test-architect
repo-test-architect doctor
repo-test-architect analyze .
Add the local stdio MCP server to an MCP-capable client:
{
"mcpServers": {
"repo-test-architect": {
"command": "npx",
"args": [
"--yes",
"repo-test-architect",
"mcp"
]
}
}
}
The client launches the server locally. Repository source stays on the machine unless the client or another configured tool sends it elsewhere. Connected models receive instructions to start with analyze_repository for a general repository review. See MCP client config and agent install paths for global-install, local-checkout, and host-specific guidance.
For a human-readable review of the current repository:
npx --yes repo-test-architect analyze .
analyze detects every project root, runs each supported adapter once, and derives the audit summary, top findings, candidate ranking, test plan, execution hints, project stats, and verification commands. Markdown stays compact; JSON preserves the complete evidence bundle:
npx --yes repo-test-architect analyze . --format json
npx --yes repo-test-architect analyze . --changed
Useful focused views:
| Goal | Command |
|---|---|
| Complete repository review | repo-test-architect analyze . |
| Concise architecture findings | repo-test-architect findings-projects . |
| Actionable cross-project plan | repo-test-architect plan-projects . |
| Raw reusable project audits | repo-test-architect audit-projects . --format json |
| Runtime readiness | repo-test-architect doctor |
Run repo-test-architect --help for the short command map or repo-test-architect <command> --help for options. The CLI reference documents the full surface.
For an MCP-connected model, the equivalent default is analyze_repository. Use narrower tools only when the request asks for one artifact or already supplies an audit artifact.
Available adapters:
csharp: one static SDK-style test project or one unique literal production/test project edge, including bounded native xUnit MTP-v2 and MSTest.Sdk v4 ownership, exact literal or one-hop root-aliased target membership, one repository-contained direct *.cs compile include, finite project-local target-conditioned package predicates, and a pair selected amid unrelated projects, with bounded nearest-file Directory.Build.props metadata and static Directory.Packages.props versions, xUnit, NUnit, or MSTest attributed tests, exact project-file commands, runnable-body-owned direct type calls, bounded concrete-local or immutable test-field receivers, one-hop stable direct-call, receiver-call, or inline out var result assertions, bounded exception assertions, and one same-class private-static test-helper hop; see the C# alpha support matrixelixir: one conventional Mix application with literal app and exact MixProject/Mixfile ownership, conventional/app-prefixed modules and protocols, exact Mix tasks, bounded acronym, terminal-plural, repeated-declaration, and compiled local ExUnit-wrapper ownership, static startup options, test-body-scoped direct fully qualified or exact-alias calls, conservative filename evidence, and a blocker-free mix test command; see Elixir alpha supportjavascript: JavaScript/TypeScript repositories with Node's test runner (including TypeScript execution scripts), Bun test, AVA, Mocha/CommonJS, Vitest, Jest, Playwright, Cypress, Express/Supertest, React Testing Library detection, and bounded literal browser request-to-route evidence; see the alpha support matrix for evidence boundaries and known gapsgo: conventional go.mod projects and literal repository-contained go.work members using runnable standard-library TestXxx, FuzzXxx, or ExampleXxx tests, package-local filename, unique top-level and parser-owned concrete receiver-method symbols through explicit types, exact simple constructor results, or exact statically typed test-helper results, bounded standard-library and Testify assertion usage, parser-scoped local shadow checks, same-package or exact external-package imports (including dot imports), generic top-level functions, and bounded callable-body-owned same-package or module-local source hops, module-local commands, and optional explicit GOOS/GOARCH/custom-tag selection; see the alpha support matrix for the supported boundary and blockerskotlin: conventional Gradle/Maven JVM module roots, settings-owned Gradle aggregates, and root-declared Maven reactors with Kotlin and/or Java standard source sets, dependency-qualified direct/exported-transitive module evidence, JUnit 4/5, kotlin.test, bounded Gradle/JUnit Platform Kotest common specs, conventional Gradle/Spock features, and method-level TestNG through direct Maven dependencies or Gradle useTestNG(); see the Kotlin/JVM alpha support matrixphp: one root Composer project with literal string-valued PSR-4 source/test ownership, bounded literal autoloaded function files, statically declared PHPUnit, exact bounded commands or explicit safe command withholding, conventional runnable test classes including one unique source- or test-owned PHPUnit base edge, direct imported or exact same-namespace class calls, and conservative basename fallback; see PHP alpha supportpython: bounded Python package, FastAPI, Django, and Flask layouts with declarative multi-package/namespace ownership, configured pytest discovery, exact absolute/relative imports, one-hop source dependency evidence, static framework test-client route evidence, pytest/unittest, async and property-based extensions, fixture reachability, pip/setuptools, uv, Poetry, Hatch, tox, nox, and coverage configuration; see the Python alpha support matrixrust: conventional Cargo packages and literal repository-contained workspace members using the built-in #[test] harness, inline #[cfg(test)] modules, exact exclusion of external test-only module graphs, exact crate-module imports from tests/, and exact unconditional crate-root symbol re-exports; see the Rust alpha support matrixruby: one conventional Bundler project with lib/ sources, one root gemspec or a complete exact named root-gemspec set, runnable Minitest::Test test_* methods or RSpec examples, exact bounded commands, root .rspec and exact per-file spec_helper loading, three-edge literal require/unique-constant evidence, exact singleton calls, exact constant-owned RSpec described_class, direct immutable constructor-local, one-line RSpec let/subject, exact source-factory and same-group RSpec helper receivers, and exact same-file literal shared-example inclusion, bounded assertion usage, conservative basename fallback, and explicit Minitest-spec/Rails/mixed-runner blockers; see the Ruby alpha support matrixswift: Swift Package Manager, Xcode-style and Bazel/rules_swift layouts, Swift Testing, XCTest, Quick/Nimble, SnapshotTesting, VaporTesting/XCTVapor, reactive frameworks, and generic Fluent database boundaries with driver-specific qualifiers; see the Swift alpha support matrixProject detection reports Elixir Mix roots through the supported bounded adapter. Unsupported ecosystems remain visible so clients can distinguish "not audited yet" from "not present."
Don't see your stack? Open an adapter request with the language or ecosystem, build system, test frameworks, and—when possible—a representative public repository. Requests help prioritize adapters against real repository shapes and user demand.
The public package exposes the audit CLI, the stdio MCP server, and a deterministic MCP invoke harness under the stable binary names documented below.
The commands below expose focused artifacts, fixtures, evals, diagnostics, and release checks for advanced use and repository development.
Run the complete analysis directly or against the polyglot example:
npm run analyze
npm run analyze:json
npm run analyze:example
npm run analyze:example:json
Check runtime and diagnostics readiness:
npm run doctor
npm run doctor:json
Local MCP diagnostics are disabled by default. They can be explicitly directed to stderr or a bounded local JSONL file; see Local diagnostics. Build a sanitized, inspectable bundle with:
npm run diagnostic-bundle -- --diagnostics-file ./.repo-test-architect/diagnostics.jsonl --format json
node ./src/cli/index.js diagnostic-bundle --diagnostics-file ./.repo-test-architect/diagnostics.jsonl --format json
List registered adapters:
npm run adapters
npm run adapters:json
Inspect project detection marker rules:
npm run detect-rules
npm run detect-rules:json
Detect project roots and adapter matches:
npm run detect:example
npm run detect:example:json
npm run detect:kotlin-fixture
npm run detect:kotlin-fixture:json
npm run detect:apple-fixture
npm run detect:apple-fixture:json
npm run audit-projects:example
npm run audit-projects:example:json
npm run audit-projects:changed-since
npm run summarize-projects:example
npm run summarize-projects:example:json
npm run rank-projects:example
npm run rank-projects:example:json
npm run plan-projects:example
npm run plan-projects:example:json
npm run hints-projects:example
npm run hints-projects:example:json
npm run findings-projects:example
npm run findings-projects:example:json
npm run placement-projects:example
npm run placement-projects:example:json
npm run placement-projects:split-example:json
npm run stats-projects:example
npm run stats-projects:example:json
For project-aware self-audits, exclude checked-in fixture or sample roots with a quoted subtree pattern:
node ./src/cli/index.js findings-projects . --exclude-project "examples/**"
Reuse a saved project audit artifact:
node ./src/cli/index.js audit-projects ./examples/polyglot-workspace --format json
node ./src/cli/index.js summarize-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js rank-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js plan-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js findings-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js placement-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js stats-projects --from-project-audits ./project-audits.json --format json
npm run audit:example
npm run audit:kotlin-fixture
Output the structured audit graph:
npm run audit:example:json
npm run audit:kotlin-fixture:json
Generate an actionable test plan from the audit graph:
npm run plan:example
npm run plan:example:json
npm run hints:example
npm run hints:example:json
npm run plan:kotlin-fixture
npm run plan:kotlin-fixture:json
npm run plan:item:example
npm run plan:changed
npm run plan:changed-since
Derive advisory execution hints while leaving the plan artifact unchanged:
node ./src/cli/index.js hints ./examples/node-vitest-basic --item add-test:src/authService.ts
node ./src/cli/index.js hints-projects ./examples/polyglot-workspace --format json
The installing CLI or agent host remains responsible for model choice, budgets, permissions, context loading, and subagent lifecycle.
Explain one audited target by stable target ID:
npm run explain:example
Rank test candidates without generating tests:
npm run rank:example
Analyze existing test placement from audit evidence:
npm run placement:example
npm run placement:example:json
npm run placement:from-audit:example
Exercise the MCP-style tool surface:
npm run mcp:tools
npm run mcp:analyze:example
npm run mcp:adapters
npm run mcp:detect-rules
npm run mcp:detect:example
npm run mcp:audit-projects:example
npm run mcp:summarize-projects:example
npm run mcp:rank-projects:example
npm run mcp:plan-projects:example
npm run mcp:findings-projects:example
npm run mcp:placement-projects:example
npm run mcp:placement-split:example
npm run mcp:stats-projects:example
npm run mcp:audit:example
npm run mcp:audit:kotlin-fixture
npm run mcp:placement:example
npm run mcp:audit:envelope
npm run mcp:stdio
npm run mcp:smoke
Generate a plan from an existing audit JSON file:
npm run plan:from-audit:example
Run the auditor regression tests:
npm test
npm run alpha:check
npm run release:check
Find and rank active public repositories for real-world adapter validation:
npm run validation:repos -- --profile react
npm run validation:repos -- --profile workspace --limit 10
npm run validation:repos -- --profile swift,gradle,maven --format json
The finder uses authenticated GitHub repository search, verifies exact ecosystem markers in root manifests, and ranks candidates using maintenance recency, stars, repository size, lockfiles, CI, and license metadata. Run npm run validation:repos -- --list-profiles for the available profiles and --help for quality-filter options.
Check that every supported adapter has a complete, pinned hardening corpus:
npm run corpus:check
npm run corpus:scorecard
npm run corpus:measure -- --case python-asyncer --checkout /path/to/pinned/asyncer
npm run corpus:measure -- --case python-django --checkout /path/to/pinned/django --profile-phases
npm run csharp:performance:check
npm run javascript:performance:check
npm run python:performance:check
npm run kotlin:performance:check
npm run rust:performance:check
npm run swift:performance:check
npm run go:performance:check
npm run ruby:performance:check
npm run php:performance:check
The versioned evals/validation-corpus.json manifest records one conventional library or service, one framework-heavy application, and one difficult ownership graph per adapter cohort. Every supported adapter must have a complete cohort; a registered experimental adapter may be added only with all three roles. Each record carries the shared detection, ownership, command, evidence, ranking, stability, and performance scorecard. All 30 current pins across the ten supported adapters pass all 210 scorecard areas. A reviewed command may be null when the adapter correctly withholds unsafe execution. Cases may also carry bounded adapter audit options, such as an explicit Go build target, so repeated measurements remain host-independent.
corpus:scorecard renders the review contract for humans. It reports review completeness separately from the pass rate among reviewed checks and keeps PASS, FAIL, and PENDING visible for every area. Use npm run corpus:scorecard -- --format json for the deterministic validation-scorecard/v1 view. These are validation-review results, not a repository-quality rating.
corpus:measure verifies the checkout's exact pinned Git SHA, runs the selected adapter at least three times, rejects canonical audit drift, and reports the raw durations, median duration, evidence-link count, and normalized audit digest used to update the scorecard. For the exact Python and Swift pins, --profile-phases defaults to five runs and additionally reports ordered samples and medians for traversal/text reading, project/build ownership, source discovery/indexing, test parsing/indexing, and evidence/classification/artifact assembly. These development timings are callback-only and never enter audit/v1, CLI/MCP audit output, or local MCP diagnostics.
Each adapter performance check separately runs a generated 400-source/200-test project, verifies its candidate and evidence counts, and enforces a broad cross-platform regression ceiling. The Rust gate includes one additional skipped src/lib.rs module-wiring target required to declare the 400 behavioral modules. These synthetic gates complement the recorded per-repository corpus distributions.
Use alpha:check for the adapter-support milestone. release:check additionally covers packaging and installed-binary readiness.
The CI workflow keeps one stable Linux pr-gate: documentation-only changes run focused contract tests, normal changes run npm run alpha:check, and distribution-sensitive changes run npm run release:check. Windows runs only for runtime and portability changes; macOS runs only for Swift-sensitive changes. A merge to master runs the complete release gate on Linux, while manual dispatch runs the full release gate on all three operating systems.
The tests include golden audit and plan snapshots under evals/expected, driven by evals/fixtures.json, plus shared adapter-conformance checks for deterministic JSON, portable paths, evidence semantics, and downstream artifact agreement.
JSON schemas and the signal registry for versioned artifacts live under schemas/.
Refresh snapshots after intentional audit behavior changes:
npm run eval:check
npm run eval:summary
npm run eval:test
npm run eval:update
Check model-consistency scenario locked fields against deterministic tool results:
npm run model-consistency:check
npm run model-consistency:json
npm run model-consistency:json -- --profile local-small
npm run model-consistency:compare -- baseline-summary.json candidate-summary.json
npm run model-consistency:stats
Node 20 or newer is required for the CLI. The default smoke check is portable across platforms:
npm run smoke
If Node is not available yet, the repository still includes a PowerShell smoke check:
powershell -ExecutionPolicy Bypass -File ./scripts/smoke.ps1
Check package contents before publishing:
npm run pack:check
npm run bin:check
npm run installed-package:check
npm run distribution:check
npm run release:check
distribution:check validates packaging and MCP metadata preparation. The stricter distribution:check:publish verifies that the public npm and MCP Registry identities are aligned before a release. See Distribution.
src/
core/
audit-model.ts
audit-phase-timing.js
plan-execution-hints.js
plan-execution-hints.ts
repository-text-files.js
report.js
report.ts
diagnostics/
diagnostics.js
adapters/
csharp/
audit.js
javascript/
audit.js
audit.ts
kotlin/
audit.js
python/
audit.js
rust/
audit.js
swift/
audit.js
cli/
index.js
examples/
csharp-sdk-project-pair/
csharp-sdk-unique-pair/
csharp-sdk-xunit-basic/
node-vitest-basic/
express-supertest/
react-testing-library/
kotlin-junit-basic/
kotlin-gradle-groovy-junit/
kotlin-gradle-module-graph-junit/
kotlin-maven-junit/
kotlin-maven-reactor-junit/
kotlin-maven-wrapper-junit4/
kotlin-gradle-aggregate-kotest/
kotlin-gradle-spock/
kotlin-maven-testng/
python-pytest-service/
python-uv-pytest/
python-poetry-pytest/
rust-cargo-basic/
rust-cargo-workspace-basic/
swift-spm-xctest/
swift-spm-swift-testing/
swift-spm-quick-nimble/
swift-spm-custom-paths/
swift-spm-alternate-roots/
swift-bazel-xctest/
swift-xcode-test-plans/
vapor-service-tests/
vapor-mongodb-boundaries/
evals/
expected/
model-consistency/
schemas/
JavaScript/TypeScript, PHP, Python, Ruby, Swift, bounded Kotlin/JVM modules, bounded Go modules, bounded C# SDK project shapes, and bounded Rust Cargo packages are supported adapter proof points. PHP support covers the bounded Composer/PSR-4/PHPUnit ownership, command-withholding, and evidence rules in PHP Alpha Support. Ruby support covers the bounded Bundler/Minitest/RSpec ownership and evidence rules in Ruby Alpha Support. Rust support includes literal repository-contained workspace members, exact package commands, built-in test ownership, literal module graphs, exact test-only module exclusion, direct logical-module imports, inherent associated calls, and exact unconditional crate-root symbol re-exports as defined in Rust Alpha Support. C# support covers one conventional SDK-style test project or one unique literal production/test project edge, including bounded native xUnit MTP-v2 and MSTest.Sdk v4 ownership, exact literal or one-hop root-aliased target membership, one repository-contained direct *.cs compile include, finite target-conditioned package predicates, and a pair amid unrelated projects, with bounded nearest-file build metadata and static central package versions, exact test-project commands, runnable-body-owned direct type calls, bounded concrete-local or immutable test-field receivers, one-hop stable direct-call, receiver-call, or inline out var result assertions, bounded exception assertions, and one same-class private-static test-helper hop while solution ownership remains excluded. Go support includes literal repository-contained go.work members, explicit static build-target selection, bounded standard-library/Testify assertion usage, parser-scoped receiver identity through concrete local and test-helper bindings, and callable-body-owned source evidence as defined in Go Alpha Support. Kotlin/JVM support is limited to conventional Gradle/Maven modules and directly declared aggregate graphs, JUnit, the documented Kotest common-spec and Spock feature variants, or method-level TestNG, and standard source sets as defined in Kotlin/JVM Alpha Support.
Important runtime surfaces:
src/cli/index.jssrc/mcp/tool-definitions.jssrc/mcp/stdio.jssrc/mcp/invoke.jsscripts/check-release-readiness.jsFAQs
Audit-first test strategy agent for repository-native test planning.
We found that repo-test-architect demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Company News
Open source maintainers are under more pressure than ever. We're raising our open source program from the Team plan to the Business plan, free.

Security News
The supply chain control that delays freshly published gems now covers lockfile generation and gem vendoring in Ruby projects.

Security News
During a UK cyber test, a Mythos 5 agent used sockpuppets, social engineering, and prompt injection to try to get a maintainer to merge malware.