mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-07 16:11:46 +02:00
DottaandPaperclip
4b968d8c05
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Paperclip can create a worktree and seed it with data from another instance. > - A full seed copied active runtime state and live process claims into the new database. > - The copied state could make the new instance restart or adopt services that belong to the source instance. > - A stale process identifier, port, or URL could then make the worktree page fail to load after a restart. > - This pull request makes cloned runtime state inactive before the new instance starts. > - The benefit is that each instance starts with clear service ownership and no stale live claims. ## Linked Issues or Issue Description - [x] I searched open and closed issues and pull requests. I found no duplicate report. **What happened?** `paperclipai worktree init --full` copied project and execution workspace runtime records without changing their active state. The new database could contain `running` desired state, `running` service state, and provider references that identify processes from the source instance. After a host restart, the cloned instance could try to recover services that it did not own. The browser then showed a load failure at a stale or moved service URL. **Expected behavior** A cloned database must not claim that source-instance runtime processes are live. Project and execution workspace services must start as stopped in the clone. An operator can start them explicitly after the clone is ready. **Steps to reproduce** 1. Start a managed worktree runtime in a source Paperclip instance. 2. Create a full worktree seed from that instance. 3. Start Paperclip with the seeded database. 4. Observe that the copied database can retain active desired state and live process, port, and URL claims. **Paperclip version or commit** Reproduced on `master` at `d1cd9c37f4`. **Deployment mode** Local development with managed worktree services. **Installation method** Built from source with pnpm. **Agent adapter(s) involved** Not adapter-specific. This is a core worktree seed bug. **Database mode** External PostgreSQL source data copied into the isolated worktree database. **Access context** Board operator. **Privacy checklist** I reviewed this description and removed private instance URLs, internal task identifiers, credentials, and user paths. ## What Changed - Stop cloned project and execution workspace runtime desired state during a full or minimal seed. - Change copied service states from `running` to `stopped`. - Clear copied process, provider, port, URL, owner, and starter claims. - Keep unrelated runtime metadata intact. - Add regression tests for project services, execution workspace services, unrelated metadata, and the live-work preservation option. - Document runtime quarantine in the worktree development guide. ## Verification - `pnpm exec vitest run cli/src/__tests__/worktree.test.ts` passes 43 tests. - `pnpm -r typecheck` passes. - `pnpm build` passes. - `pnpm test:run` passes 4,304 tests. One unrelated timing test timed out during the loaded run and passed alone. Ten unrelated exposure tests could not use their fixed ports because host Tailscale listeners already owned ports 42000 and 52000. - A managed worktree restart completes with a healthy source runtime and one authoritative service owner. - An authenticated clone inspection shows the copied runtime as stopped with no live provider, process, port, or URL claim. ## Risks - A cloned service no longer starts only because the source service was running. An operator must start the cloned service explicitly. This is the intended ownership boundary. - `--preserve-live-work` keeps the old behavior for operators who explicitly request live runtime state. - The change does not alter schema or source-instance runtime records. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used OpenAI Codex with GPT-5. The runtime does not expose a more specific deployment ID or context-window size. The model used high-reasoning mode, repository tools, code execution, and GitHub review tools. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>