docs: standardize isolated LLM worktrees (#38)

This commit is contained in:
2026-07-02 02:42:52 -04:00
parent 69d4edf37d
commit 7e8256cfaf
3 changed files with 121 additions and 3 deletions
+60 -3
View File
@@ -161,6 +161,62 @@ Legacy environment-only setups keep working unchanged until migrated.
Each runbook names the **profile role** it runs under, the steps, and a safe
prompt. Confirm the active profile first (`gitea_get_profile` / `gitea_whoami`).
## Branch worktree isolation
All LLM implementation and review work happens in an isolated branch worktree
under `branches/`. The main repository checkout is an orchestration checkout:
use it for status checks, issue creation/claiming, and creating worktrees, but
do not edit tracked repository files there.
Branch folders are ignored by git via `branches/`, so dirty work in one issue
does not block starting an unrelated issue in a separate branch folder. No LLM
may edit another issue's branch folder unless explicitly assigned to that issue.
No LLM may clean another issue's branch folder unless the PR is merged or closed
and cleanup is explicitly part of the task.
Implementation work and review work must use separate branch folders. For
example, an implementation branch might live under
`branches/fix-issue-123-example`, while a review branch for the resulting PR
uses its own folder.
Issue creation and claiming may happen from the orchestration checkout:
1. Create or identify the tracking issue.
2. Claim it with `status:in-progress`.
3. Create the issue branch worktree.
4. `cd` into the branch worktree and perform all file edits there.
Preferred helper:
```bash
scripts/worktree-start fix/issue-123-example
cd branches/fix-issue-123-example
```
Because `venv/` is ignored and not copied into new worktrees, run checks with a
known Python interpreter. Either create a venv inside the branch folder, or use
the orchestration checkout's venv by explicit path.
Equivalent manual commands:
```bash
git fetch prgs --prune
git worktree add -b fix/issue-123-example branches/fix-issue-123-example prgs/master
cd branches/fix-issue-123-example
```
For review work, create a separate review worktree/folder instead of reusing the
author's implementation folder.
Cleanup is explicit and only after merge or close:
```bash
cd <main-repo>
git fetch prgs --prune
git worktree remove branches/fix-issue-123-example
git branch -d fix/issue-123-example
```
### Create an issue / child issues
- **Profile:** issue-manager or author (any profile allowed to create issues).
@@ -172,9 +228,10 @@ prompt. Confirm the active profile first (`gitea_get_profile` / `gitea_whoami`).
### Implement an issue and open a PR
- **Profile:** author.
- **Steps:** claim the issue (`status:in-progress`); branch from latest
`master` (`feat/issue-<n>-...` / `fix/...` / `docs/...`); implement narrowly;
add/update tests if behavior changes; run the full suite; commit with an
- **Steps:** claim the issue (`status:in-progress`); create an isolated branch
worktree from latest `master` under `branches/` (`feat/issue-<n>-...` /
`fix/...` / `docs/...`); `cd` into that worktree; implement narrowly; add or
update tests if behavior changes; run the full suite; commit with an
issue-linked message; open a PR to `master`. **Do not** review or merge your
own PR.
- **Prompt:** `Use an author profile to implement issue #N and open a PR to