Recording as You Build — Plans, Saves and Bugs

Once the tree is planted, the real work begins. A tree isn’t a picture you draw once; it’s only useful if it grows along with the project. This part covers three things you’ll do every day.

Before building: draw the plan on the tree first
After building: leave a record on the tree
When something breaks: register a bug and see how far it reaches

1. Before building: draw the plan on the tree first

Umtri has Plan Mode. Branches and leaves drawn in plan mode are shown as plans that haven’t been built yet. They aren’t recorded, so you can change them as many times as you like.

Open the demo and turn on plan mode. On the server trunk there’s a Notifications branch (tell customers when their order is ready) drawn as a plan — the next feature, sketched ahead of time.

Have the AI draw the plan

When you ask for a new feature, try having the AI draw a plan first instead of building right away.

I want to notify customers when their coffee is ready.
Don't build it yet — draw it on the coffee-app tree as a plan first.
Show me which branches and leaves will appear under which trunk.

Seeing the AI’s plan on screen tells you at a glance whether it understood you. It’s much faster than reading a long explanation. If something looks off, just ask for a fix:

Notifications belong to the customer app, not the admin screen. Redraw the plan.

Hand your own plan to the AI

It works the other way too: draw the plan yourself in the app and hand it to the AI. In plan mode, click a branch and use Add Plan Node to add a leaf.

Read the Notifications branch I drew as a plan on the coffee-app tree and build it as drawn.
When you're done, write the file path on each leaf and commit the plan.

Committing a plan makes that branch a real part of the tree. A leaf needs an actual file written on it before it can be committed. That keeps branches that were only planned, never built, out of your tree.

2. After building: leave a record on the tree

When a feature is done, the tree should follow.

Add the coupon feature I just built to the coffee-app tree. Include the file paths.

The same goes for moving or renaming files while tidying up the code.

I just moved the payment files into a payments folder. Update the file paths on the tree to match.

I removed the order history screen. Clean it up on the tree too.

On a tree that has taken root, deleting a branch still leaves a trace. Replay it with the time slider later and you’ll see “there was a branch here, and then it went away.”

Attach a record every time you save your work

Saving your work once with git is called a commit. If you tell Umtri about each commit, every leaf whose file changed in that commit gets a note: “this is how it changed that day.” Click a leaf later and you’ll see when and how that part changed over time.

Record the commit I just made in Umtri too.

Tired of saying it every time? Make it a rule for the AI

Saying “add it to the tree” and “record the commit” every time gets old. Most AI tools read a rules file in your project folder first (CLAUDE.md for Claude Code, AGENTS.md for Codex). Write the rule there and the AI takes care of it.

Umtri comes with a ready-made version of this rule, so all you need to say is:

Add the Umtri commit-sync rule to this project's CLAUDE.md.

After that, the AI checks on its own before every commit:

A new feature appeared → it adds a branch or leaf to the tree.
Files moved → it fixes the file paths on the tree.
This work fixed a bug → it marks the bug as Resolved.
And last, it records the commit.

When something is unclear, the AI asks you. One question is better than a wrong branch.

3. When something breaks: register a bug and see how far it reaches

Connect the parts first

To know that “if this breaks, that breaks too,” the tree needs to say how parts are connected. There are two kinds of connection.

Dependency (Edge): one part leans on another. e.g. the order feature leans on the order storage.
API: one part calls another. e.g. the checkout screen calls the server’s “create order.”

You don’t have to draw them yourself.

Look at the coffee-app tree and connect the parts that lean on or call each other in the code.

Connections are hidden by default. Turn on API and Edge under Layers in the sidebar to see them.

See how far it reaches

Click a leaf on the tree and press Show impact: only the places affected if that leaf breaks stay bright, and everything else fades. Try the order storage (orders) in the demo. You’ll see the impact run through the server that handles orders, payments, and the sales chart on the admin screen.

You can also ask the AI:

I'm about to change checkout in coffee-app. What else should I check if I change it?

An empty impact doesn’t mean “no impact.” It means “no connections written down yet.” Add the connections first.

Register a bug

When you find a problem, register it as a bug. Bugs show up as red dots at their spot on the tree.

Register a bug in coffee-app: retrying a payment applies the coupon twice.
Also figure out which part is at fault and how serious it is.

When the AI registers the bug, it also tells you what else needs checking because of it (the impact).

Every bug gets a risk score from 0 to 8, combining “how big a problem is it” with “how hard is it to fix.”

Score	Meaning
0–1	A note or a wording fix. Nothing broken
2	Awkward to use
3–4	A minor feature problem
5–6	A major feature problem
7–8	A critical problem

Within each row, the harder it is to fix, the higher the number. The AI suggests a score, but if you see it differently, just ask for a change.

Fix a bug

Every bug gets a number like #1 or #2. Calling it by number is handy.

Look at bug #1 and fix it.
Mark it "Chasing" when you start, then "Resolved" when you're done, and write down what you actually did.

A bug moves from Wild → Chasing → Resolved. “Chasing” means “someone is already on this bug,” so it’s best to switch it the moment you start. It stops an AI in another chat, or a teammate, from grabbing the same bug twice.

And writing down what you actually did matters. When something similar happens months later, this is the first place you’ll look.

Today’s routine

When	Say this
Starting a new feature	”Don’t build it yet — draw it on the tree as a plan first”
The plan looks good	”Build it as planned, and commit the plan when you’re done”
You tidied up files	”Update the file paths on the tree too”
You found a problem	”Register it as a bug and tell me the impact”
Just once	”Add the Umtri commit-sync rule to CLAUDE.md”

The last part covers what all these records do for you months later, and how to keep what the tree can’t hold — “why we built it this way” — in the wiki.