@hublo/sentinel 1.5.0-alpha.2 → 1.5.0-alpha.21

package/docs/static-analysis-study.md

@@ -157,6 +157,29 @@ to centrality, ranking all 12 372 files twice:
 **Rank correlation DC against LOC: 0.388.** Far from 1, so the two rankings designate different
 files and centrality carries information size does not. The criticism does not bite here.
 
+### What centrality is evidence FOR, and where that evidence stops
+
+Two measurements above say what centrality is NOT: not file size in disguise, not a proxy for change
+frequency. Neither says what it is good for, and the literature does.
+
+| source                                                                                           | what it establishes                                                                                                                                                                                                                                                     |
+| ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Zimmermann and Nagappan, ICSE 2008, on Windows Server 2003                                       | models built from network measures reach a recall **10 percentage points** higher than models built from complexity metrics, and network measures identified **60%** of the binaries the developers themselves called critical, **twice** what complexity metrics found |
+| Tosun, Turhan and Bener, PROMISE 2009, five systems (three small embedded, two Eclipse versions) | network measures are important indicators of defective modules for large and complex systems, **and have no significant effect on small-scale projects**                                                                                                                |
+
+⛔ The second one is a boundary on everything this role can claim, so it is written here rather than
+left implicit. Centrality's predictive value is demonstrated on LARGE systems. A module of forty
+files gets a `DC` figure that means exactly what it says about its graph and nothing at all about
+where its defects are. `host-admin` at 5 880 files sits on one side of that line; most of
+`libs/nest` sits on the other. It becomes the `caveat` of the centrality help entry, unchanged.
+
+And it settles what the number is FOR, which is a question the role has to answer before it prints
+anything. Test impact analysis selects: given this diff, which tests can catch a defect in it.
+Centrality is a property of the code and knows nothing about a diff, so it cannot select. What it can
+do is ORDER: which tests to run first, and where strengthening tests pays. The two compose, and the
+composition has a sharp consequence worth stating: a highly central file is precisely the one where
+impact-based selection saves nothing, because changing it reaches almost everything.
+
 ### Centrality is not a proxy for change frequency
 
 The hypothesis was that a central file, being heavily used, is frequently changed, which would
@@ -762,15 +785,406 @@ The two are complementary as long as every figure carries its unit.
 | Merge and precedence                    | **settled.** The project wins; declared facts are added, `overrides` replaces and every path it sets is printed as `(module)`. A file matched by two declared journeys is still to be verified in the report                                                                                                                                                                                                                                                                         |
 | A stricter threshold on a declared path | the lint override analogy invites it, and the recommendation is to refuse it in a first version: a per-path threshold makes two files with the same measurement get different verdicts, and the first thing this role has to be able to say is that a number means the same thing everywhere                                                                                                                                                                                         |
 | Dead code inside a library              | `libs/front/components` reports **30.3%** of its lines dead, and no internal declaration fixes it: the package declares no `main`, `module`, `types`, `exports` or `files`, it has no barrel, and consumers import deep paths through a tsconfig alias (`@front/components/data-display/badge/Badge`). Reachability inside a library is therefore meaningless at module scope. Either the pass runs at workspace scope for libraries, or the metric is marked not applicable to them |
