Reimagined/resolve

What it measures: Whether any secrets (keys, tokens, passwords) have leaked into the code.

Method: In-process native secret scanner (entropy plus signature patterns) across all tracked files; no external tool. A clean result is a measured 10, not no-data zero. Deterministic.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Prevented

Secret scan ran and found no leaked secrets.

✓ On the Gold path — maintain.

Detailed fixes: d13_recommendation.md.

What it measures: Files that change often and are also complex — the riskiest hotspots.

Method: Per production file churn times cyclomatic complexity over a rolling window, computed from git and Roslyn/JS/Razor analysis. Exhaustive, deterministic per commit date.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Documented

No churn × complexity hotspots in the window.

✓ On the Gold path — maintain.

Detailed fixes: d15_recommendation.md.

What it measures: Whether the project's documentation is clear, complete, and useful.

Method: Judged by language model at low temperature (0.0-0.1) on a deterministic doc sample (READMEs plus first 25 architecture docs), with two-pass stability filtering. Advisory, sampled.

Maturity: Documented → Verified → Prevented · effective Strong / 10 · rule-coverage 100% · ceiling Documented

The reSolve documentation is clear and complete for a full-stack functional framework: an engaging README that describes CQRS/DDD event sourcing and the npx create-resolve-app workflow; a focused tests directory covering read-model configuration (App/Dev Config), projection/resolvers code examples, and template projects; and architecture/design docs visible in the outline. The body is clipped mid-test section for the remaining documents.

What to do

1. Resolve the 1 The Getting Started section mentions NodeJS 14.17 but does not state… finding(s) in Documentation Quality — start with README.md. — One of this dimension's main actionable groups (1 recommendation-level).
2. Resolve the 1 The 'Stories' read-model test config shows a default connector but no… finding(s) in Documentation Quality — start with README.md. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d19_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether names — types, methods, variables — are clear and consistent.

Method: Judged by language model at low temperature (0.0-0.1) on a deterministic random symbol sample (fixed size, not exhaustive), with disclosed confidence band. Advisory, sampled.

Maturity: Documented → Verified → Prevented · effective Exemplary / 10 · rule-coverage 100% · ceiling Verified

0 naming inconsistencies across 0 sampled symbols.

✓ On the Gold path — maintain.

Detailed fixes: d21_recommendation.md.

What it measures: Whether any secrets were ever committed — scanned across the full git history, not just now.

Method: Git-history secret scan via gitleaks detect over full history in an isolated checkout; each match flagged High. Exhaustive; degrades cleanly when tool absent.

Maturity: Documented → Verified → Prevented · effective 0.0 / 10 · rule-coverage 100% · ceiling Documented

41 finding(s): 0 critical, 41 high, 0 medium, 0 low. Remediation for historically-committed secrets is credential rotation — they remain in history regardless of later deletion.

What to do

1. Improve Secrets (history) — currently 0.0/10. — 41 finding(s): 0 critical, 41 high, 0 medium, 0 low. Remediation for historically-committed secrets is credential rotation — they remain in history regardless of later deletion.

Detailed fixes: d28_recommendation.md.

What it measures: Real static-analysis (SAST) findings — likely security bugs in the code, any language.

Method: Polyglot static analysis via semgrep across the repo using the pinned, image-baked p/security-audit + p/owasp-top-ten rulesets (no scan-time registry fetch); severity rules (ERROR/WARNING/INFO) map to a full-band severity-weighted score. Exhaustive, deterministic; degrades on parse failure.

Coverage: semgrep pattern rules over all files — exhaustive for the rule set, blind to classes of bug without a rule (clean = no rule matched).

Maturity: Documented → Verified → Prevented · effective 0.0 / 10 · rule-coverage 100% · ceiling Documented

93 finding(s): 0 critical, 73 high, 7 medium, 13 low.

What to do

1. Resolve the 50 High finding(s) in Static Analysis (SAST) — start with pr-cra.yml (28), pr-dev.yml (22). — One of this dimension's main actionable groups (50 issue-level).

Detailed fixes: d29_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether Dockerfiles / Terraform / Kubernetes config follow security best practices.

Method: IaC/container misconfiguration scan via trivy config (Dockerfile/Terraform/K8s/Helm/CloudFormation); severity rules to 0-10 moderate normalizer. NotApplicable without manifests. Exhaustive, deterministic.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Documented

trivy found no infrastructure-as-code or container misconfigurations.

