We have talked about worktrees for a while, but the more important idea is not the worktree itself.

It is the thread.

That distinction matters because a lot of developer tooling exposes its implementation detail as the user experience. You end up managing raw mechanics instead of the thing you actually care about.

For limerIQ, that would have been a mistake.

Git worktrees are how we isolate filesystem changes. They are not the mental model we want users to carry around all day.

The mental model we want is:

this is one run, one context, one thread of work.

Why the Thread Model Is Better

The new thread system is built around a deliberately simple rule:

one thread owns one primary controller workspace and can attach additional repo worktrees over time.

That does a few important things at once.

First, it keeps the common case simple. If you are working in one repo, the thread is still just the thread.

Second, it lets multi-repo execution stay coherent. If the workflow reaches into another repo through repo scopes or workflow switching, that repo can attach to the same thread instead of becoming a separate limerIQ universe.

Third, it gives the runtime a real ownership boundary. Cleanup, reuse, and inspection can all be driven from the thread manifest instead of inferred from whatever weird path shape happens to exist on disk.

That last point is less glamorous, but it is what makes the system trustworthy.

Worktrees Are Still the Right Primitive

None of this replaces worktrees. It clarifies them.

Git worktrees are still the right implementation primitive for isolated execution because they let limerIQ:

• run multiple workflows simultaneously without shared mutable state
• isolate filesystem changes per run
• preserve a clean basis for inspection and cleanup
• reuse attached repo worktrees when a thread comes back to the same scope

The key is that users should not have to think in raw worktree mechanics every time a workflow branches or touches another repository.

The product should manage that complexity for them.

One Thread, Not Ten Windows

Another deliberate choice in the new model is that a thread stays a single control surface.

If a workflow touches repo B or repo C, limerIQ can attach those repo worktrees to the thread without opening a new controller window for each one.

That is an important product call.

A naive multi-repo UX would explode into a mess of windows, sessions, and unclear ownership. It would make a coherent flow feel fragmented.

Instead, limerIQ keeps the thread as the primary object and treats attached repos as part of that same thread context. You can inspect them, open them manually when useful, and see their paths. But the workflow still feels like one piece of work moving through one lifecycle.

That is much closer to how people actually think about delivery.

Cleanup Has To Be Manifest-Driven

One of the ugly truths about any worktree-heavy system is that cleanup can get sloppy fast.

That is why the thread manifest matters so much in the new architecture.

The manifest is the system of record for thread membership. It owns:

• the thread ID
• the primary workspace
• the attached repos
• the per-repo worktree paths
• the ownership boundary for cleanup

That means deleting a thread is not "best effort remove the main thing and hope the rest is fine." It means cleaning up every worktree recorded in the manifest.

That is the kind of boring rigor that separates a real execution layer from a cool demo with residue.

Why This Matters for Parallel Work

Threads are not only about multi-repo orchestration. They also make concurrency more usable.

The old failure mode for concurrent AI work is familiar:

• shared workspace
• hidden collisions
• manual cleanup
• unclear state when something fails halfway through

The thread plus worktree model fixes that by giving each run its own isolated execution context. You can have multiple single-repo or multi-repo workflows in flight at once without letting them trample each other.

That is especially important once limerIQ moves beyond individual interactive use and into team workflows, CI triage, PR guard flows, and unattended execution.

Concurrency stops being a novelty and becomes table stakes.

This Is Also a UI Story

There is a product design lesson in this feature too.

The right abstraction matters.

Users do not actually want to manage low-level worktree topology. They want to understand:

• what thread am I in?
• what repos are attached?
• where is the work happening?
• what gets cleaned up if I end this run?

That is why Threads is the public concept. It is the right unit of meaning.

Worktrees are still there, still important, still doing real technical work. They are just no longer forced to carry the entire product story on their backs.

Why This Fits the New Positioning

If limerIQ is going to be the governed execution layer for AI-native software delivery, it has to handle the messy reality of concurrent, isolated, cross-repo work without making that mess the user's problem.

That is what Threads does.

It gives limerIQ a stable execution object for isolation, continuity, reuse, and cleanup. It makes multi-repo work understandable. It lets multiple workflows run at once. And it keeps the product surface aligned with how delivery work actually feels from the human side.

One thread.
One piece of work.
Many isolated worktrees underneath.

That is the right stack.