Skip to main content

Scenario 10: Cross-repository impact

Find dependencies and duplicated implementations across repositories. Collect results to assess change impact and plan consolidation.

User Guides

Use this scenario when a proposed change in one repository may affect code, dependencies, or duplicated implementations in other repositories. It produces a list of affected repositories, dependencies, and similar implementations with evidence for review.

When to use it

Use Scenario 10 for a bounded workspace that contains several repositories and one explicit question, such as:

  • which repositories call or duplicate a changed interface;
  • where a shared dependency creates circular or high-risk coupling;
  • which consolidation candidates need human review.

For structure inside one repository, use Scenario 11. For a broad source migration, use Scenario 13.

Prerequisites and scope

Prepare the Python environment and local configuration using the CLI guide and the programmatic guide. You need an accepted reviewer task, a current project CPG, the required graph services, and a configured LLM. Record the intended repositories and their revisions before comparing results.

Run the Python file from the workspace directory containing the intended repositories. For the invocation below, the scenario discovers Git repositories in that directory’s immediate subdirectories. For example, a workspace containing billing-service and billing-client includes both repositories in discovery. Record the workspace directory and compare the discovered list with the selected analysis scope.

First import the intended repositories. The scenario collects method and line counts for each discovered repository from the existing graph. It matches the repository name against the start of each file path in the CPG. If the method count is zero, compare graph paths with repository paths and check the import result.

Run the typed scenario

Save the example as a Python file in the configured environment and run it from the selected workspace directory. The src package must be accessible in that environment, as described in the programmatic guide. Replace the context placeholders with your accepted task, project, namespace, evidence references and source paths. Adapt the query to the actual interface, then invoke the reviewer-owned scenario:

from src.digital_employees.runtime.scenarios import (
    RoleBoundScenarioInvocationRequest,
    invoke_role_bound_scenario_request,
)

request = RoleBoundScenarioInvocationRequest(
    query="Identify cross-repository dependencies affected by changing BillingClient.",
    employee_id="codegraph_reviewer",
    scenario_id="scenario_10",
    event_type="review_start",
    context={
        "project_key": "codegraph",
        "namespace": "default",
        "task_id": "<task-id>",
        "source_refs": ["<revision-manifest-ref>"],
        "file_paths": ["<bounded-source-path>"],
    },
)
result = invoke_role_bound_scenario_request(request)
if result.get("error"):
    raise RuntimeError(result["error"])
if not result.get("scenario_id") or not result.get("answer"):
    raise RuntimeError("Scenario returned no scenario identity or answer")
print(result["answer"])

Scenario 10 uses the typed role-bound request as its public entry point. The request carries the role, event, and task evidence for the cross-repository analysis.

Read the result

Keep these fields with the review evidence:

  • answer: the synthesized explanation;
  • evidence: dependency, duplication, and circular-dependency observations;
  • metadata.role_bound_scenario_invocation: employee, event, workflow, and preflight evidence;
  • the workspace and repository revision manifest captured before the run.

Verify important claims in the named repository and revision. A similarity or dependency observation creates a review lead; compatibility follows from the comparison and the accountable decision.

Plan consolidation

Use the dependencies and similar implementations to select consolidation candidates. Compare their interfaces, behavior, and tests. Agree on changes with the owners of the affected repositories and retain the plan with the analysis result.

Failure and recovery

  • The list contains only the current directory .: check that the intended Git repositories are immediate subdirectories of the workspace. Run the example file from that workspace and compare the returned list with the selected scope.
  • Stale or mixed results: refresh the intended repositories, rerun against the same revisions, and replace the old evidence with the new revision-bound package.
  • Invocation fails: read the error message, check CPG availability, and retain details of the unavailable source. After restoring access, repeat the request over the same scope.
  • Unexpected repositories discovered: preserve the returned repository list, correct the workspace boundary, and repeat the analysis.
Report a documentation issue