-| Halstead and MI on nest                 | escomplex parses **67.4%** of `network`, and a module-level `MI` computed over two thirds of its files is not that module's `MI`. Three ways out: publish it with its coverage beside it, find whether one node type explains the 708 internal failures, or recompute Halstead on `oxc-parser`, which is already a direct dependency and parses everything the lint role parses                                                                                                      |
+| Halstead and MI on nest                 | **settled: both leave, and cognitive complexity takes their place.** The third way out was written and measured; see section 9                                                                                                                                                                                                                                                                                                                                                       |
+
+---
+
+## 9. The two scores: what is settled, what is still ours to choose
+
+Section 8 left `MI` open on escomplex's coverage. Working that question through replaced it. This
+section records the model that came out, every step of it measured, and marks plainly what is
+still a decision rather than a finding.
+
+### 9.1 Halstead and `MI` leave, and the reason is not the code
+
+The third way out of section 8, recomputing Halstead on `oxc-parser`, was written and run against
+escomplex over the 443 files of `apps/front/console` that it reads:
+
+| count                  | identical |
+| ---------------------- | --------: |
+| n1, distinct operators |     93.9% |
+| N1, total operators    |     82.8% |
+| n2, distinct operands  |     74.3% |
+| N2, total operands     |     26.0% |
+| logical SLOC           |     42.7% |
+
+Five causes were found by measuring and closed, each worth tens of points: `ignoreKeys`, walking
+INTO `TS*` nodes rather than skipping their subtree, suppressing annotations only inside a
+parameter list, one statement per function or class scope, and the implicit return of an
+expression-bodied arrow. The rest is a long tail of single-rule differences in both directions.
+
+⛔ **The gap cannot be closed, because the target is not defined.**
+
+- **IBM publishes the seven formulas and not the classification.** Its documentation says the
+  measures come directly from the operators and operands, and defines neither.
+- **The ecosystem is one implementation.** `code-complexity`, `complexity-report` and `plato` all
+  depend on escomplex; `typhonjs-escomplex` is a fork of it.
+- **The one independent implementation disagrees.** `ts-complex`, built on the TypeScript
+  compiler, agrees with escomplex on operands 8 fixtures out of 12 and on operators **0 out of
+  12**: it counts neither `[]` nor `{}` nor `()`. On `return [1, 2, 3]` one says `n1 = 4`, the
+  other `n1 = 1`. On the 8 agreeing fixtures ours matches both.
+- ⚠️ **And `ts-complex` cannot be the reference anyway.** It reads 3 683 files here with zero
+  failures, which looks better than escomplex until the instrument is checked: it runs on
+  TypeScript 2.9.2 and, on `satisfies`, `??` and `?.`, raises nothing and returns operand lists
+  containing an empty string. Silent degradation is worse than a throw.
+- **A check needing no tool was tried and failed.** Halstead's length equation does not
+  discriminate: swapping operators and operands entirely leaves the correlation at 0.9222,
+  unchanged, because it is symmetric in `n1` and `n2`. It detects only total randomness.
+
+`src/roles/static-analysis/complexity/halstead.ts` stays in the tree, imported by nothing, with
+its figures in its header: the record of a path walked far enough to know why it is not taken.
+
+### 9.2 Cognitive complexity takes the place
+
+|                            | Halstead and `MI`                    | cognitive complexity              |
+| -------------------------- | ------------------------------------ | --------------------------------- |
+| specification of the count | **none** published for TypeScript    | Campbell 2018, an exact algorithm |
+| reference implementation   | two, disagreeing 12 times out of 12  | `eslint-plugin-sonarjs`, by Sonar |
+| reads our code             | 61% to 99% depending on the family   | **100%**, 0 fatal errors          |
+| published threshold        | none transferable on the 0-171 scale | **15**, rule S3776                |
+| how ours gets validated    | hand-counted fixtures only           | function by function, as `CC` was |
+
+Sonar's own implementation, run over four modules with its threshold lowered to 0 so that every
+function is reported: sentinel 752 functions and 41 above 15, network 1 701 and 19, recruitment
+1 050 and 6, console 510 and 0. Zero fatal errors on 4 572 files, where escomplex fails on 37.9%
+of `network` and 39.0% of `recruitment`. The worst module is this package.
+
+It is absent from oxlint 1.77, so it is written once here and used twice. See 9.5.
+
+### 9.3 The maintainability figure
+
+**Which indicators are in it.** Each at its published threshold, and the ranking is by how often
+each one fires per 100 files, which is measured rather than judged:
+
+| indicator              | published threshold | per 100 files |
+| ---------------------- | ------------------: | ------------: |
+| `max-depth`            |                   4 |           0.6 |
+| `max-classes-per-file` |                   1 |           1.8 |
+| `complexity`           |                  20 |           3.7 |
+| cognitive complexity   |           15, S3776 |           6.5 |
+| `max-lines`            |                 300 |           7.5 |
+| `max-params`           |                   3 |           9.6 |
+| `max-nested-callbacks` |                  10 |             0 |
+
+**Which are out, and why.** There is a break in the data, a factor of 4.5, not a line we drew:
+
+| kept as a descriptor     | per 100 files |
+| ------------------------ | ------------: |
+| `max-statements`         |          42.9 |
+| `max-lines-per-function` |          46.9 |
+
+They fire on nearly one file in two, so they would fire on nearly every pull request. A gate that
+always fires is noise. They stay in the report as descriptors and out of the figure.
+
+⚠️ **Rarity is not severity.** It says what _can_ be a gate, not what is serious. Ordering the
+seven that remain still needs one argument per indicator, and that is open; see 9.6.
+
+**The computation.**
+
+```
+per file   breaches_f = indicators above their published threshold, in that file
+           → names the worst file, and counts the clean ones
+the figure rate = Σ breaches / files × 100
+           MI   = 1 / (1 + rate/10)        0 to 1, higher is better
+beside it  the share of files with no breach at all
+```
+
+Measured: console 0.651, components 0.390, recruitment 0.237, sentinel 0.234. Clean files: 95%,
+87%, 74%, 82%.
+
+⛔ **Three things the measurement forced, each against an idea that looked better:**
+
+- **Equal weights.** A coefficient fitted to today's distribution expires when the distribution
+  moves, which is an argument for no weights rather than for smarter ones.
+- **A denominator is unavoidable.** `1/Σ` ranks by module size, and all four modules land between
+  0.0005 and 0.0042, unreadable. `1/log(1+Σ)` does not fix it, it compresses it: a factor 1.4
+  between best and worst. No monotone transform of a raw count escapes size; only dividing by one.
+- **Never the mean of a per-file score.** 74% to 95% of files are clean, so the mean of `1/(1+n)`
+  saturates between 0.86 and 0.97, a factor 1.13, and the median is 1.000 everywhere. Jensen. The
+  per-file computation is kept for what it alone gives: the worst file, named, and the share that
+  is clean.
+
+⚠️ The `/10` is a display scale, chosen here and arbitrary. It changes the spread, never the
+order, and it is to be replaced; see 9.6. And sentinel at 0.234 and recruitment at 0.240 are
+indistinguishable, not ranked.
+
+### 9.4 Structure is not a score
+
+Each of these says its own thing, and they are reported side by side. Summing them would mean
+inventing both a scale and a direction, which is exactly what 9.3 eliminated.
+
+| metric                | what it says                             | why it cannot be summed                                   |
+| --------------------- | ---------------------------------------- | --------------------------------------------------------- |
+| cycles                | files importing each other in a circle   | 0 expected, **size-independent**: the only summable one   |
+| `Q` + community count | the quality of the assignment            | high is not good: a module split into islands scores high |
+| `Ca` / `Ce` / `I`     | coupling, per file, the 10 most imported | Martin defined them for a component, not a file           |
+| `DC`                  | centrality, beside the raw count         | normalised by `n − 1`, so incomparable between modules    |
+| density               | a web or a tree                          | 0.0216 at 101 files, 0.0005 at 4 380: size, not structure |
+
+### 9.5 Where a rule lives: gate or gauge
+
+The same algorithm is written once and consumed twice, and the split is forced by adoption rather
+than preferred.
+
+|              | the lint plugin                         | the static-analysis role                    |
+| ------------ | --------------------------------------- | ------------------------------------------- |
+| what it is   | a **gate**: it refuses                  | a **gauge**: it measures                    |
+| configurable | yes, a team may derogate                | **no**, or a number stops meaning one thing |
+| threshold    | whatever the preset sets                | the published one, identical everywhere     |
+| reaches      | **52 modules of 198** that adopted lint | **198**, it reads the oxc tree              |
+
+A score sourced from the plugin would exist on a quarter of the repository and be incomparable
+between two modules that configured the rules differently. Hence the gauge, always present.
+
+**The role never runs the module's lint.** It writes its own config to a tmpdir and passes it to
+oxlint, exactly as `tool-config.ts` already does for jscpd. Verified: a config outside the module,
+with `jsPlugins` naming a plugin by path, lints 523 files and leaves `.oxlintrc.json` untouched.
+So no new setting reaches a module's configuration, and the gauge's thresholds live in a file the
+module never sees, which is what makes them non-negotiable.
+
+> ⚠️ Gate and gauge will disagree out loud, and the report must say so. `complexity` is published
+> at 20 and the `nest` preset refuses at 30, so a nest developer will read breaches beside a green
+> lint. That is correct, not a defect: the figure compares modules, the rule refuses code. Each
+> number is printed with the line that produced it, under "measured with".
+
+### 9.6 The gate is on the diff, because on a module it saturates
+
+A worst-breach rating needs no weights and no denominator, which is why it was tried. Measured
+both ways:
+
+|     | the whole module      | one commit |
+| --- | --------------------- | ---------: |
+| A   | —                     |   39 (85%) |
+| C   | —                     |    6 (13%) |
+| D   | console               |          0 |
+| E   | sentinel, recruitment |     1 (2%) |
+
+On a module it saturates: at 1 500 to 3 700 functions, something crosses any per-function line.
+On a diff it discriminates, and the shape suits it: over 300 first-parent commits of 90 days, 18%
+touch no production file at all and the median touches **4**.
+
+> The 46-commit figure reads the files' **current** content, not their content at the commit, so
+> it answers "would this change be flagged today" rather than "did it introduce the defect".
+
+### 9.7 What is still a decision
+
+| open                               | what it needs                                                                                    |
+| ---------------------------------- | ------------------------------------------------------------------------------------------------ |
+| the `/10` in the `MI`              | the distribution over the 198 modules. It changes the spread, never the order                    |
+| the criticality order of the seven | one argument per indicator. Rarity rules two out, it does not rank the rest                      |
+| the overhead line of the SQL study | the harness rebuilt. #90 corrects the attribution and withdraws the 71%, which was never a ratio |
+| the workspace index for libraries  | built and measured in 10.4 and 10.5. Nothing open here any more                                  |
+| a feedback channel on findings     | unchanged from section 8, and it is what would let any of this be proven wrong                   |
+
+The one measurement that unblocks the first two is the same: **the eight indicators over all 198
+modules, once.** Until then the figures in this section come from four modules and are quoted as
+such.
+
+---
+
+## 10. What the perimeter is, and what a figure refuses to answer
+
+Section 9 settled the two scores. Building them raised a different question four times in one
+evening, always the same one under a new coat: **on which files does a figure speak, and what is
+it entitled to conclude about them?** Every answer below is measured, and two of them reverse a
+decision taken earlier in this document.
+
+### 10.1 The measured perimeter is a PLACE, not a list of patterns
+
+What is measured is `src`, or the module itself when it has none.
+
+| over the 208 modules with a `src` |   files |
+| --------------------------------- | ------: |
+| product files under `src`         |  30 008 |
+| outside it                        |   4 004 |
+| of those, tooling configuration   | **205** |
+
+The rest outside `src` is mostly `tests/doubles/`. One rule answers, identically for every pass,
+the three questions a reader actually asks: no, your `jest.config.ts` is not measured; no, your
+tests are not; no, nothing outside `src` is. A list of 24 exclusion patterns answered the same
+questions one argument at a time, and left the configs in.
+
+⚠️ The fallback is not a detail: **232 of the 440 nx projects have no `src` at all**, mostly cloud
+lambdas. Measuring nothing there would be a silence that reads as a pass.
+
+### 10.2 Being measured and being a USER are two different roles
+
+⭐ **A file outside the perimeter is never counted in a figure, and still proves that what it
+imports is alive.** A test is not measured; a test that imports a file shows the file is used.
+
+The measurement that forced it, on `libs/nest/auth`: **11 production files are imported only from a
+test file**, `auth.module.ts` among them, and **47 projects depend on that module**. Treating "not
+measured" as "does not exist" turns all 11 into dead code.
+
+So reachability reads imports from everywhere, and only the population reported on is bounded.
+The same holds for a configuration file: it is never measured, and an import from it still counts.
+
+⚠️ And a file that **only** tests import is not dead either, it is _used only by tests_: a third
+category with its own line. Measured: 6 such entry points on `auth`, **39 on `libs/front/components`**
+(`CalendarHeader`, `MonthCalendar`, `Cell`).
+
+### 10.3 A figure nothing can reach is not published
+
+Two of the four original passes answer a question of the form "does anything reach this?", and both
+become WRONG rather than partial when a file cannot be parsed. Measured on `apps/front/hr-management`,
+232 product `.ts`/`.js` beside 252 `.svelte`:
+
+| what was reported                                           | what it was worth                                                                                                       |
+| ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
+| 161 edges, 124 communities, 163 entry points over 232 files | dust, not an application                                                                                                |
+| 33 files reported unused                                    | **41 of the 232 are imported only from a `.svelte` file**: `debounce.ts`, `clickOutside.ts`, `isMobile.ts`, `modals.ts` |
+
+So the graph and the dead-code figures are suppressed for such a module, and the drawing with them:
+figures carry their reserve in the report, an image carries none. Duplication and complexity stay,
+because each value they produce is true of the file it was measured on.
+
+⛔ **By language, not by a share.** A cut on the unreadable proportion would be a threshold nobody
+can source, and the defect does not arrive gradually: one unreadable component disconnects the
+helpers only it imports. Across the repository this touches **2 modules of 175**: `libs/front/ui`
+(73% unreadable) and `apps/front/hr-management` (52%).
+
+### 10.4 For a library, reachability is decided outside the module
+
+This reverses section 7's assumption that one module's graph can answer its own dead code.
+
+An application has an entry point: something runs, and what it cannot reach is dead. A library has
+none. Its consumers are outside, and the role's graph stops at the module edge on purpose. So the
+figure does not measure dead code there, it measures "the module does not import itself", which is
+true of every library.
+
+| `libs/nest/auth`, 100 production files |        |
+| -------------------------------------- | -----: |
+| reported dead by the entry-point walk  | **87** |
+| `Ca = 0` inside the module graph       |     29 |
+| of those, imported from another module |     17 |
+| **imported by nobody, anywhere**       | **12** |
+
+⛔ **An index, real or synthetic, does not rescue it.** On `libs/front/components`, 432 distinct
+specifiers are used across the repository and **4 go through a barrel, 428 enter by a deep path**.
+The barrel exists and is bypassed 99 times out of 100, so a synthetic index would have to re-export
+everything and the figure would read **0% by construction**. Shape of the 164 libraries with a
+`src`: wildcard alias only **75 (46%)**, barrel and wildcard **71 (43%)**, barrel only **3 (2%)**,
+no alias of their own 15 (9%).
+
+So the decision is to extend `Ca` past the module edge for a library, and only for a library: an
+application is imported by nothing, so its outside `Ca` is zero by construction, and 39 of its 44
+already declare what runs.
+
+**The sentence of principle, written rather than slipped in.** For this one figure, and only this
+one, the role reads outside the module. Everywhere else the module edge is the boundary and that is
+deliberate: a figure comparable between modules must be computed the same way in each. Here the
+question is _who imports this_, the answer is by definition elsewhere, and refusing to look does not
+make the figure local, it makes it wrong. Measured on `libs/nest/auth`: 87 against 12.
+
+**Built, and what changed.** The walk is kept and **seeded** rather than replaced, so it keeps the
+one thing it does that a degree count cannot: transitivity, a file reachable only through a dead one
+stays dead. Its entry points become the module's declared patterns plus the files another module
+imports.
+
+| module                  | unused files |     dead lines | used only by tests |
+| ----------------------- | -----------: | -------------: | -----------------: |
+| `libs/nest/auth`        |  **87 → 20** | 40,1 % → 4,9 % |                  6 |
+| `libs/front/components` | **362 → 10** |        → 1,4 % |             **39** |
+| `recruitment`, an app   |      10 → 10 |        → 1,1 % |                  - |
+| `console`, an app       |        2 → 2 |        → 0,8 % |                  - |
+
+The two libraries move and the two applications do not, which is the shape the measurement
+predicted: an application is imported by nothing, so its outside `Ca` is zero by construction.
+
+⭐ **And a third state appeared, which neither of the two could hold.** A file no production code
+imports but another module's **specs** do is not dead, and not plainly alive either: it is alive for
+the tests alone. `usedOnlyByTests` is its own row, 6 files on `auth` and **39** on
+`libs/front/components`, among them `CalendarHeader`, `MonthCalendar` and `Cell`.
+
+⚠️ The role got **faster**, not slower: `auth` runs in 529 ms against 873 ms before the index
+existed, because the walk has far less to report.
+
+### 10.5 The index: the cost is I/O, so the answer is amortisation and not a data structure
+
+Finding a library's consumers costs 2 to 5 seconds with `git grep`, against 873 ms for the whole
+role on `auth`. The reflex is to reach for a better structure. Measured, that is the wrong end:
+
+|                                                            |         time |
+| ---------------------------------------------------------- | -----------: |
+| enumerate the 39 308 files (`git ls-files`)                |    **56 ms** |
+| `git grep` for a pattern that matches **nothing**          | **8 994 ms** |
+| `git grep` for the real pattern, 2 708 lines found         |     9 343 ms |
+| `git grep` for **every** alias at once, 22 303 lines found |     9 349 ms |
+| build the in-memory index from that output, 5 089 entries  |    **13 ms** |
+
+A pattern that finds nothing costs what a pattern finding 22 303 lines costs: the price is reading
+the disk. A balanced tree would accelerate an insertion that already takes 13 ms, and a lookup that
+is free.
+
+⭐ **The lever is in the last row: one scan serves every library.** The index is built once, not per
+module.
+
+|                                  |           |
+| -------------------------------- | --------: |
+| today, per library               | ~4 900 ms |
+| one scan, the whole index        |  9 024 ms |
+| amortised over the 164 libraries | **55 ms** |
+
+Thirteen minutes become nine seconds. Restricting the scan to the consumers' `src` saves nothing
+(4 884 against 4 911 ms) and loses 5 real consumers, so it is not done.
+
+**Where the cache lives: `node_modules/.cache/sentinel/`.** Not per module, because the index
+describes the workspace and 164 copies would be 164 different staleness states. Not inside the
+installed package, because that is the tool's directory rather than the workspace's, and an install
+replaces it.
+
+The convention already exists in this repository: `node_modules/.cache` holds 208 MB and six tools
+use it, `prettier` and `storybook` among them. Three consequences come free: nothing to add to
+`.gitignore` since `node_modules` is already ignored, one cache per workspace which is the scope the
+data has, and a fresh install clearing it.
+
+⚠️ **That it survives an install is measured, not assumed**: `node_modules/.cache` was last written
+on 2026-09-17 and `.modules.yaml`, which pnpm rewrites on every install, carries 2026-09-27. An
+install ran ten days later and the cache is still there. pnpm removes only what it tracks.
+
+And if the workspace ever switches to a hoisted linker: no collision is possible, since an npm
+package name cannot begin with a dot; the index itself is unaffected, since it maps specifiers to
+this repository's own sources and never reads `node_modules`; and the switch rebuilds `node_modules`
+wholesale, so the cache is lost once and rebuilt in nine seconds, which is the correct invalidation
+for a change that can change the installed code.
+
+Keyed on the git state, `HEAD` plus the uncommitted files, rather than on mtimes: a `git checkout`
+moves every mtime without changing a byte.
+
+### 10.6 The size indicators, and three silent traps
+
+The seven size rules are measured with oxlint, run from a config in a temporary directory at the
+threshold each rule publishes, and the module's own `.oxlintrc.json` is never read. Each trap below
+cost a wrong measurement before it was found, and none of them produced an error:
+
+- **oxlint loads 65 rules by default.** Neither `plugins: []` nor `categories: {}` stops it. On
+  `libs/nest/auth` it reported `no-unused-vars` and `no-useless-rename`, which are not indicators of
+  this gauge. Every category has to be named and turned off; then exactly 8 load.
+- **`ignorePatterns` in the config is accepted and ignored.** Same patterns on the same module: 137
+  files read through the config key against **111** through `--ignore-pattern`, and the worst file
+  it produced was a 1 436-line `permissions.guard.spec.ts`. The gauge was measuring the test suite.
+- **A diagnostic is not a breach.** `max-nested-callbacks` fires once per nesting level, so the unit
+  is the (file, rule) pair: counting diagnostics inflates the rate by **1.8x** at the published
+  thresholds and **2.8x** at lower ones.
+
+And `warn` rather than `error`, for the reason `tool-config.ts` already gives about jscpd's
+`threshold`: at `error`, oxlint exits 1 on any breach and a finding becomes indistinguishable from
+the binary failing. Measured: same 18 diagnostics either way, exit 1 against exit 0.
 
 ---
 
