Problem
Tasks and worktrees are folders living in the coordination root. The individual branches inside a worktree can be persisted to GitHub/GitLab, and onboarding memory persists in memory repos — but tasks and the worktree wrapper contracts have no equivalent persistence method.
They can't live in a memory repo either: a memory repo binds its content to one code repository, which recreates the same problem the save-gate landing zones surfaced — where do you save repo-neutral or multi-repo work, and how do you retrieve it later?
Concrete symptoms (2026-06-11):
- No way to move tasks across machines — carrying the browser-dashboard pre-task notes between machines required a manual copy-out/copy-back dance through a memory repo, including hand-reconciling a rename that had landed in between.
- Task documents can't be shared between people today.
Proposal (backburner)
A neutral repo that holds both tasks and worktree wrapper contracts: a project/task-management persistence layer, separate from any single code repo's memory layer.
- Tasks and contracts get a durable, retrievable home independent of repo binding
- Cross-machine task transfer becomes push/pull instead of manual copying
- People can share task documents
- The contract enclosure — the lifecycle's identity anchor in the settled dashboard design — gains a persistence story that scales with multi-repo enclosures
Relation to existing design
The browser-dashboard note series (coordination task 260610_browser-dashboard) settled the lifecycle/contract-enclosure model and flagged save-gate landing zones (0_misc, 1_inter-repo-work) for repo-neutral and multi-repo work — that's local placement. This issue is the persistence and sharing substrate those zones would sync against.
Deliberately parked: this needs its own substrate to work and scale, and should not be solved ad hoc inside the dashboard series.
Problem
Tasks and worktrees are folders living in the coordination root. The individual branches inside a worktree can be persisted to GitHub/GitLab, and onboarding memory persists in memory repos — but tasks and the worktree wrapper contracts have no equivalent persistence method.
They can't live in a memory repo either: a memory repo binds its content to one code repository, which recreates the same problem the save-gate landing zones surfaced — where do you save repo-neutral or multi-repo work, and how do you retrieve it later?
Concrete symptoms (2026-06-11):
Proposal (backburner)
A neutral repo that holds both tasks and worktree wrapper contracts: a project/task-management persistence layer, separate from any single code repo's memory layer.
Relation to existing design
The browser-dashboard note series (coordination task
260610_browser-dashboard) settled the lifecycle/contract-enclosure model and flagged save-gate landing zones (0_misc,1_inter-repo-work) for repo-neutral and multi-repo work — that's local placement. This issue is the persistence and sharing substrate those zones would sync against.Deliberately parked: this needs its own substrate to work and scale, and should not be solved ad hoc inside the dashboard series.