✓ On the Gold path — maintain.

Detailed fixes: d31_recommendation.md.

What it measures: Whether JavaScript/npm dependencies have known published vulnerabilities (CVEs) — the npm ecosystem's biggest risk.

Method: JS/npm CVE scan via trivy fs --scanners vuln over JS manifests (package.json/yarn.lock/pnpm-lock/bun.lockb); 0-10 tight normalizer. NotApplicable without JS manifests. Exhaustive, deterministic.

Maturity: Documented → Verified → Prevented · effective 10.0 / 10 · rule-coverage 100% · ceiling Documented

No known-vulnerable JS/npm dependencies.

✓ On the Gold path — maintain.

Detailed fixes: d33_recommendation.md.

What it measures: Whether anyone still has living knowledge of each file, or it has been orphaned — last understood long ago by someone now gone quiet. The sibling of the bus factor: D16 asks who owns it, D34 asks whether anyone still knows it.

Method: File orphaning as total living-knowledge decay below one focused-commit's worth within a year, computed per-file from the D16 decay model. Exhaustive, deterministic over fixed history.

Maturity: Documented → Verified → Prevented · effective 0.0 / 10 · rule-coverage 100% · ceiling Documented

172 of 172 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is docs/getting-started-chart/components/Server.js.

What to do

1. Resolve the 3 Largest orphaned file finding(s) in Knowledge Freshness — start with Server.js, build.ts, types.ts. — One of this dimension's main actionable groups (3 recommendation-level).
2. Resolve the 1 Dormant codebase finding(s) in Knowledge Freshness. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d34_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether files that change together actually belong together — pairs that repeatedly co-change in git history despite having no explicit code dependency, surfacing the hidden/logical coupling (and boundaries in the wrong place) a static scan can't see.

Method: Pairwise co-occurrence over the per-commit file sets in git history (production source only — tests and generated dropped): Degree-of-Coupling = shared ÷ min individual revisions, reported above noise floors (each file ≥10 revisions, ≥5 shared commits, ≥50% strength); sweeping commits excluded. Deterministic over fixed history.

Coverage: Population: PRODUCTION source files only — test and generated files are dropped before pairing, so a class co-changing with its own test (trivially ~100%) can't drown the real production↔production coupling. Pairs ranked by Degree-of-Coupling; coupling through a build step, config, or non-source file isn't seen.

Maturity: Documented → Verified → Prevented · effective 9.8 / 10 · rule-coverage 100% · ceiling Documented

Strongest change-coupling: download-resolve-repo.ts↔install.ts 64%; patch-package-json.ts↔print-finish-output.ts 60%; install.ts↔print-finish-output.ts 60%

✓ On the Gold path — maintain.

Detailed fixes: d35_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether the build pipeline provides supply-chain integrity — generated provenance/attestation, signed artifacts (cosign/sigstore), an SBOM, and pinned build actions. Presence of the configuration, not a runtime guarantee.

