Fixer-Judge architecture

Role: Act as a Principal Software Architect specializing in Agentic Workflows, Java Systems, and Graph Theory.

The Scenario: I am building a Self-Healing AI Agent to resolve Liquibase XML dependency cycles in a massive Java/Maven monolithic application. The project contains thousands of Liquibase changelog files.

The Problem: We frequently encounter build failures because the master.xml file (which includes other changelogs) is not ordered correctly. For example, File A is loaded before File B, but File A adds a foreign key to a table defined in File B.

Strict Constraints (The "Rules of Engagement"):

Scope of Fix: The agent is strictly prohibited from modifying the content of the individual changelog files (no splitting files, no moving changesets). It can ONLY change the sequence of <include file="..."> tags within the master.xml file.

Limited Context: The project is too large to fit all XML files into an LLM's context window. We cannot parse the entire project upfront.

Step Budget: The agent operates under a strict "step limit" (e.g., max 15 build attempts). It cannot rely on random permutations or infinite retry loops.

Failure Condition: If a logical cycle exists (e.g., A needs B, and B needs A), the agent must detect this deadlock deterministically, stop immediately, and report that manual intervention is required.

My Proposed Architecture: "The Log-Driven Detective" I am proposing a hybrid approach using LangGraph (for the control loop) and JGraphT (for the logic), rather than a pure GenAI approach.

Strategy: "Lazy Graph Building." We start with an empty graph. We run the Maven build. When it fails, we parse the log to identify the specific missing resource (e.g., "Table X not found"). We find the file defining Table X, add a directed edge to our graph, and re-sort.

The Brain: We use JGraphT (a Java Graph Library) to store the dependency graph, detect cycles, and perform Topological Sorts. The LLM is used only to parse logs and find file references.

My Questions for You:

Architecture Validation: Given the constraints (specifically the "Limited Context" and "Step Budget"), is this "Log-Driven JGraphT" approach the most suitable architecture? Why or why not?

LangGraph Design: Please outline the specific Nodes (e.g., BuildRunner, LogAnalyzer, ConstraintSolver) and Edges required to implement this in a LangGraph state machine.

State Schema: Define the data structure (State) that must be passed between these nodes. What specifically needs to be persisted to ensure we don't regress or loop?

The "Solver" Logic: Explain how the ConstraintSolver node should utilize JGraphT to generate the new master.xml order while respecting the "Cycle Detection" constraint.