IceEmblem/IEManageSystem

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 9.8 / 10 · rule-coverage 100% · ceiling Verified

4 duplicated block group(s) detected.

✓ On the Gold path — maintain.

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

What it measures: Whether volatile projects sit underneath others that depend on them (so their churn ripples upward), and whether project dependencies form cycles. A widely-depended-on but stable shared/kernel project is healthy, not penalised.

Method: Dependency cycles via elementary-DFS over real .csproj references, plus Martin instability (afferent/efferent) per project. Exhaustive over the reference graph, deterministic.

Coverage: Exhaustive · type-level: afferent/efferent coupling + cycles computed over every production type — the population is all types, not a name convention.

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

15 projects, 0 dependency cycle(s), 0 unstable depended-on project(s).

What to do

1. Resolve the 4 Off the main sequence finding(s) in Coupling. — One of this dimension's main actionable groups (4 warning-level).
2. Stand up a CI pipeline, then gate Coupling in it to reach Verified (currently Documented). — This repository has no CI pipeline, so there is nothing to add a gate to yet — the pipeline comes first. Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.

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

What it measures: Whether a class's methods are focused on a single responsibility.

Method: LCOM4 cohesion per production class with at least two methods: connected components of methods sharing state or calls, computed syntactically. Deterministic, not a proxy.

Coverage: Exhaustive · type-level: LCOM4 cohesion computed over every production class — the population is all types, not a name convention.

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

0 of 36 classes have LCOM4 above 3.

✓ On the Gold path — maintain.

Detailed fixes: d6_recommendation.md.

What it measures: Whether the test suite has a healthy mix of unit / integration / end-to-end tests.

Method: Test projects classified (Unit/Integration/BDD/E2E) from compiled metadata; test methods counted exhaustively across projects with placement-agnostic disk fallback. Deterministic.

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

34 test methods: 34 unit, 0 integration, 0 BDD, 0 e2e.

✓ On the Gold path — maintain.

Detailed fixes: d9_recommendation.md.

What it measures: Whether the tests truly assert behaviour rather than just running the code.

Method: Per-test assertions, skips, and mock references analyzed via Roslyn; structured skip-reason tags (BUG:/ENV:) separate documented deferrals from debt. Deterministic.

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

0 skipped, 0 zero-assertion, 1 mock references across 34 tests.

✓ On the Gold path — maintain.

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

What it measures: Whether dependencies are current, secure, and not bloated.

Method: Manifest scan via dotnet list package across all projects; worst-signal-per-package deduction (saturating for vulnerabilities, capped-linear for deprecation/outdated) per KLoC. Exhaustive, deterministic.

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

37 outdated, 2 vulnerable, 19 deprecated packages.

What to do

1. Resolve the 19 Deprecated finding(s) in Dependency Hygiene. — One of this dimension's main actionable groups (19 warning-level).
2. Resolve the 2 Vulnerable finding(s) in Dependency Hygiene. — One of this dimension's main actionable groups (2 issue-level).
3. Stand up a CI pipeline, then gate Dependency Hygiene in it to reach Verified (currently Documented). — This repository has no CI pipeline, so there is nothing to add a gate to yet — the pipeline comes first. Hardens enforcement from Documented toward Verified — provenance only; does not change the score.

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

1 secret(s) detected.

What to do

1. Resolve the 1 Leaked secret finding(s) in Secret Scanning — start with AccountConfigure.cs. — One of this dimension's main actionable groups (1 issue-level).
2. Stand up a CI pipeline, then gate Secret Scanning in it to reach Verified (currently Documented). — This repository has no CI pipeline, so there is nothing to add a gate to yet — the pipeline comes first. Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.

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

What it measures: Whether the licenses of third-party packages are compatible with your policy.

Method: Third-party package licenses resolved from declared package metadata and checked against the configured policy (allow/deny/copyleft). Deterministic; clean = no incompatible license found at metadata depth.

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

0 of 44 packages use a banned license.

✓ On the Gold path — maintain.

Detailed fixes: d14_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: Acknowledged debt left in the code — TODOs, dead code, suppressed warnings.

