feat(enrichment): add static analysis + complexity analyzer (#1477)

[Daedalus-Icarus]

Summary

Adds two REES analyzers that perform static-defect detection and cyclomatic-complexity estimation directly on the changed lines of each source file in the diff (#1477).

staticLint scans added lines for common static-defect patterns, gated by language detection:

• TypeScript/JavaScript: no-eval, no-debugger, no-console, no-empty-catch, eqeqeq (== vs ===), no-unawaited-call, no-var
• Python: no-bare-except

Each rule is a flat linear-time regex tested against a single added line — no nested quantifiers, no backtracking risk. Capped at 25 findings (configurable via maxFindings); one finding per line (first matching rule wins). Language detection gates which rules apply so non-source files are skipped.

complexity estimates cyclomatic complexity per changed function by counting decision keywords (if, else if, for, while, case, catch, &&, ||, ?). Functions with cyclomatic >= 10 are flagged (matches ESLint default threshold). Detects function declarations from BOTH added lines AND context lines — so adding decision logic inside an existing unchanged function is correctly counted. Includes churn (added-line count in the function).

Both analyzers are pure and deterministic — no external tools, no repo checkout, no network. They degrade independently (a timeout/abort marks only that analyzer degraded).

Updated from the prior review — the blocker (complexity scanner only detected functions on added lines, missing the most common case) and all 5 nits are addressed:

• Complexity scanner now detects function declarations from context lines (existing functions with added decision logic).
• braceDepth tracks per-function baseDepth instead of a global zero, so function-end detection works inside nested blocks.
• no-floating-promise renamed to no-unawaited-call with a softer, best-effort message.
• else if decision count locked with explicit tests (= 1 decision).
• Threshold changed from > 10 to >= 10 (matches ESLint default).

Closes #1477.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked an issue, or this is small enough that the summary explains why an issue is not needed.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

• The PR is entirely inside review-enrichment/ (a standalone package with its own tsconfig.json, node:test runner, and package.json). It is outside the worker src/**/*.ts Codecov scope and vitest scope. The worker-side checks do not exercise or regress from this change.
• The change IS validated by the REES package gate: npm test -> 231/232 pass (15 new; 1 pre-existing sentry-upload env failure), tsc -> exit 0.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests.
• API/OpenAPI/MCP behavior is updated and tested where needed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails. SVG screenshots are not used as review evidence. Review-only screenshots or recordings are not committed to the repository.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

UI Evidence

Not applicable — backend REES analyzers, no visible UI/frontend/docs/extension surface.

State / title	JPG/PNG evidence
n/a (backend-only change)

Notes

• Blocker fix: the complexity scanner now detects function declarations from context lines (hunk context, not just added lines). This catches the most common real-world case: a PR that adds if/for/&& logic inside an existing function whose function foo() { declaration is just diff context. The scanner tracks baseDepth (the brace depth at the function opening) so function-end detection works correctly even inside nested blocks/classes.
• Lint rules are curated for high precision without type information: each pattern is a flat regex anchored to a single added line. no-unawaited-call uses a conservative heuristic — it may produce false positives on synchronous calls, but the softer message ("if this returns a Promise") reflects the best-effort nature.
• Findings are public-safe by construction: { file, line, rule, severity, message } and { file, function, cyclomatic, churn } carry no source content or variable values. Render blocks route file paths through safeCodeSpan and messages through promptText.
• Thresholds (MAX_LINT_FINDINGS=25, MAX_COMPLEXITY_FINDINGS=10, COMPLEXITY_THRESHOLD=10) are committed as named constants.

[loopover-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 Gittensory review result - reject/close recommended

_{Review updated: 2026-06-30 03:45:13 UTC}

5 files · 1 AI reviewer · 1 blocker · readiness 55/100 · CI green · dirty

🛑 Suggested Action - Reject/Close

• AI reviewers agree on a likely critical defect: `src/review/enrichment-wire.ts` in `REES_ANALYZER_NAMES` is missing `staticLint` and `complexity`, so `resolveReesAnalyzers` rejects `REES_ANALYZERS=staticLint,complexity` as invalid and sends `analyzers: []`, preventing explicitly configured deployments from running the new analyzers. — Resolve the flagged defect, or override if the AI reviewers are mistaken, then re-run the gate.

Review summary
The PR adds pure REES analyzers for added-line static lint findings and changed-function complexity, wires them into the enrichment registry, and renders both sections in the brief. The core analyzer wiring in `review-enrichment/src/brief.ts` is coherent, but the engine-side analyzer allowlist was not extended, so explicit self-host analyzer selection cannot enable these new analyzers. The complexity scanner is deliberately TS/JS-only and the current full file does detect function declarations from context lines, so the failed AI check about `isAdded`/Python-Go tracking is not valid against this head.

Blockers

• `src/review/enrichment-wire.ts` in `REES_ANALYZER_NAMES` is missing `staticLint` and `complexity`, so `resolveReesAnalyzers` rejects `REES_ANALYZERS=staticLint,complexity` as invalid and sends `analyzers: []`, preventing explicitly configured deployments from running the new analyzers.

Nits — 6 non-blocking

• nit: `review-enrichment/src/analyzers/static-analysis.ts:52` and `review-enrichment/src/analyzers/static-analysis.ts:97` scan comments and string literals as code, so examples like `// eval(x)` or `'console.log(x)'` will produce advisory false positives.
• nit: `review-enrichment/src/analyzers/static-analysis.ts:187` counts `?`, `&&`, and `||` inside strings/comments/types, which can inflate complexity for changed lines that are not executable branches.
• nit: `review-enrichment/src/analyzers/static-analysis.ts:255` resets `braceDepth` at every hunk, so added branches in the same existing function split across multiple hunks can be attributed to separate partial scans rather than one function-level complexity estimate.
• Add `staticLint` and `complexity` to `REES_ANALYZER_NAMES` in `src/review/enrichment-wire.ts`, with a regression test showing `resolveReesAnalyzers` accepts both names.
• Before applying lint and decision regexes in `review-enrichment/src/analyzers/static-analysis.ts`, strip or ignore obvious line comments/string-only lines to reduce noisy advisory findings.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

Why this is blocked

• `src/review/enrichment-wire.ts` in `REES_ANALYZER_NAMES` is missing `staticLint` and `complexity`, so `resolveReesAnalyzers` rejects `REES_ANALYZERS=staticLint,complexity` as invalid and sends `analyzers: []`, preventing explicitly configured deployments from running the new analyzers.

Signal	Result	Evidence
Code review	❌ 1 blocker	1 reviewer
Linked issue	✅ Linked	#1477
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (size label size:L; 1 linked issue).
Validation posture	❌ 5/25	Preflight is holding this PR; address the blocker before review.
Contributor workload	✅ 10/10	Author activity: 37 registered-repo PR(s), 14 merged, 4 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	EtoileAI; Gittensor profile; 37 PR(s), 4 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: EtoileAI
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 37 PR(s), 4 issue(s).
• Related work: Items reference the same linked issue feat(enrichment): static analysis + complexity analyzer (lint/semgrep over the diff) #1477. (issue #1477)
• Related work: Open PR work references issue feat(enrichment): static analysis + complexity analyzer (lint/semgrep over the diff) #1477. (issue #1477)
• Related work: Titles/paths share 6 meaningful terms. (PR #1780)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Review top overlaps.
• Add a concise scope and risk note.
• Fix the blocker.
• Triage stale or unlinked PRs.
• Refresh registry data or choose a registered active repo.
• Check active issues and PRs before submitting.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review