Analyze legacy code

Analyze the old order system (Java · DDL) that Hanbit Delivery uses today into a code graph and a data schema, then design a new feature, “order rejection reasons”, as a proposal grounded in that graph. Claude Code on your computer does both the analysis and the design, so no OpenAI key is needed.

Designing from an old system#

So far you've designed by putting requirements into an empty project. Real work is usually changing or rebuilding a system that's already running. The most expensive mistake then is to design the new one without knowing the business rules the old system already enforces. Rules like “only orders waiting for acceptance can be rejected” or “closing the store rejects all waiting orders at once” aren't in any document. They're only in the code.

This chapter has two parts.

The practice code#

Download hanbit-legacy.zip and unzip it (it unzips into a hanbit-legacy folder). It's the old order system Hanbit Delivery has used since 2016: Java 8 + JDBC, with the PostgreSQL schema delivery you connected in Chapter 11 as its DB.

Order status goes WAITING → ACCEPTED → COOKING → DELIVERING → DELIVERED, and can end as CANCELLED or REJECTED along the way. When an order is rejected, the reason isn't stored anywhere. That's what you'll fix in Part 2.

Hands-on 1 — Create the project#

1. In the project bar on Home, click Switch project, type hanbit_legacy_en in the New project field, and click Create.
2. For the code folder, click Choose folder…, choose the unzipped hanbit-legacy folder, and click Open project. (In the screenshots the folder is named hanbit-legacy-en. The folder name doesn't matter.)

Hands-on 2 — Start the analysis#

1. On Home, open the Legacy · Data Sources card. Code on the rail shows the code folder's file tree (click a file to preview it on the right).
2. Click Start analysis at the bottom. If there's an earlier analysis, it asks whether to delete it and start over. Continue.

The analysis runs in seven stages: DDL parsing · Source loading · Project scan · Relationship linking · Analysis context setup · Code analysis · Post-processing. The first four parse the code and link classes · methods · tables with the calls · reads · writes between them. In Code analysis, the AI writes what each method does, its business rules and examples. The screen soon moves to the Code graph, and a progress window shows the stage and the number of nodes and relations. In this tutorial it took 141 seconds (about 2 minutes 20 seconds).

Hands-on 3 — Read the code graph#

When the analysis finishes, the NAVIGATOR on the left becomes a package › class › method tree. In this tutorial there were 6 classes, 18 methods and 7 tables (32 columns), linked by 23 places where methods read or write tables and 46 calls.

1. In the tree, expand order › OrderService. Double-click a method name to put it on the canvas. Put placeOrder · acceptOrder · rejectOrder · startCooking · cancelOrder · changeStatus on it. The Calls lines show that accepting, rejecting and starting cooking all go through changeStatus (cancelling runs its own update, limited to the customer's own order).
2. Click rejectOrder once in the tree, and its details open on the right: Logical name “Store order rejection”, Role Command, then OVERVIEW, BUSINESS RULE, SOURCE CODE and CONNECT.

The BUSINESS RULE section is the core material of this chapter. Each rule the code actually enforces is written as one sentence with Examples (Given · When · Then).

Open StoreService.close (logical name “Store closing with waiting order rejection”) and you'll find rules like “When a store is closed, every order of that store whose status is 'WAITING' is changed to status 'REJECTED'; orders in any other status are left unchanged.” and “After both updates, the changes are committed in one transaction and the number of orders rejected is returned; if the store has no 'WAITING' orders, 0 is returned.” These facts weren't in any document. They came out of the code.

Hands-on 4 — The data schema#

Click Data schema on the rail, and the left side lists the 7 tables read from the DDL (default › delivery). Double-click a table name to put it on the canvas. With Logical name turned on, tables show as “Orders” · “Store” · “Order item” · “Menu”, and columns show as the descriptions the code analysis wrote.

The data schema was empty when you only registered the data source in Chapter 11. Now the DDL and the code analysis have filled it. Column descriptions come from how the code uses the column, for example the order ID is “used in update conditions to select the specific order to change, such as for status transitions and cancellation”.

Hands-on 5 — Design a new feature from legacy evidence#

Now you use the analysis graph as evidence for the design. The new feature is “order rejection reasons”. The old system rejects orders but never records why.

1. In the same hanbit_legacy_en project, open the Proposals card and click + New Proposal.
2. Type the following requirement and click Start AI Analysis.

Hanbit Delivery: When a store owner rejects an incoming order, they pick one reason (out of ingredients, closed for the day, or other). Customers see the rejected order's status together with that reason. When closing the store rejects all waiting orders at once, the reason must be recorded too.

The progress window shows a difference from Chapters 3 and 12. The INTENT skill searches the legacy graph for each business axis (Searching the legacy graph: …, “→ 11 legacy candidates · 3 rules found”), and opens the useful candidates down to their source code with Inspecting legacy node: …: rejectOrder · StoreService.close · changeStatus · the orders table. In this tutorial it took 161 seconds (about 2 minutes 40 seconds).

Click View Proposal, and the header sums up the evidence: Legacy evidence 15, Evidence 11/11. That means all 11 elements (2 bounded contexts · 3 features · 4 user stories · 2 processes) have evidence somewhere in the old code. The tag on each element (🔗 2) is that element's evidence count.

Click a tag, and that element's evidence opens. The process “Order Rejection with Reason” has two pieces of evidence.

Evidence shows up in the acceptance criteria too. “Store owner: Reject an incoming order with one reason” has “Given an order that is no longer waiting (for example already accepted), When I try to reject it, Then the rejection is refused with 'Only waiting orders can be rejected' and neither the status nor any reason is recorded”. That's rejectOrder's rule, down to its exact message. The next criterion, an order of a different store is refused and left unchanged, comes from changeStatus only updating the given store's orders. In “Store owner: Waiting orders are rejected with reason 'Closed for the day' when the store closes”, the other order “keeps its status with no rejection reason”, and “the store closing and every rejection with its reason are recorded together”. Both follow the StoreService.close rules (only 'WAITING' orders, one transaction). And in “Store owner: Close the store for the day”, “I am told that 3 orders were rejected” (0 when there are none) comes from close returning the number of rejected orders. None of these were in the requirement sentence.

The Legacy evidence panel on the right of the Impact Map section groups the evidence by old code (in this tutorial, 8 cited · 7 searched). Hover over a card to see wires to the requirements that cite it. Click it to see the source and the elements citing it.

Like PRO-001 in Chapter 3, this proposal continues from Proceed to Plan → to the constitution, the plan and the implementation. The skills of the plan and implementation stages reuse the same evidence. They don't search again for source code they've already opened.

What to check#

• The Legacy › Code graph tree has order › OrderService › rejectOrder, and its details show a business rule with examples.
• The data schema has 7 tables (delivery).
• The “order rejection reasons” proposal has “Evidence n/m” in its header, and clicking an element's tag shows the source code (file : line).

Quiz#

1. Where do business rules and examples come from, documents or code?
2. What does “Evidence 11/11” mean? If you get 0/11, what do you check first?
3. What's the difference between “Source-inspected” and “Search-confirmed” evidence?
4. The acceptance criterion “I am told that 3 orders were rejected” wasn't in the requirement sentence. Where did it come from?