Show & tell: Threshold, a project-rooted harness built on Pi

[Key-of-door]

Hi everyone, I’m building Threshold, a local harness for continuing software projects across independent Pi sessions.
The idea is to keep the project around while letting the workers change. One Run can do part of a task, leave a checkpoint and messages, then a fresh Run can inspect the current project and pick up the work. It doesn’t need the previous worker’s conversation copied into its context.
Threshold organizes this as Project → Task → Run:

• A Project points to your repository
• A Task holds the work instructions, checkpoint, and messages
• A Run is one Pi worker working on that task
  For example, one Run might implement and test a parser change, while another picks up the remaining CLI work. The new worker reads the task state and is instructed to check the actual files, Git state, and relevant evidence before continuing. Messages and checkpoints are references to verify, rather than instructions it must agree with.
  Pi handles agent execution, Git holds the code, and SQLite stores the project records. Runs are independent peers. The core doesn’t assign a permanent leader or prescribe a workflow; an optional scheduler can coordinate ordinary Runs in separate worktrees. Ending that coordinating Run doesn’t stop the others.
  There’s a CLI and a TUI. Skills and Pi extensions are selected per Run, so one worker can use a reviewer skill or GitHub reader without the next worker automatically inheriting them. The basic workflow doesn’t require these extras.
  It’s currently alpha.7, intended for one machine and a trusted local user. The README has installation steps and short demos, and the capability repository has optional tools and experiment writeups.
  If you give it a try, I’d be interested in where the handoff feels awkward, or what a fresh worker is missing when it picks up a task.