-## 9. Sources
+## 11. Sources
 
 - Ben Khalfallah, H. _Code Health Meter: A Quantitative and Graph-Theoretic Foundation for
   Automated Code Quality and Architecture Assessment._ ACM TOSEM 35(4), article 114, March 2026.
   <https://doi.org/10.1145/3737670>
+- Zimmermann, T. and Nagappan, N. _Predicting Defects using Network Analysis on Dependency Graphs._
+  ICSE 2008.
+  <https://www.microsoft.com/en-us/research/publication/predicting-defects-using-network-analysis-on-dependency-graphs/>
+- Tosun, A., Turhan, B. and Bener, A. _Validation of network measures as indicators of defective
+  modules in software systems._ PROMISE 2009. <https://doi.org/10.1145/1540438.1540446>
+- Hammant, P. _The Rise of Test Impact Analysis._ martinfowler.com, August 2017.
+  <https://martinfowler.com/articles/rise-test-impact-analysis.html>
 - Hassan, A. E. _Predicting Faults Using the Complexity of Code Changes._ ICSE 2009.
   <https://sailresearch.github.io/sail-website/data/pdfs/ICSE2009_PredictingFaultsUsingTheComplexityOfCodeChanges.pdf>
 - Sadowski, C. et al. _Tricorder: Building a Program Analysis Ecosystem._ Google.