flagrm 0.2.1 → 0.4.0

package/CHANGELOG.md

@@ -5,6 +5,133 @@ All notable changes to this project are documented here. The format follows
 [Semantic Versioning](https://semver.org/). Before 1.0, a minor version may
 contain breaking changes.
 
+## [Unreleased]
+
+## [0.4.0] - 2026-10-11
+
+### Added
+
+- `testResults` reads Jest JSON (`jest --json`, Vitest's `json` reporter); a
+  result file that doesn't parse, or an XML file that isn't complete, is skipped.
+- Without `testResults`, `verify` reads the changed test files to list
+  deleted and renamed tests, and warns when the log's test count dropped by
+  more than the diff deletes.
+- Without `testResults`, `verify` reads failing test names and counts from
+  the test command's log (Karma, Jest, Vitest, `dotnet test`; Go and pytest
+  names), so a test that already failed at the baseline is a known failure
+  there too.
+- `doctor`'s warning about a test command without `testResults` says how
+  to get results for the detected runner (Vitest, Jest, Karma, `dotnet test`).
+- An optional per-project `lint` command (lint or type-check), run by
+  `baseline`, `verify` and `doctor --run`. `verify`'s new `lint` check fails
+  on lint errors the removal caused; a lint that already failed at the
+  baseline only warns, unless its log has error lines the baseline's didn't
+  (line and column numbers ignored).
+- `verify`'s new `coverage` check warns about changed files that no build,
+  test or lint command checks; a project's optional `covers` globs say which
+  files its commands check (default: everything under its path). Files
+  already dirty at the baseline and unchanged since don't count, nor do
+  documentation and deleted files outside every project. With
+  `--strict`, such a file now fails verify.
+- `/flagrm-remove` takes several flags (`/flagrm-remove A B C`): it asks
+  once whether they are all ON and whether to commit each one, then removes
+  them one after another, one commit per flag.
+- `/flagrm-remove` ends with the verify overview and a proposed commit
+  message, so `/flagrm-verify` is only needed to check a removal later. The
+  commit message takes the ticket from the branch name and wraps its body.
+- A passing full verify saves its build and test results; `baseline` and
+  `verify` on the same tree with the same commands reuse them instead of
+  running them again, and say so. Removing flags one after another, each
+  next baseline takes seconds, and so does `/flagrm-verify` after a
+  removal. `--no-reuse` runs them anyway.
+- Angular: a renamed import of a flag registry
+  (`import { FeatureFlags as AppFeatureFlags }`) is followed, so
+  `AppFeatureFlags.X` is recorded and checked like `FeatureFlags.X`.
+- Angular: a name checked only in a component's `.ts` file is checked in
+  its `templateUrl` template too, whether discovery or `--file` scoped it.
+- Angular: `list` and `baseline` follow a flag's value through the fields,
+  getters, parameterless methods and locals holding an evaluation of it
+  (`isPaginationEnabled = this.ff.isFeatureFlagEnabled(…)`), names derived
+  from those, and one hop into the child component input a template binds
+  one of them to. Names that mention the flag are recorded; generic ones are
+  listed as `suggestedNames`.
+- `baseline --file` repeats: `--name x --file a.ts --file b.ts` records the
+  name for every file in one call.
+- `baseline --name` refuses a name whose code reads only other flags (a
+  helper named like this flag that evaluates a different one), since
+  `verify` would then ask to delete the other flag's code.
+
+### Changed
+
+- **Breaking:** JSON schema version 8: `--json`, `baseline.json` and `verify.json` gain
+  the `lint` and `coverage` checks, `lint` runs and `git.dirtyHashes`.
+  Version 6 and 7 baselines are still read.
+- The Angular adapter's default test command now writes test results when
+  the workspace's runner can without setup: JUnit for Angular's Vitest
+  builder (`ng test --reporters=junit --output-file`) and plain Vitest, Jest
+  JSON for Jest, and JUnit for Karma once karma.conf configures
+  `karma-junit-reporter`. Results go to `.flagrm/test-results/<project>/`.
+  A baseline taken before upgrading reports the test command as changed
+  once; `flagrm baseline <flag> --accept config` or a new baseline clears it.
+
+### Fixed
+
+- A failed test run without test results showed only "exited with 1":
+  `verify` now lists the log's error lines, as for a failed build.
+- A lint, build or test command that fails because its package script
+  (`npm run lint` without a `lint` script) or ESLint config is missing is a
+  setup problem: `verify` and `doctor --run` fail on it instead of treating
+  it as lint debt.
+- Deleting a committed file that matches `exclude` (say, a generator removing
+  `graphify-out/graph.html`) no longer invalidates a passing verify: the
+  Stop hook's tree fingerprint now leaves out deletions under `exclude`, as
+  it already did for edits and new files.
+- `/flagrm-remove` tells the agent not to run code generators or formatters
+  after the passing verify, or to verify again if it must.
+
+## [0.3.0] - 2026-10-07
+
+### Changed
+
+- **Breaking:** `build` and `test` each fall back to the adapter's default on
+  their own. Setting only `test` no longer drops the default build, so the
+  dead-code check has a build log to read. `build: false` / `test: false`
+  turn one off. The default .NET test command writes TRX to
+  `.flagrm/test-results/<project>/` and sets `testResults`, so tests are
+  compared by name and tests that already failed before the removal only
+  warn. `flagrm scope --write` writes that `testResults` out along with the
+  test command, and no longer folds long commands over two lines.
+- flagrm's own setup files (`flagrm.config.yaml`, `.gitignore`,
+  `.claude/settings.json`, the installed `flagrm-*` skills and prompt files,
+  `AGENTS.md`, `flagrm.slnf`) and paths matching `exclude` no longer count as
+  part of a removal: verify's changed files, `baseline --force` and the Stop
+  hook ignore them, so generated output such as `graphify-out/` no longer
+  invalidates a passing verify. An `exclude` entry that names a directory
+  covers everything under it, as it already did for scanning.
+- `flagrm doctor` and the `/flagrm-remove` precondition accept a tree whose
+  only uncommitted files are flagrm's setup files or paths matching `exclude`,
+  so a freshly run `flagrm init` no longer blocks the first removal.
+
+### Added
+
+- `flagrm doctor` marks the build and test commands that are adapter
+  defaults, and warns about a test command without `testResults`. With
+  `--run` it fails when the test command writes no results matching
+  `testResults`, so a broken setup shows up before a removal instead of
+  halfway through, and only warns when tests already fail: the baseline
+  records those as known failures.
+- `flagrm baseline <flag> --accept config,failures` acknowledges a change to
+  the flagrm config or the baseline's failing tests, also mid-removal, when
+  `--force` is no longer allowed. verify stops warning about the accepted
+  config (tests it leaves out still count as excluded by config) and lists
+  accepted known failures as info, so `--strict` can pass. A changed `tools:`
+  no longer warns at all.
+- The `dead-code` check warns about a method, property, field or type the
+  removal left referenced only where it is declared. Compilers don't report
+  that for public or internal members. The check is text-based: strings,
+  templates, Razor views and config files count as references, comments
+  don't, and language keywords and the flag's recorded names are left out.
+
 ## [0.2.1] - 2026-10-04
 
 ### Fixed
