v1.5.0 · August 17, 2026

Two agents, one repo: concurrent instances via git worktrees

AIDLC could only do one thing at a time. Start a feature and the next idea waited. The work did not conflict. The framework simply had one working directory, one checked-out branch and one place to keep an instance's state, so two agents in the same repository would write over each other's files.

What changed

Each instance can now get its own git worktree, which means its own directory and its own branch. aidlc start takes --worktree and --no-code, aidlc status --prune cleans up, and there is a new concurrency: block in the config. Nothing breaks for existing projects: old claims migrate transparently, with a fallback if they cannot.

The interesting part was the bookkeeping, not the worktrees. I started from the assumption that .aidlc/state/ was scratch data I could move into git's shared internals. It is not. In this repository it is tracked and committed on purpose, because those artifacts are the record the lifecycle exists to produce. They show up in pull requests and survive a re-clone.

So the real job was narrower. Some state is a durable artifact that belongs to a branch and stays in git. Other state is live coordination, like who holds an instance right now, which means nothing per branch and must be visible from every worktree at once.

Why this way

I split by meaning, in the smallest form that works. Artifacts stay tracked per branch. Claims, and only claims, move to git's common directory, shared by every worktree. The session log stays tracked, because cost attribution reads its history and moving it would lose that history on a re-clone. The cost stash already found its identity through that common directory, so the mechanism had precedent.

Putting everything in the shared directory was the tempting option. It would have untracked state this repo deliberately commits. Keeping everything tracked fails the other way: a claim made on one branch is invisible from another.

The worktree is created when the instance starts, not later. If I waited until implementation, early files would land in whatever branch happened to be checked out in the primary directory, and git worktree add does not carry uncommitted files over. Isolation has to begin before the first write, not before the first line of code.

For stale claims I reused the existing claim timeout rather than add a second one.

What it costs

Claims leave the instance file, so that is a schema change. An instance's existence is still per branch. And a claim cannot be declared stale until renewing it is a defined duty, which it was not when this started. I handed that gap to the requirements step instead of guessing.

$ aidlc start full-feature --name dark-mode
✓ instance created: dark-mode
✓ branch: feat/20260821-dark-mode
→ phase: ideation▊

name: dark-mode
template: full-feature
current_phase: ideation
scope: full