Ionic-Team/ionic-Framework

What it measures: Copy-pasted code that should be shared instead.

Method: Code duplication via token-stream sliding windows with type-aware normalization (locals masked, type names preserved), density-scored per KLoC of production code. Deterministic.

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

0 duplicated block group(s) detected.

✓ On the Gold path — maintain.

Detailed fixes: d4_recommendation.md.

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

Top hotspots: core/src/components/datetime/datetime.tsx (4×26=104)

✓ On the Gold path — maintain.

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

What it measures: Whether knowledge is concentrated in too few people (the "bus factor").

Method: Living knowledge per author via time-decayed commit attribution (6-month half-life, focus weighting) across largest source files. Deterministic, avoids blame's mechanical-refactor false positives.

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

15 source file(s) have their living knowledge concentrated in one author (≥90% of recent, decayed contribution). The largest is packages/react/src/components/createInlineOverlayComponent.tsx.

✓ On the Gold path — maintain.

Detailed fixes: d16_recommendation.md · top locations in Appendix A, every location in findings.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

This project's documentation is strong and well-structured: a single README with an aligned architecture/Docs markdown set gives complete coverage of each section in the outline. The main docs are a cohesive developer-resources page that covers What is Ionic Framework?, Guides (contributing, component guide, Sass, shadow parts), Packages, and links to all outlined sections; there is also a dedicated @ionic/core README covering features, usage, framework bindings, and custom elements build, plus Vue-specific documentation. The README itself is clear but slightly thin on the front lines.

What to do

1. Improve Documentation Quality — currently 8.0/10. — This project's documentation is strong and well-structured: a single README with an aligned architecture/Docs markdown set gives complete coverage of each section in the outline. The main docs are a cohesive developer-resources page that covers What is Ionic Framework?, Guides (contributing, component guide, Sass, shadow parts), Packages, and links to all outlined sections; there is also a dedicated @ionic/core README covering features, usage, framework bindings, and custom elements build, plus Vue-specific documentation. The README itself is clear but slightly thin on the front lines.

Detailed fixes: d19_recommendation.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 8.0 / 10 · rule-coverage 100% · ceiling Documented

2 finding(s): 0 critical, 2 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. Resolve the 2 Secret finding(s) in Secrets (history) — start with index.html, index.ts. — One of this dimension's main actionable groups (2 issue-level).
2. Resolve the 1 Rotate the exposed credentials finding(s) in Secrets (history). — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d28_recommendation.md · top locations in Appendix A, every location in findings.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.6 / 10 · rule-coverage 100% · ceiling Documented

16 finding(s): 0 critical, 16 high, 0 medium, 0 low.

What to do

1. Resolve the 16 High finding(s) in Static Analysis (SAST) — start with action.yml (7), stencil-nightly.yml (4), release-orchestrator.yml (3). — One of this dimension's main actionable groups (16 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 9.7 / 10 · rule-coverage 100% · ceiling Documented

1 finding(s): 0 critical, 1 high, 0 medium, 0 low.

✓ On the Gold path — maintain.

Detailed fixes: d31_recommendation.md · top locations in Appendix A, every location in findings.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 4.0 / 10 · rule-coverage 100% · ceiling Documented

112 of 185 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is core/src/utils/transition/ios.transition.ts.

What to do

1. Resolve the 3 Largest orphaned file finding(s) in Knowledge Freshness — start with ios.transition.ts, nav.tsx, utils.ts. — One of this dimension's main actionable groups (3 recommendation-level).
2. Resolve the 1 Concentrated knowledge decay 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 10.0 / 10 · rule-coverage 100% · ceiling Documented

Strongest change-coupling: modal-interface.ts↔popover-interface.ts 59%; datetime-button.tsx↔datetime.tsx 50%

✓ 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 2.5 / 10 · rule-coverage 100% · ceiling Documented

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

What to do

1. Resolve the 1 PR-triggered workflow without a permissions block finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
2. Resolve the 1 Secret passed as a command-line argument 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

50 finding(s): 5 critical, 27 high, 15 medium, 3 low.

What to do

1. Resolve the 27 High CVE finding(s) in OSV Dependency Vulnerabilities — start with package-lock.json (27). — One of this dimension's main actionable groups (27 issue-level).
2. Resolve the 14 Medium CVE finding(s) in OSV Dependency Vulnerabilities — start with package-lock.json (14). — One of this dimension's main actionable groups (14 warning-level).
3. Resolve the 5 Critical CVE finding(s) in OSV Dependency Vulnerabilities — start with package-lock.json (5). — One of this dimension's main actionable groups (5 issue-level).

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

Other · Accessibility — Whether non-text content carries a text alternative — img/area/input[type=image] have alt, a meaningful svg has a title or aria-label, video has a captions track, and object/embed/canvas have a name or fallback content. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: every img/area/input[type=image] checked for alt, svg[role=img] for a title/aria-label, video for a captions <track>. Components skipped, spreads suppressed. Deterministic, hard fact per element.