@@ -144,6 +271,8 @@ removes the flag through the `flagrm-remove` skill, and flagrm checks the result
   `doctor` warns about an incremental `dotnet build`, which hides existing
   warnings from the dead-code comparison.
 
+[0.4.0]: https://github.com/dino-cosic/flagrm/releases/tag/v0.4.0
+[0.3.0]: https://github.com/dino-cosic/flagrm/releases/tag/v0.3.0
 [0.2.1]: https://github.com/dino-cosic/flagrm/releases/tag/v0.2.1
 [0.2.0]: https://github.com/dino-cosic/flagrm/releases/tag/v0.2.0
 [0.1.1]: https://github.com/dino-cosic/flagrm/releases/tag/v0.1.1

package/README.md

@@ -8,8 +8,8 @@ Remove feature flags with your AI coding agent, safely.
 flagrm gives Claude Code, GitHub Copilot and Codex a flag-removal skill and the
 guardrails to check the result. It records a baseline before the edit, then
 gates the removal with `flagrm verify`, which fails while the flag is still
-referenced, the build breaks, a test regresses, or the removal leaves unused
-code behind.
+referenced, the build breaks, a test or lint regresses, or the removal leaves
+unused code behind.
 
 The agent does the reasoning and the edits: finding the flag, its aliases and
 wrappers, removing the OFF path, and refactoring methods the flag was passed