Method: Roslyn syntactic debt markers (suppressions/TODO/FIXME/HACK/empty-catch/commented-code/Obsolete) plus SymbolFinder dead-code analysis; weighted-debt-per-KLoC density deducted 2.0x per unit. Deterministic, exhaustive.

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

5 deducted debt markers + 0 dead symbols across 10522 LoC (0.2/KLoC) → score 9.6.

✓ On the Gold path — maintain.

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

What it measures: Whether the solution is laid out in a sensible, conventional structure.

Method: Solution structure: project count, decomposition, shell-project detection, build success (confirmed failures cap the score); traced to actual .sln files and binaries. Deterministic.

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

15 projects, 363 source files, 12216 hand-written lines of code (10522 production / 1694 test), 73 inter-project edges.

✓ On the Gold path — maintain.

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

IEManageSystem 的 README 是一个不错的项目介绍文档，涵盖了 CMS 的功能描述、相对于其他 CMS 的优点、源码与功能、运行步骤、演示地址、截图以及技术使用信息。但文档质量受限于其单一的 README（仅 231 字），且架构/设计文件和 XML 文档覆盖严重不足：Architecture/Docs markdown 文件有 10 个，XML 文档覆盖率不到 5%（IEManageSystem.EntityFrameworkCore 和 IEManageSystem.Common 零覆盖率）。

What to do

1. Resolve the 1 文档内容高度依赖截图和链接（如 'http 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 architecture decisions are recorded well (context, decision, consequences).

Method: Per-ADR judgment by language model at low temperature with two-pass stability; confidence is share of ADRs evaluated; enforcement-field presence detected deterministically. Advisory.

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

No architecture decision records were found.

What to do

1. Resolve the 1 No ADRs found finding(s) in ADR Quality. — One of this dimension's main actionable groups (1 recommendation-level).

Detailed fixes: d20_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

1 naming inconsistencies across 200 sampled symbols.

✓ On the Gold path — maintain.

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

What it measures: Whether each project is a focused, coherent unit rather than an oversized grab-bag.

Method: Project size overshoot penalties (LoC / public-type count / namespace count, 2-of-3 flag) weighted by log magnitude. Exhaustive across projects, deterministic, LLM-independent.

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

1 of 15 projects flagged as possibly oversized/incoherent.

What to do

1. Resolve the 1 Split IEManageSystem.Application finding(s) in Project Cohesion. — One of this dimension's main actionable groups (1 recommendation-level).

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

What it measures: How far you must trace to follow a call — low indirection and co-located slices read easier.

Method: Call indirection (interface hops, cross-namespace calls, slice-locality scaled) over a sampled set of method invocations, size-aware baseline. Sampled; confidence discounted by symbol-resolution gaps.

Coverage: Slice locality from the first namespace segments, SAMPLED (≤400 methods) — not exhaustive.

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

90 % of calls cross a namespace and 20 % go through an interface, but 91 % of collaborators are co-located — so following a call takes several hops. Baseline: medium — clean/modular boundaries expected.

What to do

1. Improve Navigability — currently 7.2/10. — 90 % of calls cross a namespace and 20 % go through an interface, but 91 % of collaborators are co-located — so following a call takes several hops. Baseline: medium — clean/modular boundaries expected.

Detailed fixes: d27_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. Improve Secrets (history) — currently 8.0/10. — 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.

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

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

✓ On the Gold path — maintain.

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

What it measures: Whether any dependencies have known published vulnerabilities (CVEs), direct or transitive.

Method: NuGet CVE scan via dotnet list package --vulnerable including transitive; severity tally (Critical/High/Medium/Low) to 0-10 tight normalizer. Exhaustive, deterministic; degrades when absent.

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

20 vulnerable package(s): 6 critical, 7 high, 7 medium, 0 low.

What to do

1. Resolve the 7 High CVE finding(s) in Dependency Vulnerabilities. — One of this dimension's main actionable groups (7 issue-level).
2. Resolve the 7 Medium CVE finding(s) in Dependency Vulnerabilities. — One of this dimension's main actionable groups (7 warning-level).
3. Resolve the 6 Critical CVE finding(s) in Dependency Vulnerabilities. — One of this dimension's main actionable groups (6 issue-level).

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

