feat(rees): add real before/after complexity-delta analyzer

[JSONbored]

Summary

• Adds a complexityDelta REES analyzer that uses the shared reconstructOldContent primitive (Generalize reconstructOldContent into a shared before-content capability on AnalysisContext #4739) to recover a changed file's pre-PR text, re-runs complexity.ts's own decision-point counting against both the reconstructed old and current head versions, matches functions by name, and diffs the two scores into a structured {file, line, name, before, after, delta} finding.
• Closes the gap where complexity.ts only scores newly-added functions (whose opening line is visible in the diff) against a fixed absolute threshold, so a PR that meaningfully simplifies an existing gnarly function currently gets no credit at all.
• Registered as a separate AnalyzerName (complexityDelta, cost: "github-light", requires: ["files","github-token","head-sha"]) rather than folded into complexity's existing entry. Reasoning documented in both files' headers: merging the network-dependent fetch into complexity's single requires/cost would either (a) gate complexity's existing free, local, always-on absolute-threshold check behind a token/headSha — regressing it whenever either is unavailable, since scheduler.ts's skipReasonForAnalyzer skips a descriptor's run entirely based on its declared requires, before run is ever invoked — or (b) mislabel the network-dependent half as cost: "local", letting it dodge the github-light concurrency/timeout budget and the fast profile's network-free guarantee. Two honestly-classified descriptors instead of one dishonest one.
• complexity.ts's own absolute-threshold behavior (scanPatchForComplexity/scanComplexity/ComplexityFinding) is completely unchanged — only additive exports (isJsTsPath, scanContentForComplexity) so the new analyzer reuses the identical file-eligibility filter and decision-point counting rather than duplicating it.
• Both null (unreconstructable patch) and "" (wholly-added file) returns from reconstructOldContent are treated identically via plain truthiness (if (!oldContent)), per that function's own doc comment — never a strict === null check, which would wrongly treat a brand-new file's "" as valid before-content.

Closes #4740
Part of epic #4737

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused (REES analyzer + its own wiring only) 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.
• Linked issue: Closes #4740 (a complete, independently-resolved sub-issue of epic Epic: PR improvement signal — quality-delta scoring as the positive-axis counterpart to slop-risk #4737).

Validation

• git diff --check — clean.
• npm run actionlint — not run; no .github/workflows/** changes in this diff.
• npm run typecheck — clean.
• npm run test:coverage — not run; this change is scoped to review-enrichment/** (a separate Node --test-based service; per codecov.yml, "coverage is collected by vitest (v8) over src/**", so review-enrichment/** is outside that gate entirely) plus one non-branching array-literal addition in src/review/enrichment-analyzer-names.ts (module-level const array, executed on import by every existing test that already imports it transitively). Ran REES's own full suite instead: npm run rees:test — 1260/1260 passing, including 52 tests across the new/changed complexity files. Also ran the specific affected root unit test, test/unit/review-enrichment-config.test.ts — 17/17 passing.
• npm run test:workers — not run; no Workers runtime code touched.
• npm run build:mcp / npm run test:mcp-pack — not run; no MCP package changes.
• npm run ui:openapi:check — not run; no OpenAPI/API schema changes (this is an internal REES analyzer registration, not a documented HTTP endpoint change).
• npm run ui:lint / npm run ui:typecheck / npm run ui:build — not run; the only apps/gittensory-ui/** file touched is the auto-regenerated rees-analyzers.ts data catalog (via npm run metadata), not hand-authored UI logic.
• npm audit --audit-level=moderate — clean, 0 vulnerabilities (no new dependencies added).
• New/changed behavior has unit tests for new branches, fallback paths, and both reconstructOldContent degradation cases (null vs ""), each as its own distinct test.

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. (This analyzer's rendered brief text feeds only the internal AI-review prompt, never a public comment directly.)
• N/A — no auth, cookie, CORS, GitHub App, Cloudflare, or session changes.
• N/A — no OpenAPI/MCP-facing behavior changed (internal analyzer registry addition only).
• N/A — no UI changes beyond an auto-regenerated data catalog file.
• N/A — no visible UI change; no UI Evidence needed.
• N/A — no public docs/changelog edit (not a release-prep PR).

Notes

• Local gate run: npm run rees:test (1260/1260 tests passing, Node 22 via .nvmrc), root npm run typecheck (clean), npm audit --audit-level=moderate (clean), git diff --check (clean).
• Regenerated and committed: review-enrichment/analyzer-metadata.json, apps/gittensory-ui/src/lib/rees-analyzers.ts, and the generated block in .env.example via npm run metadata, mirroring the exact file set touched by the two closest precedent PRs that added a REES analyzer (#4155, #3594).
• File count (12) is slightly above this repo's usual small-PR preference; this mirrors the established, seemingly-unavoidable multi-file wiring pattern for registering any single new REES analyzer in this codebase (confirmed against both precedent PRs above), and 3 of the 12 are mechanically auto-regenerated, not hand-authored surface area.
• Not merging this myself — opening for review/the automated gate to evaluate.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	gittensory-ui	92b6706	Commit Preview URL Branch Preview URL	Jul 11 2026, 12:33 AM

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.23%. Comparing base (2dbfc46) to head (92b6706).
⚠️ Report is 8 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4758   +/-   ##
=======================================
  Coverage   94.23%   94.23%           
=======================================
  Files         441      441           
  Lines       38793    38793           
  Branches    14129    14129           
=======================================
  Hits        36556    36556           
  Misses       1577     1577           
  Partials      660      660           

Files with missing lines	Coverage Δ
...ory-engine/src/review/enrichment-analyzer-names.ts	100.00% <ø> (ø)
src/review/enrichment-analyzer-names.ts	100.00% <ø> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-11 00:27:26 UTC}

13 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · dirty

⏸️ Suggested Action - Manual Review

Review summary
This is a solid, well-scoped addition of a `complexityDelta` analyzer that closes a real gap in `complexity.ts` (which only scores newly-added functions from diff hunks, never a simplified/regressed existing function). It reuses `reconstructOldContent` and a newly-exported `scanContentForComplexity` from `complexity.ts` rather than duplicating counting logic, matches functions by name with ambiguous-name exclusion, and is registered as a properly-separate `AnalyzerName` with honest `cost`/`requires` so it doesn't regress the existing free/local `complexity` check or dodge the `github-light` budget. Tests are extensive and drive the real entrypoint (fetch → reverse-apply → diff), not just the pure helper, including abort/oversize/malformed-patch edge cases. The PR closes linked issue #4740 and the diff matches its description; I don't see a reachable correctness defect in the visible code.

Nits — 6 non-blocking

• complexity-delta.ts hardcodes MAX_FILES=20/MAX_FINDINGS internally rather than reading them from the descriptor's `limits` field in registry.ts — confirm this is the same convention complexity.ts itself uses, or wire req-level limits through so the registry's declared limits aren't just documentation.
• scanComplexityDelta fetches files sequentially in a for-loop (review-enrichment/src/analyzers/complexity-delta.ts) rather than in parallel — bounded by MAX_FILES=20 so not a blocker, but worth a comment on why sequential was chosen given the github-light timeout budget.
• The per-function doc comment in complexity-delta.ts references issue Aggregate deterministic structural-improvement sub-score #4742 for a 'sibling aggregator' that isn't part of this diff — confirm that dependency actually exists/is scheduled, since a dangling forward reference is easy to let rot.
• The three-plus paragraph header comments in complexity-delta.ts and complexity.ts are very long for a repo convention — consider trimming to the parts a future reader actually needs (the requires/cost split rationale) and moving the rest to the linked issue.
• Consider exposing `MAX_FILES`/`MAX_FINDINGS` as parameters sourced from the registry descriptor's `limits` so config-as-code overlays (.gittensory.yml) can actually tune this analyzer, matching the pattern presumably used elsewhere.
• PR author also opened the linked issue — Link an issue that was opened by a different contributor, or provide a rationale for why this self-authored issue represents genuine discovery work.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#4740
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 48 registered-repo PR(s), 40 merged, 275 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 48 PR(s), 275 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 48 PR(s), 275 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.

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.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop			—
/	mobile			—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

_{🟩 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