Summary / 06. Dependency and impact analysis / Document
Paper 2026-09-04
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# The Blast Radius: Deterministic, Change-Type-Aware Dependency and Impact Analysis for a Weak-Model Coding Harness *Component 06 of 27 — Coding-Harness Program. This document specifies the dependency-and-impact-analysis stage: the forward-looking projection from an intended change to everything else it may break, computed before any further code is written. It sits after component 05 (localization: where is the fault) and answers the question localization deliberately does not: given the edit I am about to make, what else does it reach. It is the first stage in the pipeline whose arrow points forward rather than backward — retrieval gathers, localization searches backward, impact projects forward. It is written to drive a reversible build; the executable specification follows in a companion document.* --- ## Abstract Dependency and impact analysis is the first forward-looking stage of the coding-harness program: reconnaissance orients, retrieval gathers, localization searches backward to the fault site, and impact projects forward from the intended edit to the set of downstream sites that edit can break. This paper argues that the stage should be deterministic, incremental, change-type-aware, and causal. Each proposed edit is classified into an atomic change type by AST diffing; only the dependency relations through which that change type can propagate are traversed; structural impact is enriched with git co-change and test-impact evidence; the graph is maintained incrementally rather than rebuilt; and the resulting blast radius is materialized as an explicit impact DAG whose edges carry cause labels and whose leaves carry downstream change and validation obligations. The whole structure is handed to a weak model as a map — never as code blobs — and the dependency-consistent batch, not the file, is the unit of change. Every stage upstream of the single learned next-edit decision is deterministic software, so the pipeline runs on CPU. Measurement separates impact quality from repair quality and probes the hidden channels where static analysis is blind. ## 1. Introduction The coding-harness program decomposes software engineering into a sequence of questions, and components 01 through 05 answered the opening five: how to *interact* with code (01), how to *choose* an action (02), what the repository *is* (03), what context is *relevant* (04), and *where the fault is* (05). This paper answers the question that a competent engineer asks the instant a candidate edit site is identified: *if I change this, what else breaks?* Component 06, dependency and impact analysis, consumes a proposed change and produces a projected set of downstream consequences — before any of those consequences are discovered the expensive way, by running the build and watching it fail. Impact analysis is the first forward-looking stage, and the distinction from its three predecessors is not merely temporal. Reconnaissance, retrieval, and localization all answer questions about the repository *as it is*: what exists, what is relevant, where the fault lies. Impact analysis answers a question about the repository *as it will be* after an edit. It is a prediction problem, not a discovery problem, and the object it predicts is a *counterfactual state*. That difference determines everything downstream: an impact analyzer cannot simply read structure out of the code, because the structure it must reason about is the structure that will exist *after* the change, reachable only through the dependency relations the change itself perturbs. The central fact of the problem is *fan-out*. A single-symbol edit — renaming a method, widening a parameter type, changing a field's initializer — can propagate through the dependency graph to hundreds of downstream sites. A seed change that appears localized on its face forces a chain of adaptations, each of which is itself a change with its own blast radius [1]. The fan-out is not uniform; it is *typed*. Changing a method signature propagates through one set of relations (callers, overriders, overridees); changing a method body propagates through a different, much narrower set; changing a field initializer through a third. A change-type-blind analyzer that traverses every relation from every edit either under-approximates (missing breakage) or over-approximates (drowning the model in irrelevant sites), and both failure modes are expensive for a weak model. A second, subtler fact is that the *cheap* propagation channels are visible, but the *dangerous* ones are not. Call edges, imports, and inheritance are statically recoverable. Duck-typed call sites, reflection-based instantiation, and string-keyed references — attribute lookups where the attribute name is computed at runtime, dynamic dispatch through registry dictionaries — are not. These hidden channels are precisely what breaks production, because they are the edges a static analyzer cannot see and therefore the edges a naive harness never flags. The honest impact analyzer must acknowledge the limit of its own visibility, and Section 6 makes that acknowledgment a measurement rather than a footnote. Impact analysis also determines edit *sequencing*, not merely edit *membership*. A repository-level change is a partial order, not a set: the signature must be changed before its callers can be adapted, and the callers adapted before the code compiles. CodePlan's defining property — *temporal consistency*, the repository is valid after every step, not merely at the end — is a statement about sequencing [1]. An impact analyzer that returns an unordered set of "affected files" has done half the job; the other half is the DAG that says which adaptation may precede which. Finally, impact analysis already exists in the harness's measurement vocabulary under a different name. The *pass-to-pass* regression rate — a test that passed before the edit and fails after it — is impact analysis rendered as a score: the empirical shadow of the blast radius, counted at the validation stage when the damage has already been done. TDAD reports the cost of *not* projecting forward: 562 pass-to-pass failures across 86 non-empty generated patches, approximately 6.5 broken tests per patch, cut to 155 — 72% fewer — when a deterministic dependency-driven test-selection stage is inserted [3]. The forward-looking stage and the pass-to-pass score are two ends of the same quantity; building the former is how one stops paying the latter. The thesis follows from these observations. **Dependency and impact analysis should be deterministic, incremental, change-type-aware, and causal: classify each proposed edit into an atomic change type by AST diffing; traverse only the dependency relations through which that change type can propagate; enrich structural impact with git co-change and test-impact evidence; maintain the graph incrementally; and convert the blast radius into an explicit impact DAG with cause-edge labels plus downstream change and validation obligations — handed to the weak model as a map, never as code blobs, with the dependency-consistent batch as the unit of change.** The paper proceeds as follows. Section 2 reviews five lines of prior work plus the classical roots, each with its claims, numbers, and weak-model/CPU implication. Section 3 derives six design principles. Section 4 specifies the architecture, labeling every node deterministic (D) or learned (L). Section 5 states the recursive self-improvement protocol. Section 6 gives the measurement plan. Section 7 concludes. ## 2. Related Work The literature divides into five modern lines — an incremental-dependency anchor, an intent-aware retriever, a regression-test-selection result, a two-class-edge model, and a unit-of-change result — plus the classical roots that underpin all five. Each answers one question the impact stage must resolve: what is the phase structure, how to filter semantically, what is the cost of skipping, how to combine hard and soft evidence, and what is the atomic unit of change. ### 2.1 The incremental-dependency anchor: CodePlan **CodePlan** [1] is the anchor for this component because it makes dependency analysis *incremental, adaptive, and causal* rather than a one-shot pass. Its pipeline frames repository-level coding as a planning problem over a dependency graph: from a seed change, it derives a *change may impact* relation, computes an adaptive plan (a sequence of edits in which each step is conditioned on the observed effects of the prior step), and executes that plan so that the repository remains valid after *every* step — the temporal-consistency property that distinguishes it from end-state-only planning [1]. The classification mechanism is the design's center of gravity, and it is *deterministic*. CodePlan's Table 1 maps an atomic change type to the set of dependency relations through which that change type propagates: a **method signature** change traverses `CalledBy`, `Overrides`, and `OverriddenBy`; a **method body** change traverses callers, but only after an *escape analysis* gates them (a body change whose externally observable behavior is unchanged does not propagate); a **field** change traverses `UsedBy` and `ConstructedBy`; a **class declaration** change traverses `InstantiatedBy` and the inheritance relation; a **constructor** change traverses `InstantiatedBy`; an **import** change traverses `ImportedBy`. The atomic-change-type classification is deterministic AST pattern-matching — no language model is consulted to decide what kind of change is being made [1]. This is the single most important transferable design decision for a weak-model harness: the *type* of the edit determines the *shape* of the traversal, and the type is recoverable mechanically. The paper names its own central failure mode, and it is a causal one. When a change to a base-class method breaks an overriding subclass, the *compiler blames the override* — the error surfaces where the constraint is violated, not where the change was made. A naive repair agent, seeing the compiler's complaint, fixes the override; the seed change is thereby *reverted*, and the original intent is silently destroyed. CodePlan's diagnosis is a sentence this paper adopts verbatim as a principle: *the build system is agnostic to cause-effect* [1]. The antidote is to carry the cause edge explicitly: the planner knows the override is a *consequence* of the seed change, not the seed itself. The validity numbers establish that the approach works where baselines do not: five of six repositories (arXiv version) and five of seven (camera-ready version) pass the validity check, against zero of the compared baselines [1]. The context handed to the language model is worth recording precisely, because it is a *map*, not a blob: sketched code fragments, *spatial* context (graph neighbors), and *temporal* context (linearized root-to-node paths, with each edge labeled by its cause) [1]. The weak-model/CPU implication is direct: everything upstream of the LLM — classification, traversal, plan synthesis — is deterministic software, and the LLM's role is to consume a small, cause-labeled slice and produce the next edit. ### 2.2 Intent-aware impact: Ripple / "From Seed to Scope" **Ripple** ("From Seed to Scope") [2] supplies the semantic-filter layer and the weak-model warning. It is a *plan-then-predict* architecture: a Planner LLM converts the seed change into a Change Plan, and a Reasoner LLM predicts the impacted methods from *summaries*, never from bodies [2]. Two properties matter for this harness. First, the deterministic recall phase — git co-change history plus call and class-member relations at distance L=1 — cuts the candidate set by 86.4% while retaining 76.8% recall [2]. Second, *dependence clustering* ensures the LLM ever sees a slice of the repository, never the whole [2]. The reported precision/recall/F1 of 28.2 / 36.3 / 25.0, with a Dependence Hit@k of 86%, mark the task's difficulty: impact prediction is hard even with a strong model, and these numbers are an upper bound on what the semantic layer can contribute [2]. Two further findings carry the design directly. The observation that 54% of commits have *structurally-isolated* impacts — the deterministic recall phase already contains the answer, and the LLM semantic filter does only the residual work — is the quantitative warrant for deterministic-first [2]. And the explicit weak-model warning is a caution this paper internalizes: Gemini-2.0 Flash fails the output format 11% of the time [2], a reminder that a learned stage fed to a weak model must be *format-trivial* (emit identifiers) or eliminated. Ripple is designed for a noisy or outright wrong seed [2], which is exactly the condition under which a weak-model harness operates. ### 2.3 Regression/test selection: TDAD **TDAD** [3] supplies the cost-of-skipping measurement and the single most relevant empirical result for this paper's thesis. Its baseline establishes the price of *not* projecting forward: 562 pass-to-pass test failures across 86 non-empty generated patches, approximately 6.5 broken tests per generated patch. Inserting a deterministic dependency-and-test-impact analysis stage — *before* submission — cuts that to 155 failures, 72% fewer, and drives the regression rate from 6.08% to 1.82% [3]. This is impact analysis doing measurable work: the forward-looking stage is not an abstraction, it is a 4.3-percentage-point reduction in regressions. Three structural findings deserve recording. First, the *TDD Prompting Paradox*: procedurally instructing the model to "write tests first" *without telling it which tests* makes regressions *worse* than doing nothing (9.94%) — context beats procedure, and the gap widens for small models [3]. Second, agentic test selection is *not* classical regression test selection: the goal is to minimize regressions, not test time; the output must be a grep-able static file an LLM can read; and selection happens *before* submission, as a verification gate [3]. Third, the mechanism is deliberately cheap: a 4-node × 5-edge graph (CONTAINS, CALLS, IMPORTS, TESTS, INHERITS) built with the stdlib `ast` module, with impact computed as four strategies merged by confidence weights [3]. Two weak-model lessons are explicit in the source: brevity matters — condensing a SKILL.md from 107 lines to 20 quadrupled resolution — and the whole design is stress-tested on Qwen3-Coder 30B at 4-bit quantization on consumer hardware [3]. ### 2.4 Two-class edges: Athena **Athena** [4] supplies the hard/soft distinction this component adopts, and a caution about provenance. Its architecture separates **hard edges** — call and class-member dependence, recoverable statically — from **soft edges** — conceptual coupling derived from code embeddings, which capture the hidden semantic affinity between files that never directly reference each other. The motivating finding is that each single source (static, dynamic, or evolutionary) is individually unreliable, and the two orthogonal classes are *complementary* [4]. On the Alexandria benchmark — 25 projects, 910 commits, and 4,405 impact-analysis tasks drawn from manually untangled bug-fix commits — the combined model reports mRR 60.32%, mAP 35.19%, and Hit@10 81.48%, with combining program-dependence-graph and conceptual-coupling evidence gaining +9.55 to +11.68 percentage points over either source alone [4]. The weak-model/CPU implication is a subtraction, not an addition. The full neural recipe — embeddings and the fine-tuning that produces them — is too heavy for a CPU-bound weak-model harness. But the *architecture* is exactly right and costs nothing to keep: hard edges decide membership, soft edges rank within the membership. This paper adopts the architecture and replaces the learned soft edge with a deterministic lexical-coupling proxy (Section 4), sacrificing some of Athena's soft-edge recall in exchange for a pipeline that runs without a GPU. Provenance requires an honest note: despite the 2607 arXiv identifier, this is an FSE 2024 paper (PACMSE DOI 10.1145/3643770) that was only posted to arXiv in July 2026 — it is *not* a 2026 preprint, and it should be cited as 2024 work [4]. ### 2.5 The unit of change: DepWareTrans **DepWareTrans** [5] supplies the last design decision: what is the atomic unit of change. Its central claim is that the *file* is the wrong unit — a source-language change that spans multiple interdependent files cannot be translated, compiled, or validated one file at a time. The remedy is the *dependency-consistent batch*: the transitive closure of hard-edge neighbors, translated and validated *together*. The numbers are stark on a 51K-LOC industrial repository: file-level translation reaches 38.16% compilation and 9.39% test pass, while dependency-aware batching reaches 100% and 100% [5]. The weak-model implication is the payoff of the whole section: a weak model benefits from being handed a *small, pre-cohered change cluster* — the dependencies already resolved — rather than being asked to rediscover the dependency structure file by file. Batching is impact analysis made operational. ### 2.6 The classical roots The modern lines rest on four classical results, cited once here for lineage rather than numbers. Program slicing, introduced by Weiser [6], is the origin of the core idea that a change's consequences are a backward-reachable slice of the program. Chianti's atomic-change decomposition of a Java diff and its per-change impact sets [7] is the direct ancestor of CodePlan's change-type table. Bohner and Arnold's survey [8] established impact analysis as a named discipline with static and dynamic variants. And Rothermel and Harrold's safe regression-test-selection criterion [9] is the formal root of the test-impact edge this paper reuses — the guarantee that a test whose dependencies are unchanged need not be re-run is the theoretical license for the deterministic test-selection stage of Section 4. ## 3. Design Principles Six principles follow from the review, each tied to the evidence above. **P1 — Change-type-aware traversal.** Classify the edit into an atomic change type first, then traverse *only* the dependency relations that change type can propagate through. A method-body change must not explode through signature edges; a signature change must not be confined to body edges. CodePlan's Table 1 [1] is the warrant for the shape; the escape-analysis gating of body changes [1] is the warrant for the narrowest possible traversal in each class. **P2 — Deterministic and incremental.** Both the classification and the traversal are deterministic AST diffing and graph walking; no language model is consulted to decide what kind of change is being made [1]. The dependency graph is *patched* after each accepted edit, never rebuilt — the incrementality that CodePlan's adaptive planning [1] assumes and that a CPU-bound harness cannot afford to forgo. **P3 — Causal and provenance-carrying.** The output is not a set of "affected" sites but a DAG whose edges are labeled with the cause relation, so that a downstream failure at an override is attributable to the seed change rather than mistaken for a new, independent fault. CodePlan's compiler-blames-the-override failure mode [1] is the motivation; the labeled root-to-node paths [1] are the mechanism. The analyzer reasons cause→effect, never symptom-only. **P4 — Forward-looking.** The stage converts a proposed change into *downstream change and validation obligations* before any further code is written: which sites must be edited, which tests must be re-run, and in what order. The pass-to-pass regression cost that TDAD quantifies [3] is the price paid when this projection is skipped; the dependency-consistent batch of DepWareTrans [5] is the form the obligations take. **P5 — Hard-gate, soft-rank.** Hard edges (call, import, inherit, class-member) decide membership in the impact set; cheap deterministic lexical coupling ranks within it. This is Athena's two-class architecture [4] with the learned soft edge replaced by a deterministic proxy — the membership guarantee survives, the ranking quality is deliberately traded for CPU tractability. **P6 — Dependency-consistent batch.** The unit of change is the cluster, not the file: the transitive closure of hard-edge neighbors is edited and validated together, with temporal consistency — a valid repository — restored after every step. DepWareTrans's 100%/100% batching result [5] and CodePlan's temporal-consistency property [1] are the twin warrants. ## 4. The Architecture The pipeline is a sequence of stages; every node is labeled D (deterministic software) or L (a learned model). The invariant that governs the whole is: *the L column contains exactly one entry — the next-edit decision read off the map — and every upstream step is deterministic.* The concrete graph reuses the index already built by component 03 (repository reconnaissance): nodes are files, classes, methods, and fields; edges are `call`, `import`, `inherit`, and `class-member`, augmented with `TESTS` edges linking each unit to the tests that exercise it. Git co-change weights, recovered from the history that component 05 (localization) already queries, are attached as a soft signal. The flow, from proposed change to next edit: 1. **Atomic change-type classification [D].** The proposed edit is AST-diffed against the current tree and classified into one atomic change type — method signature, method body, field, class declaration, constructor, import, or a composition of several. Classification is pattern-matching over the diff, no language model [1]. A multi-part edit is decomposed into atomic changes, each analyzed separately; the composite impact is their deduplicated union. 2. **Relation-set selection [D].** A fixed table maps each atomic change type to the relation set it may propagate through (CodePlan's Table 1 [1]): signature → callers/overriders/overridees; body → escape-analysis-gated callers; field → users/constructors; class declaration → instantiators/inheritors; constructor → instantiators; import → importers. This is a table lookup, and it is the P1 gate: relations not in the table are not traversed. 3. **Reverse graph walk [D].** From the edited node, walk the selected relations *backward* — against the direction of the dependency — to collect the downstream sites. The walk is bounded by distance and gated by the change type, so a body change with no observable escape terminates immediately. In parallel, two enriching signals are computed: **git co-change recall** (files that historically changed together with the edited file, from component 05's history) and **test impact** (the `TESTS` edges that Rothermel-Harrold-style selection [9] identifies as transitively dependent on the edit). 4. **Impact-candidate assembly [D].** The structural walk, the co-change recall, and the test impact are merged into a single candidate set, each member tagged with the relation(s) that admitted it. 5. **Hard-gate / soft-rank [D].** Hard edges decide membership: a candidate admitted only by a soft signal is not a member. Within membership, a deterministic lexical-coupling proxy — shared identifiers, shared string literals, shared imported names — ranks the candidates by plausibility, standing in for Athena's embedding-based soft edge [4]. 6. **Triage [D].** The ranked membership is partitioned into three buckets: **MUST-IMPACT** (hard-edge reachable through a relation the change type provably perturbs, e.g. a call site whose signature binding is broken), **MAY-IMPACT** (hard-edge reachable but not provably perturbed, or reachable only through a soft signal), and **LOW-RISK** (everything else the walk touched). The triage is the blast-radius summary the model actually consumes. 7. **Change obligations [D].** From the triage, the analyzer emits the dependency-consistent batch — the transitive closure of hard-edge neighbors that must be edited and validated together, per DepWareTrans [5] — and the targeted validation set — the tests whose `TESTS` edge passes through any MUST/MAY-IMPACT node. These are obligations, not suggestions: they are what the next edit must discharge. 8. **Impact DAG [D].** The obligations are materialized as an explicit DAG whose nodes are the downstream sites and whose edges carry cause labels ("signature changed → caller must be re-bound", "field re-initialized → constructor must be updated"). The DAG encodes *sequencing* (which adaptation precedes which) and *cause* (which edge justifies which obligation), so that a later compiler error at an override is attributable to the seed change, never mistaken for a new fault [1]. 9. **Next-edit decision [L].** The weak model reads the impact DAG and the method summaries of the MUST-IMPACT nodes — a *map*, never a code blob — and decides what to edit next. It emits identifiers, not free-form exploration. This is the sole learned node. The target is explicit and checkable: the L column holds exactly one entry — the next-edit decision from the map — and every stage before it is deterministic software on CPU. Any proposed addition that would put a language model earlier in the pipeline is a regression against P1–P6 and must clear the same bar as before: beat the deterministic stage on the honest metrics of Section 6, on held-out repositories, at a defensible cost, or be rejected. ## 5. Recursive Self-Improvement Protocol Component 6 of 27 follows the program's uniform protocol: the executable specification is written to 100%, round 1 lands at approximately 80% of the specified behavior, and later rounds close the gap. Each round is A/B-gated against the honest metrics of Section 6 — never the end-to-end resolve rate, which would let repair quality mask impact quality. The deterministic stages (1–8) improve by direct engineering, measured by ablation against the fused baseline; the single learned stage (9) improves only if a candidate model beats the deterministic next-edit baseline on held-out repositories. A stage may be removed when the A/B shows it does not move the honest metrics; the roadmap's design rule holds throughout — make the environment better at programming rather than prompting the model harder. ## 6. Measurement & Evaluation Impact analysis is measured *separately* and *honestly*, in four instruments, because a phase that cannot be scored apart from its consumer cannot be diagnosed apart from it. **Impact-set recall/precision.** The ground truth is the *co-changed file set* of untangled commits — the files a maintainer actually touched together in a single, manually separated change. Against that ground truth, report recall and precision of the MUST/MAY-IMPACT set, and distance-to-co-changed-file as a graded metric (rewarding "wrong file, right cluster" over a correct-looking wrong answer). The Alexandria benchmark's manual untangling [4] is the methodological model: the ground truth is a human's causal account of what a change reached, not a model's claim. **The PASS_TO_PASS regression rate.** The empirical shadow of the blast radius, counted at the validation stage: how many tests that passed before the edit fail after it, per patch. TDAD's 562 → 155 reduction [3] is the template: this instrument is how the forward-looking stage is shown to be *working*, by the downstream failure count falling when the stage is enabled. **The oracle-impact diagnostic.** Run repair twice: once with the *oracle* impact set (the true co-changed files supplied), once with the *computed* impact set. The gap is the impact ceiling — the portion of downstream breakage recoverable by improving impact analysis alone. This isolates the forward-looking stage from the repair engine it feeds, the forward-looking analogue of the oracle-localization diagnostic of component 05. **The hidden-channel probe.** A curated corpus of deliberately hidden propagation: string-keyed references, duck-typed call sites, reflection-based instantiation, and registry-driven dispatch. Static analysis is *blind* to these by construction, so the probe measures not whether the analyzer finds them (it cannot) but whether it *flags the region as un-analyzable* rather than silently reporting LOW-RISK. A static analyzer that honestly reports "this boundary is invisible to me" is preferable to one that confidently reports a false negative. Two honest caveats close the section. First, the strong-model-transfer caveat: the semantic-filter numbers of Section 2 (Ripple's 28.2/36.3/25.0 [2], Athena's 81.48% Hit@10 [4]) were obtained with strong models, and a weak model should not be expected to reproduce them; the deterministic stages of this architecture are designed to carry the load precisely because the learned stages will underperform. Second, the memorization lesson inherited from component 05: impact metrics must be reported on held-out and out-of-benchmark repositories, because a model that has memorized a repository's co-change history will score well on in-benchmark impact prediction without having projected anything forward — the same contamination that the SWE-Bench Illusion finding exposed for localization applies, unchanged, to impact. ## 7. Conclusion Dependency and impact analysis is the stage that turns a proposed edit into a *forecast* of its consequences, and the forecast must be deterministic, incremental, change-type-aware, and causal. This paper has argued that each edit should be classified into an atomic change type by AST diffing, that only the relations that change type can propagate through should be traversed, that structural impact should be enriched with git co-change and test-impact evidence, that the graph should be patched rather than rebuilt, and that the resulting blast radius should be materialized as an explicit impact DAG with cause-edge labels and downstream change and validation obligations. The weak model is handed a map, never a code blob, and its single role is the next-edit decision read off that map; the dependency-consistent batch, not the file, is the unit of change. For a weak model on CPU, the consequence is concrete: impact analysis is deterministic software, the model contributes one decision per cycle, and the honest metrics — impact-set recall, the pass-to-pass regression rate, the oracle-impact gap, and the hidden-channel probe — rather than the vibes, decide whether the stage is doing its job. --- ## References 1. Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Vageesh D C, Arun Iyer, Suresh Parthasarathy, Sriram Rajamani, B. Ashok, and Shashank Shet. *CodePlan: Repository-level Coding using LLMs and Planning.* Proceedings of the ACM on Software Engineering (PACMSE), FSE 2024. arXiv:2309.12499. 2. *Ripple ("From Seed to Scope").* ICSE 2026. DOI 10.1145/3744916.3773265. *(No arXiv ID; authors and full title not independently verified.)* 3. *TDAD.* arXiv:2603.17973, March 2026. *(Preprint; authors and full title not independently verified.)* 4. *Athena.* Proceedings of the ACM on Software Engineering (PACMSE), FSE 2024. DOI 10.1145/3643770; posted to arXiv July 2026 as arXiv:2607.23355. *(Note: despite the 2607 identifier, this is FSE 2024 work, not a 2026 preprint; authors and full title not independently verified.)* 5. *DepWareTrans.* ASE 2026 Industry Showcase. arXiv:2608.14128. *(Preprint; authors and full title not independently verified.)* 6. Mark Weiser. *Program Slicing.* Proceedings of the 5th International Conference on Software Engineering (ICSE), 1981, pp. 439–449. 7. Xiaoxia Ren, Fenil Shah, Frank Tip, Barbara G. Ryder, and Ophelia Chesley. *Chianti: A Tool for Change Impact Analysis of Java Programs.* Proceedings of OOPSLA 2004, ACM. 8. Shawn A. Bohner and Robert S. Arnold (eds.). *Software Change Impact Analysis.* IEEE Computer Society Press, 1996. 9. Gregg Rothermel and Mary Jean Harrold. *A Safe, Efficient Regression Test Selection Technique.* ACM Transactions on Software Engineering and Methodology 6(2), 1997, pp. 173–210.