Other · Accessibility — Whether form controls have a programmatic label (an associated label, aria-label or aria-labelledby), buttons have text, links have an accessible name, fieldsets have a non-empty legend, known UI-library field components carry a label prop, and a placeholder isn't used as the only label. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: inputs/selects/textareas checked for an associated label[for]/wrapping label/aria-label/aria-labelledby (per document), buttons for accessible text, fieldsets for a legend; placeholder-only labelling flagged. Deterministic, hard fact per control.

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 interactive behaviour is keyboard-reachable — no click handler on a non-interactive element lacking a role, tabindex and key handler, no positive tabindex, no href-less anchor, no placeholder-href (#/javascript) link acting as a button. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: click handlers on non-interactive elements lacking role+tabindex+key handler, positive tabindex values, and href-less anchors. Components skipped, spreads suppressed. Deterministic, hard fact per element.

• A click handler on a plain element isn't keyboard-operable. Use a <button>, or add role + tabindex="0" + a key handler. (×2) — accordion.tsx:519, popover.tsx:759
• A click handler on a plain element with no role and no tabindex: even where another element's key handler can reach it, assistive tech can neither focus it nor announce what it is. Use a <button>, or add role + tabindex="0". (×3) — checkbox.tsx:387, input.tsx:907, toggle.tsx:503

What to do

• Make custom controls keyboard-operable (role + tabindex + key handler), drop positive tabindex, and give anchors a real href.

Other · Accessibility — Whether ARIA is used correctly — valid non-abstract roles, the ARIA state a role requires, valid (non-misspelled) aria-* attribute names, in-enum values for token-typed aria-* attributes, and no aria-hidden on (or wrapping) a focusable element. Static markup readiness, not a WCAG conformance claim.

Method: Static markup-model scan: role values checked against the WAI-ARIA role set (abstract/invalid flagged), required ARIA state for a role, and aria-hidden on a focusable element. Deterministic, role/attribute level.

• aria-hidden="true" hides the element from assistive tech but leaves it keyboard-focusable — a confusing dead stop. Remove aria-hidden or make the element non-focusable. (×8) — action-sheet.tsx:617, action-sheet.tsx:667, alert.tsx:848, …
• aria-labelledby is present but empty, so it references no element and the relationship is lost. Point it at the id(s) of the target element, or remove it. — input.tsx:733

What to do

• Use valid, non-abstract roles, supply the ARIA state each role requires, and never put aria-hidden on a focusable element.

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.

• a11y checks run in tests (Verified) but aren't gated in CI — wire axe/pa11y/Lighthouse into the pipeline so an a11y regression blocks the merge (Prevented).

What to do

• Enforce accessibility in the toolchain: add eslint-plugin-vuejs-accessibility, 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.

• 74 code files changed in the last 6 months but the README was not touched — it may no longer reflect the system.

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 4 of 12 project(s) that lack one — worth up to 0.7 pts.
• Review the README against recent changes; refresh the parts that drifted.

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.
• No C4/PlantUML/Mermaid diagram or architecture.md — the high-level shape isn't documented.

What to do

• Start an ADR log (docs/adr/) recording significant decisions and their rationale.
• Add a C4 context/container diagram (Structurizr, PlantUML or Mermaid) or an architecture.md overview.

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.

What to do

• 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.

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.

• core/src/components/checkbox/checkbox.tsx:87 · core/src/components/toggle/toggle.tsx:105 — checkbox.tsx:87
• packages/angular/test/apps/ng16/src/app/lazy/version-test/modal-nav-params/modal-nav-params.component.ts:5 · packages/angular/test/apps/ng17/src/app/lazy/version-test/modal-nav-params/modal-nav-params.component.ts:5 · packages/angular/test/apps/ng18/src/app/lazy/version-test/modal-nav-params/modal-nav-params.component.ts:5 — modal-nav-params.component.ts:5
• core/src/components/input-otp/input-otp.tsx:136 · core/src/components/input/input.tsx:311 — input-otp.tsx:136
• core/src/components/card/card.tsx:44 · core/src/components/fab-button/fab-button.tsx:43 — card.tsx:44
• packages/angular/standalone/src/directives/input-otp.ts:91 · packages/angular/standalone/src/directives/input.ts:113 — input-otp.ts:91
• core/src/components/breadcrumb/breadcrumb.tsx:49 · core/src/components/fab-button/fab-button.tsx:38 — breadcrumb.tsx:49
• core/src/components/col/col.tsx:22 · core/src/components/col/col.tsx:64 · core/src/components/col/col.tsx:102 — col.tsx:22
• core/src/components/datetime/datetime.tsx:503 · core/src/components/range/range.tsx:298 · core/src/components/searchbar/searchbar.tsx:215 — datetime.tsx:503

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.

• packages/react/src/components/IonPage.tsx:4 reaches into another package with a relative path (../routing/PageManager) — import the package by name instead. — IonPage.tsx:4
• packages/react/src/components/IonRouterOutlet.tsx:5 reaches into another package with a relative path (../routing/OutletPageManager) — import the package by name instead. — IonRouterOutlet.tsx:5
• packages/react/src/components/navigation/IonTabs.tsx:6 reaches into another package with a relative path (../../routing/PageManager) — import the package by name instead. — IonTabs.tsx:6
• packages/react/src/index.ts:5 reaches into another package with a relative path (./routing) — import the package by name instead. — index.ts:5
• packages/react/src/routing/NavManager.tsx:5 reaches into another package with a relative path (../components/IonRouterContext) — import the package by name instead. — NavManager.tsx:5
• packages/react/src/routing/NavManager.tsx:7 reaches into another package with a relative path (../contexts/NavContext) — import the package by name instead. — NavManager.tsx:7
• packages/react/src/routing/OutletPageManager.tsx:4 reaches into another package with a relative path (../components/inner-proxies) — import the package by name instead. — OutletPageManager.tsx:4
• packages/react/src/routing/OutletPageManager.tsx:5 reaches into another package with a relative path (../contexts/IonLifeCycleContext) — import the package by name instead. — OutletPageManager.tsx:5

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) — range.tsx:1084, router.ts:213, input-otp.tsx:615, …

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 — its behavior is unverified. (×8) — datetime.tsx, modal.tsx, select.tsx, …

