Parallel thread handoff#

The repository has an implemented strict workspace, quality tooling, maintained examples and a reporting UI prototype. Select the base from the current issue and verified implementation handoffs, not a historical universal planning branch.

Before dividing work, read AFK implementation, reliable development, and parallel T3 worktrees.

Ownership#

Use live issue assignment and native dependencies to choose work. Claim the issue before editing, and give each thread a distinct branch/worktree with disjoint task ownership. Track shared-file changes and coordinate exact prerequisite commits before integrating. An assignment to the same developer does not distinguish two threads. After assignment, run pnpm workflow:claim <issue> <thread-id> and pnpm workflow:ready <issue> <thread-id>. Atomic claims in the shared Git directory reject competing local worktrees, branches and sessions. Reuse the stable thread ID when resuming the same worktree; command exit does not expire ownership. The claim command announces ownership on the issue; it reserves ownership without certifying prerequisite readiness. Open blockers still require the documented exact-commit stacking procedure before implementation. Across machines or independent clones, inspect those live announcements before claiming; the local registry is not a distributed lock. Run pnpm workflow:release <issue> <thread-id> when deliberately handing off or abandoning ownership; it requires the original owner and publishes the release. Claims are never stolen automatically after a timeout or process exit. Registry changes also hold a short operation lock; if interrupted, inspect the printed owner record and use pnpm workflow:claim-unlock <owner-token> only for a dead process. This recovers the registry operation, preserving the task claims.

The foundation backlog owns the remaining version, CI, Pages, and contribution-documentation tasks. The reliability implementation owns the initial workflow safeguards and parallel browser helpers. Read their live scope and prerequisites rather than copying old lane prompts.

Product decisions remain under the product roadmap. Human-led report-model and prototype decisions require their own recorded resolutions; an illustrative UI is not a substitute.

Worktree runtime#

Run pnpm worktree:setup in each worktree after selecting the pinned toolchain. Start the owned dev server with pnpm dev:examples or pnpm prototype:theming. Use its printed URL in that thread's owned T3 preview tab. Stop the server before verification in the same worktree. Different worktrees can run concurrently; conflicting commands inside one worktree fail safely.

Every change needs the complete gate and observed browser evidence. Inspect server/build identity, keep run evidence separate, and follow the exact-commit stacking and handoff procedure. Integrate against the declared base and verify the combined result. Merge, release and deployment remain separately authorized actions.