@aburi/diff 0.2.0 → 0.4.0

package/dist/index.d.mts

@@ -1,22 +1,93 @@
-import { CallEdge, SerializeOptions } from "@aburi/core";
-import { Component, ComponentDiff, Dependency, DependencyDiff, DiffResult, IR, IRRef, MatchRationale, Signature, SliceRecord, Symbol, SymbolChange, SymbolDelta, SymbolId } from "@aburi/types";
+import { CallEdge, IntegrityViolation, SerializeOptions } from "@aburi/core";
+import { Component, ComponentDiff, Dependency, DependencyDiff, DependencyEndpoint, DependencyUnknown, DiffResult, IR, IRRef, MatchRationale, NotComparedFile, RelativePath, Signature, SkipReason, SliceRecord, Summary, Symbol, SymbolChange, SymbolDelta, SymbolId } from "@aburi/types";
 
 //#region src/components.d.ts
 /**
- * §6.1 — Component diff. Component identity is `id`; when a Component is present in both
- * base and head with the same id, the three delta booleans describe which axes actually
- * moved (roots reshuffle, public API globs, or framework hint list). `modified` deltas
- * are intentionally absent from this diff (§5.2.3): fields are reported as before/after
- * pairs via the `changed[]` entries so consumers can render them without stringifying
- * arrays.
+ * `docs/design/diff-algorithm.md` §6.1 — Component diff. Assumes `components[].id` is unique on each side (ir-schema.md §14
+ * #2) and does not check it: `buildDiff` establishes that before calling, and a caller
+ * reaching this export directly owns the obligation, because the lookup map here is
+ * last-write-wins and a repeat is lost rather than reported.
+ *
+ * Component identity is `id`; when a Component is present in both base and head with the same
+ * id, *any* field that differs makes it `changed` — the whole object is compared, not the three
+ * axes the delta names. Those two questions were conflated once: a rename, an added language or
+ * an edited description left the diff reporting `componentsChanged: 0` and an empty `changed[]`,
+ * so the projection layer had no before/after pair to render. The delta booleans stay exactly
+ * what they were — a summary of the three axes a reviewer scans for architectural movement — and
+ * a `changed[]` entry with all three `false` is a well-formed answer meaning "something else
+ * about this component moved", not a bug.
+ *
+ * `modified` deltas are intentionally absent from this diff (diff-algorithm.md §5.2.3): fields
+ * are reported as before/after pairs via the `changed[]` entries so consumers can render them
+ * without stringifying arrays.
  */
 declare function diffComponents(base: readonly Component[], head: readonly Component[]): ComponentDiff;
 /**
- * §6.2 — Dependency diff. Identity is the composite `(from, to, via)` triple; direction
- * and effect changes are surfaced as an added + removed pair so `modified` is not part of
- * the schema (§6.2 tail).
+ * What one document knows about itself, for deciding whether the *other* document's silence
+ * about an edge is evidence.
+ *
+ * `symbolFiles` is keyed on the endpoint id exactly as `dependencies[]` spells it, and its
+ * values come from `symbols[].source.file` — the same space `stats.skippedFiles[].path` is in,
+ * and the same space `buildDiff` classifies Symbols by. Reading the file out of the id's path
+ * segment instead would introduce a second answer to "which file is this endpoint in", and
+ * nothing in the schema forces the two to agree; a Symbol reported `unknown` while its edges
+ * stayed `removed` is precisely the inconsistency this exists to remove.
+ *
+ * A Component endpoint is absent from the map, which is how it stays out of the reclassification
+ * without a special case: a Component is an aggregate over roots and has no file to lose.
+ */
+interface DependencySideView {
+  /**
+   * `source.file` of every Symbol this document holds, by the id an endpoint would name it
+   * with. Keyed by `DependencyEndpoint` rather than `SymbolId` because that is the question
+   * being asked: the lookup happens with an endpoint whose kind is not yet known, and "absent"
+   * is the answer for a Component id. Demanding the kind up front would move that decision to
+   * the caller, where it would need a second Symbol-id silhouette test to make.
+   */
+  symbolFiles: ReadonlyMap<DependencyEndpoint, RelativePath>;
+  /**
+   * Files this document never analysed, by path, with the reason it gave. `RelativePath` on
+   * both sides of the file space is what states the bridge these two maps exist to make — one
+   * map's values are the other's keys — though the alias is unbranded, so it is intent rather
+   * than enforcement.
+   */
+  lostFiles: ReadonlyMap<RelativePath, SkipReason>;
+}
+/**
+ * Build a side view from a document. The only construction site there is.
+ *
+ * `buildDiff` reads `lostFiles` for its own Symbol classification too, from this same object,
+ * so "a Symbol reported unknown and the edges it took with it cannot disagree about which file
+ * went missing" is a property of the wiring rather than a claim in a comment.
+ *
+ * Exported because `DependencySideView` is public and `diffDependencies` requires one: without
+ * a factory a caller would have to reproduce the `symbols[].source.file` keying and the
+ * `stats.skippedFiles` read, and the likeliest outcome of that is a caller who gets it wrong.
+ */
+declare function dependencySideView(ir: IR): DependencySideView;
+/**
+ * `docs/design/diff-algorithm.md` §6.2 — Dependency diff. Identity is the composite
+ * `(from, to, via)` triple; direction and effect changes are surfaced as an added + removed
+ * pair so `modified` is not part of the schema (§6.2 tail). Uniqueness of that triple is the caller's obligation on the same
+ * terms as `diffComponents` above — a repeat here is indistinguishable in the output from
+ * the flip it encodes.
+ *
+ * `sides` is what separates a deletion from a loss (`docs/design/diff-algorithm.md` §6.2.1).
+ * It is required rather than optional: omitting it would classify every edge into a lost file
+ * as a deletion again — silently, and while still writing `unknown: []`, which this schema
+ * defines as "nothing was unknown" rather than "nobody looked". A caller with no skip list to
+ * offer says so by passing a side view whose `lostFiles` is empty, which is the honest spelling
+ * of an IR written before `stats.skippedFiles` existed.
+ *
+ * The return type declares `unknown` present, where the schema leaves it optional for documents
+ * that predate the field. A reader may find it missing; this function always writes it.
  */