41 of 41 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is src/UtilityAction/Web/FileContentType.cs.

What to do

1. Resolve the 1 Dormant codebase finding(s) in Knowledge Freshness. — One of this dimension's main actionable groups (1 recommendation-level).
2. Resolve the 1 Largest orphaned file finding(s) in Knowledge Freshness — start with FileContentType.cs. — 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: ExecLogicService.cs↔ActuatorFactory.cs 70%; PageManageAppService.cs↔PageDataManager.cs 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 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

94 finding(s): 19 critical, 45 high, 21 medium, 9 low.

What to do

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

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

Method: IL instruction count per method, read from the BUILT first-party assemblies via Mono.Cecil (the target is compiled on a deep run); scored on the fraction of methods whose emitted IL body exceeds the size threshold. Sees compiler-generated bloat source can't; not-applicable when the target fails to build. Deterministic.

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

3 of 614 first-party methods have an oversized IL body.

✓ On the Gold path — maintain.

Detailed fixes: d39_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.

• An image with no alt (and no aria-label/aria-labelledby) is unreadable to assistive tech. Add alt — alt="" if it's purely decorative. — Preview.jsx:6

What to do

• Add a text alternative — alt on images (alt="" for purely decorative ones), a title or aria-label on meaningful svg, an aria-label or inner fallback content on canvas, and a captions <track> on video.

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.

• This UI-library field component has no label / aria-label / aria-labelledby / id / name — and neither does anything it renders — so it likely renders an unlabelled control. Name it whichever way this library supports: a label prop, an aria-label, or an id on the rendered control with a <label htmlFor> pointing at it. For a group of controls, name the group itself (aria-label, or a fieldset with a legend) — labelling each item leaves the set unnamed. (×11) — Component.jsx:21, DataConfig.jsx:35, DataConfig.jsx:132, …
• This UI-library field component is named only by a placeholder — a placeholder is not a label (it vanishes as soon as the user types, and many assistive technologies ignore it). Give it a real name whichever way this library supports: a label prop, an aria-label, or an id on the rendered control with a <label htmlFor> pointing at it. For a group of controls, name the group itself (aria-label, or a fieldset with a legend) — labelling each item leaves the set unnamed. (×3) — PageData.jsx:139, PageData.jsx:153, BtnLists.jsx:39

What to do

• Give every control a programmatic label (a <label for> / wrapping <label> / aria-label) and every button text — a placeholder is not a label.

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.

• No <main> (or role="main") means no "skip to content" target and a weaker landmark map. Wrap the primary content in <main>. — index.html:2
• An iframe with no title (or an empty one) is announced only as "frame". Add a non-empty title describing its content, or an aria-label. — WebView.tsx:13

What to do

• Declare <html lang>, a document <title> and a <main> landmark, keep headings in order, leave zoom enabled, title iframes and drop meta-refresh.

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.

• An <a href="#"> (or javascript:) with a click handler is a button dressed as a link — it announces the wrong role and stops working without JS. Use a <button> for an action. — Component.jsx:13
• A click handler on a plain element isn't keyboard-operable. Use a <button>, or add role + tabindex="0" + a key handler. (×3) — Component.jsx:17, PictureBox.jsx:81, PictureBox.jsx:82

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.

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.

• `.picturemanage .custom-file-label::after` sets color: #fff on background-color: #28a745 — 3.1:1, below the 4.5:1 WCAG AA minimum for normal text. Darken or lighten one of them. — index.css:22
• `.default-text` sets color: #343a40 on background-color: #343a40 — 1.0:1, below the 4.5:1 WCAG AA minimum for normal text. Darken or lighten one of them. — RichTextEditor.css:11
• `.IERankingList-item-icon` sets color: #fff on background-color: #db3964 — 4.4:1, below the 4.5:1 WCAG AA minimum for normal text. Darken or lighten one of them. — IERankingList.css:17

What to do

