Stacking Features and Recording Them in the Tree — Plus the Season Concept

Now that MCP is connected, it’s time to weave Umtri into your actual development flow. In this post, we’ll cover the routine of leaving a record in the tree every time you add a feature, and the Season concept for dividing up a project’s growth cycle. We’ll keep using the bookmark app as our example.

One thing before we start — an Umtri tree grows inside a season. If all you did last time was create a ground, there’s nowhere for your nodes to be planted yet, so add your first season over at app.umtri.io. We’ll get to seasons properly further down.

Leaving a Trail in the Tree as Features Pile Up

As you add features one at a time with vibe coding, the code gets more complex, and at some point even the AI struggles to grasp the whole context at once. The way to solve this is to leave a record in the Umtri tree every time you add a feature.

The record itself doesn’t need to be complicated. If you created a new component, adding a single leaf node to the Umtri tree is enough.

With MCP connected, ask Claude Code something like this:

I finished adding the tag feature.
Please update the bookmark-app ground tree in Umtri with the following:

- TagFilter component → add as a leaf under the BookmarkList twig
  (implemented in src/components/TagFilter.jsx)
- AddForm now has a tag input, so update the AddForm leaf's description
- localStorage now has a tags array, so update the storage.js leaf's description too

For each node, also record which files implemented it under implements.

Recording “the files that made this node”

That last line looks minor, but it matters. Every Umtri node has a slot called metadata.implements that holds the list of files that actually implemented it. Naming a node TagFilter doesn’t make Umtri go find TagFilter.jsx on its own. Someone has to write it down.

That one line is what makes two later things possible.

Commits attach themselves to nodes. The commit logging we’ll cover in the next post works by matching the files a commit changed against these implements lists, and adding the commit to the history of the nodes that match. A node with no files recorded never picks up a single commit.
Plan nodes can be committed. In Plan mode, described just below, a node with an empty implements is refused outright when you try to promote it.

So make “and record the implementing files too” a habit, and your tree stays genuinely wired to your code.

There’s a Reverse Order Too — Plan Mode

So far the order has been “write the code, then record it in the tree.” The flow Umtri actually intends is the opposite: draw it first, commit it later.

In the app, use Plan mode to sketch the nodes you’re about to build as drafts (plan nodes).
Ask Claude Code to “read the plan nodes and realize them.”
Claude Code reads the tree and treats each plan node as a kind of work brief while writing the code.
It records the files it wrote into that node’s implements, then promotes (commits) the node into the real tree.

Read the nodes that are in plan state in Umtri bookmark-app.
Write the code for them, and when it's done, record the files you
implemented under implements and commit the plans.

When you want to design the structure up front, this direction is better; when your hands have already run ahead, record after the fact using the earlier approach. Either way you end up in the same place — a tree wired to files.

Once you’ve recorded this, the next time you want to add a feature you can do this:

Pull up the bookmark-app tree from Umtri.
I want to add a search feature — suggest where it should go given the current structure.

Claude Code reads the current tree structure, figures out which components the search feature would relate to and where it should live, and then makes a suggestion. It grasps the whole context from the tree structure alone, without needing to open every code file.

Using the Season Concept

Umtri has a concept called Season — a unit that divides up the “chapters” of a project’s growth. Think of it as a version, a phase, or a period. Just like the seasons in nature, a project also grows in stages.

How you divide seasons is entirely up to you. For example, you could split it like this:

Season	Content
Season 1	Core features (save/delete bookmarks)
Season 2	Tag and search features added
Season 3	Deployment and sharing features

Of all your seasons, exactly one is now and the rest are past. Adding a new season seals whatever was now into the past and opens a fresh season to keep planting in. So adding a season is closer to drawing a line and saying “that was one stage” than to filing things into buckets.

Time Lives in the Slider

The structure spreading up and down the tree view is space — higher doesn’t mean newer. Time is held separately, in the season slider at the bottom of the screen.

Drag the slider backward and branches and leaves sprout and fall according to when each node came into being and when it went away. From the pre-planting (PRE) state through each season’s events, you can retrace exactly what order the project grew in. When “why did the structure change to this?” comes up later, this is where you go looking.

Seasons Are Made by People

One thing worth knowing — AI can’t create a season. Umtri’s MCP has no tool for it at all. Asking Claude Code to “open a new season” leaves it with nothing it can do.

That’s deliberate. Planting and editing nodes is work, but drawing the line that says “that was one season” is a judgment call. So adding seasons — and finishing off a ground by rooting it — is left to people, in the app.

Practical Tip: A Routine for Adding Features

Here’s a routine worth repeating every time you add a feature.

1. Before you start: check the current structure

Pull up the bookmark-app tree from Umtri and summarize the current structure.

2. Write code: request one feature at a time

Break the feature into small pieces and request them in order.

3. Verify it works

Check directly in the browser that the newly added feature works correctly.

4. Record it: update the Umtri tree

Please update the Umtri tree with [what you added].
Record the files you implemented under implements as well.

5. When a stage wraps up: close out the season

Once you judge that a chunk of work is done, add a new season in the app. This part is yours to do.

Repeating this routine keeps the structure from getting blurry no matter how many features you add. Every time you start a new task, you can always start with a clear picture of exactly how far you’ve gotten.

Coming Up Next

In the next post, we’ll cover how to record post-development events — deployments, refactoring, and bugs — in Umtri: auto-logging deploys with GitHub Actions, syncing the tree after refactoring, and mapping a bug’s scope of impact through the tree.