@@ -18,7 +18,7 @@ into. flagrm decides when the work is done.
 Angular and .NET projects work out of the box. Any other stack works through the
 generic adapter.
 
-> **Status:** flagrm is at version 0.1. Until 1.0, a minor release may contain
+> **Status:** flagrm is at version 0.4. Until 1.0, a minor release may contain
 > breaking changes.
 
 ## Requirements
@@ -48,14 +48,11 @@ agent:
 /flagrm-remove NewCheckout
 ```
 
-When the agent reports back, review the result:
-
-```
-/flagrm-verify NewCheckout
-```
-
-You get a short overview (checks, changed files, tests deleted or renamed) and
-a proposed commit message. The agent never commits for you. The overview looks
+The agent ends with a short overview (checks, changed files, tests deleted or
+renamed) and a proposed commit message; it commits only when you ask. Several
+flags at once: `/flagrm-remove NewCheckout DarkMode` asks the ON question and
+whether to commit each flag once, then removes them one after another. To
+check a removal later, run `/flagrm-verify NewCheckout`. The overview looks
 like this (abridged):
 
 ```md
@@ -67,6 +64,8 @@ like this (abridged):
 | dead-code | ✅ pass | no new unused-code diagnostics |
 | build | ✅ pass | web, api built successfully |
 | tests | ✅ pass | tests passed (web 24 → 22: 2 deleted, 1 renamed; api 18 → 16: 2 deleted) |
+| lint | ✅ pass | web linted cleanly |
+| coverage | ✅ pass | every changed file is built, tested or linted |
 
 **Files changed since baseline (26):** `backend/src/Shop.Api/Services/CheckoutService.cs`, ...
 
@@ -97,26 +96,29 @@ of these reasons is a warning, for the agent to explain in its notes.
    `flagrm baseline <flag>`, which records the git commit, the build and test
    results, and the flag's names. It finds every usage with its own search,
    records wrappers and aliases with `flagrm baseline <flag> --name`, removes
-   the flag, and repeats `flagrm verify <flag>` until it passes.
+   the flag, and repeats `flagrm verify <flag>` until it passes. It ends with
+   the overview and a commit message. With several flags it asks once whether
+   they are all ON and whether to commit each, then removes them in order,
+   one commit each.
 3. **The Stop hook** (Claude Code) keeps the agent from finishing while a
    removal is in progress and not verified. In progress means a file git