What to do

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

React / JS · Readiness — How outdated the npm dependencies are (a maturity signal). JS/npm CVEs are scored separately in D33 (JS/npm Dependency Vulnerabilities).

Method: npm dependency staleness from manifest/registry metadata (a maturity signal; JS/npm CVEs are scored separately in D33). Deterministic.

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.

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.

• 1 file(s) (~2 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. — custom-elements
• 2 file(s) (~88 LoC) were excluded from dead-code analysis — declare main/module/exports or a conventional entry (src/index.*, an index.html script) so reachability can see this package. — angular-server
• 3 file(s) (~93 LoC) were excluded from dead-code analysis — declare main/module/exports or a conventional entry (src/index.*, an index.html script) so reachability can see this package. — ng16
• Unreachable from the 40 application, 43 tooling and 912 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 (40 application, 43 tooling, 912 test roots considered) (×4) — datetime.tsx, modal.tsx, select.tsx, …

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.

• Imported but not declared in any reachable package.json — installs work only by hoisting accident. (×3) — toHaveReceivedEventDetail.ts:2, app.server.module.ts:2, server.ts:3
• Declared in packages/angular/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)

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.

• core/src/utils/transition/index.ts → core/src/utils/transition/ios.transition.ts → core/src/utils/transition/index.ts — index.ts
• packages/angular/common/src/directives/navigation/router-outlet.ts → packages/angular/common/src/directives/navigation/stack-controller.ts → packages/angular/common/src/providers/nav-controller.ts → packages/angular/common/src/directives/navigation/router-outlet.ts — router-outlet.ts
• packages/angular/test/base/src/app/lazy/keep-contents-mounted/index.ts → packages/angular/test/base/src/app/lazy/keep-contents-mounted/keep-contents-mounted.module.ts → packages/angular/test/base/src/app/lazy/keep-contents-mounted/keep-contents-mounted-routing.module.ts → packages/angular/test/base/src/app/lazy/keep-contents-mounted/index.ts — index.ts
• packages/angular/test/base/src/app/lazy/modal-dynamic-wrapper/index.ts → packages/angular/test/base/src/app/lazy/modal-dynamic-wrapper/modal-dynamic-wrapper.module.ts → packages/angular/test/base/src/app/lazy/modal-dynamic-wrapper/modal-dynamic-wrapper-routing.module.ts → packages/angular/test/base/src/app/lazy/modal-dynamic-wrapper/index.ts — index.ts
• packages/angular/test/base/src/app/lazy/modal-inline/index.ts → packages/angular/test/base/src/app/lazy/modal-inline/modal-inline.module.ts → packages/angular/test/base/src/app/lazy/modal-inline/modal-inline-routing.module.ts → packages/angular/test/base/src/app/lazy/modal-inline/index.ts — index.ts
• packages/angular/test/base/src/app/lazy/modal-sheet-inline/index.ts → packages/angular/test/base/src/app/lazy/modal-sheet-inline/modal-sheet-inline.module.ts → packages/angular/test/base/src/app/lazy/modal-sheet-inline/modal-sheet-inline-routing.module.ts → packages/angular/test/base/src/app/lazy/modal-sheet-inline/index.ts — index.ts

What to do

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