• Keep a visible focus style (don't remove the outline without a replacement), guard animation with prefers-reduced-motion, and raise low-contrast colour pairs to at least 4.5:1.

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 · Architecture — Whether any singleton service captures a scoped/transient dependency — a silent lifetime/threading bug.

Method: Roslyn scan: DI registrations parsed from AddSingleton/Scoped/Transient; each singleton checked for captured shorter-lifetime dependencies. Exhaustive, deterministic.

Other · Architecture — How the codebase splits by code ROLE — domain, application, infrastructure, test, generated. The significance map behind the knowledge/coupling weighting, and a DDD signal in its own right: a thin domain core under fat infrastructure is the anemic-domain smell, quantified.

Method: Roslyn line-count by code ROLE: every source file classified Domain/Application/Infrastructure/Test/Generated by namespace + path convention (the shared CodeRoleClassifier), then significant lines summed per role. Deterministic; the advisory score is the business-logic (domain+application) share of production code.

Coverage: Population: ALL source files, each bucketed into ONE of five roles (Domain/Application/Infrastructure/Test/Generated) by namespace + path convention — a file whose layer isn't named in the convention falls to Application (the neutral default), and the split is line-count, not semantic depth or business value.

Other · Architecture — Whether the project-reference graph is acyclic (cycles block independent build/deploy and signal eroding boundaries).

Method: Project reference cycles via elementary-DFS over real .csproj references, using the engine shared with D5/D7; cyclic versus acyclic. Exhaustive, deterministic.

Other · Architecture — Whether the codebase has a recognisable, scale-appropriate structure (a named architectural style, or modular enough for its size) rather than being an ad-hoc ball of mud.

Method: Roslyn plus csproj analysis: architecture style detection (DDD, clean, vertical-slice, CQRS) and structure fitness for repo size. Deterministic.

Other · Architecture — Whether interfaces stay focused rather than fat — the Interface-Segregation principle (SOLID 'I').

Method: Roslyn scan: public interface member counts; fat-interface threshold (over 15 members) flagged per type. Deterministic, type-level.

Other · Architecture — Whether production projects stay free of references to test projects — tests may depend on production, never the reverse.

Method: Csproj graph: each production project checked for references to test projects (identified by test-framework presence, not name). Zero violations is clean. Deterministic.

Other · Security — Whether sensitive data is encrypted at rest and in transit and keys are vaulted.

Method: Roslyn plus filesystem scan: encryption presence (EF ColumnEncryption, key-vault references, HTTPS enforcement) and key-derivation KDF detection. Deterministic.

• No data-protection or encryption usage (ASP.NET Data Protection, AES, column encryption, PBKDF2) was found — sensitive data at rest may be unprotected. If TDE/KMS/vault is delegated to infrastructure, ignore.

What to do

• Encrypt sensitive data at rest (ASP.NET Core Data Protection / column encryption) and manage keys in a vault. Skip if delegated to infra (Postgres TDE, KMS, etc.).
• Enforce HTTPS (UseHttpsRedirection / RequireHttpsMetadata) so data in transit is always encrypted.

Other · Security — Whether access is authorized by default — a framework authorization attribute/decorator or policy, or imperative guard methods (throw-on-violation) called from handlers.

Method: Roslyn scan: [Authorize] usage and authorization policies, plus imperative throw-on-violation guard methods detected via syntax. Deterministic.

• No [Authorize]/policies and no imperative guard methods (throw-on-violation) were found — endpoints may be unprotected.

What to do

• Protect endpoints by default-deny: [Authorize] + role/policy authorization, or imperative guard methods (throw-on-violation) called from every handler.

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.

Other · Code Health — Unreviewed-generation residue: shipped members still throwing NotImplementedException, and placeholder string literals left in non-test, non-generated code. Scored as a quality signature, never as a claim about authorship.

Method: Roslyn syntax scan: NotImplementedException throws and placeholder string literals in non-test, non-generated shipped code. Deterministic, code-shape signature.

Other · Code Health — Unfinished work detected by code SHAPE, not keywords: members that only throw a "not implemented" exception, methods that take inputs and return a constant, async methods that never await, dead `if (false)` / `#if false` branches, and skeleton types most of whose members are holes. A real, objective slice of technical debt.

Method: Roslyn syntax scan: incompleteness by code shape (constant-returning methods, async-never-await, #if false branches, skeleton types), not keyword-gated. Deterministic, code-shape heuristic.

• `GetRoles` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — RoleManageAppService.cs:42
• `DeleteRole` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — RoleManageAppService.cs:67
• `UpdateRole` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — RoleManageAppService.cs:74
• `AddPermission` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — RoleManageAppService.cs:98
• `RemovePermission` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — RoleManageAppService.cs:114
• `GetUserInfo` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — UserAppService.cs:108
• `SetSafetyProblem` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — UserAppService.cs:128
• A line of code has been commented out rather than removed — dead weight that rots and confuses. Delete it (version control remembers). (×3) — IMenuManageAppService.cs:13, IMenuManageAppService.cs:15, ActuatorFactory.cs:56

What to do

• Clear the softer debt: remove commented-out code and dead branches, re-enable or delete skipped tests, and replace blanket warning suppressions with targeted ones.

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 build/run (quick start) section to the root README — the first thing a newcomer needs.
• 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 15 of 15 project(s) that lack one — worth up to 2 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.
• 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.

• README claims Web端和安卓App端，但证据显示只有WebApp存在（src/IEManageSystem.Web.ClientApp）
• 声称组件具有可执行逻辑并由服务器动态编译，但证据中没有体现任何动态编译或可执行组件的代码
• README claims 项目属于开发阶段且有bug，但证据显示该项目是完整的IEManageSystem.Web.ClientApp分支（src/IEManageSystem.Web）

What to do

• Reconcile the README with reality: README claims Web端和安卓App端，但证据显示只有WebApp存在（src/IEManageSystem.Web.ClientApp）; 声称组件具有可执行逻辑并由服务器动态编译，但证据中没有体现任何动态编译或可执行组件的代码; README claims 项目属于开发阶段且有bug，但证据显示该项目是完整的IEManageSystem.Web.ClientApp分支（src/IEManageSystem.Web）.

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.

• No CI workflow found (.github/workflows, azure-pipelines.yml, .gitlab-ci.yml, …) — changes aren't gated by an automated build/test.

What to do

• Add a CI workflow that builds and runs the test suite on every push/PR.

Readiness · Readiness — For a library: a deliberate (small) public API surface and explicit semantic versioning so consumers can depend on it safely.

Method: Roslyn scan: public API surface area and semantic-versioning markers (SemVer attributes, changelog entries) for libraries. Exhaustive, deterministic.

• 334/334 types (100%) are public. For a library, every public type is a stability contract — make internal-by-default and expose only the intended API.

What to do

• Make types internal by default; expose only the deliberate public API so internals can change without breaking consumers.

Readiness · Readiness — Whether the code is diagnosable in production — structured logging, tracing/metrics, health checks.

Method: Filesystem/Roslyn scan: structured-logging frameworks (Serilog, NLog), OpenTelemetry, and health-check endpoint patterns. Exhaustive, deterministic.

• Only 2/7 service-like projects use logging (pure contract/DTO projects are excluded — they have nothing to log).

What to do

• Extend structured logging to the remaining service-like projects so the whole executable surface is diagnosable in production.
• Consider OpenTelemetry tracing/metrics and a health-check endpoint for operability.

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 csharp pack (it analyses VB.NET too), or a security analyzer package (or `semgrep --config=auto`, which runs on any language) as a CI step.

What to do

• Add a SAST step to CI running what this repository's stack ships: CodeQL's csharp pack (it analyses VB.NET too), or a security analyzer package — or `semgrep --config=auto`, which runs on any language — 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.

What to do

• Add an approval/environment gate (required reviewers / protection rules) before production promotion.

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.

• No CHANGELOG/HISTORY/RELEASES file — what shipped when isn't easy to reconstruct for support or audit. (Versioning/tagging makes releases traceable, but a changelog records the what.)

What to do

• Keep a changelog (e.g. Keep-a-Changelog) recording what shipped in each release.

Readiness · Readiness — Whether EF Core schema changes go through versioned migrations rather than the un-evolvable EnsureCreated().

Method: Roslyn scan: EF Core DbContext for a versioned migrations directory versus bare EnsureCreated usage. Exhaustive per project, deterministic.

• `EnsureCreated()` builds the schema once and can't evolve it — there's no upgrade path for an existing production database, and it bypasses the migrations history. Adopt a versioned schema-migration mechanism (with EF Core: `dotnet ef migrations add` + `Migrate()` on startup) so schema changes are versioned and applied safely. — InitSiteController.cs:113

What to do

• Replace EnsureCreated() with a versioned schema-migration mechanism (EF Core migrations) so the production schema can evolve safely and reproducibly.

Readiness · Performance — Whether the library protects its performance with benchmarks — a benchmark suite, allocation/memory measurement, and (ideally) a CI gate. Presence is credited as a bonus, never a deduction.

Method: Repo + source scan: BenchmarkDotNet referenced (csproj/source), [Benchmark]/[MemoryDiagnoser] attribute counts, and a benchmark step in CI — scored as a bonus ladder (absence is neutral, never a deduction). Deterministic, presence detection.

• No benchmark suite was found. For a performance-sensitive library, a benchmark guards against silent regressions — but it's a bonus here, not a deduction.

What to do

• Add a benchmarking harness for the hot paths and run it in CI to catch regressions (for .NET, a BenchmarkDotNet project with [MemoryDiagnoser] to track allocations).

Readiness · Performance — Whether the code is written to minimise allocations so it doesn't pressure its host's memory manager — buffer/slice views over copies, object pooling, stack or value-type allocation, and buffer writers. Reward-only: credited where present, never penalised where a simpler style is fine.

Method: Production-source scan: density (per 1k LoC) of allocation-aware APIs — Span/Memory, ArrayPool/ObjectPool, stackalloc, ValueTask, value-type structs, IBufferWriter, string.Create, SkipLocalsInit. Reward-only. Deterministic, syntax/text detection.

• No Span/Memory, pooling (ArrayPool/ObjectPool), stackalloc, ValueTask or buffer-writer usage was found. If this library sits on a hot path, these reduce the GC pressure it puts on its host — a bonus, not a requirement.

What to do

• On hot paths, prefer Span<T>/ReadOnlySpan<T>, ArrayPool<T>, stackalloc and ValueTask to cut allocations a consumer would otherwise inherit.

Readiness · Performance — Whether asynchronous code keeps its host responsive — a library awaits with ConfigureAwait(false) (so it never captures and stalls the host's context) and avoids sync-over-async blocking (.Wait()/.GetAwaiter().GetResult()) that wastes threads and risks deadlock.

Method: Production-source scan: sync-over-async blocking (.Wait()/.GetAwaiter().GetResult()) counted everywhere, and — for a library with ≥5 awaits — the share of awaits using ConfigureAwait(false). Deterministic, syntax/text detection.

• Only 0/16 awaits use ConfigureAwait(false). A library that captures the caller's context can stall or deadlock its host — the classic way a dependency drags an app down.

What to do

• In library code, append .ConfigureAwait(false) to every await (or set <ConfigureAwait>false</ConfigureAwait> / use the analyzer CA2007) so the library never captures the host's context.

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.

• 116 typed · 471 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.

• src/IEManageSystem.Web/ClientApp/src/Templates/RNIETemplateComponents/index.js:30 · src/IEManageSystem.Web/ClientApp/src/Templates/WebIETemplateComponents/index.js:42 — index.js:30
• src/IEManageSystem.Web/ClientApp/src/RNApp/RNCommon/Theme/NativeBaseTheme/variables/commonColor.js:19 · src/IEManageSystem.Web/ClientApp/src/RNApp/RNCommon/Theme/NativeBaseTheme/variables/material.js:14 — commonColor.js:19
• src/IEManageSystem.Web/ClientApp/src/Templates/IETemplateComponents/IELine/Setting.ts:33 · src/IEManageSystem.Web/ClientApp/src/Templates/IETemplateComponents/IELine/Setting.ts:92 — Setting.ts:33
• src/IEManageSystem.Web/ClientApp/src/Common/ice-common/Theme/index.ts:131 · src/IEManageSystem.Web/ClientApp/src/Common/ice-common/Theme/index.ts:151 · src/IEManageSystem.Web/ClientApp/src/Common/ice-common/Theme/index.ts:171 — index.ts:131
• src/IEManageSystem.Web/ClientApp/src/RNApp/RNCommon/Theme/NativeBaseTheme/variables/commonColor.js:293 · src/IEManageSystem.Web/ClientApp/src/RNApp/RNCommon/Theme/NativeBaseTheme/variables/material.js:286 · src/IEManageSystem.Web/ClientApp/src/RNApp/RNCommon/Theme/NativeBaseTheme/variables/platform.js:316 — commonColor.js:293
• src/IEManageSystem.Web/ClientApp/src/Common/BaseCMSManage/Components/BaseComponents/InteractiveComponent/InteractivConfigFeature.js:10 · src/IEManageSystem.Web/ClientApp/src/Common/BaseCMSManage/Components/BaseComponents/InteractiveComponent/InteractivConfigFeature.js:36 — InteractivConfigFeature.js:10
• src/IEManageSystem.Web/ClientApp/src/RNApp/RNCMS/Component/ComponentContainerBoxs/ComponentContainerBoxShow.js:7 · src/IEManageSystem.Web/ClientApp/src/WebApp/Adapters/RNComponentContainerBoxShow.js:7 — ComponentContainerBoxShow.js:7
• src/IEManageSystem.Web/ClientApp/src/RNApp/RNCommon/Theme/NativeBaseTheme/components/Button.js:14 · src/IEManageSystem.Web/ClientApp/src/RNApp/RNCommon/Theme/NativeBaseTheme/components/Button.js:36 · src/IEManageSystem.Web/ClientApp/src/RNApp/RNCommon/Theme/NativeBaseTheme/components/Button.js:58 — Button.js:14

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.

• src/IEManageSystem.Web/ClientApp/index.js:2 reaches into another package with a relative path (./src/RNApp/RNStart/index) — import the package by name instead. — index.js:2
• src/IEManageSystem.Web/ClientApp/src/RNApp/RNStart/src/Module.js:9 reaches into another package with a relative path (../../ModuleList) — import the package by name instead. — Module.js:9
• src/IEManageSystem.Web/ClientApp/src/WebApp/Start/src/Module.js:4 reaches into another package with a relative path (../../ModuleList) — import the package by name instead. — Module.js:4
• src/IEManageSystem.Web/ClientApp/src/WebApp/index.js:1 reaches into another package with a relative path (./Start/src/index.js) — import the package by name instead. — index.js:1

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) — Header.js:8, index.js:20, webpack.config.js:91, …

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) — PageData.jsx, ListItem.js, Header.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 eslint and `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.

• 73 file(s) (~3251 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. — BaseCMSManage
• 8 file(s) (~236 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. — BaseLayout
• 9 file(s) (~152 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. — BasePerson
• Unreachable from the 18 application, 6 tooling and 11 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 (18 application, 6 tooling, 11 test roots considered) (×4) — fileTransform.js, pnpTs.js, cssTransform.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.

• Imported but not declared in any reachable package.json — installs work only by hoisting accident. (×3) — EditFrame.test.js:2, EditFrame.test.js:1, ContentPagePermissionCollection.ts:1
• Declared in src/IEManageSystem.Web/ClientApp/src/RNApp/RNStart/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.

• src/IEManageSystem.Web/ClientApp/src/Common/ice-common/IEStore.ts → src/IEManageSystem.Web/ClientApp/src/Common/ice-common/index.js → src/IEManageSystem.Web/ClientApp/src/Common/ice-common/IEStore.ts — IEStore.ts

What to do

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

Other · Security — Transport security, security headers, secure cookies, input validation, middleware order and crypto hygiene (presence, not runtime).

Method: Roslyn plus filesystem scan: HSTS/security headers, secure cookies, input validation, middleware order, weak crypto (MD5/SHA1/DES); HTTPS-metadata context-aware. Deterministic.

• MD5/SHA1 is constructed here, and both are collision-broken. If this digest protects anything — a signature, an integrity or tamper check, a credential, or any value an attacker can influence — that is a real weakness: use SHA-256+ for content integrity, or a KDF (PBKDF2/Argon2/BCrypt) for password storage. If it only derives a non-security identifier (a cache key, a file or mutex name), collision resistance carries no security consequence here; make that intent explicit instead — a non-cryptographic hash such as `System.IO.Hashing.XxHash64`/`Crc32` says it in code — since the algorithm alone cannot distinguish the two uses. — Encrypt.cs:12
• No Content-Security-Policy / X-Frame-Options / X-Content-Type-Options configuration found — defense in depth, even when a reverse proxy could set them. (−2.0 on this card.)
• No UseHttpsRedirection/UseHsts and no reverse-proxy signal — transport security is unverified at the app layer. (−2.0 on this card.)

What to do

• Review each MD5/SHA1 use by what it protects: replace it with SHA-256+ (or a KDF for passwords) where the digest is security-relevant, and switch it to a non-cryptographic hash (`System.IO.Hashing.XxHash64`/`Crc32`) where it only derives an identifier such as a cache key or a mutex name.
• Add security response headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options) — defense in depth, even when a reverse proxy could set them.
• Enforce HTTPS at the app layer (UseHttpsRedirection / UseHsts) — only skip this if a reverse proxy demonstrably terminates TLS.

Other · Code Health — Whether the code avoids sync-over-async (deadlock-prone blocking on tasks) and async void.

Method: Roslyn syntax scan: async methods scanned for .Wait()/.GetAwaiter().GetResult() and async-void outside event handlers. Deterministic, hard fact per invocation.

Other · Code Health — Whether async methods accept a CancellationToken so work can be cancelled (adoption curve).

Method: Roslyn scan: every async method (excluding framework-fixed overrides/Blazor handlers) checked for CancellationToken parameter presence. Deterministic, adoption percentage.

• Only 0/8 async methods accept a CancellationToken, so in-flight work can't be stopped early when the caller gives up — whatever ends it in your host (shutdown signal, timeout, abandoned request, user cancel). Thread a token through the call chain and honour it at each await and loop; where a method genuinely cannot be interrupted, omitting it is a deliberate choice — judge against your hosting model.
• No CancellationToken parameter — this work can't be stopped early once started. (×8) — AccountController.cs:61, AccountController.cs:81, LoginManager.cs:36, …

What to do

• Thread a CancellationToken through async methods so work stops promptly on cancellation.

Other · Code Health — Whether exceptions are handled rather than silently swallowed or rethrown with lost stack traces.

Method: Roslyn syntax scan: every catch clause counted; empty catches and bare rethrows flagged. Population is all catch clauses, not estimated. Deterministic, hard fact.

• An empty catch block silently discards the error — failures vanish with no log and no rethrow. Log it, handle it, or don't catch it. (×2) — InitSiteController.cs:77, WebModelBinding.cs:51
• `throw ex;` resets the exception's stack trace to this line, hiding where it really came from. Use a bare `throw;` to preserve the original stack. — ActuatorFactory.cs:170

What to do

• Swallowed exception (empty catch)

Other · Code Health — Whether log calls use message templates (queryable) rather than interpolated strings.

Method: Roslyn syntax scan: every log call-site counted; interpolated-string first-argument violations flagged. Population is all log calls, not estimated. Deterministic.

Other · Code Health — Whether nullable reference types are enabled and not undermined by heavy `!` suppression.

Method: Roslyn compiler-options scan: NullableContextOptions per project; null-forgiving (!) suppression density per 1k syntax nodes. Deterministic, adoption plus suppression penalty.

• 0/10 projects enable <Nullable>enable</Nullable>. NRTs catch a whole class of null-deref bugs at compile time.

What to do

• Enable <Nullable>enable</Nullable> across all projects and resolve warnings rather than suppressing with `!`.