-   tracks changed on top of the baseline commit (changes to
-   `flagrm.config.yaml` and untracked files don't count, so a removal paused
-   on a question to the user doesn't block), or the last verify used `--skip`.
-4. **`/flagrm-verify <flag>`** runs `flagrm verify <flag> --md` and adds notes
-   and a commit message.
+   tracks changed on top of the baseline commit (untracked files and
+   flagrm's own setup files don't count, so a removal paused on a question to
+   the user doesn't block), or the last verify used `--skip`.
+4. **`/flagrm-verify <flag>`** checks a removal later: runs
+   `flagrm verify <flag> --md` and adds notes and a commit message.
 
 ## Commands
 
 | Command | What it does | Exit codes |
 |---|---|---|
 | `init` | Set up the config and `.gitignore` entry, and each chosen AI tool's files (asks, or `--tool claude-code,copilot,codex`; saved as `tools:`). Never overwrites or deletes | 0, 2 usage error |
-| `doctor` | Check the config, build and test commands (`--run` runs them), the .NET SDK `global.json` asks for, `cargo` and Docker where projects need them, git, `.gitignore`, installed skills and hook, and abandoned baselines | 0 ok, 1 problems |
+| `doctor` | Check the config, the build, test and lint commands (marking adapter defaults; `--run` runs them and fails when tests write no readable `testResults`), the .NET SDK `global.json` asks for, `cargo` and Docker where projects need them, git, `.gitignore`, installed skills and hook, and abandoned baselines | 0 ok, 1 problems |
 | `scope` | For each .NET project, show what the machine lacks and which projects a solution filter would leave out; `--write` creates `flagrm.slnf`, adds it to `.git/info/exclude` and points the project's build and test at it | 0 nothing missing, 1 something missing |
 | `update` | Refresh the installed skills, prompt files, `AGENTS.md` block and hook from this flagrm version, for the config's `tools:` | 0 |
-| `list` | List every feature flag in the project: definitions, configured state per environment, reference counts | 0 |
-| `baseline <flag>` | Before any edit, record the git commit, build and test results and the flag's names in `.flagrm/<flag>/baseline.json`. In .NET code the names include the locals, fields, parameters and methods the flag's value travels through when they name the flag (a local, parameter or field is checked only in its own file); generic or ambiguous ones are listed as `suggestedNames`, with `parameterizedTests` that pass the value as a literal. `--file` limits `--name` entries to one file (and records them as wrappers). `--name X --kind alias\|wrapper` adds names to an existing baseline; `--json` prints a summary (test counts, at most 20 failed test names; the file keeps everything); `--force` starts over, but only while the code is unedited since the baseline commit (changes to `flagrm.config.yaml` and `testResults` files are fine); `--no-checks` skips build and tests | 0, 2 usage error |
-| `verify <flag>` | Gate the removal with `leftovers`, `dead-code`, `build` and `tests`. Writes `.flagrm/<flag>/verify.json`. `--md` prints the overview, `--json` the full result, `--skip` skips checks, `--strict` fails on warnings | 0 pass, 1 fail, 2 usage error |
+| `list` | List every feature flag in the project: definitions, configured state per environment, reference counts; flow names include renamed imports of a flag registry (`import { FeatureFlags as AppFeatureFlags }`) and, in Angular, the fields, getters, methods and locals holding a flag and a child component's input bound to one | 0 |
+| `baseline <flag>` | Before any edit, record the git commit, build, test and lint results and the flag's names in `.flagrm/<flag>/baseline.json`. In .NET and Angular code the names include the locals, fields, getters, parameters and methods the flag's value travels through when they name the flag (a local, parameter or field is checked only in its own file, and an Angular component's template); generic or ambiguous ones are listed as `suggestedNames`, with `parameterizedTests` that pass the value as a literal. `--file` (repeatable) limits `--name` entries to those files (and records them as wrappers). `--name X --kind alias\|wrapper` adds names to an existing baseline (a name whose declaration reads only other flags is refused); `--json` prints a summary (test counts, at most 20 failed test names; the file keeps everything); `--force` starts over, but only while the code is unedited since the baseline commit; `--accept config,failures` acknowledges, also mid-removal, a config change or the baseline's failing tests so verify stops warning about them; `--no-checks` skips build, tests and lint; build, test and lint results of a passing verify on the same tree and commands are reused (`--no-reuse` runs them) | 0, 2 usage error |
+| `verify <flag>` | Gate the removal with `leftovers`, `dead-code`, `build`, `tests`, `lint` and `coverage`. Writes `.flagrm/<flag>/verify.json`. `--md` prints the overview, `--json` the full result, `--skip` skips checks, `--strict` fails on warnings; reuses its own or another flag's passing runs on the same tree and commands (`--no-reuse` runs them) | 0 pass, 1 fail, 2 usage error |
 | `hook stop` | The Claude Code Stop hook installed by `init` | always 0 |
 
 `list`, `baseline` and `verify` accept `--json`, `--config <path>`, and
@@ -127,12 +129,14 @@ of these reasons is a warning, for the agent to explain in its notes.
 | Check | Fails when |
 |---|---|
 | `leftovers` | A recorded name (the flag literal, its constants, wrappers the agent recorded) is still in code or config. A mention in a comment is a warning, and so is a test that checks text the removal deleted from the code (a test of the OFF path that never names the flag), or deleted text whose replacement on the same line no test checks (lost ON coverage) |
-| `dead-code` | The compiler reports new unused code (locals, imports, private members) in changed files |
+| `dead-code` | The compiler reports new unused code (locals, imports, private members) in changed files. A method, property, field or type the removal left named only where it is declared is a warning (compilers don't report public members) |
 | `build` | A project's build command fails |
-| `tests` | A test that passed at the baseline fails. With `testResults`, tests that already failed at the baseline are known failures and only warn. A test that no longer runs though the diff neither deletes nor renames it and the test config is unchanged, and a changed test file none of whose tests ran, are warnings for the agent to account for |
+| `tests` | A test that passed at the baseline fails. Tests that already failed at the baseline are known failures and only warn; without `testResults` they are read from the test log (Karma, Jest, Vitest, `dotnet test`), and count as known only when the log names every failing test. A test that no longer runs though the diff neither deletes nor renames it and the test config is unchanged, and a changed test file none of whose tests ran, are warnings for the agent to account for. Without `testResults`, deleted and renamed tests come from the changed test files, and a test count that dropped by more than the diff deletes is a warning (info when the changed test files use data rows such as `[InlineData]`, `TestCase`, `DataRow` or `.each`, whose cases count separately, or when the test config changed since the baseline) |
+| `lint` | The project's `lint` command fails where it passed at the baseline. A lint that already failed at the baseline only warns, unless its log has error lines the baseline's didn't (line and column numbers ignored); a missing package script or ESLint config is a setup problem and fails |
+| `coverage` | A changed file that no project's build, test or lint command checks (outside every project with a command, or outside its `covers` globs) is a warning, so it fails only with `--strict`. Files already dirty at the baseline and unchanged since don't count, nor do projects whose commands `--skip` left out |
 
 The baseline also records the configuration it was taken with: each project's
-resolved build and test commands, the files they name (a `.slnf`, a
+resolved build, test and lint commands, the files they name (a `.slnf`, a
 `.runsettings`, a filter list) and the text of `flagrm.config.yaml`. When any
 of it changed since, the check it affects warns and shows the difference: a
 narrower test command makes "no new failures" mean less.
@@ -152,6 +156,8 @@ projects:
     build: npm run build
     test: npx ng test --watch=false
     testResults: ./frontend/test-results/junit.xml
+    lint: npx eslint e2e && npx tsc --noEmit -p e2e   # optional lint / type-check
+    covers: ['src/**', 'e2e/**']         # what the commands check (default: everything under path)
     methods: [isEnabled, watch]          # flag evaluation methods
   - name: api
     adapter: dotnet
@@ -168,13 +174,46 @@ exclude: ['**/Migrations/**']
 ```
 
 Paths are relative to the config file, and commands run inside each project's
-path. Without `build` or `test`, the adapter's defaults are used (`dotnet build
---no-incremental`, `npx ng build`, and so on). `testResults` (JUnit XML or TRX)
-lets `verify` compare individual tests against the baseline. Only files written during the run are read, so result files left by earlier runs don't count, and projects whose patterns overlap don't count each other's files. `timeout`
-(seconds) fails a project's build or test command that runs longer, for example
-a test runner left in watch mode. `tools` lists the AI coding tools whose files
-`init` and `update` manage (`claude-code`, `copilot`, `codex`); dropping one
-leaves its files in place, and `init` names them so you can delete them.
+path. `build` and `test` are resolved one at a time:
+
+| In the config | Command that runs |
+|---|---|
+| absent | the adapter's default (`dotnet build --no-incremental`, `npx ng build`, and so on) |
+| a command | that command |
+| `false` | none, not even the default |
+
+`testResults` (JUnit XML, TRX or Jest JSON; a path or a glob) lets `verify`
+compare individual tests against the baseline. Only files written during
+the run are read, and every matching file is merged, so a sharded run can
+use `./test-results/*.xml`. The default .NET test command writes TRX to
+`.flagrm/test-results/<project>/`. So does the default Angular test command,
+when the workspace's runner can write results without setup: JUnit for
+Angular's Vitest builder and Vitest, Jest JSON for Jest, and JUnit for Karma
+once karma.conf configures `karma-junit-reporter`. A `test` command of your
+own needs its own `testResults`, and `flagrm doctor` says what to add.
+Without result files, `verify` reads failing test names and counts from the
+test log and deleted tests from the diff, which is coarser: passing tests
+aren't named. `timeout` (seconds) fails a project's build or test command
+that runs longer, for example a test runner left in watch mode. `tools` lists
+the AI coding tools whose files `init` and `update` manage (`claude-code`,
+`copilot`, `codex`); dropping one leaves its files in place, and `init` names
+them so you can delete them.
+
+`lint` is an optional lint or type-check command (no adapter default) that
+`baseline` and `verify` run like `build` and `test`; use it for code the build
+and tests don't reach, such as end-to-end specs. A lint that already fails at
+the baseline only warns, unless the removal adds error lines. flagrm doesn't
+check formatting: put a formatter's check (`npx prettier --check .`) in
+`lint` if you want it. `covers` lists the files (globs relative to `path`) the
+project's commands check; the `coverage` check warns about a changed file no
+project with a command covers. Without `covers`, a project covers everything
+under its path.
+
+Paths matching `exclude` (relative to the config file or a project's path; a
+directory excludes everything under it) and flagrm's own setup files don't
+count as part of a removal, so generated output such as `graphify-out/` that
+changes during a session doesn't invalidate a passing verify or block the Stop
+hook. `--exclude` on the command line doesn't reach the Stop hook.
 
 ### When the machine can't build everything
 

package/dist/adapters/angular/component-files.js

@@ -0,0 +1,41 @@
+/** The files that share a component's scope: its `templateUrl` template. Parsed, never type-checked. */
+import fs from "node:fs";
+import path from "node:path";
+import ts from "typescript";
+export function componentScopeFiles(file) {
+    if (!file.endsWith(".ts"))
+        return [];
+    let text;
+    try {
+        text = fs.readFileSync(file, "utf8");
+    }
+    catch {
+        return [];
+    }
+    if (!text.includes("templateUrl"))
+        return [];
+    const sf = ts.createSourceFile(file, text, ts.ScriptTarget.Latest, true);
+    const out = [];
+    for (const statement of sf.statements) {
+        if (!ts.isClassDeclaration(statement))
+            continue;
+        for (const decorator of ts.getDecorators(statement) ?? []) {
+            const call = decorator.expression;
+            if (!ts.isCallExpression(call) || call.expression.getText(sf) !== "Component")
+                continue;
+            const options = call.arguments[0];
+            if (!options || !ts.isObjectLiteralExpression(options))
+                continue;
+            for (const prop of options.properties) {
+                if (!ts.isPropertyAssignment(prop) || prop.name.getText(sf) !== "templateUrl")
+                    continue;
+                if (!ts.isStringLiteralLike(prop.initializer))
+                    continue;
+                const template = path.resolve(path.dirname(file), prop.initializer.text);
+                if (fs.existsSync(template))
+                    out.push(template);
+            }
+        }
+    }
+    return out;
+}

package/dist/adapters/angular/flow.js

@@ -0,0 +1,121 @@
+/**
+ * Where a flag's value goes in TypeScript code: renamed imports of a flag
+ * registry (`import { FeatureFlags as AppFeatureFlags }`), so `AppFeatureFlags.X`
+ * is checked like `FeatureFlags.X`, and the fields, getters, methods and
+ * locals holding an evaluation of the flag (`holders.ts`), and a child
+ * component's input a template binds one of them to (`inputs.ts`). Each file
+ * is parsed at most once, never type-checked.
+ */
+import fs from "node:fs";
+import path from "node:path";
+import ts from "typescript";
+import { isTestPath } from "../../core/scan.js";
+import { collectSites, deriveHolders, evaluationMatcher, skipParens } from "./holders.js";
+import { childInputs } from "./inputs.js";
+/** A renamed named import: `import { A as B }`, `import type { A as B }`, `import X, { A as B }`. */
+const RENAMED_IMPORT = /\bimport\s*(?:type\s+)?(?:[\w$]+\s*,\s*)?\{[^}]*\bas\s/;
+export function angularFlow(ctx, flags, evalMethods) {
+    const files = parseFiles(ctx, evalMethods);
+    const names = files.flatMap((f) => importAliases(ctx, f, flags));
+    if (evalMethods.length === 0)
+        return { names, tests: [] };
+    const code = files.filter((f) => !f.isTest);
+    const evaluates = evaluationMatcher(evalMethods, flagOfArgument(flags, names));
+    const sites = collectSites(code);
+    let holders = deriveHolders(sites, evaluates);
+    // One hop: a child's inputs bound to a holder, then what the child derives from them.
+    const inputs = childInputs(code, holders);
+    if (inputs.length > 0)
+        holders = deriveHolders(sites, evaluates, inputs);
+    for (const h of holders) {
+        if (evalMethods.includes(h.name))
+            continue;
+        const same = (n) => n.flag === h.flag && n.name === h.name && n.kind === h.kind && n.file === h.file;
+        if (names.some(same))
+            continue;
+        names.push({
+            flag: h.flag,
+            name: h.name,
+            kind: h.kind,
+            ...(h.ambiguous ? { ambiguous: true } : {}),
+            project: ctx.name,
+            file: h.file,
+            line: h.line,
+        });
+    }
+    return { names, tests: [] };
+}
+/** The `.ts` files any pass needs, each read and parsed once. */
+function parseFiles(ctx, evalMethods) {
+    const files = [];
+    for (const file of ctx.files) {
+        if (!file.endsWith(".ts"))
+            continue;
+        let text;
+        try {
+            text = fs.readFileSync(file, "utf8");
+        }
+        catch {
+            continue;
+        }
+        const wanted = RENAMED_IMPORT.test(text) ||
+            (evalMethods.length > 0 && (text.includes("@Component") || evalMethods.some((m) => text.includes(m))));
+        if (!wanted)
+            continue;
+        const sf = ts.createSourceFile(file, text, ts.ScriptTarget.Latest, true);
+        files.push({ file, text, sf, isTest: isTestPath(path.relative(ctx.root, file)) });
+    }
+    return files;
+}
+/** The flag names a renamed import in `f` gives: `AppFeatureFlags.X` for `FeatureFlags.X`. */
+function importAliases(ctx, f, flags) {
+    const names = [];
+    for (const statement of f.sf.statements) {
+        const bindings = ts.isImportDeclaration(statement) ? statement.importClause?.namedBindings : undefined;
+        if (!bindings || !ts.isNamedImports(bindings))
+            continue;
+        for (const element of bindings.elements) {
+            if (!element.propertyName)
+                continue;
+            const original = element.propertyName.text;
+            const renamed = element.name.text;
+            const line = f.sf.getLineAndCharacterOfPosition(element.getStart(f.sf)).line + 1;
+            for (const { flag, aliases } of flags) {
+                for (const alias of aliases) {
+                    if (!alias.startsWith(`${original}.`))
+                        continue;
+                    const name = `${renamed}${alias.slice(original.length)}`;
+                    names.push({ flag, name, kind: "alias", project: ctx.name, file: f.file, line });
+                }
+            }
+        }
+    }
+    return names;
+}
+/**
+ * The flag an eval call's first argument names: its string literal, one of
+ * its qualified names (`FeatureFlags.X`), or an import alias of one declared
+ * in the same file (`AppFeatureFlags.X`).
+ */
+function flagOfArgument(flags, aliases) {
+    const literals = new Set(flags.map((f) => f.flag));
+    const qualified = new Map();
+    for (const { flag, aliases: names } of flags) {
+        for (const name of names)
+            if (!qualified.has(name))
+                qualified.set(name, flag);
+    }
+    const imported = new Map();
+    for (const a of aliases) {
+        const inFile = imported.get(a.file) ?? new Map();
+        inFile.set(a.name, a.flag);
+        imported.set(a.file, inFile);
+    }
+    return (file, arg) => {
+        const value = skipParens(arg);
+        if (ts.isStringLiteralLike(value))
+            return literals.has(value.text) ? value.text : undefined;
+        const text = value.getText(file.sf).replace(/\s+/g, "");
+        return qualified.get(text) ?? imported.get(file.file)?.get(text);
+    };
+}