-declare function diffDependencies(base: readonly Dependency[], head: readonly Dependency[]): DependencyDiff;
+declare function diffDependencies(base: readonly Dependency[], head: readonly Dependency[], sides: {
+  base: DependencySideView;
+  head: DependencySideView;
+}): DependencyDiff & {
+  unknown: DependencyUnknown[];
+};
 //#endregion
 //#region src/delta.d.ts
 declare const DEFAULT_LINE_FUZZ = 2;
@@ -55,6 +126,13 @@ type GitRenameMap = ReadonlyMap<string, string>;
 /**
  * §3.1 — segments Symbols with identical `id` into paired matches. Runs first because it
  * is the highest-confidence signal (no heuristics, just hash lookup).
+ *
+ * Assumes `id` is unique on each side (ir-schema.md §14 #1) and does not check it:
+ * `buildDiff` establishes that before calling, and a caller reaching this export directly
+ * owns the obligation. A repeat on the head side loses all but the last entry to the lookup
+ * map and then removes every one of them from `remainingHead`; a repeat on the base side
+ * pairs the same head Symbol more than once. The later stages track consumed base Symbols
+ * by id and lose a repeat the same way.
  */
 declare function matchStageId(base: readonly Symbol[], head: readonly Symbol[]): {
   matched: SymbolPair[];
@@ -63,7 +141,9 @@ declare function matchStageId(base: readonly Symbol[], head: readonly Symbol[]):
 };
 /**
  * §3.2 — git rename detection. When a rename map is available (typical of ref-driven
- * scans), rewrite the base id with the head-side file path and look for a hit.
+ * scans), rewrite the base id with the head-side file path and look for a hit. Two base
+ * files renamed onto one target predict the same head id, so the claimants are collected
+ * before one is chosen.
  *
  * The rewriter only touches the `file` portion of the id — the `<language>:` prefix and
  * the trailing `#<qualified-name>` segment stay unchanged so a moved file with the same
@@ -76,11 +156,10 @@ declare function matchStageGitRename(remainingBase: readonly Symbol[], remaining
   remainingHead: Symbol[];
 };
 /**
- * §3.3 — group base Symbols by `fingerprint.logic` and match head Symbols whose logic
- * fingerprint is in the map. Two disambiguation branches:
- * - single candidate → paired with `logic-fingerprint`
- * - multiple candidates → best `nameSimilarity` wins if ≥ 0.85; otherwise leave both
- *   sides in remaining for stage 4 to re-evaluate
+ * §3.3 — group both sides by `fingerprint.logic` and pair within each group. Two branches:
+ * - single base candidate → paired with `logic-fingerprint`, no similarity test
+ * - several → `nameSimilarity` disambiguates at ≥ 0.85; a group that cannot reach it is left
+ *   whole for stage 4 to re-evaluate
  *
  * Dropped symbols are excluded (§3.3 tail) — their logic fingerprint is the sentinel
  * `"000000000000"` and would collide with every other dropped Symbol in the workspace.
@@ -96,17 +175,35 @@ declare function matchStageLogicFingerprint(remainingBase: readonly Symbol[], re
  * `signatureNullness` distinguishes symbols with no signature (`interface`, `type`,
  * `class`) from callable ones so that a class body is never paired against a function.
  *
- * The composite score:
- *   0.5 * nameSimilarity + 0.3 * signatureSimilarity + 0.2 * ownerSimilarity
+ * §3.4.6's owner gate runs before the score: a pair whose owners are not the same class, or
+ * one a rename of the other, is not the same Symbol however well the rest agrees, and no
+ * weight small enough to leave the name axis meaning something can outvote a matching member
+ * name and signature.
+ *
+ * The composite score, over the pairs that clear it:
+ *   0.5 * memberSimilarity + 0.3 * signatureSimilarity + 0.2 * OWNER_AXIS_SATISFIED
+ *
+ * `memberSimilarity` reads the last segment, not the whole qualified name: the gate has
+ * already settled the owner, and reading it again on the name axis charges for it twice —
+ * which is what kept a renamed class from ever pairing (§3.4.6).
  *
- * §3.4.3 threshold table:
- * - 1-token name → 1.0 (unreachable → never paired; false-positive shield)
- * - 2-token name → 0.95 (strict, avoids `getUser` vs `getUsers`)
- * - default      → 0.85
+ * §3.4.3 threshold table, applied per head by the token count of its last name segment:
+ * - 1 token  → 1.0 (an exact match on both remaining axes)
+ * - 2 tokens → 0.95 (strict, avoids `getUser` vs `getUsers`)
+ * - default  → 0.85
  *
- * §3.4.3 tail — if both sides are signature-less, we skip pairing entirely because
- * signatureSimilarity always returns 1.0 for `null + null` and would flood the bucket with
- * false pairings.
+ * §3.4.3 also names two Symbols the stage does not read at all, because for them the score is
+ * high on evidence it does not have rather than on a resemblance: one whose signature is
+ * null, since `signatureSimilarity(null, null)` is 1.0 and the bucket key restricts it to
+ * candidates that are equally signature-less; and one whose qualified name carries a single
+ * distinct token, since that is the whole of what its identity amounts to. Neither can be
+ * expressed as a threshold — the second wants a bar above the top of the scale.
+ *
+ * Every pairing in a bucket that clears its head’s threshold becomes a candidate, and the
+ * candidates are settled in score order rather than one head at a time — see
+ * `acceptInScoreOrder`. That doubles the pairings scored, from a bucket that shrank as heads
+ * consumed it to the full bucket every time; `createNameScorer` more than pays for it by
+ * tokenising each distinct name once per pass instead of once per comparison.
  */
 declare function matchStageNameSignature(remainingBase: readonly Symbol[], remainingHead: readonly Symbol[]): {
   matched: SymbolPair[];
@@ -114,13 +211,32 @@ declare function matchStageNameSignature(remainingBase: readonly Symbol[], remai
   remainingHead: Symbol[];
 };
 /**
- * §3.4.5 — dropped-only weak matcher. For dropped Symbols the fingerprint is zeroed and
- * name/signature are the only remaining signals. Score is a coarse "did the last name
- * segment or file basename survive?" — if either half matches we pair (threshold 0.5).
+ * §3.4.5 — dropped-only weak matcher. For dropped Symbols the fingerprint is zeroed, so the
+ * only signals left are the trailing segment of the qualified name and the file basename.
+ * Either one alone is enough to pair, which is deliberately lax: §3.4.5 accepts a
+ * false-positive risk because dropped Symbols sit outside the IR's main review surface.
+ *
+ * What it does not accept is a signal that identifies nothing. A basename hit on `index.ts`
+ * — the most common filename in a TypeScript monorepo — paired every dropped Symbol of one
+ * kind under one with every other, at a score they all tied on, and the results landed in
+ * `summary.moved`, which `--fail-on moved` gates on. So a half counts only when exactly one
+ * dropped base and one dropped head carry that key: such a key names a pair, where a key
+ * several Symbols carry names a group, and a group is not a pairing.
+ *
+ * That makes the candidates the identifying keys themselves — at most one pairing each,
+ * two axes, so at most `2 × min(base, head)` of them rather than the cross-product a shared
+ * basename used to produce.
  *
- * This is deliberately lax; diff-algorithm.md §3.4.5 already accepts that dropped Symbols live
- * outside the main IR review surface, so occasional false pairings only affect the
- * "Drop-rule variation" fold-out section in the Markdown projection.
+ * "Exactly one" is counted over the Symbols this stage is handed, not over every dropped
+ * Symbol in the Document — stages 1 and 2 have already taken theirs, and a key they emptied
+ * out identifies again. That is the intended reading, since the question is which leftover a
+ * key picks out, but it is also how a shared `index.ts` comes back: three dropped classes
+ * under one, two of them matched by id, and the basename identifies the two that are left.
+ *
+ * It also leaves nothing for §3.4.5's 0.5-per-half scale to rank, so §3.8's sweep is the
+ * wrong instrument: it settles conflicts by score, and with none to settle by it would drop
+ * one identified pairing for another over nothing but the id it sorts under. `bestPairing`
+ * takes a maximum matching instead.
  */
 declare function matchStageDroppedWeak(remainingBase: readonly Symbol[], remainingHead: readonly Symbol[]): {
   matched: SymbolPair[];
@@ -129,6 +245,18 @@ declare function matchStageDroppedWeak(remainingBase: readonly Symbol[], remaini
 };
 //#endregion
 //#region src/diff.d.ts
+/**
+ * The two counters `buildDiff` always writes, narrowed off `Summary`'s optionals.
+ *
+ * They are optional on the wire so a diff written before they existed stays valid, and that
+ * optionality is about *documents*, not about this function — a caller holding a value it just
+ * built should not have to re-decide what "absent" would have meant. Same reason
+ * `diffDependencies` declares its `unknown` array present.
+ */
+interface UnknownCounters {
+  unknown: number;
+  depsUnknown: number;
+}
 interface DiffInput {
   baseIR: IR;
   headIR: IR;
@@ -152,7 +280,19 @@ interface DiffInput {
  * pipe the result through additional steps (Markdown projection, `--fail-on` gate) before
  * serialisation.
  */
-declare function buildDiff(input: DiffInput): DiffResult;
+declare function buildDiff(input: DiffInput): DiffResult & {
+  notCompared: NotComparedFile[];
+  summary: Summary & UnknownCounters;
+};
+/**
+ * The files a document's scan never analysed, by path, with why.
+ *
+ * `stats.skippedFiles` is Class B: absent means the writer predates the field, not that
+ * nothing was lost. An empty map is the honest answer either way — with no enumeration
+ * there is no absence this function can explain, and guessing from
+ * `totalFiles > parsedFiles` would attach a reason to whichever Symbols happened to be
+ * missing. The CLI says so on stderr instead; a diff cannot invent the list.
+ */
 /**
  * Byte-deterministic serialiser for a DiffResult. Delegates to `@aburi/core`
  * `serializeCanonical` so the sort order, NFC normalisation, and codepoint key sort are
@@ -161,18 +301,32 @@ declare function buildDiff(input: DiffInput): DiffResult;
 declare function writeCanonicalDiff(diff: DiffResult, options?: SerializeOptions): string;
 //#endregion
 //#region src/errors.d.ts
-/**
- * Coded error class for every @aburi/diff failure. Consumers branch on `code` without
- * parsing message text. Codes are stable and additions are non-breaking; renames are not.
- */
 type DiffErrorCode = /** `base.$schema` and `head.$schema` disagree; a diff across schema versions cannot be trusted (§9.1). */"schema-mismatch" /** `config.diff.lineFuzz` was outside the documented [0, 10] range (diff-algorithm.md §5.2.1). */ | "invalid-line-fuzz"
 /**
- * `baseIR` or `headIR` failed the top-level shape check that `buildDiff` enforces
- * before touching any Symbol. Missing / non-array `symbols`, `components`,
- * `dependencies`, or an absent `$schema` — anything that would otherwise crash with a
- * cryptic `TypeError: undefined is not iterable` deep in a matching stage.
+ * `baseIR` or `headIR` is not a Document of the shape `aburi.ir.v1` requires. `buildDiff`
+ * establishes that before touching any Symbol, by running invariant #20
+ * (`checkDocumentShape`): every field the schema requires, at every depth, named by the
+ * record it sits in and the field inside it — so a missing `stats` or `workspace`, a
+ * `symbols[3]` with no `fingerprint`, and a `stats.effectPropagation` with no `sccCount`
+ * all raise this. Anything here would otherwise crash during classification or the delta
+ * with a `TypeError` naming neither the record nor the field.
+ *
+ * A non-empty `$schema` is raised under this code too. That one is `buildDiff`'s own
+ * requirement rather than the schema's — two Documents that both say `""` agree with each
+ * other, so `schema-mismatch` would never fire on the pair.
+ *
+ * Not the semantic invariants: those are statements about a Document whose answer the diff
+ * does not depend on, and refusing an unsorted `symbols[]` would withhold a diff the
+ * matcher can produce.
  */
 | "ir-shape-invalid"
+/**
+ * `baseIR` or `headIR` repeats an identity the diff keys on: a `symbols[].id`, a
+ * `components[].id`, or a `dependencies[]` `(from, to, via)` triple. Distinct from
+ * `ir-shape-invalid` because the Document is well-formed — the collision changes the
+ * answer rather than preventing one, and ir-schema.md §14 #1 / #2 / #13 already forbid it.
+ */
+| "ir-identity-collision"
 /**
  * A `SliceRecord` broke the derivation invariant of slice-view.md §7.1 / §8.2:
  * `members[]` empty, `members[]` not in strictly ascending order, or `id` not
@@ -186,10 +340,20 @@ interface DiffErrorDetail {
   code: DiffErrorCode;
   /** Offending value (schema id, fuzz value, etc.) when applicable. */
   value?: string;
+  /**
+   * Populated only for `ir-shape-invalid`, one entry per breach of invariant #20.
+   *
+   * The message quotes the first and counts the rest, which is enough to start on and not
+   * enough to finish: a caller fixing a hand-assembled Document needs the others without
+   * running the diff again per field. `CoreErrorDetail.violations` carries the same array
+   * for the same reason, and the two are the same `IntegrityViolation` type.
+   */
+  violations?: readonly IntegrityViolation[];
 }
 declare class DiffError extends Error {
   readonly code: DiffErrorCode;
   readonly value: string | undefined;
+  readonly violations: readonly IntegrityViolation[] | undefined;
   constructor(message: string, detail: DiffErrorDetail, options?: {
     cause?: unknown;
   });
@@ -229,6 +393,15 @@ declare function signatureSimilarity(base: Signature | null | undefined, head: S
  * The result is de-duplicated so `InvoiceService.createInvoice` collapses to
  * `["invoice", "service", "create"]` — Jaccard similarity relies on set semantics, so
  * repeated tokens must not double-count.
+ *
+ * **The camel boundary is ASCII.** `isCamelBoundary` compares code points against `a`–`z`,
+ * `A`–`Z` and `0`–`9`, so a name written in a script with no ASCII case boundary and no
+ * separator comes back whole: `获取用户信息` and `ユーザー情報を取得する` are one token each,
+ * and so is `получитьПользователя` — its camel hump does not register. A separator still
+ * splits (`ユーザー.取得` gives two), and a mixed name splits on its ASCII half.
+ *
+ * That makes the token count a poor measure of how much such a name says, which matters
+ * wherever a count is read as a proxy for that — see §3.4.3's admissibility rule.
  */
 declare function tokenizeName(input: string): string[];
 /**
@@ -237,7 +410,11 @@ declare function tokenizeName(input: string): string[];
  * purpose of §3.4.1). Empty on one side only returns 0.0.
  */
 declare function jaccard(a: readonly string[], b: readonly string[]): number;
-/** name-token Jaccard shortcut used by nameSimilarity and ownerSimilarity call sites. */
+/**
+ * Jaccard over the tokens of two strings. Part of the module's surface rather than an
+ * internal shortcut: the two formulas below go through a token table they share for one
+ * matching pass, so this has no caller inside this file.
+ */
 declare function jaccardTokens(a: string, b: string): number;
 /**
  * §3.4.1 — Jaccard over the tokens of the full qualified name. The last segment is not
@@ -246,20 +423,36 @@ declare function jaccardTokens(a: string, b: string): number;
  */
 declare function nameSimilarity(baseName: string, headName: string): number;
 /**
- * §3.4.6 — owner similarity: same as nameSimilarity but restricted to everything **before**
- * the last segment. Compensates for the R-8 same-name-different-class collision, where
- * `UserRepo.getUser` should not be pair-swapped with `AdminRepo.getUser`.
+ * §3.4.1 — Jaccard over the tokens of the **last segment**: the member name with its owner
+ * removed. What §3.4's composite reads, because §3.4.6 decides the owner separately and
+ * reading it on both axes charges for it twice.
+ */
+declare function memberSimilarity(baseName: string, headName: string): number;
+/**
+ * §3.4.6 (R-8) — whether two Symbols are close enough in *scope* to be the same Symbol: the
+ * same owner, or one whose owner was renamed. A gate rather than a score, because grading the
+ * owner cannot do what R-8 asks. `UserRepo.findById` and `AdminRepo.findById` agree on their
+ * member name and their signature, so a shared `Repo` token at weight 0.2 carries them to
+ * 0.8667 against a 0.85 threshold — while `UsersRepository.findById`, which *is* the rename,
+ * shares no owner token and scores 0.8000. The collision outscores the rename, and raising the
+ * weight only moves both: at 0.3 two three-token class names sharing two tokens land on
+ * exactly 0.85.
  *
  * Owner extraction:
  * - `Class::method` → `Class`
  * - `A.B.C.method` → `A.B.C`
  * - `topLevel`     → `` (empty)
  *
- * When both owners are empty (top-level functions), returns 1.0 because both live in the
- * same "no-owner" bucket. When one is empty and the other is not, returns 0.0 because the
- * two Symbols live in structurally different scopes.
+ * Two empty owners are compatible: top-level Symbols share the one outer scope. One empty and
+ * one not are never compatible — the two live at different depths.
+ *
+ * Otherwise the owners must correspond segment for segment, and within a segment every token
+ * on each side must find a distinct partner on the other under `sameWord`. Both sides must be
+ * covered, so `UserRepo` and `UserRepoV2` are two classes rather than one renamed — an added
+ * token is as much evidence of a sibling as of a rename, and R-8's business is refusing the
+ * collision.
  */
-declare function ownerSimilarity(baseName: string, headName: string): number;
+declare function ownersAreCompatible(baseName: string, headName: string): boolean;
 /** §3.4.1 tail note — used by drop-4.5 weak matcher and threshold lookup. */
 declare function lastSegment(qname: string): string;
 //#endregion
@@ -355,5 +548,4 @@ declare function classifyStatus(base: Symbol, head: Symbol): SymbolStatus;
 type DropDirection = "to-dropped" | "to-kept";
 declare function dropDirection(head: Symbol): DropDirection;
 //#endregion
-export { DEFAULT_LINE_FUZZ, type DeltaOptions, DiffError, type DiffErrorCode, type DiffErrorDetail, type DiffInput, type DropDirection, type GitRenameMap, MAX_LINE_FUZZ, MIN_LINE_FUZZ, type SliceInput, type SliceRecordViolation, type SliceViolationKind, type SymbolPair, type SymbolStatus, assertSliceRecordInvariant, buildDiff, classifyStatus, computeSlices, computeSymbolDelta, diffComponents, diffDependencies, dropDirection, jaccard, jaccardTokens, lastSegment, matchStageDroppedWeak, matchStageGitRename, matchStageId, matchStageLogicFingerprint, matchStageNameSignature, nameSimilarity, ownerSimilarity, signatureSimilarity, sliceAnchor, sliceRecordViolation, tokenizeName, writeCanonicalDiff };
-//# sourceMappingURL=index.d.mts.map
+export { DEFAULT_LINE_FUZZ, type DeltaOptions, type DependencySideView, DiffError, type DiffErrorCode, type DiffErrorDetail, type DiffInput, type DropDirection, type GitRenameMap, MAX_LINE_FUZZ, MIN_LINE_FUZZ, type SliceInput, type SliceRecordViolation, type SliceViolationKind, type SymbolPair, type SymbolStatus, assertSliceRecordInvariant, buildDiff, classifyStatus, computeSlices, computeSymbolDelta, dependencySideView, diffComponents, diffDependencies, dropDirection, jaccard, jaccardTokens, lastSegment, matchStageDroppedWeak, matchStageGitRename, matchStageId, matchStageLogicFingerprint, matchStageNameSignature, memberSimilarity, nameSimilarity, ownersAreCompatible, signatureSimilarity, sliceAnchor, sliceRecordViolation, tokenizeName, writeCanonicalDiff };