Method: Supply-chain provenance/signing read deterministically from CI/build config (.github/workflows, .gitlab-ci.yml, azure-pipelines, Jenkinsfile, .circleci) + the release surface: four signals — generated provenance/attestation (SLSA/in-toto/actions-attest), artifact signing (cosign/sigstore/gitsign), an SBOM (syft/sbom-action/*.spdx.json/*.cdx.json), and SHA-pinned build actions — scored 10·present/denom. NotApplicable without a build pipeline. Detects configuration presence, not runtime enforcement.

Maturity: Documented → Verified → Prevented · effective 0.0 / 10 · rule-coverage 100% · ceiling Documented

0/4 supply-chain integrity signals present (provenance, signing, SBOM, pinned actions).

What to do

1. Resolve the 1 Unpinned build actions finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
2. Resolve the 1 Workflow token permissions not restricted finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
3. Resolve the 1 No build provenance finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d36_recommendation.md · top locations in Appendix A, every location in findings.md.

What it measures: Whether dependencies have known published vulnerabilities (CVEs) per the OSV database — read natively from whatever lockfile the repository ships (Cargo, npm, Go, Python, Maven, RubyGems, …). D33 and D30 add ecosystem-specific scanners on top for npm and .NET.

Method: Multi-ecosystem dependency-CVE scan via osv-scanner --recursive (queries the osv.dev database + parses lockfiles natively across ecosystems: npm package-lock/yarn/pnpm/bun, Go go.mod, Rust Cargo.lock, Maven/Gradle pom.xml/gradle.lockfile, PyPI requirements.txt/poetry.lock/Pipfile.lock, Composer composer.lock, RubyGems Gemfile.lock, Hex mix.lock, pub pubspec.lock, Swift Package.resolved); severity tally (Critical/High/Medium/Low) to 0-10 tight normalizer (8.0). NotApplicable only when the repo declares no supported non-.NET dependency lockfile (a NuGet-only repo stays NotApplicable — .NET CVEs are D30's domain); coverage needs a resolved lockfile. Additive to D33 (trivy fs); exhaustive + deterministic, DB kept fresh.

Maturity: Documented → Verified → Prevented · effective 0.0 / 10 · rule-coverage 100% · ceiling Documented

93 finding(s): 13 critical, 42 high, 27 medium, 11 low.

What to do

1. Resolve the 35 High CVE finding(s) in OSV Dependency Vulnerabilities — start with yarn.lock (35). — One of this dimension's main actionable groups (35 issue-level).
2. Resolve the 12 Critical CVE finding(s) in OSV Dependency Vulnerabilities — start with yarn.lock (12). — One of this dimension's main actionable groups (12 issue-level).
3. Resolve the 2 High vulnerability finding(s) in OSV Dependency Vulnerabilities — start with yarn.lock (2). — One of this dimension's main actionable groups (2 issue-level).

Detailed fixes: d38_recommendation.md · top locations in Appendix A, every location in findings.md.

Other · Accessibility — Whether pages declare a language (well-formed BCP-47) and a non-empty title, expose exactly one main landmark and a sane heading order with non-empty headings, keep zoom enabled, title their iframes, give data tables header cells, and avoid meta-refresh. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: html lang, document <title>, a main landmark and heading order on full documents only, plus zoom-disabling viewports, untitled iframes and meta-refresh anywhere. Deterministic, per structural checkpoint.

Other · Accessibility — Whether focus outlines aren't removed without a replacement, motion respects prefers-reduced-motion, and literal CSS colour pairs meet contrast — PARTIAL: inline styles, in-repo <style> blocks, in-repo .css files, var() tokens, Tailwind neutral utilities and CSS-in-JS literals are read (hex/rgb/hsl/named), never computed/runtime/external-CDN colour. Static markup readiness, not a WCAG conformance claim.

Method: Static markup/CSS scan: inline outline:none/0, literal inline colour/background contrast against the 4.5:1 AA floor, and <style>-block animation without a prefers-reduced-motion guard. Deterministic but PARTIAL — only inline styles and in-repo CSS literals are visible.

Other · Accessibility — Whether accessibility is ENFORCED in the toolchain — an a11y linter (eslint-plugin-jsx-a11y / vuejs-accessibility) configured, and axe/pa11y/Lighthouse wired into tests or CI — on the Documented→Verified→Prevented ladder.

Method: Repo config/CI scan: an a11y linter (eslint-plugin-jsx-a11y / vuejs-accessibility) configured, and axe/pa11y/Lighthouse in tests or CI, graded on the Documented→Verified→Prevented rungs. Deterministic, presence/rung detection.

• An a11y linter is configured (Documented) but there's no automated a11y test or CI gate. Add jest-axe to verify at runtime, then gate it in CI.

What to do

• Enforce accessibility in the toolchain: add eslint-plugin-jsx-a11y, assert with jest-axe in tests, then gate axe/pa11y/Lighthouse in CI.

Other · Domain Modelling — Whether the domain layer stays free of infrastructure dependencies — a domain aggregate fused to a persistence ORM (TypeORM/Prisma/MikroORM/Sequelize/Mongoose) on its own declaration (active-record) couples the domain to infrastructure. The clean-architecture dependency rule.

Method: Roslyn (DDD-gated): domain-layer types scanned for infrastructure usage in member SIGNATURES and inside method/accessor BODIES — resolved calls and object-creations into EF/Marten/HTTP/Mongo/Redis/message-bus types (not just a namespace allowlist). Deterministic, symbol-resolved, exhaustive over domain-layer bodies, DDD-native.

Coverage: Domain layer identified by NAMESPACE heuristic; infrastructure then resolved by symbol in member SIGNATURES and method/accessor BODIES — rename the layer and the check evaporates.

Maturity · Maturity — Whether the repo and its projects have a README, and whether it's substantive and current.

Method: Filesystem scan: README presence, word count, and headings for depth; git history for staleness. Exhaustive across root and project dirs, deterministic.

What to do

• Add a 'Testing' section to the root README — how to run the test suite.
• Add an 'Architecture' / 'How it works' section to the root README — the high-level shape.
• Add a README to the 11 of 66 project(s) that lack one — worth up to 0.3 pts.

Maturity · Maturity — Whether key decisions (ADRs) and the high-level shape (C4/diagrams) are written down.

Method: Filesystem scan: ADR folder/naming conventions or content, plus Mermaid/PlantUML/C4/architecture.md discovery. Exhaustive, deterministic.

• No Architecture Decision Records found — decisions aren't captured for future maintainers.

What to do

• Start an ADR log (docs/adr/) recording significant decisions and their rationale.

Maturity · Maturity — Whether the repo is organised deliberately — src/test separation and consistent project naming.

Method: Filesystem scan: src/test folder separation and namespace-prefix consistency (majority RootNamespace agreement). Exhaustive across projects, deterministic.

Maturity · Maturity — Whether the README actually describes the code that exists (LLM-judged, advisory).

Method: Judged by language model at low temperature: README accuracy versus actual projects, within a disclosed tolerance. Advisory, not a measured number.

Readiness · Readiness — Whether an automated pipeline builds and tests every change.

Method: Filesystem scan: CI workflow files (.github/workflows, .gitlab-ci.yml, etc.) for build and test stages. Exhaustive, deterministic.

Readiness · Readiness — Whether SAST, secret/dependency scanning and performance benchmarking are wired in (presence, not runtime).

Method: Filesystem scan: SAST configuration, dependency-update automation, secret scanning, and a benchmark harness or benchmark step — in this repository's own ecosystem. Exhaustive, deterministic.

• No static application security testing detected. For this repository's stack, add CodeQL's javascript-typescript pack, `semgrep --config=p/typescript`, or eslint-plugin-security as a CI step.

What to do

• Add a SAST step to CI running what this repository's stack ships: CodeQL's javascript-typescript pack, `semgrep --config=p/typescript`, or eslint-plugin-security — so a security regression fails the build instead of landing.
• Enable Dependabot/Renovate or a dependency-review gate.
• Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.

Readiness · Readiness — Whether releases are automated and safely reversible (probes, rolling updates, approval gates) — from manifests/pipeline files, not the live environment.

Method: Filesystem scan: deployment manifests/IaC (K8s YAML, Helm, Terraform) for rolling updates, probes, approval gates, migration hooks. Exhaustive, deterministic.

Readiness · Readiness — Whether releases are traceable — a maintained changelog and explicit version stamping.

Method: Filesystem scan: changelog file presence and version tags in csproj or git tags. Exhaustive, deterministic.

What to do

• Stamp a version in your build/package manifest (e.g. csproj <Version>, package.json, pyproject.toml, Cargo.toml, or a VERSION file) or tag releases with semver so builds and releases are traceable.

React / JS · Code Health — How much of the frontend is typed TypeScript vs untyped JavaScript.

Method: Frontend file inventory: the share of typed TypeScript vs untyped JavaScript across the source tree. Deterministic, exhaustive over frontend files.

• 813 typed · 503 plain JS

What to do

• Migrate the remaining .js/.jsx files to TypeScript.

React / JS · Code Health — Copy-pasted token-identical blocks across the frontend (the D4 clone algorithm over JS/TS tokens, D-386).

Method: Copy-pasted token-identical blocks across the frontend (the D4 clone algorithm run over JS/TS tokens). Deterministic.

• functional-tests/app/config.prod.js:20 · templates/js/react/config.prod.js:19 · templates/ts/react/config.prod.ts:20 · tutorial/lesson-1/config.prod.js:19 — config.prod.js:20
• functional-tests/app/config.dev.js:17 · functional-tests/app/config.prod.js:16 · templates/js/react/config.prod.js:15 · templates/ts/react/config.prod.ts:16 — config.dev.js:17
• tests/read-model-advanced-sample/config.js:27 · tests/read-model-comments-sample/config.js:27 · tests/read-model-store-api/config.js:21 · tests/read-model-stories-sample/config.js:27 — config.js:27
• templates/js/react/config.dev.js:19 · templates/ts/react/config.dev.ts:20 · tutorial/lesson-2/config.dev.js:19 · tutorial/lesson-3/config.dev.js:19 — config.dev.js:19
• packages/runtime/adapters/readmodel-adapters/readmodel-mysql/src/reset.ts:19 · packages/runtime/adapters/readmodel-adapters/readmodel-mysql/src/resubscribe.ts:26 · packages/runtime/adapters/readmodel-adapters/readmodel-mysql/src/unsubscribe.ts:24 — reset.ts:19
• packages/runtime/adapters/eventstore-adapters/eventstore-lite/src/index.ts:73 · packages/runtime/adapters/eventstore-adapters/eventstore-mysql/src/index.ts:55 · packages/runtime/adapters/eventstore-adapters/eventstore-postgresql/src/index.ts:85 — index.ts:73
• packages/runtime/adapters/readmodel-adapters/readmodel-lite/src/resubscribe.ts:16 · packages/runtime/adapters/readmodel-adapters/readmodel-lite/src/unsubscribe.ts:14 — resubscribe.ts:16
• packages/runtime/adapters/readmodel-adapters/readmodel-mysql/src/resubscribe.ts:19 · packages/runtime/adapters/readmodel-adapters/readmodel-mysql/src/unsubscribe.ts:17 — resubscribe.ts:19

What to do

• Extract the duplicated blocks into shared functions/components.

React / JS · Architecture — Conformance to the detected frontend architecture layout (feature-sliced / layered src) plus cross-package deep-import rules (D-386).

Method: Conformance to the detected frontend layout (feature-sliced / layered src) plus cross-package deep-import rules, over the module graph. Deterministic.

• functional-tests/utils/utils.ts:3 reaches into another package with a relative path (../app/common/view-models/resolver-failed.resolver) — import the package by name instead. — utils.ts:3
• functional-tests/utils/utils.ts:4 reaches into another package with a relative path (../app/common/view-models/monitoring.projection) — import the package by name instead. — utils.ts:4
• functional-tests/utils/utils.ts:6 reaches into another package with a relative path (../app/common/view-models/init-failed.projection) — import the package by name instead. — utils.ts:6
• functional-tests/utils/utils.ts:8 reaches into another package with a relative path (../app/common/view-models/resolver-failed.projection) — import the package by name instead. — utils.ts:8
• functional-tests/utils/utils.ts:9 reaches into another package with a relative path (../app/common/view-models/resolver-failed.resolver) — import the package by name instead. — utils.ts:9

What to do

• Fix the listed violations: import through public entries (package exports / slice index), never reach into another layer or package's internals.

React / JS · Code Health — Per-function cyclomatic/cognitive complexity from the token-level function scanner (D-386) — real branching, not a regex heuristic.

Method: Per-function cyclomatic/cognitive complexity from a token-level function scanner (real branching, not a regex heuristic), computed over every frontend function. Deterministic.

• Branch-heavy code is where defects cluster — extract decisions into smaller functions. (×8) — build.ts:154, update-to-set-expression.ts:10, build.ts:37, …

What to do

• Break down the listed branch-heavy functions; aim P95 cyclomatic ≤ 5.

React / JS · Code Health — How many components/modules exceed the large-file threshold.

Method: Components/modules exceeding the large-file threshold, counted exhaustively across the frontend source tree. Deterministic.

What to do

• Split the oversized components into smaller, focused ones.

React / JS · Readiness — Static test reachability (D-386): the share of production files reachable from any test via the import graph — measured without running anything.

Method: Static test reachability: the share of production files reachable from any test via the import graph — measured without running anything. Deterministic.

• No test imports this module directly or transitively. If it is a CLI, check whether a suite runs it as a child process; otherwise it has no test reaching it. (×8) — run.ts, wrap-procedure.ts, config.app.js, …

What to do

• Add tests that import the unreached modules (directly or through their public entry).

React / JS · Readiness — Whether the project wires up test, lint and typecheck — detected from each package.json script's COMMAND (eslint / tsc / vitest / jest / playwright), not just its name, and corroborated against CI-workflow invocations so a tool run only in CI still counts.

Method: package.json scanned for test/lint/typecheck script wiring. Deterministic presence check.

• test ✓ · lint ✓ · typecheck ✗

What to do

• Add `tsc --noEmit` as package.json scripts and run them in CI.

React / JS · Code Health — Files unreachable from every application/tooling/test entry point, and exports nothing imports (module-graph reachability, D-386).

Method: Dead code: files unreachable from every application/tooling/test entry point plus exports nothing imports, via module-graph reachability. Deterministic, exhaustive over the import graph.

• 20 file(s) (~2811 LoC) were excluded from dead-code analysis. This package DOES declare main/module/exports — but every declared target is missing from the scanned tree, which is what a build-output entry (dist/, lib/, out/) looks like before the package is built. Point a declared target at the source entry, or build the package before scanning, so reachability can follow it. — react-hooks
• 55 file(s) (~4057 LoC) were excluded from dead-code analysis. This package DOES declare main/module/exports — but every declared target is missing from the scanned tree, which is what a build-output entry (dist/, lib/, out/) looks like before the package is built. Point a declared target at the source entry, or build the package before scanning, so reachability can follow it. — runtime-base
• 122 file(s) (~7574 LoC) were excluded from dead-code analysis. This package DOES declare main/module/exports — but every declared target is missing from the scanned tree, which is what a build-output entry (dist/, lib/, out/) looks like before the package is built. Point a declared target at the source entry, or build the package before scanning, so reachability can follow it. — scripts
• Unreachable from the 185 application, 32 tooling and 244 test entry point(s) detected in this repo. Gate removals on your build/type-check — an undetected custom entry would make these reachable.
• no import path from any entry point (185 application, 32 tooling, 244 test roots considered) (×4) — wrap-procedure.ts, replicate.ts, index.js, …

What to do

• Delete the dead files and unused exports — every line is maintenance cost and rebuild-estimate inflation with zero runtime value.

React / JS · Readiness — npm dependency truthfulness (D-386): unused dependencies, imports not declared anywhere, and type-/test-only packages shipped as production deps.

Method: npm dependency truthfulness: unused dependencies, imports declared nowhere, and type-/test-only packages shipped as production deps — from the manifest + import graph. Deterministic.

• Declared in functional-tests/app/package.json but never imported anywhere in that package or its workspace members — dead weight and attack surface. Verify against build tooling before removing. (×3)
• Only test files import it — move it to devDependencies. — benchmark.test.ts:6

What to do

• Remove unused dependencies, declare unlisted imports explicitly, and demote type-/test-only packages to devDependencies.

React / JS · Architecture — Import cycles in the module graph (D-386) — files that can only be understood and changed together.

Method: Import cycles in the module graph, detected exhaustively over JS/TS imports (the same cycle detection as the .NET coupling dimension). Deterministic.

• packages/core/client/src/middleware.ts → packages/core/client/src/middleware/parse-response.ts → packages/core/client/src/middleware.ts — middleware.ts
• packages/runtime/runtimes/runtime-aws-serverless/src/cloud-service-event-handler.ts → packages/runtime/runtimes/runtime-aws-serverless/src/types.ts → packages/runtime/runtimes/runtime-aws-serverless/src/lambda-worker.ts → packages/runtime/runtimes/runtime-aws-serverless/src/cloud-service-event-handler.ts — cloud-service-event-handler.ts
• packages/tools/testing-tools/src/flow/aggregate/as.ts → packages/tools/testing-tools/src/flow/aggregate/command.ts → packages/tools/testing-tools/src/flow/aggregate/as.ts — as.ts
• packages/tools/testing-tools/src/flow/aggregate/make-test-environment.ts → packages/tools/testing-tools/src/runtime/get-event-store.ts → packages/tools/testing-tools/src/types.ts → packages/tools/testing-tools/src/flow/aggregate/make-test-environment.ts — make-test-environment.ts
• packages/tools/testing-tools/src/flow/read-model/as.ts → packages/tools/testing-tools/src/flow/read-model/not.ts → packages/tools/testing-tools/src/flow/read-model/query.ts → packages/tools/testing-tools/src/flow/read-model/as.ts — as.ts
• packages/tools/testing-tools/src/flow/read-model/read-model.ts → packages/tools/testing-tools/src/flow/read-model/with-adapter.ts → packages/tools/testing-tools/src/flow/read-model/read-model.ts — read-model.ts
• packages/tools/testing-tools/src/flow/saga/allow-side-effects.ts → packages/tools/testing-tools/src/flow/saga/saga.ts → packages/tools/testing-tools/src/flow/saga/allow-side-effects.ts — allow-side-effects.ts
• packages/tools/testing-tools/src/flow/saga/make-assertions.ts → packages/tools/testing-tools/src/flow/saga/mock-command-implementation.ts → packages/tools/testing-tools/src/flow/saga/make-assertions.ts — make-assertions.ts

What to do

• Break each cycle by extracting the shared piece into a module both sides can import.